Re: [PATCH 16/24] KVM: SEV: Decouple the need to sync the GHCB SA from the need to free the SA

[Sean Christopherson <seanjc@google.com>]

On Sat, May 30, 2026, sashiko-bot@kernel.org wrote:
> > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> > index 437282f0ea943..11d46600cbdc0 100644
> > --- a/arch/x86/kvm/svm/sev.c
> > +++ b/arch/x86/kvm/svm/sev.c
> > @@ -3560,20 +3560,17 @@ void sev_es_unmap_ghcb(struct vcpu_svm *svm)
> >  	if (!svm->sev_es.ghcb)
> >  		return;
> >  
> > -	if (svm->sev_es.ghcb_sa_free) {
> > -		/*
> > -		 * The scratch area lives outside the GHCB, so there is a
> > -		 * buffer that, depending on the operation performed, may
> > -		 * need to be synced, then freed.
> > -		 */
> > -		if (svm->sev_es.ghcb_sa_sync) {
> > -			kvm_write_guest(svm->vcpu.kvm,
> > -					svm->sev_es.sw_scratch,
> > -					svm->sev_es.ghcb_sa,
> > -					svm->sev_es.ghcb_sa_len);
> > -			svm->sev_es.ghcb_sa_sync = false;
> > -		}
> > +	/*
> > +	 * If the scratch area lives outside the GHCB, there's a buffer that,
> > +	 * depending on the operation performed, may need to be synced.
> > +	 */
> > +	if (svm->sev_es.ghcb_sa_sync) {
> > +		kvm_write_guest(svm->vcpu.kvm, svm->sev_es.sw_scratch,
> > +				svm->sev_es.ghcb_sa, svm->sev_es.ghcb_sa_len);
> > +		svm->sev_es.ghcb_sa_sync = false;
> > +	}
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but can this call to
> kvm_write_guest() trigger a warning

Yes.

> or cause silent guest memory corruption?

I suppose in theory, yes?

> In arch/x86/kvm/x86.c:vcpu_enter_guest(), KVM disables preemption before
> calling prepare_switch_to_guest():
> 
> 	preempt_disable();
> 
> 	kvm_x86_call(prepare_switch_to_guest)(vcpu);
> 
> For SEV-ES guests, this invokes svm_prepare_switch_to_guest() ->
> sev_es_unmap_ghcb(). Within sev_es_unmap_ghcb(), if svm->sev_es.ghcb_sa_sync is
> true, KVM calls kvm_write_guest().
> 
> Since kvm_write_guest() is a sleepable function and preemption is disabled,
> this could trigger a warning in might_fault(), potentially leading to a host
> denial of service if panic_on_warn is set.

LOL, yes, for all of those production environments that run with panic_on_warn=1,
CONFIG_DEBUG_ATOMIC_SLEEP=y, and a preemptible kernel model.

We (Google) have an internal patch that we've been carrying for a while, but it's
a hack.  It's basically:

	kvm_x86_call(prepare_switch_to_guest_early)(vcpu);

	preempt_disable();

	kvm_x86_call(prepare_switch_to_guest)(vcpu);

Given that the external scratch area is deprecated in v2, i.e. now that we know
it's not going to be a super common operation, I think the proper way to fix this
would be to have kvm_sev_es_mmio() and kvm_sev_es_{ins,outs}() sync and free the
buffer.