Re: [PATCH v2 03/12] KVM: Add KVM_GET_EXT_LAPIC and KVM_SET_EXT_LAPIC for extapic

[Sean Christopherson <seanjc@google.com>]

On Tue, Dec 16, 2025, Naveen N Rao wrote:
> On Mon, Sep 01, 2025 at 10:51:46AM +0530, Manali Shukla wrote:
> > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > index 6aa40ee05a4a..0653718a4f04 100644
> > --- a/Documentation/virt/kvm/api.rst
> > +++ b/Documentation/virt/kvm/api.rst
> > @@ -2048,6 +2048,18 @@ error.
> >  Reads the Local APIC registers and copies them into the input argument.  The
> >  data format and layout are the same as documented in the architecture manual.
> >  
> > +::
> > +
> > +  #define KVM_APIC_EXT_REG_SIZE 0x540

As discussed in PUCK, just go the full 0x1000 bytes, and do:

#define KVM_GET_LAPIC2            _IOR(KVMIO,  0x8e, struct kvm_lapic_state2)
#define KVM_SET_LAPIC2            _IOW(KVMIO,  0x8f, struct kvm_lapic_state2)

> > +  struct kvm_ext_lapic_state {
> > +	__DECLARE_FLEX_ARRAY(__u8, regs);
> > +  };
> > +
> > +Applications should use KVM_GET_EXT_LAPIC ioctl if extended APIC is
> > +enabled. KVM_GET_EXT_LAPIC reads Local APIC registers with extended
> > +APIC register space located at offsets 400h-530h and copies them into input
> > +argument.
> 
> I suppose the reason for using a flex array was for addressing review 
> comments on the previous version -- to make the new APIs extensible so 
> that they can accommodate any future changes to the extended APIC 
> register space.
> 
> I wonder if it would be better to introduce a KVM extension, say 
> KVM_CAP_EXT_LAPIC (along the lines of KVM_CAP_PMU_CAPABILITY).

Please figure out a different name than "ext_lapic".  Verbatim from the SDM
(minus a closing parenthesis)

  the xAPIC architecture) is an extension of the APIC architecture

and

  EXTENDED XAPIC (X2APIC)
  The x2APIC architecture extends the xAPIC architecture

There's zero chance I'm going to remember which "extended" we're talking about. 

KVM_CAP_X2APIC_API further muddies the waters, so maybe something absurd and
arbitrary like KVM_CAP_LAPIC2?  The capability doesn't have to strictly follow
the naming of the underlying feature(s) it supports.