From: Magnus Kulke <[email protected]> Sent: Wednesday, September 30, 2026 4:33 AM > > On Fri, Sep 25, 2026 at 04:23:15PM +0000, Michael Kelley wrote: > > From: Magnus Kulke <[email protected]> Sent: Thursday, > > September 17, 2026 1:11 PM > > > > > > hv_call_deposit_pages() donates pages (deposit) to hypervisor for L2 > > > guest on L1VH systems via HVCALL_DEPOSIT_MEMORY. The hypervisor takes > > > ownership of those pages and per contract revokes root partition > > > access to them, raising a #GP on access from the L1VH root partition. > > > > > > However, the pages remain mapped in the kernel direct map, so kernel > > > code may still access them even though the hypervisor has revoked > > > access. > > > > > > Helpers such as "load_unaligned_zeropad()" deliberately read past the > > > end of a buffer and across page boundaries. A read into an unmapped > > > page is tolerated and triggers a #PF, for which the kernel executed > > > > s/executed/executes/ > > ack > > > > > > a fixup in the exception table. > > > > > > If such a call steps into a page that has been deposited, the access > > > raises a #GP by the hypervisor from which the above handler cannot > > > recover and the kernel panics: > > > > > > Oops: general protection fault, maybe for address 0xff1100941a3dfffc > > > RIP: 0010:csum_partial+0xe5/0x110 > > > > Is there any possibility of updating the load_unaligned_zeropad() fixup > > handler to handle the #GP like #PF? I had looked at a variant of this > > problem a few years back for CoCo VMs. See the code comment above > > hv_vtom_clear_present(). In that case, a smarter load_unaligned_zeropad() > > fixup handler wasn't an option because these were #VC or #VE exceptions > > routed to the paravisor instead of the main Linux guest. But in your case, > > the Linux gets the #GP, so I wondered if a smarter fixup handler would be > > possible. Of course, both the x86 and arm64 versions would need updates. > > > > I wouldn't rule it out, but I found it daunting. We don't have a proper > faulting address ("maybe for address"). AFAIU, for a #PF the CR2 is > populated with the actual faulting address, so the fixup handler knows > that it is within the trailing bytes. For a #GP this page is hardcored > to 0, so we would have to have another sourcefor the actual fault > address. >
I went back and refreshed my memory on the discussion from July 2023. At least on x86, the faulting address is used only as a sanity check in ex_handler_zeropad(). The #GP exception handler already calls fixup_exception(), but it calls with fault_addr set to zero, so ex_handler_zeropad() always returns false (i.e., it says it can't do the fixup). From looking at the code, it appears the deposited pages case would "just work" if the sanity test against fault_addr was removed in ex_handler_zeropad(). There was a past discussion about removing the sanity test [1], but at the time there wasn't a strong reason for or against, so it was left in (having been added relatively recently in c4e34dd99f2e). An option for the deposited pages problem would be to make the case now for removing the sanity test. I haven't looked at the situation on arm64. It's your call on how to proceed -- I just wanted to make sure the full context is available to you. Michael [1] https://lore.kernel.org/lkml/CAHk-=wipev18s9sert+ino_rzgyvgtce38fr1cyo0u_hgvg...@mail.gmail.com/
