From: Sean Christopherson <seanjc@google.com>
To: Wei W Wang <wei.w.wang@intel.com>
Cc: James Houghton <jthoughton@google.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Peter Xu <peterx@redhat.com>,
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: Fri, 9 Aug 2024 12:04:33 -0700 [thread overview]
Message-ID: <ZrZoQZEfTffvVT75@google.com> (raw)
In-Reply-To: <DS0PR11MB6373A1908092810E99F387F7DCBA2@DS0PR11MB6373.namprd11.prod.outlook.com>
On Fri, Aug 09, 2024, Wei W Wang wrote:
> On Friday, August 9, 2024 3:05 AM, James Houghton wrote:
> > On Thu, Aug 8, 2024 at 5:15 AM Wang, Wei W <wei.w.wang@intel.com> wrote:
> There also seems to be a race condition between KVM userfault and userfaultfd.
> For example, guest access to a guest-shared page triggers KVM userfault to
> userspace while vhost (or KVM) could access to the same page during the window
> that KVM userfault is handling the page, then there will be two simultaneous faults
> on the same page.
> I'm thinking how would this case be handled? (leaving it to userspace to detect and
> handle such cases would be an complex)
Userspace is going to have to handle racing "faults" no matter what, e.g. if
multiple vCPUs hit the same fault and exit at the same time. I don't think it'll
be too complex to detect spurious/fixed faults and retry.
next prev parent reply other threads:[~2024-08-09 19:04 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 [this message]
2024-08-12 14:12 ` Wang, Wei W
2024-08-12 15:24 ` Peter Xu
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=ZrZoQZEfTffvVT75@google.com \
--to=seanjc@google.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=peterx@redhat.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