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

[Tim Wiederhake]

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.
> > > > 
> > > > This series documents the two undocumented constraints (irqchip
> > > > before
> > > > vcpu, APIC base memory hole) and adds early checks so the error
> > > > is
> > > > reported at the ioctl that actually violates the constraint.
> > > > 
> > > > Patches 1-2 are documentation only.  Patches 3-4 add early
> > > > validation
> > > > that turns a confusing -EEXIST at vcpu creation into an
> > > > explicit
> > > > error
> > > > at the point where the conflict is introduced.
> > > 
> > > I'm 100% in favor of documenting the behavior, but I'm not
> > > exactly
> > > excited about
> > > the enforcement.  It's not needed for KVM's safety, and while I
> > > appreciate that
> > > such a goof would be somewhat annoying to debug, I have a hard
> > > time
> > > believing it's
> > > a common failure.  I.e. I'm not convinced carrying the code is
> > > worth
> > > the marginal
> > > benefits it provides.
> > 
> > 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. 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.

> > indeed quite a ride. The EEXIST from vcpu creation led me
> > completely
> > astray and I was very close to just giving up. If I had, I wouldn't
> > have written this patch, and the failure would be perceived as even
> > less common.
> > 
> > I don't mind dropping patches 3 and 4 (the actual "enforcement"
> > patches) for v2, the documentation is more important in my opinion.
> > Still, if there is interest, I'd be more than happy to rework these
> > patches for eventual inclusion.
> > 
> > Thanks for the review,
> > Tim
> >