| Message ID | 20230209024022.3371768-10-robert.hu@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Linear Address Masking (LAM) KVM Enabling | expand |
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@linux.intel.com> > Reviewed-by: Jingqi Liu <jingqi.liu@intel.com> > --- > 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)? May be it should be handled similarly as LA57. > ); > > kvm_cpu_cap_init_kvm_defined(CPUID_7_1_EDX,
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@linux.intel.com> > > Reviewed-by: Jingqi Liu <jingqi.liu@intel.com> > > --- > > 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.
On 2/21/2023 3:26 PM, Robert Hoo wrote: > 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@linux.intel.com> >>> Reviewed-by: Jingqi Liu <jingqi.liu@intel.com> >>> --- >>> 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. The special handling for LA57 is from the patch "kvm: x86: Return LA57 feature based on hardware capability". https://lore.kernel.org/lkml/1548950983-18458-1-git-send-email-yu.c.zhang@linux.intel.com/ The reason is host kernel may disable 5-level paging using cmdline parameter 'no5lvl', and it will clear the feature bit for LA57 in boot_cpu_data. boot_cpu_data is queried in kvm_set_cpu_caps to derive kvm cpu cap masks. " VMs can still benefit from extended linear address width, e.g. to enhance features like ASLR" even when host doesn't use 5-level paging. So, the patch sets LA57 based on hardware capability. I was just wondering whether LAM could be the similar case that the host disabled the feature somehow (e.g via clearcpuid), and the guest still want to use it. > > Without explicit rationality, I would tend to follow most conventions. > >
> > The special handling for LA57 is from the patch "kvm: x86: Return LA57 > feature based on hardware capability". > https://lore.kernel.org/lkml/1548950983-18458-1-git-send-email-yu.c.zhang@linux.intel.com/ > > The reason is host kernel may disable 5-level paging using cmdline parameter > 'no5lvl', and it will clear the feature bit for LA57 in boot_cpu_data. > boot_cpu_data is queried in kvm_set_cpu_caps to derive kvm cpu cap masks. > > " VMs can still benefit from extended linear address width, e.g. to enhance > features like ASLR" even when host doesn't use 5-level paging. > So, the patch sets LA57 based on hardware capability. > > I was just wondering whether LAM could be the similar case that the host > disabled the feature somehow (e.g via clearcpuid), and the guest still want > to use it. Paging modes in root & non-root are orthogonal, so should LAM. B.R. Yu
On 2/21/2023 7:13 PM, Yu Zhang wrote: >> The special handling for LA57 is from the patch "kvm: x86: Return LA57 >> feature based on hardware capability". >> https://lore.kernel.org/lkml/1548950983-18458-1-git-send-email-yu.c.zhang@linux.intel.com/ >> >> The reason is host kernel may disable 5-level paging using cmdline parameter >> 'no5lvl', and it will clear the feature bit for LA57 in boot_cpu_data. >> boot_cpu_data is queried in kvm_set_cpu_caps to derive kvm cpu cap masks. >> >> " VMs can still benefit from extended linear address width, e.g. to enhance >> features like ASLR" even when host doesn't use 5-level paging. >> So, the patch sets LA57 based on hardware capability. >> >> I was just wondering whether LAM could be the similar case that the host >> disabled the feature somehow (e.g via clearcpuid), and the guest still want >> to use it. > Paging modes in root & non-root are orthogonal, so should LAM. Agree. > > B.R. > Yu
On Tue, 2023-02-21 at 21:18 +0800, Binbin Wu wrote: > On 2/21/2023 7:13 PM, Yu Zhang wrote: > > > The special handling for LA57 is from the patch "kvm: x86: Return > > > LA57 > > > feature based on hardware capability". > > > https://lore.kernel.org/lkml/1548950983-18458-1-git-send-email-yu.c.zhang@linux.intel.com/ > > > > > > The reason is host kernel may disable 5-level paging using > > > cmdline parameter > > > 'no5lvl', and it will clear the feature bit for LA57 in > > > boot_cpu_data. > > > boot_cpu_data is queried in kvm_set_cpu_caps to derive kvm cpu > > > cap masks. > > > > > > " VMs can still benefit from extended linear address width, e.g. > > > to enhance > > > features like ASLR" even when host doesn't use 5-level paging. > > > So, the patch sets LA57 based on hardware capability. > > > > > > I was just wondering whether LAM could be the similar case that > > > the host > > > disabled the feature somehow (e.g via clearcpuid), and the guest > > > still want > > > to use it. > > > > Paging modes in root & non-root are orthogonal, so should LAM. > > Agree. > Understand In https://lore.kernel.org/lkml/1548950983-18458-1-git-send-email-yu.c.zhang@linux.intel.com/ , it mentioned "As discussed earlier, VMs can still benefit from extended linear address width, e.g. to enhance features like ASLR. So we would like to fix this..." Apparently something was "discussed earlier", some request was made for that (perhaps related to ASLR). Read through kvm_set_cpu_caps(), such kind of handling, i.e. bypass host/KVM and expose the feature as long as HW supports it, is exception case. Therefore, though LAM could be done like LA57, I hesitate to make LAM exception case to break existing framework, unless analogous discussion/request for it occurs.
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) ); kvm_cpu_cap_init_kvm_defined(CPUID_7_1_EDX,