From: Peter Xu <peterx@redhat.com>
To: "Wang, Wei W" <wei.w.wang@intel.com>
Cc: Sean Christopherson <seanjc@google.com>,
James Houghton <jthoughton@google.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Oliver Upton <oliver.upton@linux.dev>,
Axel Rasmussen <axelrasmussen@google.com>,
David Matlack <dmatlack@google.com>,
Anish Moorthy <amoorthy@google.com>
Subject: Re: [ANNOUNCE] PUCK Agenda - 2024.08.07 - KVM userfault (guest_memfd/HugeTLB postcopy)
Date: Mon, 12 Aug 2024 11:24:40 -0400 [thread overview]
Message-ID: <ZropOA2IQqOP9_7X@x1n> (raw)
In-Reply-To: <DS0PR11MB63734864431AD2783C229C57DC852@DS0PR11MB6373.namprd11.prod.outlook.com>
On Mon, Aug 12, 2024 at 02:12:29PM +0000, Wang, Wei W wrote:
> In the example above, both UFFDIO_COPY and KVM_USERFAULT_COPY need to be
> invoked, e.g.:
> #1 invoke KVM_USERFAULT_COPY
> #2 invoke UFFDIO_COPY
>
> This requires that UFFDIO_COPY does not conflict with KVM_USERFAULT_COPY. Current
> UFFDIO_COPY will fail (thus not waking up the threads on the waitq) when it fails to
> install the PTE into the page table (in the above example the PTE has already been
> installed into the page table by KVM_USERFAULT_COPY at #1).
Indeed, maybe we can fix that with an explicit UFFDIO_WAKE upon UFFDIO_COPY
failures iff -EEXIST (in this case, it should fall into "page cache exists"
category, even if pgtable can still be missing).
I assume OTOH a racy KVM_USERFAULT_COPY in whatever form doesn't need
anything but to kick the vcpu, irrelevant of whether the copy succeeded or
not.
Thanks,
--
Peter Xu
prev parent reply other threads:[~2024-08-12 15:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-01 22:43 [ANNOUNCE] PUCK Agenda - 2024.08.07 - KVM userfault (guest_memfd/HugeTLB postcopy) Sean Christopherson
2024-08-07 17:21 ` James Houghton
2024-08-08 0:17 ` Sean Christopherson
2024-08-08 12:15 ` Wang, Wei W
2024-08-08 19:04 ` James Houghton
2024-08-09 13:51 ` Wang, Wei W
2024-08-09 19:04 ` Sean Christopherson
2024-08-12 14:12 ` Wang, Wei W
2024-08-12 15:24 ` Peter Xu [this message]
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=ZropOA2IQqOP9_7X@x1n \
--to=peterx@redhat.com \
--cc=amoorthy@google.com \
--cc=axelrasmussen@google.com \
--cc=dmatlack@google.com \
--cc=jthoughton@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oliver.upton@linux.dev \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=wei.w.wang@intel.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