On Fri, Dec 20, 2024, Daniel P. Berrangé wrote: > On Thu, Dec 19, 2024 at 04:04:45PM -0600, Kalra, Ashish wrote: > > On 12/18/2024 7:11 PM, Kalra, Ashish wrote: > > > But, i believe there is another alternative approach : > > > > > > - PSP driver can call SEV Shutdown right before calling DLFW_EX and then do > > > a SEV INIT after successful DLFW_EX, in other words, we wrap DLFW_EX with > > > SEV_SHUTDOWN prior to it and SEV INIT post it. This approach will also allow > > > us to do both SNP and SEV INIT at KVM module load time, there is no need to > > > do SEV INIT lazily or on demand before SEV/SEV-ES VM launch. > > > > > > This approach should work without any changes in qemu and also allow > > > SEV firmware hotloading without having any concerns about SEV INIT state. > > > > > > > And to add here that SEV Shutdown will succeed with active SEV and SNP guests. > > > > SEV Shutdown (internally) marks all SEV asids as invalid and decommission all > > SEV guests and does not affect SNP guests. > > > > So any active SEV guests will be implicitly shutdown and SNP guests will not be > > affected after SEV Shutdown right before doing SEV firmware hotloading and > > calling DLFW_EX command. > > > > It should be fine to expect that there are no active SEV guests or any active > > SEV guests will be shutdown as part of SEV firmware hotloading while keeping > > SNP guests running. > > That's a pretty subtle distinction that I don't think host admins will > be likely to either learn about or remember. IMHO if there are active > SEV guests, the kernel should refuse the run the operation, rather > than kill running guests. The host admin must decide whether it is > appropriate to shutdown the guests in order to be able to run the > upgrade. +1 to this and what Dionna said. Aside from being a horrible experience for userspace, trying to forcefully stop actions from within the kernel gets ugly.
