On Mon, Jan 02, 2023, Xiaoyao Li wrote:
> On 12/31/2022 12:24 AM, Aaron Lewis wrote:
> > Be a good citizen and don't allow any of the supported MPX xfeatures[1]
> > to be set if they can't all be set. That way userspace or a guest
> > doesn't fail if it attempts to set them in XCR0.
> >
> > [1] CPUID.(EAX=0DH,ECX=0):EAX.BNDREGS[bit-3]
> > CPUID.(EAX=0DH,ECX=0):EAX.BNDCSR[bit-4]
> >
> > Suggested-by: Jim Mattson <jmattson@xxxxxxxxxx>
> > Signed-off-by: Aaron Lewis <aaronlewis@xxxxxxxxxx>
> > ---
> > arch/x86/kvm/cpuid.c | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> > index c4e8257629165..2431c46d456b4 100644
> > --- a/arch/x86/kvm/cpuid.c
> > +++ b/arch/x86/kvm/cpuid.c
> > @@ -855,6 +855,16 @@ static int __do_cpuid_func_emulated(struct kvm_cpuid_array *array, u32 func)
> > return 0;
> > }
> > +static u64 sanitize_xcr0(u64 xcr0)
> > +{
> > + u64 mask;
> > +
> > + mask = XFEATURE_MASK_BNDREGS | XFEATURE_MASK_BNDCSR;
> > + if ((xcr0 & mask) != mask)
> > + xcr0 &= ~mask;
>
> Maybe it can WARN_ON_ONCE() here.
>
> It implies either a kernel bug that permitted_xcr0 is invalid or a broken
> HW.
I'm pretty sure KVM can't WARN, as this falls into the category of "it's technically
architecturally legal to report only one of the features, but real hardware will
always report both".
