| Message ID | 20240227192451.3792233-1-seanjc@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [GIT,PULL] KVM: x86: SVM changes for 6.9 | expand |
On Tue, Feb 27, 2024 at 8:24 PM Sean Christopherson <seanjc@google.com> wrote: > Please pull a single series that allows KVM to play nice with systems that have > all ASIDs binned to SEV-ES+ guests, which makes SEV unusuable despite being > enabled. Ok, will do so tomorrow. > This is the main source of conflicts between kvm/next and your "allow > customizing VMSA features". guest_memfd_fixes also has a minor conflict in > kvm_is_vm_type_supported(), but you should already have that pull request for > 6.8[1]. > > There is one more trivial conflict in my "misc" branch, in > kvm_vcpu_ioctl_x86_set_debugregs(), but I am going to hold off one sending a > pull request for that branch until next week. The main reason is because I > screwed up and forgot to push a pile of commits from my local tree to kvm-x86, > and sending a pull request for ~3 commits, and then another for the remaining > 16 or so commits seemed rather silly. The other reason is that I am hoping we > can avoid that conflict entirely, by adding a common choke point in > kvm_arch_vcpu_ioctl()[2]. Yes, I'll do that. I have to respin anyway to get the SEV test infrastructure. I'll keep posting against kvm-x86/next, though. Paolo
Please pull a single series that allows KVM to play nice with systems that have all ASIDs binned to SEV-ES+ guests, which makes SEV unusuable despite being enabled. This is the main source of conflicts between kvm/next and your "allow customizing VMSA features". guest_memfd_fixes also has a minor conflict in kvm_is_vm_type_supported(), but you should already have that pull request for 6.8[1]. There is one more trivial conflict in my "misc" branch, in kvm_vcpu_ioctl_x86_set_debugregs(), but I am going to hold off one sending a pull request for that branch until next week. The main reason is because I screwed up and forgot to push a pile of commits from my local tree to kvm-x86, and sending a pull request for ~3 commits, and then another for the remaining 16 or so commits seemed rather silly. The other reason is that I am hoping we can avoid that conflict entirely, by adding a common choke point in kvm_arch_vcpu_ioctl()[2]. [1] https://lore.kernel.org/all/20240223211547.3348606-1-seanjc@google.com [2] https://lore.kernel.org/all/ZdjL783FazB6V6Cy@google.com The following changes since commit 41bccc98fb7931d63d03f326a746ac4d429c1dd3: Linux 6.8-rc2 (2024-01-28 17:01:12 -0800) are available in the Git repository at: https://github.com/kvm-x86/linux.git tags/kvm-x86-svm-6.9 for you to fetch changes up to fdd58834d132046149699b88a27a0db26829f4fb: KVM: SVM: Return -EINVAL instead of -EBUSY on attempt to re-init SEV/SEV-ES (2024-02-06 11:10:12 -0800) ---------------------------------------------------------------- KVM SVM changes for 6.9: - Add support for systems that are configured with SEV and SEV-ES+ enabled, but have all ASIDs assigned to SEV-ES+ guests, which effectively makes SEV unusuable. Cleanup ASID handling to make supporting this scenario less brittle/ugly. - Return -EINVAL instead of -EBUSY if userspace attempts to invoke KVM_SEV{,ES}_INIT on an SEV+ guest. The operation is simply invalid, and not related to resource contention in any way. ---------------------------------------------------------------- Ashish Kalra (1): KVM: SVM: Add support for allowing zero SEV ASIDs Sean Christopherson (3): KVM: SVM: Set sev->asid in sev_asid_new() instead of overloading the return KVM: SVM: Use unsigned integers when dealing with ASIDs KVM: SVM: Return -EINVAL instead of -EBUSY on attempt to re-init SEV/SEV-ES arch/x86/kvm/svm/sev.c | 58 +++++++++++++++++++++++++++++--------------------- arch/x86/kvm/trace.h | 10 ++++----- 2 files changed, 39 insertions(+), 29 deletions(-)