Re: [PATCH] KVM: x86/hyperv: do not overwrite hc->ingpa for slow SIGNAL_EVENT hypercall

[James Houghton]

On Mon, Sep 21, 2026 at 4:33 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>
> On 9/22/26 01:23, James Houghton wrote:
> >> James, how are you feeling about an early morning PUCK in the near future?
> > No problems here; the 23rd is fine. The only day I can't do in the
> > near-ish future is Oct 14. Thanks!
>
> Great.  To sum up what I would like to understand, this is it:
>
> 1) the overlap between memory protection attributes and kvm-userfault.
> It seems to me that they are almost the same, but I may be wrong.
>
> In particular, they are almost the same in that they are both
> stop-and-retry interfaces, unlike userfaultfd which hides the
> stop-and-retry behind a page fault and a stopped thread.

Hi Paolo,

They are very similar, yes. But I am unsure what the new memory
attribute work is motivated by (maybe I missed it? I don't see it in
the cover letters I checked).

KVM Userfault was motivated by post-copy live migration (for VMs with
guest_memfd memslots and as an optimization for userfaultfd-based
post-copy with conventional VMs). KVM Userfault's interface reflects
this; it uses a userspace-modifiable bitmap to track state, which has
predictable memory overhead and is fast to modify. If memory
attributes are meant to be used for post-copy as well, we'll want a
bitmap-based interface for userspace and for tracking in KVM.

Other than the interface, KVM Userfault was intentionally limited to
only EPT/NPT faults because it is always "safe" for those to return to
userspace with -EFAULT and the bad address. This means that
implementing post-copy completely requires *also* using userfaultfd
(or something else) for the other guest memory access cases. Memory
protection attributes include many of the other important
(guest-initiated) cases, so post-copy could maybe be implemented
without userfaultfd. Great!

I was assuming that these new checks would be (1) difficult to
maintain and (2) potentially cause issues with instruction emulation
(or any case where unwinding and replaying is challenging).

> 2) what strategy you have implemented, or you have in mind, to handle
> stop-and-retry for code that does many consecutive memory accesses.  The
> main one is nested vmentry/vmexit.  I have here some mostly untested
> code that splits them into prepare/commit/cancel phases, but I haven't
> dared posting it.

Ah exactly... :) This is why userfaultfd remained in the picture for a
complete post-copy implementation with KVM Userfault. From my
perspective, the only way around using userfaultfd is to add support
for nested vmentry/vmexit going back out to userspace and coming back
in, like the phases you have.

"KVM Demand Paging" in Google's downstream kernel has essentially the
same checks that you have in the memory attribute series. It uses a
netlink socket for the long flows (and waits for userspace to mark the
page as ready). Perhaps there's an argument that this would be better
than making the long flows support exiting to userspace? But I doubt
it.

> (Secondarily, we have a TDX-sized dependency between planes, memory
> attributes, VBS, and kvm-userfault.  That is probably something worth
> discussing too, sooner or later).

Yes I want to hear more, I'm not sure of all the context here. :)

Thanks!

James