From: Naveen N Rao <naveen@kernel.org>
To: Manali Shukla <manali.shukla@amd.com>
Cc: seanjc@google.com, pbonzini@redhat.com, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, kvm@vger.kernel.org,
x86@kernel.org, santosh.shukla@amd.com, nikunj.dadhania@amd.com,
dapeng1.mi@linux.intel.com
Subject: Re: [PATCH v1 9/9] KVM: SVM: Add AVIC support for extended LVT MSRs
Date: Thu, 14 May 2026 20:40:22 +0530 [thread overview]
Message-ID: <agXiCnwgYHHLZwXS@blrnaveerao1> (raw)
In-Reply-To: <20260204074452.55453-10-manali.shukla@amd.com>
On Wed, Feb 04, 2026 at 07:44:52AM +0000, Manali Shukla wrote:
> Configure MSR intercepts for extended LVT registers when both AVIC and
> AVIC_EXTLVT are supported by hardware. Extended LVT registers are
> x2APIC MSRs at offsets 0x500-0x530 in the APIC register space.
That sounds a bit weird, since AFAIK the extended LVT registers are also
present in the MMIO-based xAPIC.
>
> When AVIC is enabled and MSR intercepts are disabled, allow passthrough
> access to extended LVT MSRs. Hardware accelerates reads without VM-exits,
> while writes trigger trap-style VM-exits that are handled by the existing
> avic_unaccelerated_access_interception() path.
With Sean's recent changes
(https://lore.kernel.org/kvm/20260506184746.2719880-1-seanjc@google.com),
the preference is to intercept all the MSRs that are not
write-accelerated by AVIC, so the only change for this patch would be
for AVIC_UNACCELERATED_ACCESS handling for xAVIC.
Also, per the APM Section "15.29.3.1 Virtual APIC Register Accesses":
"Accesses to any other register locations not explicitly defined
in this table are allowed to read and write the backing page."
So, I don't think we need to be too strict about which EILVT registers
can cause this. It's probably simplest to just list the 4 EILVT
registers handled by AVIC today:
diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
index 101ffab48145..b2eececf41e9 100644
--- a/arch/x86/kvm/svm/avic.c
+++ b/arch/x86/kvm/svm/avic.c
@@ -818,6 +818,13 @@ static bool is_avic_unaccelerated_access_trap(u32 offset)
case APIC_TDCR:
ret = true;
break;
+ case APIC_EILVTn(0):
+ case APIC_EILVTn(1):
+ case APIC_EILVTn(2):
+ case APIC_EILVTn(3):
+ if (cpu_feature_enabled(X86_FEATURE_AVIC_EXTLVT))
+ ret = true;
+ break;
default:
break;
}
- Naveen
next prev parent reply other threads:[~2026-05-14 15:18 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-04 7:44 [PATCH v1 0/9] KVM: x86: Add support for AMD Extended APIC registers Manali Shukla
2026-02-04 7:44 ` [PATCH v1 1/9] KVM: x86: Refactor APIC register mask handling to support extended " Manali Shukla
2026-05-14 12:48 ` Naveen N Rao
2026-02-04 7:44 ` [PATCH v1 2/9] x86/apic: Add helper to get maximum number of Extended LVT registers Manali Shukla
2026-05-06 11:22 ` Borislav Petkov
2026-05-14 12:50 ` Naveen N Rao
2026-02-04 7:44 ` [PATCH v1 3/9] KVM: SVM: Set kvm_caps.has_extapic when CPU supports Extended APIC Manali Shukla
2026-05-14 12:58 ` Naveen N Rao
2026-02-04 7:44 ` [PATCH v1 4/9] KVM: x86: Introduce KVM_CAP_LAPIC2 for 4KB APIC register space support Manali Shukla
2026-05-14 13:08 ` Naveen N Rao
2026-02-04 7:44 ` [PATCH v1 5/9] KVM: x86: Refactor APIC state get/set to accept variable-sized buffers Manali Shukla
2026-05-14 14:20 ` Naveen N Rao
2026-02-04 7:44 ` [PATCH v1 6/9] KVM: Add KVM_GET_LAPIC2 and KVM_SET_LAPIC2 for extended APIC Manali Shukla
2026-03-16 13:00 ` Nikunj A. Dadhania
2026-03-23 11:15 ` Manali Shukla
2026-05-14 14:36 ` Naveen N Rao
2026-05-14 14:41 ` Naveen N Rao
2026-02-04 7:44 ` [PATCH v1 7/9] KVM: x86: Emulate Extended LVT registers for AMD guests Manali Shukla
2026-05-14 14:48 ` Naveen N Rao
2026-02-04 7:44 ` [PATCH v1 8/9] x86/cpufeatures: Add CPUID feature bit for Extended LVT AVIC acceleration Manali Shukla
2026-02-04 7:44 ` [PATCH v1 9/9] KVM: SVM: Add AVIC support for extended LVT MSRs Manali Shukla
2026-05-14 15:10 ` Naveen N Rao [this message]
2026-03-10 6:17 ` [PATCH v1 0/9] KVM: x86: Add support for AMD Extended APIC registers Manali Shukla
2026-04-27 4:34 ` Shukla, Manali
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=agXiCnwgYHHLZwXS@blrnaveerao1 \
--to=naveen@kernel.org \
--cc=bp@alien8.de \
--cc=dapeng1.mi@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=manali.shukla@amd.com \
--cc=mingo@redhat.com \
--cc=nikunj.dadhania@amd.com \
--cc=pbonzini@redhat.com \
--cc=santosh.shukla@amd.com \
--cc=seanjc@google.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.