[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZrZoQZEfTffvVT75@google.com>
Date: Fri, 9 Aug 2024 12:04:33 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Wei W Wang <wei.w.wang@...el.com>
Cc: James Houghton <jthoughton@...gle.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Peter Xu <peterx@...hat.com>,
Paolo Bonzini <pbonzini@...hat.com>, Oliver Upton <oliver.upton@...ux.dev>,
Axel Rasmussen <axelrasmussen@...gle.com>, David Matlack <dmatlack@...gle.com>,
Anish Moorthy <amoorthy@...gle.com>
Subject: Re: [ANNOUNCE] PUCK Agenda - 2024.08.07 - KVM userfault
(guest_memfd/HugeTLB postcopy)
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@...el.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.
Powered by blists - more mailing lists