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
