Re: RFC: A KVM-specific alternative to UserfaultFD

[Peter Xu <peterx@redhat.com>]

On Wed, Nov 08, 2023 at 12:10:15PM -0800, Sean Christopherson wrote:
> On Wed, Nov 08, 2023, Peter Xu wrote:
> > On Wed, Nov 08, 2023 at 08:56:22AM -0800, David Matlack wrote:
> > > Thanks for the longer explanation. Yes kvm_read_guest() eventually
> > > calls __copy_from_user() which will trigger a page fault and
> > > UserfaultFD will notify userspace and wait for the page to become
> > > present. In the KVM-specific proposal I outlined, calling
> > > kvm_read_guest() will ultimately result in a check of the VM's present
> > > bitmap and KVM will nnotify userspace and wait for the page to become
> > > present if it's not, before calling __copy_from_user(). So I don't
> > > expect a KVM-specific solution to have any increased maintenance
> > > burden for VGIC (or any other widgets).
> > 
> > The question is how to support modules that do not use kvm apis at all,
> > like vhost.  I raised the question in my initial reply, too.
> > 
> > I think if vhost is going to support gmemfd, it'll need new apis so maybe
> > there'll be a chance to take that into account, but I'm not 100% sure it'll
> > be the same complexity, also not sure if that's the plan even for CoCo.
> >
> > Or is anything like vhost not considered to be supported for gmemfd at all?
> 
> vhost shouldn't require new APIs.  To support vhost, guest_memfd would first need
> to support virtio for host userspace, i.e. would need to support .mmap().  At that
> point, all of the uaccess and gup() stuff in vhost should work without modification.

Then I suppose it means we will treat QEMU, vhost and probably the whole
host hypervisor stack the same trust level from gmemfd's regard.

But then it'll be a harder question for a new demand paging scheme, as the
new interface should need to be separately proposed.  Another option is to
only support kvm-api based virt modules, but it may then become slightly
less attractive.

Thanks,

-- 
Peter Xu