sema: r391 per-page destination resolution for virtual fills - the r390 guest panic root cause

The 383620-byte context-init zero fill (FILL-NOREMAP class) resolved only
its FIRST page through the pin (va=0x7c36c7400000 -> pa=0x131b63000, the
pin stream's first run = 29 pages) and then wrote the whole 375 KiB
contiguously past it. The pin stream shows the VA's pages are independent
guest allocations with split runs (0x131b63000 / 0x131a80000 / 0x128340000),
so the contiguous write covered unrelated memory - on r390 exactly the
guest kernel's page-table pages 0x131ba1000/0x131ba2000/0x131bab000. The
direct map grew three 4 KiB holes and the guest died with 'Fatal exception
in interrupt' (unmap_page_range / cpuacct_account_field / psi_task_change
faults on physmap addresses).

svc_copy has always translated virtual operands per 4 KB page ('a linear PA
walk past the first page reads the wrong memory'); svc_fill never did.
New svc_fill_dst_page_pa() resolves every page of a virtual fill through
the same authority order (fresh pin wins and repairs the landing table,
then the landing table, then the resolver chain); the SYS write loop clamps
each chunk to the page boundary and writes at that page's own landing; a
page with no resolution fails the fill loudly (FILL-TRUNC) instead of
writing through a contiguous guess. The >= 64 KiB landing-table pre-store
now records only the contiguous VID (shadow) case; SYS landings are stored
per page as they are written.

Also extends the r384 page-table-shape refusal to every page of a virtual
zero fill (the r390 fill's first page was the client's buffer, so the
first-page-only check could not see the PTE pages it later covered).

Evidence: /tmp/opencode/r390-live.log (FILL-EXEC + sema-opadd lines),
/tmp/opencode/r390-guestram.raw (three zeroed PTE pages, CR3 walk),
pin log 12-pin_gr_stream-r390.log line 789 (the split runs).

0 files changed, 0 insertions, 0 deletions