On Tue, 2023-02-21 at 13:47 +0800, Binbin Wu wrote: > On 2/9/2023 10:40 AM, Robert Hoo wrote: > > LAM feature is enumerated by (EAX=07H, ECX=01H):EAX.LAM[bit26]. > > > > Signed-off-by: Robert Hoo <robert.hu@xxxxxxxxxxxxxxx> > > Reviewed-by: Jingqi Liu <jingqi.liu@xxxxxxxxx> > > --- > > arch/x86/kvm/cpuid.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > > index b14653b61470..79f45cbe587e 100644 > > --- a/arch/x86/kvm/cpuid.c > > +++ b/arch/x86/kvm/cpuid.c > > @@ -664,7 +664,7 @@ void kvm_set_cpu_caps(void) > > > > kvm_cpu_cap_mask(CPUID_7_1_EAX, > > F(AVX_VNNI) | F(AVX512_BF16) | F(CMPCCXADD) | > > F(AMX_FP16) | > > - F(AVX_IFMA) > > + F(AVX_IFMA) | F(LAM) > > Do we allow to expose the LAM capability to guest when host kernel > disabled LAM feature (e.g. via clearcpuid)? No > > May be it should be handled similarly as LA57. > You mean expose LAM to guest based on HW capability rather than host status? Why is LA57 exposure like this? unlike most features. Without explicit rationality, I would tend to follow most conventions.
