All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Yu Zhang <yu.c.zhang@linux.intel.com>,
	kvm@vger.kernel.org, pbonzini@redhat.com, maz@kernel.org,
	james.morse@arm.com, alexandru.elisei@arm.com,
	suzuki.poulose@arm.com, oliver.upton@linux.dev,
	catalin.marinas@arm.com, will@kernel.org, paul@xen.org
Subject: Re: [PATCH v4 1/2] KVM: MMU: Introduce 'INVALID_GFN' and use it for GFN values
Date: Thu, 22 Dec 2022 18:53:35 +0000	[thread overview]
Message-ID: <Y6Snr42pMGvIO+9d@google.com> (raw)
In-Reply-To: <89a8f726e6fb1a91097ef18d6e837aff31a675f3.camel@infradead.org>

On Tue, Dec 20, 2022, David Woodhouse wrote:
> On Fri, 2022-12-16 at 16:34 +0000, Sean Christopherson wrote:
> > On Fri, Dec 16, 2022, Yu Zhang wrote:
> > > Currently, KVM xen and its shared info selftest code uses
> > > 'GPA_INVALID' for GFN values, but actually it is more accurate
> > > to use the name 'INVALID_GFN'. So just add a new definition
> > > and use it.
> > > 
> > > No functional changes intended.
> > > 
> > > Suggested-by: David Woodhouse <dwmw2@infradead.org>
> > > Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
> > > ---
> > >  arch/x86/kvm/xen.c                                   | 4 ++--
> > >  include/linux/kvm_types.h                            | 1 +
> > >  tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c | 4 ++--
> > >  3 files changed, 5 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
> > > index d7af40240248..6908a74ab303 100644
> > > --- a/arch/x86/kvm/xen.c
> > > +++ b/arch/x86/kvm/xen.c
> > > @@ -41,7 +41,7 @@ static int kvm_xen_shared_info_init(struct kvm *kvm, gfn_t gfn)
> > >         int ret = 0;
> > >         int idx = srcu_read_lock(&kvm->srcu);
> > >  
> > > -       if (gfn == GPA_INVALID) {
> > > +       if (gfn == INVALID_GFN) {
> > 
> > Grrr!  This magic value is ABI, as "gfn == -1" yields different behavior than a
> > random, garbage gfn.
> >                                                                                 
> > So, sadly, we can't simply introduce INVALID_GFN here, and instead need to do
> > something like:
> > 
> 
> Well... you can still use INVALID_GFN as long as its value remains the
> same ((uint64_t)-1).
> 
> But yes, the KVM API differs here from Xen because Xen only allows a
> guest to *set* these (and later they invented SHUTDOWN_soft_reset).
> While KVM lets the userspace VMM handle soft reset, and needs to allow
> them to be *unset*. And since zero is a valid GPA/GFN, -1 is a
> reasonable value for 'INVALID'.

Oh, yeah, I'm not arguing against using '-1', just calling out that there is
special meaning given to '-1' and so it needs to be formalized so that KVM doesn't
accidentally break userspace.

> But I do think that detail escaped the documentation and the uapi headers, so
> your suggestion below is a good one, although strictly we need a GPA one too.

Ah, right, for struct kvm_xen_vcpu_attr.

  reply	other threads:[~2022-12-22 18:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-16  8:59 [PATCH v4 0/2] KVM: MMU: Use 'INVALID_GPA' and 'INVALID_GFN' properly Yu Zhang
2022-12-16  8:59 ` [PATCH v4 1/2] KVM: MMU: Introduce 'INVALID_GFN' and use it for GFN values Yu Zhang
2022-12-16 12:20   ` Michal Luczaj
2022-12-16 16:16     ` Sean Christopherson
2022-12-16 17:29       ` Michal Luczaj
2022-12-16 16:34   ` Sean Christopherson
2022-12-20  8:16     ` Yu Zhang
2022-12-20 19:59     ` David Woodhouse
2022-12-22 18:53       ` Sean Christopherson [this message]
2022-12-22 19:28         ` David Woodhouse
2022-12-22 19:50           ` Sean Christopherson
2022-12-16  8:59 ` [PATCH v4 2/2] KVM: MMU: Make the definition of 'INVALID_GPA' common Yu Zhang
2022-12-16 16:36   ` Sean Christopherson
2022-12-17  6:41   ` Huang, Kai

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=Y6Snr42pMGvIO+9d@google.com \
    --to=seanjc@google.com \
    --cc=alexandru.elisei@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=dwmw2@infradead.org \
    --cc=james.morse@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=paul@xen.org \
    --cc=pbonzini@redhat.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.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.