Re: [PATCH 0/4] KVM: x86: Document and enforce APIC base memory hole

[Sean Christopherson]

On Wed, Jul 08, 2026, Tim Wiederhake wrote:
> On Wed, 2026-07-08 at 06:41 -0700, Sean Christopherson wrote:
> > On Wed, Jul 08, 2026, Tim Wiederhake wrote:
> > > On Mon, 2026-07-06 at 15:26 -0700, Sean Christopherson wrote:
> > > > On Mon, Jul 06, 2026, Tim Wiederhake wrote:
> > > > > When an in-kernel irqchip is enabled on x86, KVM installs a private
> > > > > memory slot at the default APIC base address (0xfee00000) during vcpu
> > > > > creation.  If user space has already mapped a memory region covering
> > > > > that address, vcpu creation fails with -EEXIST.  The same happens in
> > > > > reverse: mapping memory over the APIC base after vcpu creation also
> > > > > fails with -EEXIST.
> > > > > 
> > > > > None of this is documented, and the error is reported far from where
> > > > > the actual conflict is introduced.  A VMM developer hitting this has
> > > > > to trace through KVM internals to understand what went wrong.
> > > > I'm 100% in favor of documenting the behavior, but I'm not exactly
> > > > excited about the enforcement.

...

> > > FWIW, I did run into this exact issue myself and debugging it was
> > 
> > What were you doing (or trying to do?) when you ran afoul of this?  I ask
> > because maybe there's a way to help developers without impacting KVM's
> > uABI.
> 
> Experimenting, mostly with pmode code. 

"pmode" being Protected Mode?  Or something else?

> For simplicity, I use a single memory slot at 0x0. Due to an off-by-one
> error, I gave the VM only 2 GB instead of 4 GB as intended. When I fixed
> that, suddenly vcpu creation failed.

Heh, fun.  I don't think there's a good answer here.  Or rather, I don't think
there's an answer that you'll find satisfying.  "Unintentionally" creating a
memslot that overlaps the PCI hole and the RESET vector is always going to end
in tears unless VMM and the guest are doing very special things.  I.e. not
covering up the local APIC base is so foundational that trying to guard against
it in KVM isn't worthwhile, because such a goof is just the tip of the iceberg.