[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZropOA2IQqOP9_7X@x1n>
Date: Mon, 12 Aug 2024 11:24:40 -0400
From: Peter Xu <peterx@...hat.com>
To: "Wang, Wei W" <wei.w.wang@...el.com>
Cc: Sean Christopherson <seanjc@...gle.com>,
James Houghton <jthoughton@...gle.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
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 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
Powered by blists - more mailing lists