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

[Tim Wiederhake <twiederh@redhat.com>]

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