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

[Tim Wiederhake]

On Thu, 2026-07-09 at 10:38 -0700, Sean Christopherson wrote:
> 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?
> 
Yes, Protected Mode.

> > 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.

I noticed :). And I learned a lot from the experience, which made it
worthwhile. But I'd love to make the experience less painful for the
next person, hence v2 that puts up some warning signs in the docs:
 
https://lore.kernel.org/kvm/20260708133856.302151-1-twiederh@xxxxxxxxxx/