On Fri, Mar 3, 2023 at 9:23 PM Mingwei Zhang <mizhang@xxxxxxxxxx> wrote:
>
> On Fri, Feb 24, 2023, 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 | 15 ++++++++++++++-
> > 1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> > index e1165c196970..b2e7407cd114 100644
> > --- a/arch/x86/kvm/cpuid.c
> > +++ b/arch/x86/kvm/cpuid.c
> > @@ -60,9 +60,22 @@ u32 xstate_required_size(u64 xstate_bv, bool compacted)
> > return ret;
> > }
> >
> > +static u64 sanitize_xcr0(u64 xcr0)
> > +{
> > + u64 mask;
> > +
> > + mask = XFEATURE_MASK_BNDREGS | XFEATURE_MASK_BNDCSR;
> > + if ((xcr0 & mask) != mask)
> > + xcr0 &= ~mask;
> > +
> > + return xcr0;
> > +}
>
> Is it better to put sanitize_xcr0() into the previous patch? If we do
> that, this one will be just adding purely the MPX related logic and thus
> cleaner I think.
I don't mind doing that. I considered putting in its own commit
actually. The only reason I didn't is I wasn't sure it was
appropriate to have a commit that only added an empty function. If
that's okay I think I'd lean more towards doing it that way.
> > +
> > u64 kvm_permitted_xcr0(void)
> > {
> > - return kvm_caps.supported_xcr0 & xstate_get_guest_group_perm();
> > + u64 permitted_xcr0 = kvm_caps.supported_xcr0 & xstate_get_guest_group_perm();
> > +
> > + return sanitize_xcr0(permitted_xcr0);
> > }
> >
> > /*
> > --
> > 2.39.2.637.g21b0678d19-goog
> >
