From: "Huang, Kai" <kai.huang@intel.com>
To: "Li, Xin3" <xin3.li@intel.com>, "Gao, Chao" <chao.gao@intel.com>
Cc: "Yang, Weijiang" <weijiang.yang@intel.com>,
"seanjc@google.com" <seanjc@google.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"bp@alien8.de" <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"hpa@zytor.com" <hpa@zytor.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 1/2] KVM: VMX: Cleanup VMX basic information defines and usages
Date: Thu, 18 Jan 2024 03:08:28 +0000 [thread overview]
Message-ID: <6d8d04899f00a05ef2512f24f81e58fcb4dad098.camel@intel.com> (raw)
In-Reply-To: <SA1PR11MB67340002B67910588EE335B1A8722@SA1PR11MB6734.namprd11.prod.outlook.com>
On Wed, 2024-01-17 at 16:34 +0000, Li, Xin3 wrote:
> > > +#define VMX_BASIC_FEATURES_MASK \
> > > + (VMX_BASIC_DUAL_MONITOR_TREATMENT | \
> > > + VMX_BASIC_INOUT | \
> > > + VMX_BASIC_TRUE_CTLS)
> > > +
> > > +#define VMX_BASIC_RESERVED_BITS \
> > > + (GENMASK_ULL(63, 56) | GENMASK_ULL(47, 45) | BIT_ULL(31))
> >
> > When we add a new feature (e.g., in CET series, bit 56 is added), the above
> > two macros need to be modified.
> >
> > Would it be better to use a macro for bits exempt from the bitwise check below
> > e.g.,
> >
> > #define VMX_BASIC_MULTI_BITS_FEATURES_MASK
> >
> > (GENMASK_ULL(53, 50) | GENMASK_ULL(44, 32) | GENMASK_ULL(30, 0))
> >
> > and do
> > if (!is_bitwise_subset(vmx_basic, data,
> > ~VMX_BASIC_MULTI_BITS_FEATURES_MASK)
> >
> > then we don't need to change the macro when adding new features.
>
> Sounds a good idea to me, and just need to add comments about why.
>
> >
> > > +
> > > static int vmx_restore_vmx_basic(struct vcpu_vmx *vmx, u64 data)
> > > {
> > > - const u64 feature_and_reserved =
> > > - /* feature (except bit 48; see below) */
> > > - BIT_ULL(49) | BIT_ULL(54) | BIT_ULL(55) |
> > > - /* reserved */
> > > - BIT_ULL(31) | GENMASK_ULL(47, 45) | GENMASK_ULL(63, 56);
> > > u64 vmx_basic = vmcs_config.nested.basic;
> > >
> > > - if (!is_bitwise_subset(vmx_basic, data, feature_and_reserved))
> > > + static_assert(!(VMX_BASIC_FEATURES_MASK &
> > VMX_BASIC_RESERVED_BITS));
> > > +
> > > + if (!is_bitwise_subset(vmx_basic, data,
> > > + VMX_BASIC_FEATURES_MASK |
> > VMX_BASIC_RESERVED_BITS))
> > > return -EINVAL;
> > >
> > > /*
> > > * KVM does not emulate a version of VMX that constrains physical
> > > * addresses of VMX structures (e.g. VMCS) to 32-bits.
> > > */
> > > - if (data & BIT_ULL(48))
> > > + if (data & VMX_BASIC_32BIT_PHYS_ADDR_ONLY)
> > > return -EINVAL;
> >
> > Side topic:
> >
> > Actually, there is no need to handle bit 48 as a special case. If we add bit 48
> > to VMX_BASIC_FEATURES_MASK, the bitwise check will fail if bit 48 of @data is 1.
>
> Good point! This is also what you suggested above.
>
Please try to avoid mixing things together in one patch. If you want to do
above, could you please do it in a separate patch so that can be reviewed
separately?
E.g., people who have reviewed or acked this patch may not be interested in the
new (logically separate) things.
next prev parent reply other threads:[~2024-01-18 3:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-12 9:34 [PATCH v4 1/2] KVM: VMX: Cleanup VMX basic information defines and usages Xin Li
2024-01-12 9:34 ` [PATCH v4 2/2] KVM: VMX: Cleanup VMX misc " Xin Li
2024-01-15 11:46 ` [PATCH v4 1/2] KVM: VMX: Cleanup VMX basic " Huang, Kai
2024-01-16 4:13 ` Li, Xin3
2024-01-16 7:46 ` Chao Gao
2024-01-17 16:34 ` Li, Xin3
2024-01-18 3:08 ` Huang, Kai [this message]
2024-01-18 5:15 ` Li, Xin3
2024-01-18 3:13 ` Huang, Kai
2024-01-18 5:16 ` Li, Xin3
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=6d8d04899f00a05ef2512f24f81e58fcb4dad098.camel@intel.com \
--to=kai.huang@intel.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=weijiang.yang@intel.com \
--cc=x86@kernel.org \
--cc=xin3.li@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox