[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a52c307c-66a8-41df-b40d-d4b4fcd5da5c@redhat.com>
Date: Fri, 17 May 2024 17:25:25 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sean Christopherson <seanjc@...gle.com>, Kai Huang <kai.huang@...el.com>
Cc: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
Rick Edgecombe <rick.p.edgecombe@...el.com>,
"sagis@...gle.com" <sagis@...gle.com>,
"dmatlack@...gle.com" <dmatlack@...gle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>,
Yan Y Zhao <yan.y.zhao@...el.com>, Erdem Aktas <erdemaktas@...gle.com>
Subject: Re: [PATCH 02/16] KVM: x86/mmu: Introduce a slot flag to zap only
slot leafs on slot deletion
On 5/15/24 21:09, Sean Christopherson wrote:
> Hmm, actually, we already have new uAPI/ABI in the form of VM types. What if
> we squeeze a documentation update into 6.10 (which adds the SEV VM flavors) to
> state that KVM's historical behavior of blasting all SPTEs is only_guaranteed_
> for KVM_X86_DEFAULT_VM?
>
> Anyone know if QEMU deletes shared-only, i.e. non-guest_memfd, memslots during
> SEV-* boot?
Yes, the process is mostly the same for normal UEFI boot, SEV and SEV-ES.
However, it does so while the VM is paused (remember the atomic memslot
updates attempts? that's now enforced by QEMU). So it's quite possible
that the old bug is not visible anymore, independent of why VFIO caused
it.
Paolo
> If so, and assuming any such memslots are smallish, we could even
> start enforcing the new ABI by doing a precise zap for small (arbitrary limit TBD)
> shared-only memslots for !KVM_X86_DEFAULT_VM VMs.
Powered by blists - more mailing lists