[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABgObfbtdSnzRCsiDHgjnT5OTROMOEgWZL+AMOSFj2+hXOsATw@mail.gmail.com>
Date: Thu, 8 Jan 2026 17:26:32 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Binbin Wu <binbin.wu@...ux.intel.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org, seanjc@...gle.com,
x86@...nel.org, stable@...r.kernel.org
Subject: Re: [PATCH 1/4] x86/fpu: Clear XSTATE_BV[i] in save state whenever XFD[i]=1
On Thu, Jan 8, 2026 at 4:08 AM Binbin Wu <binbin.wu@...ux.intel.com> wrote:
> > + /*
> > + * KVM's guest ABI is that setting XFD[i]=1 *can* immediately revert
> > + * the save state to initialized. Likewise, KVM_GET_XSAVE does the
>
> Nit:
> To me "initialized" has the implication that it's active.
> I prefer the description "initial state" or "initial configuration" used in
> SDM here.
> I am not a native English speaker though, please ignore it if it's just my
> feeling.
Sure, why not:
KVM's guest ABI is that setting XFD[i]=1 *can* immediately revert the
save state to its initial configuration. Likewise, KVM_GET_XSAVE does
the same as XSAVE and returns XSTATE_BV[i]=0 whenever XFD[i]=1.
> > + /*
> > + * Do not reject non-initialized disabled features for backwards
> > + * compatibility, but clear XSTATE_BV[i] whenever XFD[i]=1.
> > + * Otherwise, XRSTOR would cause a #NM.
> > + */
Same here:
For backwards compatibility, do not expect disabled features to be in
their initial state. XSTATE_BV[i] must still be cleared whenever
XFD[i]=1, or XRSTOR would cause a #NM.
Thanks!
Paolo
Powered by blists - more mailing lists