| Message ID | 20230404122652.275005-3-aleksandr.mikhalitsyn@canonical.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: SVM: small tweaks for sev_hardware_setup | expand |
On Tue, 4 Apr 2023 14:26:52 +0200 Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> wrote: > Let's add a few pr_info's to sev_hardware_setup to make SEV/SEV-ES > enabling a little bit handier for users. Right now it's too hard > to guess why SEV/SEV-ES are failing to enable. > > There are a few reasons. > SEV: > - npt is disabled (module parameter) ^NPT > - CPU lacks some features (sev, decodeassists) > - Maximum SEV ASID is 0 > > SEV-ES: > - mmio_caching is disabled (module parameter) > - CPU lacks sev_es feature > - Minimum SEV ASID value is 1 (can be adjusted in BIOS/UEFI) > > Cc: Sean Christopherson <seanjc@google.com> > Cc: Paolo Bonzini <pbonzini@redhat.com> > Cc: Stéphane Graber <stgraber@ubuntu.com> > Cc: kvm@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> > --- > arch/x86/kvm/svm/sev.c | 27 +++++++++++++++++++++------ > 1 file changed, 21 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > index a42536a0681a..14cbb8f14c6b 100644 > --- a/arch/x86/kvm/svm/sev.c > +++ b/arch/x86/kvm/svm/sev.c > @@ -2168,17 +2168,24 @@ void __init sev_hardware_setup(void) > bool sev_es_supported = false; > bool sev_supported = false; > > - if (!sev_enabled || !npt_enabled) > + if (!sev_enabled) > goto out; > > + if (!npt_enabled) { > + pr_info("Failed to enable AMD SEV as it requires Nested Paging to be enabled\n"); > + goto out; Shouldn't we use pr_err() for error message? > + } > + > /* > * SEV must obviously be supported in hardware. Sanity check that the > * CPU supports decode assists, which is mandatory for SEV guests to > * support instruction emulation. > */ > if (!boot_cpu_has(X86_FEATURE_SEV) || > - WARN_ON_ONCE(!boot_cpu_has(X86_FEATURE_DECODEASSISTS))) > + WARN_ON_ONCE(!boot_cpu_has(X86_FEATURE_DECODEASSISTS))) { > + pr_info("Failed to enable AMD SEV as it requires decodeassists and sev CPU features\n"); > goto out; > + } > > /* Retrieve SEV CPUID information */ > cpuid(0x8000001f, &eax, &ebx, &ecx, &edx); > @@ -2188,8 +2195,10 @@ void __init sev_hardware_setup(void) > > /* Maximum number of encrypted guests supported simultaneously */ > max_sev_asid = ecx; > - if (!max_sev_asid) > + if (!max_sev_asid) { > + pr_info("Failed to enable SEV as the maximum SEV ASID value is 0.\n"); > goto out; > + } > > /* Minimum ASID value that should be used for SEV guest */ > min_sev_asid = edx; > @@ -2234,16 +2243,22 @@ void __init sev_hardware_setup(void) > * instead relies on #NPF(RSVD) being reflected into the guest as #VC > * (the guest can then do a #VMGEXIT to request MMIO emulation). > */ > - if (!enable_mmio_caching) > + if (!enable_mmio_caching) { > + pr_info("Failed to enable SEV-ES as it requires MMIO caching to be enabled\n"); > goto out; > + } > > /* Does the CPU support SEV-ES? */ > - if (!boot_cpu_has(X86_FEATURE_SEV_ES)) > + if (!boot_cpu_has(X86_FEATURE_SEV_ES)) { > + pr_info("Failed to enable SEV-ES as it requires sev_es CPU feature\n"); > goto out; > + } > > /* Has the system been allocated ASIDs for SEV-ES? */ > - if (min_sev_asid == 1) > + if (min_sev_asid == 1) { > + pr_info("Failed to enable SEV-ES as the minimum SEV ASID value is 1.\n"); > goto out; > + } > > sev_es_asid_count = min_sev_asid - 1; > if (misc_cg_set_capacity(MISC_CG_RES_SEV_ES, sev_es_asid_count)) As this patch is making sev_hardware_setup()more informative, it would be better to print both ASID range and count (instead of only ASID count in the current code). I was suspecting there seems a bug of ASID range allocation in the current code, but I don't have the HW to test yet...
On Tue, Apr 11, 2023 at 9:43 PM Zhi Wang <zhi.wang.linux@gmail.com> wrote: > > On Tue, 4 Apr 2023 14:26:52 +0200 > Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> wrote: > > > Let's add a few pr_info's to sev_hardware_setup to make SEV/SEV-ES > > enabling a little bit handier for users. Right now it's too hard > > to guess why SEV/SEV-ES are failing to enable. > > > > There are a few reasons. > > SEV: > > - npt is disabled (module parameter) > ^NPT > > - CPU lacks some features (sev, decodeassists) > > - Maximum SEV ASID is 0 > > > > SEV-ES: > > - mmio_caching is disabled (module parameter) > > - CPU lacks sev_es feature > > - Minimum SEV ASID value is 1 (can be adjusted in BIOS/UEFI) > > > > Cc: Sean Christopherson <seanjc@google.com> > > Cc: Paolo Bonzini <pbonzini@redhat.com> > > Cc: Stéphane Graber <stgraber@ubuntu.com> > > Cc: kvm@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org > > Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> > > --- > > arch/x86/kvm/svm/sev.c | 27 +++++++++++++++++++++------ > > 1 file changed, 21 insertions(+), 6 deletions(-) > > > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > > index a42536a0681a..14cbb8f14c6b 100644 > > --- a/arch/x86/kvm/svm/sev.c > > +++ b/arch/x86/kvm/svm/sev.c > > @@ -2168,17 +2168,24 @@ void __init sev_hardware_setup(void) > > bool sev_es_supported = false; > > bool sev_supported = false; > > > > - if (!sev_enabled || !npt_enabled) > > + if (!sev_enabled) > > goto out; > > > > + if (!npt_enabled) { > > + pr_info("Failed to enable AMD SEV as it requires Nested Paging to be enabled\n"); > > + goto out; > > Shouldn't we use pr_err() for error message? I'm not sure. Because technically that's not an error, that is an information message about current configuration. > > > + } > > + > > /* > > * SEV must obviously be supported in hardware. Sanity check that the > > * CPU supports decode assists, which is mandatory for SEV guests to > > * support instruction emulation. > > */ > > if (!boot_cpu_has(X86_FEATURE_SEV) || > > - WARN_ON_ONCE(!boot_cpu_has(X86_FEATURE_DECODEASSISTS))) > > + WARN_ON_ONCE(!boot_cpu_has(X86_FEATURE_DECODEASSISTS))) { > > + pr_info("Failed to enable AMD SEV as it requires decodeassists and sev CPU features\n"); > > goto out; > > + } > > > > /* Retrieve SEV CPUID information */ > > cpuid(0x8000001f, &eax, &ebx, &ecx, &edx); > > @@ -2188,8 +2195,10 @@ void __init sev_hardware_setup(void) > > > > /* Maximum number of encrypted guests supported simultaneously */ > > max_sev_asid = ecx; > > - if (!max_sev_asid) > > + if (!max_sev_asid) { > > + pr_info("Failed to enable SEV as the maximum SEV ASID value is 0.\n"); > > goto out; > > + } > > > > /* Minimum ASID value that should be used for SEV guest */ > > min_sev_asid = edx; > > @@ -2234,16 +2243,22 @@ void __init sev_hardware_setup(void) > > * instead relies on #NPF(RSVD) being reflected into the guest as #VC > > * (the guest can then do a #VMGEXIT to request MMIO emulation). > > */ > > - if (!enable_mmio_caching) > > + if (!enable_mmio_caching) { > > + pr_info("Failed to enable SEV-ES as it requires MMIO caching to be enabled\n"); > > goto out; > > + } > > > > /* Does the CPU support SEV-ES? */ > > - if (!boot_cpu_has(X86_FEATURE_SEV_ES)) > > + if (!boot_cpu_has(X86_FEATURE_SEV_ES)) { > > + pr_info("Failed to enable SEV-ES as it requires sev_es CPU feature\n"); > > goto out; > > + } > > > > /* Has the system been allocated ASIDs for SEV-ES? */ > > - if (min_sev_asid == 1) > > + if (min_sev_asid == 1) { > > + pr_info("Failed to enable SEV-ES as the minimum SEV ASID value is 1.\n"); > > goto out; > > + } > > > > sev_es_asid_count = min_sev_asid - 1; > > if (misc_cg_set_capacity(MISC_CG_RES_SEV_ES, sev_es_asid_count)) > > As this patch is making sev_hardware_setup()more informative, it would be > better to print both ASID range and count (instead of only ASID count in > the current code). I was suspecting there seems a bug of ASID range allocation > in the current code, but I don't have the HW to test yet...
On Tue, Apr 04, 2023, Alexander Miqqqqkhalitsyn wrote: > Let's add a few pr_info's to sev_hardware_setup to make SEV/SEV-ES > enabling a little bit handier for users. Right now it's too hard > to guess why SEV/SEV-ES are failing to enable. Hmm, I'm somewhat torn, but I'm against taking this patch, at least not in its current form. I appreciated that determining why KVM isn't enabling SEV/SEV-ES is annoying, but there's very little actionable information provided here that isn't also super obvious. I also don't want to start us down a slippery slope of printing out messages every time KVM doesn't enable a feature. If someone tries to enable SEV and doesn't check that their CPU supports SEV, then IMO that's on them. Ditto for SEV-ES. The NPT thing is mildly interesting, but practically speaking I don't expect that to ever be a hindrace for generic enabling. Ditto for MMIO caching. The decode assists check is (a) completely unactionable for the vast, vast majority of users and (b) is a WARN_ON_ONCE() condition. The ASID stuff is by far the most interesting, but that's also quite interesting for when SEV and SEV-ES _are_ fully supported. So if we want to provide the user more info, I'd prefer to do something like the below, which I think would be more helpful and would avoid my slippery slope concerns. diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index c25aeb550cd9..eb4c6e3812d9 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -2216,7 +2216,6 @@ void __init sev_hardware_setup(void) if (misc_cg_set_capacity(MISC_CG_RES_SEV, sev_asid_count)) goto out; - pr_info("SEV supported: %u ASIDs\n", sev_asid_count); sev_supported = true; /* SEV-ES support requested? */ @@ -2243,11 +2242,16 @@ void __init sev_hardware_setup(void) sev_es_asid_count = min_sev_asid - 1; if (misc_cg_set_capacity(MISC_CG_RES_SEV_ES, sev_es_asid_count)) goto out; - - pr_info("SEV-ES supported: %u ASIDs\n", sev_es_asid_count); sev_es_supported = true; out: + if (boot_cpu_has(X86_FEATURE_SEV)) + pr_info("SEV %s (ASIDs %u - %u)\n", + sev_supported ? "enabled" : "disabled", ...); + if (boot_cpu_has(X86_FEATURE_SEV_ES)) + pr_info("SEV-ES %s (ASIDs %u - %u)\n", + sev_es_supported ? "enabled" : "disabled", ...); + sev_enabled = sev_supported; sev_es_enabled = sev_es_supported; #endif
On Fri, May 19, 2023 at 8:17 PM Sean Christopherson <seanjc@google.com> wrote: > > On Tue, Apr 04, 2023, Alexander Miqqqqkhalitsyn wrote: > > Let's add a few pr_info's to sev_hardware_setup to make SEV/SEV-ES > > enabling a little bit handier for users. Right now it's too hard > > to guess why SEV/SEV-ES are failing to enable. > > Hmm, I'm somewhat torn, but I'm against taking this patch, at least not in its > current form. I appreciated that determining why KVM isn't enabling SEV/SEV-ES > is annoying, but there's very little actionable information provided here that > isn't also super obvious. I also don't want to start us down a slippery slope > of printing out messages every time KVM doesn't enable a feature. > > If someone tries to enable SEV and doesn't check that their CPU supports SEV, > then IMO that's on them. Ditto for SEV-ES. > > The NPT thing is mildly interesting, but practically speaking I don't expect that > to ever be a hindrace for generic enabling. Ditto for MMIO caching. > > The decode assists check is (a) completely unactionable for the vast, vast majority > of users and (b) is a WARN_ON_ONCE() condition. > > The ASID stuff is by far the most interesting, but that's also quite interesting > for when SEV and SEV-ES _are_ fully supported. > > So if we want to provide the user more info, I'd prefer to do something like the > below, which I think would be more helpful and would avoid my slippery slope > concerns. Dear Sean, Thanks for looking into this! I agree with your points, let's go that way and print only ASID stuff as it can be not obvious to the end-user. I'm ready to prepare -v2 if you don't mind. Kind regards, Alex > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > index c25aeb550cd9..eb4c6e3812d9 100644 > --- a/arch/x86/kvm/svm/sev.c > +++ b/arch/x86/kvm/svm/sev.c > @@ -2216,7 +2216,6 @@ void __init sev_hardware_setup(void) > if (misc_cg_set_capacity(MISC_CG_RES_SEV, sev_asid_count)) > goto out; > > - pr_info("SEV supported: %u ASIDs\n", sev_asid_count); > sev_supported = true; > > /* SEV-ES support requested? */ > @@ -2243,11 +2242,16 @@ void __init sev_hardware_setup(void) > sev_es_asid_count = min_sev_asid - 1; > if (misc_cg_set_capacity(MISC_CG_RES_SEV_ES, sev_es_asid_count)) > goto out; > - > - pr_info("SEV-ES supported: %u ASIDs\n", sev_es_asid_count); > sev_es_supported = true; > > out: > + if (boot_cpu_has(X86_FEATURE_SEV)) > + pr_info("SEV %s (ASIDs %u - %u)\n", > + sev_supported ? "enabled" : "disabled", ...); > + if (boot_cpu_has(X86_FEATURE_SEV_ES)) > + pr_info("SEV-ES %s (ASIDs %u - %u)\n", > + sev_es_supported ? "enabled" : "disabled", ...); > + > sev_enabled = sev_supported; > sev_es_enabled = sev_es_supported; > #endif
On Fri, May 19, 2023, Aleksandr Mikhalitsyn wrote: > On Fri, May 19, 2023 at 8:17 PM Sean Christopherson <seanjc@google.com> wrote: > > > > On Tue, Apr 04, 2023, Alexander Miqqqqkhalitsyn wrote: > > > Let's add a few pr_info's to sev_hardware_setup to make SEV/SEV-ES > > > enabling a little bit handier for users. Right now it's too hard > > > to guess why SEV/SEV-ES are failing to enable. > > > > Hmm, I'm somewhat torn, but I'm against taking this patch, at least not in its > > current form. I appreciated that determining why KVM isn't enabling SEV/SEV-ES > > is annoying, but there's very little actionable information provided here that > > isn't also super obvious. I also don't want to start us down a slippery slope > > of printing out messages every time KVM doesn't enable a feature. > > > > If someone tries to enable SEV and doesn't check that their CPU supports SEV, > > then IMO that's on them. Ditto for SEV-ES. > > > > The NPT thing is mildly interesting, but practically speaking I don't expect that > > to ever be a hindrace for generic enabling. Ditto for MMIO caching. > > > > The decode assists check is (a) completely unactionable for the vast, vast majority > > of users and (b) is a WARN_ON_ONCE() condition. > > > > The ASID stuff is by far the most interesting, but that's also quite interesting > > for when SEV and SEV-ES _are_ fully supported. > > > > So if we want to provide the user more info, I'd prefer to do something like the > > below, which I think would be more helpful and would avoid my slippery slope > > concerns. > > Dear Sean, > > Thanks for looking into this! > > I agree with your points, let's go that way and print only ASID stuff > as it can be not obvious to the end-user. > > I'm ready to prepare -v2 if you don't mind. Ya, fire away. Thanks!
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index a42536a0681a..14cbb8f14c6b 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -2168,17 +2168,24 @@ void __init sev_hardware_setup(void) bool sev_es_supported = false; bool sev_supported = false; - if (!sev_enabled || !npt_enabled) + if (!sev_enabled) goto out; + if (!npt_enabled) { + pr_info("Failed to enable AMD SEV as it requires Nested Paging to be enabled\n"); + goto out; + } + /* * SEV must obviously be supported in hardware. Sanity check that the * CPU supports decode assists, which is mandatory for SEV guests to * support instruction emulation. */ if (!boot_cpu_has(X86_FEATURE_SEV) || - WARN_ON_ONCE(!boot_cpu_has(X86_FEATURE_DECODEASSISTS))) + WARN_ON_ONCE(!boot_cpu_has(X86_FEATURE_DECODEASSISTS))) { + pr_info("Failed to enable AMD SEV as it requires decodeassists and sev CPU features\n"); goto out; + } /* Retrieve SEV CPUID information */ cpuid(0x8000001f, &eax, &ebx, &ecx, &edx); @@ -2188,8 +2195,10 @@ void __init sev_hardware_setup(void) /* Maximum number of encrypted guests supported simultaneously */ max_sev_asid = ecx; - if (!max_sev_asid) + if (!max_sev_asid) { + pr_info("Failed to enable SEV as the maximum SEV ASID value is 0.\n"); goto out; + } /* Minimum ASID value that should be used for SEV guest */ min_sev_asid = edx; @@ -2234,16 +2243,22 @@ void __init sev_hardware_setup(void) * instead relies on #NPF(RSVD) being reflected into the guest as #VC * (the guest can then do a #VMGEXIT to request MMIO emulation). */ - if (!enable_mmio_caching) + if (!enable_mmio_caching) { + pr_info("Failed to enable SEV-ES as it requires MMIO caching to be enabled\n"); goto out; + } /* Does the CPU support SEV-ES? */ - if (!boot_cpu_has(X86_FEATURE_SEV_ES)) + if (!boot_cpu_has(X86_FEATURE_SEV_ES)) { + pr_info("Failed to enable SEV-ES as it requires sev_es CPU feature\n"); goto out; + } /* Has the system been allocated ASIDs for SEV-ES? */ - if (min_sev_asid == 1) + if (min_sev_asid == 1) { + pr_info("Failed to enable SEV-ES as the minimum SEV ASID value is 1.\n"); goto out; + } sev_es_asid_count = min_sev_asid - 1; if (misc_cg_set_capacity(MISC_CG_RES_SEV_ES, sev_es_asid_count))
Let's add a few pr_info's to sev_hardware_setup to make SEV/SEV-ES enabling a little bit handier for users. Right now it's too hard to guess why SEV/SEV-ES are failing to enable. There are a few reasons. SEV: - npt is disabled (module parameter) - CPU lacks some features (sev, decodeassists) - Maximum SEV ASID is 0 SEV-ES: - mmio_caching is disabled (module parameter) - CPU lacks sev_es feature - Minimum SEV ASID value is 1 (can be adjusted in BIOS/UEFI) Cc: Sean Christopherson <seanjc@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Stéphane Graber <stgraber@ubuntu.com> Cc: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> --- arch/x86/kvm/svm/sev.c | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-)