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/[email protected]/ > > 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%[email protected]
