Re: [PATCH 1/1] KVM: x86/mmu: Emulate, don't kill the VM, on access to a disabled passthrough BAR

[Sean Christopherson <seanjc@google.com>]

On Tue, Jun 23, 2026, Mikhail Malyshev wrote:
> On Mon, Jun 22, 2026, Sean Christopherson wrote:
> > I really don't like this.  It's an ABI change that affects years of precedent,
> > and the ABI it creates is very haphazard.  E.g. why should PFNMAP memory get
> > emulate MMIO semantics for this case?  And a PROT_NONE VMA really shouldn't get
> > MMIO semantics either.
> >
> > I would rather have KVM exit to userspace with KVM_EXIT_MEMORY_FAULT and fill
> > run->memory_fault, i.e.
> 
> Agreed, thanks - that's the right layer, and the PROT_NONE case alone is reason
> enough not to overload the pfn classification the way I did.
> 
> For context on v1's shape: localizing the fix in KVM was a deliberate scoping
> choice - it was the smallest change that stopped the crash without updating
> another major component (the VMM) at the same time. I agree that optimizing for
> a single-component change put the policy in the wrong layer; KVM reporting
> KVM_EXIT_MEMORY_FAULT and the VMM applying device semantics is the right split.
> 
> Plan: implement your suggestion (kvm_mmu_prepare_memory_fault_exit() in
> kvm_handle_error_pfn()) and pair it with a QEMU change that recognizes a
> memory-fault on a vfio-pci BAR whose memory space is currently disabled and
> emulates it as an Unsupported Request (reads all ones, writes dropped) rather
> than aborting. Note QEMU's current KVM_EXIT_MEMORY_FAULT handling only covers
> guest_memfd shared/private conversion, so this is new vfio-pci handling on the
> VMM side - I'll test the kernel + QEMU pair against the reproducer before
> sending v2.
> 
> FWIW this is the concrete user the 2024 KVM_CAP_MEMORY_FAULT_INFO work
> (Zr-8M9rYplgN6IS3) was missing: an assigned Intel iGPU whose guest driver clears
> PCI_COMMAND.MEM on one vCPU while another is mid-MMIO to the BAR, which kills the
> VM. Reproducible on demand and seen in the field.
> 
> Two questions before I respin:
> 
> - Prefer I revive Anish's x86 patch from that series (rebased), or a fresh
>   minimal change against kvm-x86/next? The tree has moved a lot since 2024
>   (kvm_follow_pfn, etc.), so I was leaning fresh with a Link: to the original
>   and Suggested-by: you.

Oh, I forgot that Anish had posted the x86 MMU change as an isolated patch.

Given that patch 2 still applies cleanly, I would say take Anish's patch, rewrite
the changelog, and then give yourself a Co-developed-by.  I.e. give attribution
to both Anish and you.

> - You'd asked for KVM_BUG_ON() + -EIO conversions on that x86 patch - still want
>   those folded in,

Yes, please tack on a separate patch to convert the WARN_ON_ONCE()-protected
EFAULTS in x86's fault path to KVM_BUG_ON() + -EIO.

> and should this stay x86-only or also cover arm64?

Definitely keep your patches x86-only.  For all intents and purposes this is a
bug fix, let someone else deal with the pain of enabling KVM_CAP_MEMORY_FAULT_INFO
on arm64 :-)