On 2/18/25 19:26, Sean Christopherson wrote: > This is a hastily thrown together series, barely above RFC, to try and > address the worst of the issues that arise with guest controlled SEV > features (thanks AP creation)[1]. > > In addition to the initial flaws with DebugSwap, I came across a variety > of issues when trying to figure out how best to handle SEV features in > general. E.g. AFAICT, KVM doesn't guard against userspace manually making > a vCPU RUNNABLE after it has been DESTROYED (or after a failed CREATE). > > This is essentially compile-tested only, as I don't have easy access to a > system with SNP enabled. I ran the SEV-ES selftests, but that's not much > in the way of test coverage. > > AMD folks, I would greatly appreciate reviews, testing, and most importantly, > confirmation that all of this actually works the way I think it does. A quick test of a 64 vCPU SNP guest booted successfully, so that's a good start. I'll take a closer look at these patches over the next few days. Thanks, Tom > > [1] https://lore.kernel.org/all/Z7TSef290IQxQhT2@xxxxxxxxxx > > Sean Christopherson (10): > KVM: SVM: Save host DR masks but NOT DRs on CPUs with DebugSwap > KVM: SVM: Don't rely on DebugSwap to restore host DR0..DR3 > KVM: SVM: Terminate the VM if a SEV-ES+ guest is run with an invalid > VMSA > KVM: SVM: Don't change target vCPU state on AP Creation VMGEXIT error > KVM: SVM: Require AP's "requested" SEV_FEATURES to match KVM's view > KVM: SVM: Simplify request+kick logic in SNP AP Creation handling > KVM: SVM: Use guard(mutex) to simplify SNP AP Creation error handling > KVM: SVM: Mark VMCB dirty before processing incoming snp_vmsa_gpa > KVM: SVM: Use guard(mutex) to simplify SNP vCPU state updates > KVM: SVM: Invalidate "next" SNP VMSA GPA even on failure > > arch/x86/kvm/svm/sev.c | 218 +++++++++++++++++++---------------------- > arch/x86/kvm/svm/svm.c | 7 +- > arch/x86/kvm/svm/svm.h | 2 +- > 3 files changed, 106 insertions(+), 121 deletions(-) > > > base-commit: fed48e2967f402f561d80075a20c5c9e16866e53
