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

[Sean Christopherson <seanjc@google.com>]

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.

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