Hi Dapeng Mi, Thank you for reviewing my patches. On 7/15/2025 7:51 AM, Mi, Dapeng wrote: > > On 6/28/2025 12:25 AM, Manali Shukla wrote: >> Modern AMD processors expose four additional extended LVT registers in >> the extended APIC register space, which can be used for additional >> interrupt sources such as instruction-based sampling and others. >> >> To support this, introduce two new vCPU-based IOCTLs: >> KVM_GET_LAPIC_W_EXTAPIC and KVM_SET_LAPIC_W_EXTAPIC. These IOCTLs works >> similarly to KVM_GET_LAPIC and KVM_SET_LAPIC, but operate on APIC page >> with extended APIC register space located at APIC offsets 400h-530h. >> >> These IOCTLs are intended for use when extended APIC support is >> enabled in the guest. They allow saving and restoring the full APIC >> page, including the extended registers. >> >> To support this, the `struct kvm_lapic_state_w_extapic` has been made >> extensible rather than hardcoding its size, improving forward >> compatibility. >> >> Documentation for the new IOCTLs has also been added. >> >> For more details on the extended APIC space, refer to AMD Programmer’s >> Manual Volume 2, Section 16.4.5: Extended Interrupts. >> https://bugzilla.kernel.org/attachment.cgi?id=306250 >> >> Signed-off-by: Manali Shukla <manali.shukla@xxxxxxx> >> --- >> Documentation/virt/kvm/api.rst | 23 ++++++++++++++++++++ >> arch/x86/include/uapi/asm/kvm.h | 5 +++++ >> arch/x86/kvm/lapic.c | 12 ++++++----- >> arch/x86/kvm/lapic.h | 6 ++++-- >> arch/x86/kvm/x86.c | 37 ++++++++++++++++++++++++--------- >> include/uapi/linux/kvm.h | 10 +++++++++ >> 6 files changed, 76 insertions(+), 17 deletions(-) >> >> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst >> index 1bd2d42e6424..0ca11d43f833 100644 >> --- a/Documentation/virt/kvm/api.rst >> +++ b/Documentation/virt/kvm/api.rst >> @@ -2041,6 +2041,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 >> + struct kvm_lapic_state_w_extapic { >> + __DECLARE_FLEX_ARRAY(__u8, regs); >> + }; >> + >> +Applications should use KVM_GET_LAPIC_W_EXTAPIC ioctl if extended APIC is >> +enabled. KVM_GET_LAPIC_W_EXTAPIC reads Local APIC registers with extended >> +APIC register space located at offsets 400h-530h and copies them into input >> +argument. >> + >> If KVM_X2APIC_API_USE_32BIT_IDS feature of KVM_CAP_X2APIC_API is >> enabled, then the format of APIC_ID register depends on the APIC mode >> (reported by MSR_IA32_APICBASE) of its VCPU. x2APIC stores APIC ID in >> @@ -2072,6 +2084,17 @@ always uses xAPIC format. >> Copies the input argument into the Local APIC registers. The data format >> and layout are the same as documented in the architecture manual. >> >> +:: >> + >> + #define KVM_APIC_EXT_REG_SIZE 0x540 >> + struct kvm_lapic_state_w_extapic { >> + __DECLARE_FLEX_ARRAY(__u8, regs); >> + }; >> + >> +Applications should use KVM_SET_LAPIC_W_EXTAPIC ioctl if extended APIC is enabled. >> +KVM_SET_LAPIC_W_EXTAPIC copies input arguments with extended APIC register into >> +Local APIC and extended APIC registers. >> + >> The format of the APIC ID register (bytes 32-35 of struct kvm_lapic_state's >> regs field) depends on the state of the KVM_CAP_X2APIC_API capability. >> See the note in KVM_GET_LAPIC. >> diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h >> index 6f3499507c5e..91c3c5b8cae3 100644 >> --- a/arch/x86/include/uapi/asm/kvm.h >> +++ b/arch/x86/include/uapi/asm/kvm.h >> @@ -124,6 +124,11 @@ struct kvm_lapic_state { >> char regs[KVM_APIC_REG_SIZE]; >> }; >> >> +#define KVM_APIC_EXT_REG_SIZE 0x540 >> +struct kvm_lapic_state_w_extapic { >> + __DECLARE_FLEX_ARRAY(__u8, regs); >> +}; > > The name "kvm_lapic_state_w_extapic" seems a little bit too long, maybe > "kvm_ext_lapic_state" is enough? I also found the name to be quite long, but I couldn't come up with a better alternative. I'm fine with keeping kvm_ext_lapic_state as it appears concise and self-explanatory. I will change the name in V2. -Manali