From: Sean Christopherson <seanjc@google.com>
To: Yu Zhang <yu.c.zhang@linux.intel.com>
Cc: David Stevens <stevensd@chromium.org>,
Marc Zyngier <maz@kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Peter Xu <peterx@redhat.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org
Subject: Re: [PATCH v7 4/8] KVM: x86/mmu: Migrate to __kvm_follow_pfn
Date: Fri, 4 Aug 2023 15:30:24 -0700 [thread overview]
Message-ID: <ZM18AAFj21Fo36hg@google.com> (raw)
In-Reply-To: <20230705080756.xv7fm3jxewipunvn@linux.intel.com>
On Wed, Jul 05, 2023, Yu Zhang wrote:
> On Tue, Jul 04, 2023 at 04:50:49PM +0900, David Stevens wrote:
> > From: David Stevens <stevensd@chromium.org>
> >
> > Migrate from __gfn_to_pfn_memslot to __kvm_follow_pfn.
Please turn up your changelog verbosity from ~2 to ~8. E.g. explain the transition
from async => FOLL_NOWAIT+KVM_PFN_ERR_NEEDS_IO, there's no reason to force readers
to suss that out on their own.
> > Signed-off-by: David Stevens <stevensd@chromium.org>
> > ---
> > arch/x86/kvm/mmu/mmu.c | 35 +++++++++++++++++++++++++----------
> > 1 file changed, 25 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > index ec169f5c7dce..e44ab512c3a1 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> > @@ -4296,7 +4296,12 @@ void kvm_arch_async_page_ready(struct kvm_vcpu *vcpu, struct kvm_async_pf *work)
> > static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault)
> > {
> > struct kvm_memory_slot *slot = fault->slot;
> > - bool async;
> > + struct kvm_follow_pfn foll = {
> > + .slot = slot,
> > + .gfn = fault->gfn,
> > + .flags = FOLL_GET | (fault->write ? FOLL_WRITE : 0),
> > + .allow_write_mapping = true,
> > + };
> >
> > /*
> > * Retry the page fault if the gfn hit a memslot that is being deleted
> > @@ -4325,12 +4330,14 @@ static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault
> > return RET_PF_EMULATE;
> > }
> >
> > - async = false;
> > - fault->pfn = __gfn_to_pfn_memslot(slot, fault->gfn, false, false, &async,
> > - fault->write, &fault->map_writable,
> > - &fault->hva);
> > - if (!async)
> > - return RET_PF_CONTINUE; /* *pfn has correct page already */
> > + foll.flags |= FOLL_NOWAIT;
> > + fault->pfn = __kvm_follow_pfn(&foll);
> > +
> > + if (!is_error_noslot_pfn(fault->pfn))
> > + goto success;
> > +
> > + if (fault->pfn != KVM_PFN_ERR_NEEDS_IO)
> > + return RET_PF_CONTINUE;
>
> IIUC, FOLL_NOWAIT is set only when we wanna an async fault. So
> KVM_PFN_ERR_NEEDS_IO may not be necessary?
But FOLL_NOWAIT is set above. This logic is essentially saying "bail immediately
if __gfn_to_pfn_memslot() returned a fatal error".
A commented would definitely be helpful though. How about?
/*
* If __kvm_follow_pfn() failed because I/O is needed to fault in the
* page, then either set up an asynchronous #PF to do the I/O, or if
* doing an async #PF isn't possible, retry __kvm_follow_pfn() with
I/O allowed. All other failures are fatal, i.e. retrying won't help.
*/
if (fault->pfn != KVM_PFN_ERR_NEEDS_IO)
return RET_PF_CONTINUE;
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Yu Zhang <yu.c.zhang@linux.intel.com>
Cc: kvm@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
linux-kernel@vger.kernel.org, Peter Xu <peterx@redhat.com>,
David Stevens <stevensd@chromium.org>,
kvmarm@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v7 4/8] KVM: x86/mmu: Migrate to __kvm_follow_pfn
Date: Fri, 4 Aug 2023 15:30:24 -0700 [thread overview]
Message-ID: <ZM18AAFj21Fo36hg@google.com> (raw)
In-Reply-To: <20230705080756.xv7fm3jxewipunvn@linux.intel.com>
On Wed, Jul 05, 2023, Yu Zhang wrote:
> On Tue, Jul 04, 2023 at 04:50:49PM +0900, David Stevens wrote:
> > From: David Stevens <stevensd@chromium.org>
> >
> > Migrate from __gfn_to_pfn_memslot to __kvm_follow_pfn.
Please turn up your changelog verbosity from ~2 to ~8. E.g. explain the transition
from async => FOLL_NOWAIT+KVM_PFN_ERR_NEEDS_IO, there's no reason to force readers
to suss that out on their own.
> > Signed-off-by: David Stevens <stevensd@chromium.org>
> > ---
> > arch/x86/kvm/mmu/mmu.c | 35 +++++++++++++++++++++++++----------
> > 1 file changed, 25 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > index ec169f5c7dce..e44ab512c3a1 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> > @@ -4296,7 +4296,12 @@ void kvm_arch_async_page_ready(struct kvm_vcpu *vcpu, struct kvm_async_pf *work)
> > static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault)
> > {
> > struct kvm_memory_slot *slot = fault->slot;
> > - bool async;
> > + struct kvm_follow_pfn foll = {
> > + .slot = slot,
> > + .gfn = fault->gfn,
> > + .flags = FOLL_GET | (fault->write ? FOLL_WRITE : 0),
> > + .allow_write_mapping = true,
> > + };
> >
> > /*
> > * Retry the page fault if the gfn hit a memslot that is being deleted
> > @@ -4325,12 +4330,14 @@ static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault
> > return RET_PF_EMULATE;
> > }
> >
> > - async = false;
> > - fault->pfn = __gfn_to_pfn_memslot(slot, fault->gfn, false, false, &async,
> > - fault->write, &fault->map_writable,
> > - &fault->hva);
> > - if (!async)
> > - return RET_PF_CONTINUE; /* *pfn has correct page already */
> > + foll.flags |= FOLL_NOWAIT;
> > + fault->pfn = __kvm_follow_pfn(&foll);
> > +
> > + if (!is_error_noslot_pfn(fault->pfn))
> > + goto success;
> > +
> > + if (fault->pfn != KVM_PFN_ERR_NEEDS_IO)
> > + return RET_PF_CONTINUE;
>
> IIUC, FOLL_NOWAIT is set only when we wanna an async fault. So
> KVM_PFN_ERR_NEEDS_IO may not be necessary?
But FOLL_NOWAIT is set above. This logic is essentially saying "bail immediately
if __gfn_to_pfn_memslot() returned a fatal error".
A commented would definitely be helpful though. How about?
/*
* If __kvm_follow_pfn() failed because I/O is needed to fault in the
* page, then either set up an asynchronous #PF to do the I/O, or if
* doing an async #PF isn't possible, retry __kvm_follow_pfn() with
I/O allowed. All other failures are fatal, i.e. retrying won't help.
*/
if (fault->pfn != KVM_PFN_ERR_NEEDS_IO)
return RET_PF_CONTINUE;
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Yu Zhang <yu.c.zhang@linux.intel.com>
Cc: David Stevens <stevensd@chromium.org>,
Marc Zyngier <maz@kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Peter Xu <peterx@redhat.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org
Subject: Re: [PATCH v7 4/8] KVM: x86/mmu: Migrate to __kvm_follow_pfn
Date: Fri, 4 Aug 2023 15:30:24 -0700 [thread overview]
Message-ID: <ZM18AAFj21Fo36hg@google.com> (raw)
In-Reply-To: <20230705080756.xv7fm3jxewipunvn@linux.intel.com>
On Wed, Jul 05, 2023, Yu Zhang wrote:
> On Tue, Jul 04, 2023 at 04:50:49PM +0900, David Stevens wrote:
> > From: David Stevens <stevensd@chromium.org>
> >
> > Migrate from __gfn_to_pfn_memslot to __kvm_follow_pfn.
Please turn up your changelog verbosity from ~2 to ~8. E.g. explain the transition
from async => FOLL_NOWAIT+KVM_PFN_ERR_NEEDS_IO, there's no reason to force readers
to suss that out on their own.
> > Signed-off-by: David Stevens <stevensd@chromium.org>
> > ---
> > arch/x86/kvm/mmu/mmu.c | 35 +++++++++++++++++++++++++----------
> > 1 file changed, 25 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > index ec169f5c7dce..e44ab512c3a1 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> > @@ -4296,7 +4296,12 @@ void kvm_arch_async_page_ready(struct kvm_vcpu *vcpu, struct kvm_async_pf *work)
> > static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault)
> > {
> > struct kvm_memory_slot *slot = fault->slot;
> > - bool async;
> > + struct kvm_follow_pfn foll = {
> > + .slot = slot,
> > + .gfn = fault->gfn,
> > + .flags = FOLL_GET | (fault->write ? FOLL_WRITE : 0),
> > + .allow_write_mapping = true,
> > + };
> >
> > /*
> > * Retry the page fault if the gfn hit a memslot that is being deleted
> > @@ -4325,12 +4330,14 @@ static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault
> > return RET_PF_EMULATE;
> > }
> >
> > - async = false;
> > - fault->pfn = __gfn_to_pfn_memslot(slot, fault->gfn, false, false, &async,
> > - fault->write, &fault->map_writable,
> > - &fault->hva);
> > - if (!async)
> > - return RET_PF_CONTINUE; /* *pfn has correct page already */
> > + foll.flags |= FOLL_NOWAIT;
> > + fault->pfn = __kvm_follow_pfn(&foll);
> > +
> > + if (!is_error_noslot_pfn(fault->pfn))
> > + goto success;
> > +
> > + if (fault->pfn != KVM_PFN_ERR_NEEDS_IO)
> > + return RET_PF_CONTINUE;
>
> IIUC, FOLL_NOWAIT is set only when we wanna an async fault. So
> KVM_PFN_ERR_NEEDS_IO may not be necessary?
But FOLL_NOWAIT is set above. This logic is essentially saying "bail immediately
if __gfn_to_pfn_memslot() returned a fatal error".
A commented would definitely be helpful though. How about?
/*
* If __kvm_follow_pfn() failed because I/O is needed to fault in the
* page, then either set up an asynchronous #PF to do the I/O, or if
* doing an async #PF isn't possible, retry __kvm_follow_pfn() with
I/O allowed. All other failures are fatal, i.e. retrying won't help.
*/
if (fault->pfn != KVM_PFN_ERR_NEEDS_IO)
return RET_PF_CONTINUE;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-08-04 22:30 UTC|newest]
Thread overview: 165+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-04 7:50 [PATCH v7 0/8] KVM: allow mapping non-refcounted pages David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` [PATCH v7 1/8] KVM: Assert that a page's refcount is elevated when marking accessed/dirty David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` [PATCH v7 2/8] KVM: Introduce __kvm_follow_pfn function David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-05 3:10 ` Yu Zhang
2023-07-05 3:10 ` Yu Zhang
2023-07-05 3:10 ` Yu Zhang
2023-07-05 9:22 ` David Stevens
2023-07-05 9:22 ` David Stevens
2023-07-05 9:22 ` David Stevens
2023-07-05 10:53 ` Yu Zhang
2023-07-05 10:53 ` Yu Zhang
2023-07-05 10:53 ` Yu Zhang
2023-07-06 5:29 ` David Stevens
2023-07-06 5:29 ` David Stevens
2023-07-06 5:29 ` David Stevens
2023-07-06 14:52 ` Yu Zhang
2023-07-06 14:52 ` Yu Zhang
2023-07-06 14:52 ` Yu Zhang
2023-08-04 22:03 ` Sean Christopherson
2023-08-04 22:03 ` Sean Christopherson
2023-08-04 22:03 ` Sean Christopherson
2023-07-05 8:47 ` Zhi Wang
2023-07-05 8:47 ` Zhi Wang
2023-07-05 8:47 ` Zhi Wang
2023-07-05 9:08 ` David Stevens
2023-07-05 9:08 ` David Stevens
2023-07-05 9:08 ` David Stevens
2023-07-11 17:37 ` Zhi Wang
2023-07-11 17:37 ` Zhi Wang
2023-07-11 17:37 ` Zhi Wang
2023-07-06 1:34 ` Isaku Yamahata
2023-07-06 1:34 ` Isaku Yamahata
2023-07-06 1:34 ` Isaku Yamahata
2023-07-06 5:52 ` David Stevens
2023-07-06 5:52 ` David Stevens
2023-07-06 5:52 ` David Stevens
2023-08-04 22:13 ` Sean Christopherson
2023-08-04 22:13 ` Sean Christopherson
2023-08-04 22:13 ` Sean Christopherson
2023-07-04 7:50 ` [PATCH v7 3/8] KVM: Make __kvm_follow_pfn not imply FOLL_GET David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-05 7:23 ` Yu Zhang
2023-07-05 7:23 ` Yu Zhang
2023-07-05 7:23 ` Yu Zhang
2023-07-05 11:56 ` Yu Zhang
2023-07-05 11:56 ` Yu Zhang
2023-07-05 11:56 ` Yu Zhang
2023-07-06 6:09 ` David Stevens
2023-07-06 6:09 ` David Stevens
2023-07-06 6:09 ` David Stevens
2023-07-05 13:19 ` Zhi Wang
2023-07-05 13:19 ` Zhi Wang
2023-07-05 13:19 ` Zhi Wang
2023-07-06 6:49 ` David Stevens
2023-07-06 6:49 ` David Stevens
2023-07-06 6:49 ` David Stevens
2023-07-11 17:33 ` Zhi Wang
2023-07-11 17:33 ` Zhi Wang
2023-07-11 17:33 ` Zhi Wang
2023-07-11 21:59 ` Sean Christopherson
2023-07-11 21:59 ` Sean Christopherson
2023-07-11 21:59 ` Sean Christopherson
2023-09-05 8:26 ` David Stevens
2023-09-05 8:26 ` David Stevens
2023-09-05 8:26 ` David Stevens
2023-09-06 0:45 ` Sean Christopherson
2023-09-06 0:45 ` Sean Christopherson
2023-09-06 0:45 ` Sean Christopherson
2023-09-06 3:24 ` David Stevens
2023-09-06 3:24 ` David Stevens
2023-09-06 3:24 ` David Stevens
2023-09-06 22:03 ` Sean Christopherson
2023-09-06 22:03 ` Sean Christopherson
2023-09-06 22:03 ` Sean Christopherson
2023-07-04 7:50 ` [PATCH v7 4/8] KVM: x86/mmu: Migrate to __kvm_follow_pfn David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-05 8:07 ` Yu Zhang
2023-07-05 8:07 ` Yu Zhang
2023-07-05 8:07 ` Yu Zhang
2023-08-04 22:30 ` Sean Christopherson [this message]
2023-08-04 22:30 ` Sean Christopherson
2023-08-04 22:30 ` Sean Christopherson
2023-07-06 1:54 ` Isaku Yamahata
2023-07-06 1:54 ` Isaku Yamahata
2023-07-06 1:54 ` Isaku Yamahata
2023-08-24 8:03 ` David Stevens
2023-08-24 8:03 ` David Stevens
2023-08-24 8:03 ` David Stevens
2023-07-04 7:50 ` [PATCH v7 5/8] KVM: x86/mmu: Don't pass FOLL_GET " David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-05 10:18 ` Yu Zhang
2023-07-05 10:18 ` Yu Zhang
2023-07-05 10:18 ` Yu Zhang
2023-07-05 14:17 ` Yu Zhang
2023-07-05 14:17 ` Yu Zhang
2023-07-05 14:17 ` Yu Zhang
2023-07-06 4:52 ` David Stevens
2023-07-06 4:52 ` David Stevens
2023-07-06 4:52 ` David Stevens
2023-07-06 7:19 ` Yu Zhang
2023-07-06 7:19 ` Yu Zhang
2023-07-06 7:19 ` Yu Zhang
2023-07-06 15:58 ` Isaku Yamahata
2023-07-06 15:58 ` Isaku Yamahata
2023-07-06 15:58 ` Isaku Yamahata
2023-07-07 1:35 ` David Stevens
2023-07-07 1:35 ` David Stevens
2023-07-07 1:35 ` David Stevens
2023-07-10 16:34 ` Isaku Yamahata
2023-07-10 16:34 ` Isaku Yamahata
2023-07-10 16:34 ` Isaku Yamahata
2023-07-11 2:59 ` David Stevens
2023-07-11 2:59 ` David Stevens
2023-07-11 2:59 ` David Stevens
2023-08-04 22:45 ` Sean Christopherson
2023-08-04 22:45 ` Sean Christopherson
2023-08-04 22:45 ` Sean Christopherson
2023-07-05 10:25 ` Yu Zhang
2023-07-05 10:25 ` Yu Zhang
2023-07-05 10:25 ` Yu Zhang
2023-08-24 8:03 ` David Stevens
2023-08-24 8:03 ` David Stevens
2023-08-24 8:03 ` David Stevens
2023-08-24 15:15 ` Sean Christopherson
2023-08-24 15:15 ` Sean Christopherson
2023-08-24 15:15 ` Sean Christopherson
2023-08-25 1:38 ` David Stevens
2023-08-25 1:38 ` David Stevens
2023-08-25 1:38 ` David Stevens
2023-08-31 21:18 ` Sean Christopherson
2023-08-31 21:18 ` Sean Christopherson
2023-08-31 21:18 ` Sean Christopherson
2023-07-06 2:10 ` Isaku Yamahata
2023-07-06 2:10 ` Isaku Yamahata
2023-07-06 2:10 ` Isaku Yamahata
2023-07-06 5:18 ` David Stevens
2023-07-06 5:18 ` David Stevens
2023-07-06 5:18 ` David Stevens
2023-07-19 6:09 ` Yan Zhao
2023-07-19 6:09 ` Yan Zhao
2023-07-19 6:09 ` Yan Zhao
2023-07-19 7:16 ` David Stevens
2023-07-19 7:16 ` David Stevens
2023-07-19 7:16 ` David Stevens
2023-07-04 7:50 ` [PATCH v7 6/8] KVM: arm64: Migrate " David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` [PATCH v7 7/8] KVM: PPC: " David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` [PATCH v7 8/8] KVM: remove __gfn_to_pfn_memslot David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-08-04 22:47 ` [PATCH v7 0/8] KVM: allow mapping non-refcounted pages Sean Christopherson
2023-08-04 22:47 ` Sean Christopherson
2023-08-04 22:47 ` Sean Christopherson
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=ZM18AAFj21Fo36hg@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maz@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=peterx@redhat.com \
--cc=stevensd@chromium.org \
--cc=yu.c.zhang@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.