Re: [PATCH v1 6/9] KVM: Add KVM_GET_LAPIC2 and KVM_SET_LAPIC2 for extended APIC

[Naveen N Rao <naveen@kernel.org>]

On Mon, Mar 23, 2026 at 04:45:43PM +0530, Manali Shukla wrote:
> On 3/16/2026 6:30 PM, Nikunj A. Dadhania wrote:
> > 
> > 
> > On 2/4/2026 1:14 PM, Manali Shukla wrote:

...

> >> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> >> index 669c894f1061..ccd16bdff56a 100644
> >> --- a/arch/x86/kvm/x86.c
> >> +++ b/arch/x86/kvm/x86.c
> >> @@ -5331,6 +5331,17 @@ static int kvm_vcpu_ioctl_get_lapic(struct kvm_vcpu *vcpu,
> >>  	return kvm_apic_get_state(vcpu, s->regs, sizeof(*s));
> >>  }
> >>  
> >> +static int kvm_vcpu_ioctl_get_lapic2(struct kvm_vcpu *vcpu,
> >> +				    struct kvm_lapic_state2 *s)
> >> +{
> >> +	if (vcpu->arch.apic->guest_apic_protected)
> >> +		return -EINVAL;
> >> +
> >> +	kvm_x86_call(sync_pir_to_irr)(vcpu);
> >> +
> >> +	return kvm_apic_get_state(vcpu, s->regs, sizeof(*s));
> >> +}
> > 
> > Should this function verify that KVM_CAP_LAPIC2 was enabled for the VM?
> > The KVM_CAP_LAPIC2 documentation states "This must be called before
> > creating any VCPUs" which implies userspace must explicitly enable the
> > capability. However, this ioctl doesn't check kvm->arch.nr_extlvt or any
> > flag indicating the capability was enabled.
> > 
> > Looking at how this interacts with kvm_apic_get_state() in
> > arch/x86/kvm/lapic.c:
> > 
> >     int kvm_apic_get_state(struct kvm_vcpu *vcpu, void *regs, unsigned int size)
> >     {
> >         memcpy(regs, vcpu->arch.apic->regs, size);
> >         ...
> >     }
> > 
> > The function copies 'size' bytes from vcpu->arch.apic->regs. Since
> > sizeof(struct kvm_lapic_state2) is 4096 bytes and apic->regs is allocated
> > as a single page (also 4096 bytes), this works. But if the extended APIC
> > capability wasn't enabled via KVM_ENABLE_CAP, should userspace be allowed
> > to read the extended register space?
> > 
> 
> Yeah. Correct. If the capability is not enabled, userspace should not be
> allowed to read/write the extended register space. It makes sense to put
> a check here. I will fix this in V2.

I think the base KVM_GET_LAPIC2/KVM_SET_LAPIC2 ioctls should always be 
allowed, since we will now advertise KVM_CAP_LAPIC2 always.

Even though additional capability bits (to advertise AMD EXTAPIC space, 
for instance) may need some KVM code/validation, I am not sure we need 
to enforce it here by rejecting KVM_[G|S]ET_LAPIC2. 


- Naveen