Re: [RFC PATCH] target/i386: SEV: Allow pflash devices with SEV-ES guests

[Sean Christopherson <seanjc@google.com>]

On Thu, Jun 11, 2026, Naveen N Rao wrote:
> On Wed, Jun 10, 2026 at 02:33:20PM -0500, Michael Roth wrote:
> > > > Right, normal well-behaved SEV-ES/SNP guests work just fine as they 
> > > > don't write to any of the read-only areas.
> > > 
> > > Yes they do. There is specific support to make a direct GHCB MMIO
> > > request because of the lack of the #VC exception (see
> > > OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlashDxe.c).
> 
> Good to know!
> 
> > With that change in place, it seems like we don't have remaining guest-side
> > code for ES/SNP guests that relies on emulate-on-write in OVMF for private
> > MMIO (seems like it never would have worked properly anyway).
> > 
> > It's possible we still rely on emulate-on-write for writes to shared MMIO
> > ranges though. But in that case I don't see why it wouldn't be okay to
> > continue to just forward the corresponding write-faults to userspace as
> > KVM_EXIT_MMIO events since QEMU can access shared memory just fine.
> > 
> > It's only the private MMIO that would misbehave because the emulation
> > path ... but I'm a little confused on this, because we'd still get #NPFs
> > due to the write protection... and it looks like this would trigger a
> > KVM_EXIT_MEMORY_FAULT to QEMU... so if QEMU really wanted to catch this
> > case... which seems to be the only one that's indicative of misbehavior,
> > we could just terminate if the access is to a read-only memslot and we
> > are running an ES/SNP guest... so if that's all that's holding us back
> > on the kernel side, we could directly start re-advertising
> > KVM_CAP_READONLY_MEM, or some new variant of it where userspace needs to
> > be aware of these additional considerations for private MMIO.
> 
> Right, Sean did suggest a change to do exactly that (send out -EFAULT to 
> userspace on writes to RO memslots):
> https://lore.kernel.org/kvm/aUq9_cUDWeEW_qli@google.com/
> 
> This change kills a KVM_X86_DEFAULT_VM SEV-ES guest if it writes to RO 
> memslot. If Sean's change disabling KVM_CAP_READONLY_MEM for SEV-ES 
> guests (and the subsequent commit d30d9ee94cc0 ("KVM: x86: Only 
> advertise KVM_CAP_READONLY_MEM when supported by VM")) are reverted, 
> this results in what you are describing: killing SEV-ES guests that 
> write to RO memslot without #NPF loop.
> 
> This was discussed in PUCK and my understanding is that Sean is still 
> opposed to enabling KVM_CAP_READONLY_MEM for SEV-ES guests (and he has 
> written as much in the above mail I have linked to).
> 
> Introducing a variant of KVM_CAP_READONLY_MEM might be a good option 
> - I suppose Qemu can just check for that capability for encrypted guests 
>   and everything else can mostly work as-is.
> 
> Sean?

If you're ok terminating the guest, just map the memory as read-only in the VMA
so that faulting in the PFN fails with KVM_PFN_ERR_FAULT => -EFAULT.

If we also need to support guest_memfd, then I would prefer to add support for
RWX memory attributes (per-VM), which are allegedly being working on by Amazon
and/or Microsoft for VBS(-like) support in KVM.

https://lore.kernel.org/all/Y1a1i9vbJ%2FpVmV9r@google.com