From: Sean Christopherson <seanjc@google.com>
To: Peter Xu <peterx@redhat.com>
Cc: David Matlack <dmatlack@google.com>,
Oliver Upton <oliver.upton@linux.dev>,
Paolo Bonzini <pbonzini@redhat.com>,
kvm list <kvm@vger.kernel.org>,
James Houghton <jthoughton@google.com>,
Oliver Upton <oupton@google.com>,
Axel Rasmussen <axelrasmussen@google.com>,
Mike Kravetz <mike.kravetz@oracle.com>,
Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: RFC: A KVM-specific alternative to UserfaultFD
Date: Wed, 8 Nov 2023 12:10:15 -0800 [thread overview]
Message-ID: <ZUvrJz42KXPsffJH@google.com> (raw)
In-Reply-To: <ZUvGpmk680nBKwOE@x1n>
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.
next prev parent reply other threads:[~2023-11-08 20:10 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-06 18:25 RFC: A KVM-specific alternative to UserfaultFD David Matlack
2023-11-06 20:23 ` Peter Xu
2023-11-06 22:24 ` Axel Rasmussen
2023-11-06 23:03 ` Peter Xu
2023-11-06 23:22 ` David Matlack
2023-11-07 14:21 ` Peter Xu
2023-11-07 16:11 ` James Houghton
2023-11-07 17:24 ` Peter Xu
2023-11-07 19:08 ` James Houghton
2023-11-07 16:25 ` Paolo Bonzini
2023-11-07 20:04 ` David Matlack
2023-11-07 21:10 ` Oliver Upton
2023-11-07 21:34 ` David Matlack
2023-11-08 1:27 ` Oliver Upton
2023-11-08 16:56 ` David Matlack
2023-11-08 17:34 ` Peter Xu
2023-11-08 20:10 ` Sean Christopherson [this message]
2023-11-08 20:36 ` Peter Xu
2023-11-08 20:47 ` Axel Rasmussen
2023-11-08 21:05 ` David Matlack
2023-11-08 20:49 ` David Matlack
2023-11-08 20:33 ` Paolo Bonzini
2023-11-08 20:43 ` David Matlack
2023-11-07 22:29 ` Peter Xu
2023-11-09 16:41 ` David Matlack
2023-11-09 17:58 ` Sean Christopherson
2023-11-09 18:33 ` David Matlack
2023-11-09 22:44 ` David Matlack
2023-11-09 23:54 ` Sean Christopherson
2023-11-09 19:20 ` Peter Xu
2023-11-11 16:23 ` David Matlack
2023-11-11 17:30 ` Peter Xu
2023-11-13 16:43 ` David Matlack
2023-11-20 18:32 ` James Houghton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZUvrJz42KXPsffJH@google.com \
--to=seanjc@google.com \
--cc=aarcange@redhat.com \
--cc=axelrasmussen@google.com \
--cc=dmatlack@google.com \
--cc=jthoughton@google.com \
--cc=kvm@vger.kernel.org \
--cc=mike.kravetz@oracle.com \
--cc=oliver.upton@linux.dev \
--cc=oupton@google.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).