Re: [PATCH v2 0/9] Move initializing SEV/SNP functionality to KVM

[Sean Christopherson <seanjc@google.com>]

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.