Re: [PATCH v1 4/9] KVM: x86: Introduce KVM_CAP_LAPIC2 for 4KB APIC register space support

[Manali Shukla <manali.shukla@amd.com>]

Hi Naveen,

Thank you for reviewing my patches.

On 5/14/2026 6:38 PM, Naveen N Rao wrote:
> On Wed, Feb 04, 2026 at 07:44:47AM +0000, Manali Shukla wrote:
>> Add KVM_CAP_LAPIC2 to allow userspace to opt into extended APIC register
>> space, i.e. to expose the full 4KB APIC page to the guest.  Extended LVT
>> registers are part of the 4KB APIC page and are AMD-specific. Extended
>> APIC registers provide additional interrupt vectors for hardware features
>> like Instruction Based Sampling (IBS).
>>
>> Use a capability negotiation model to allow for future extensibility.
>> KVM_CHECK_EXTENSION returns a bitmask of supported capabilities, and
>> userspace enables the intersection of KVM and VMM support via
>> KVM_ENABLE_CAP.  This allows KVM and userspace to independently add
>> support for new APIC configurations without breaking compatibility.
>>
>> Define two capability flags:
>>   - KVM_LAPIC2_DEFAULT: full 4KB APIC page support
>>   - KVM_LAPIC2_AMD_DEFAULT: extended LVT registers are supported
> 
> This should be split into two patches to separate out the AMD bits. The 
> base patch should introduce KVM_CAP_LAPIC2 and either also introduce 
> KVM_GET_LAPIC2/KVM_SET_LAPIC2, or should be after the patch adding 
> support for KVM_GET_LAPIC2/KVM_SET_LAPIC2.
> 

Sure.

>>
>> Require that the capability be enabled before vCPUs are created to avoid
>> the need to handle runtime changes to the APIC page size.
>>
>> When KVM_LAPIC2_AMD_DEFAULT is enabled, set kvm->arch.nr_extlvt to
>> KVM_X86_NR_EXTLVT_DEFAULT (4) to track the number of extended LVT
>> registers available to the guest.  Future patches will use nr_extlvt to
>> emulate guest accesses to extended LVT registers at APIC offset 0x500.
>>
>> Suggested-by: Naveen N Rao (AMD) <naveen@kernel.org>
>> Signed-off-by: Manali Shukla <manali.shukla@amd.com>
>> ---
>>  Documentation/virt/kvm/api.rst  | 31 +++++++++++++++++++++++++++++++
>>  arch/x86/include/asm/kvm_host.h |  1 +
>>  arch/x86/kvm/x86.c              | 30 ++++++++++++++++++++++++++++++
>>  include/uapi/linux/kvm.h        |  5 +++++
>>  4 files changed, 67 insertions(+)
>>
>> diff --git a/Documentation/virt/kvm/api.rst 
>> b/Documentation/virt/kvm/api.rst
>> index 01a3abef8abb..71b4d24f009a 100644
>> --- a/Documentation/virt/kvm/api.rst
>> +++ b/Documentation/virt/kvm/api.rst
>> @@ -9291,6 +9291,37 @@ KVM exits with the register state of either the L1 or L2 guest
>>  depending on which executed at the time of an exit. Userspace must
>>  take care to differentiate between these cases.
>>  
>> +8.46 KVM_CAP_LAPIC2
>> +---------------------------
>> +
>> +:Architectures: x86
>> +:Target: VM
>> +:Parameters: args[0] is a bitmask of LAPIC2 capabilities
>> +:Returns: 0 on success, -EINVAL when arg[0] contains invalid bits
>> +
>> +This capability indicates that KVM supports extended APIC register space of the
>> +whole 4KB page.
>> +
>> +Calling KVM_CHECK_EXTENSION for this capability returns a bitmask of LAPIC2
>> +capabilities that can be enabled on a VM.
>> +
>> +The argument to KVM_ENABLE_CAP is also a bitmask that selects which LAPIC2
>> +capabilities to enable for the VM.  Userspace should enable the intersection
>> +of capabilities supported by KVM (from KVM_CHECK_EXTENSION) and capabilities
>> +supported by the VMM.  This must be called before creating any VCPUs.
>> +
>> +At this time, KVM_LAPIC2_DEFAULT and KVM_LAPIC2_AMD_DEFAULT are the supported
>> +capabilities:
>> +
>> +  - KVM_LAPIC2_DEFAULT: Full 4KB APIC page support
>> +  - KVM_LAPIC2_AMD_DEFAULT: Extended LVT registers are supported (they are part
>> +    of 4KB APIC page)
> 
> I don't think KVM_ENABLE_CAP should be necessary for the base LAPIC2 
> capability (i.e., for using the full 4k space). That will make it easy 
> for userspace to default to LAPIC2: it will only need to query for the 
> capability and can use the LAPIC2 get/set ioctls always.
> 
> - Naveen

Yeah. Makes sense. Will take care of it in V2.

-Manali