| Message ID | 20210114003708.3798992-3-seanjc@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: SVM: Misc SEV cleanups | expand |
On 1/13/21 6:36 PM, Sean Christopherson wrote: > Free sev_asid_bitmap if the reclaim bitmap allocation fails, othwerise > KVM will unnecessarily keep the bitmap when SEV is not fully enabled. > > Freeing the page is also necessary to avoid introducing a bug when a > future patch eliminates svm_sev_enabled() in favor of using the global > 'sev' flag directly. While sev_hardware_enabled() checks max_sev_asid, > which is true even if KVM setup fails, 'sev' will be true if and only > if KVM setup fully succeeds. > > Fixes: 33af3a7ef9e6 ("KVM: SVM: Reduce WBINVD/DF_FLUSH invocations") > Cc: Tom Lendacky <thomas.lendacky@amd.com> > Signed-off-by: Sean Christopherson <seanjc@google.com> > --- > arch/x86/kvm/svm/sev.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > index c8ffdbc81709..0eeb6e1b803d 100644 > --- a/arch/x86/kvm/svm/sev.c > +++ b/arch/x86/kvm/svm/sev.c > @@ -1274,8 +1274,10 @@ void __init sev_hardware_setup(void) > goto out; > > sev_reclaim_asid_bitmap = bitmap_zalloc(max_sev_asid, GFP_KERNEL); > - if (!sev_reclaim_asid_bitmap) > + if (!sev_reclaim_asid_bitmap) { > + bitmap_free(sev_asid_bitmap); Until that future change, you probably need to do sev_asid_bitmap = NULL here to avoid an issue in sev_hardware_teardown() when it tries to free it again. Thanks, Tom > goto out; > + } > > pr_info("SEV supported: %u ASIDs\n", max_sev_asid - min_sev_asid + 1); > sev_supported = true; >
On Thu, Jan 14, 2021, Tom Lendacky wrote: > On 1/13/21 6:36 PM, Sean Christopherson wrote: > > Free sev_asid_bitmap if the reclaim bitmap allocation fails, othwerise > > KVM will unnecessarily keep the bitmap when SEV is not fully enabled. > > > > Freeing the page is also necessary to avoid introducing a bug when a > > future patch eliminates svm_sev_enabled() in favor of using the global > > 'sev' flag directly. While sev_hardware_enabled() checks max_sev_asid, > > which is true even if KVM setup fails, 'sev' will be true if and only > > if KVM setup fully succeeds. > > > > Fixes: 33af3a7ef9e6 ("KVM: SVM: Reduce WBINVD/DF_FLUSH invocations") > > Cc: Tom Lendacky <thomas.lendacky@amd.com> > > Signed-off-by: Sean Christopherson <seanjc@google.com> > > --- > > arch/x86/kvm/svm/sev.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > > index c8ffdbc81709..0eeb6e1b803d 100644 > > --- a/arch/x86/kvm/svm/sev.c > > +++ b/arch/x86/kvm/svm/sev.c > > @@ -1274,8 +1274,10 @@ void __init sev_hardware_setup(void) > > goto out; > > sev_reclaim_asid_bitmap = bitmap_zalloc(max_sev_asid, GFP_KERNEL); > > - if (!sev_reclaim_asid_bitmap) > > + if (!sev_reclaim_asid_bitmap) { > > + bitmap_free(sev_asid_bitmap); > > Until that future change, you probably need to do sev_asid_bitmap = NULL > here to avoid an issue in sev_hardware_teardown() when it tries to free it > again. Argh, you're right. Thanks!
On 1/14/21 11:12 AM, Sean Christopherson wrote: > On Thu, Jan 14, 2021, Tom Lendacky wrote: >> On 1/13/21 6:36 PM, Sean Christopherson wrote: >>> Free sev_asid_bitmap if the reclaim bitmap allocation fails, othwerise >>> KVM will unnecessarily keep the bitmap when SEV is not fully enabled. >>> >>> Freeing the page is also necessary to avoid introducing a bug when a >>> future patch eliminates svm_sev_enabled() in favor of using the global >>> 'sev' flag directly. While sev_hardware_enabled() checks max_sev_asid, >>> which is true even if KVM setup fails, 'sev' will be true if and only >>> if KVM setup fully succeeds. >>> >>> Fixes: 33af3a7ef9e6 ("KVM: SVM: Reduce WBINVD/DF_FLUSH invocations") Oops, missed this last time... I don't think the Fixes: tag is needed anymore unless you don't want the memory consumption of the first bitmap, should the allocation of the second bitmap fail, until kvm_amd is rmmod'ed. Up to you. Thanks, Tom >>> Cc: Tom Lendacky <thomas.lendacky@amd.com> >>> Signed-off-by: Sean Christopherson <seanjc@google.com> >>> --- >>> arch/x86/kvm/svm/sev.c | 4 +++- >>> 1 file changed, 3 insertions(+), 1 deletion(-) >>> >>> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c >>> index c8ffdbc81709..0eeb6e1b803d 100644 >>> --- a/arch/x86/kvm/svm/sev.c >>> +++ b/arch/x86/kvm/svm/sev.c >>> @@ -1274,8 +1274,10 @@ void __init sev_hardware_setup(void) >>> goto out; >>> sev_reclaim_asid_bitmap = bitmap_zalloc(max_sev_asid, GFP_KERNEL); >>> - if (!sev_reclaim_asid_bitmap) >>> + if (!sev_reclaim_asid_bitmap) { >>> + bitmap_free(sev_asid_bitmap); >> >> Until that future change, you probably need to do sev_asid_bitmap = NULL >> here to avoid an issue in sev_hardware_teardown() when it tries to free it >> again. > > Argh, you're right. Thanks! >
On Thu, Jan 14, 2021, Tom Lendacky wrote: > On 1/14/21 11:12 AM, Sean Christopherson wrote: > > On Thu, Jan 14, 2021, Tom Lendacky wrote: > > > On 1/13/21 6:36 PM, Sean Christopherson wrote: > > > > Free sev_asid_bitmap if the reclaim bitmap allocation fails, othwerise > > > > KVM will unnecessarily keep the bitmap when SEV is not fully enabled. > > > > > > > > Freeing the page is also necessary to avoid introducing a bug when a > > > > future patch eliminates svm_sev_enabled() in favor of using the global > > > > 'sev' flag directly. While sev_hardware_enabled() checks max_sev_asid, > > > > which is true even if KVM setup fails, 'sev' will be true if and only > > > > if KVM setup fully succeeds. > > > > > > > > Fixes: 33af3a7ef9e6 ("KVM: SVM: Reduce WBINVD/DF_FLUSH invocations") > > Oops, missed this last time... I don't think the Fixes: tag is needed > anymore unless you don't want the memory consumption of the first bitmap, If Fixes is viewed as purely a "this needs to be backported", then yes, it should be dropped. But, since KVM policy is to backport only patches that are explicitly tagged with stable@, I like to use to Fixes to create a paper trail for bug fixes even if the bug is essentially benign. That being said, I have no objection to dropping it if anyone feels strongly about not playing fast and loose with Fixes. > should the allocation of the second bitmap fail, until kvm_amd is rmmod'ed. > Up to you.
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index c8ffdbc81709..0eeb6e1b803d 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -1274,8 +1274,10 @@ void __init sev_hardware_setup(void) goto out; sev_reclaim_asid_bitmap = bitmap_zalloc(max_sev_asid, GFP_KERNEL); - if (!sev_reclaim_asid_bitmap) + if (!sev_reclaim_asid_bitmap) { + bitmap_free(sev_asid_bitmap); goto out; + } pr_info("SEV supported: %u ASIDs\n", max_sev_asid - min_sev_asid + 1); sev_supported = true;
Free sev_asid_bitmap if the reclaim bitmap allocation fails, othwerise KVM will unnecessarily keep the bitmap when SEV is not fully enabled. Freeing the page is also necessary to avoid introducing a bug when a future patch eliminates svm_sev_enabled() in favor of using the global 'sev' flag directly. While sev_hardware_enabled() checks max_sev_asid, which is true even if KVM setup fails, 'sev' will be true if and only if KVM setup fully succeeds. Fixes: 33af3a7ef9e6 ("KVM: SVM: Reduce WBINVD/DF_FLUSH invocations") Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Sean Christopherson <seanjc@google.com> --- arch/x86/kvm/svm/sev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)