From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Jim Mattson <jmattson@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Joerg Roedel <joro@8bytes.org>, kvm list <kvm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] KVM: x86: Add build-time assertion on usage of bit()
Date: Wed, 11 Dec 2019 11:18:17 -0800 [thread overview]
Message-ID: <20191211191817.GJ5044@linux.intel.com> (raw)
In-Reply-To: <CALMp9eR93otezrDot23oODV1S6M9kUAF9oB5UD7+E765cHRXjw@mail.gmail.com>
On Wed, Dec 11, 2019 at 10:24:36AM -0800, Jim Mattson wrote:
> On Wed, Dec 11, 2019 at 9:58 AM Sean Christopherson
> <sean.j.christopherson@intel.com> wrote:
> >
> > Add build-time checks to ensure KVM isn't trying to do a reverse CPUID
> > lookup on Linux-defined feature bits, along with comments to explain
> > the gory details of X86_FEATUREs and bit().
> >
> > Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> > ---
> >
> > Note, the premature newline in the first line of the second comment is
> > intentional to reduce churn in the next patch.
> >
> > arch/x86/kvm/x86.h | 23 +++++++++++++++++++++--
> > 1 file changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
> > index cab5e71f0f0f..4ee4175c66a7 100644
> > --- a/arch/x86/kvm/x86.h
> > +++ b/arch/x86/kvm/x86.h
> > @@ -144,9 +144,28 @@ static inline bool is_pae_paging(struct kvm_vcpu *vcpu)
> > return !is_long_mode(vcpu) && is_pae(vcpu) && is_paging(vcpu);
> > }
> >
> > -static inline u32 bit(int bitno)
> > +/*
> > + * Retrieve the bit mask from an X86_FEATURE_* definition. Features contain
> > + * the hardware defined bit number (stored in bits 4:0) and a software defined
> > + * "word" (stored in bits 31:5). The word is used to index into arrays of
> > + * bit masks that hold the per-cpu feature capabilities, e.g. this_cpu_has().
> > + */
> > +static __always_inline u32 bit(int feature)
> > {
> > - return 1 << (bitno & 31);
> > + /*
> > + * bit() is intended to be used only for hardware-defined
> > + * words, i.e. words whose bits directly correspond to a CPUID leaf.
> > + * Retrieving the bit mask from a Linux-defined word is nonsensical
> > + * as the bit number/mask is an arbitrary software-defined value and
> > + * can't be used by KVM to query/control guest capabilities.
> > + */
> > + BUILD_BUG_ON((feature >> 5) == CPUID_LNX_1);
> > + BUILD_BUG_ON((feature >> 5) == CPUID_LNX_2);
> > + BUILD_BUG_ON((feature >> 5) == CPUID_LNX_3);
> > + BUILD_BUG_ON((feature >> 5) == CPUID_LNX_4);
> > + BUILD_BUG_ON((feature >> 5) > CPUID_7_EDX);
>
> What is magical about CPUID_7_EDX?
It's currently the last cpufeatures word. My thought was to force this to
be updated in order to do reverse lookup on the next new word. I didn't
want to use NCAPINTS because that gets updated when a new word is added to
cpufeatures, i.e. wouldn't catch the case where the next new word is a
Linux-defined word, which is extremely unlikely but theoretically possible.
> > +
> > + return 1 << (feature & 31);
>
> Why not BIT(feature & 31)?
That's a very good question.
> > }
> >
> > static inline u8 vcpu_virt_addr_bits(struct kvm_vcpu *vcpu)
> > --
> > 2.24.0
> >
next prev parent reply other threads:[~2019-12-11 19:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-11 17:58 [PATCH 0/2] KVM: x86: X86_FEATURE bit() cleanup Sean Christopherson
2019-12-11 17:58 ` [PATCH 1/2] KVM: x86: Add build-time assertion on usage of bit() Sean Christopherson
2019-12-11 18:24 ` Jim Mattson
2019-12-11 19:18 ` Sean Christopherson [this message]
2019-12-11 17:58 ` [PATCH 2/2] KVM: x86: Refactor and rename bit() to feature_bit() macro Sean Christopherson
2019-12-11 18:27 ` Jim Mattson
2019-12-14 3:35 ` [PATCH 0/2] KVM: x86: X86_FEATURE bit() cleanup 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=20191211191817.GJ5044@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.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.