From: Sean Christopherson <seanjc@google.com>
To: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Cc: Borislav Petkov <bp@alien8.de>,
linux-kernel@vger.kernel.org, tglx@linutronix.de,
mingo@redhat.com, dave.hansen@linux.intel.com,
Thomas.Lendacky@amd.com, nikunj@amd.com, Santosh.Shukla@amd.com,
Vasant.Hegde@amd.com, Suravee.Suthikulpanit@amd.com,
David.Kaplan@amd.com, x86@kernel.org, hpa@zytor.com,
peterz@infradead.org, pbonzini@redhat.com, kvm@vger.kernel.org,
kirill.shutemov@linux.intel.com, huibo.wang@amd.com,
naveen.rao@amd.com, francescolavra.fl@gmail.com,
tiala@microsoft.com
Subject: Re: [RFC PATCH v6 07/32] KVM: x86: apic_test_vector() to common code
Date: Fri, 6 Jun 2025 11:47:08 -0700 [thread overview]
Message-ID: <aEM3rBrlxHMk6Mct@google.com> (raw)
In-Reply-To: <4dd45ddb-5faf-4766-b829-d7e10d3d805f@amd.com>
On Mon, May 26, 2025, Neeraj Upadhyay wrote:
>
>
> On 5/24/2025 5:42 PM, Borislav Petkov wrote:
> >
> > The previous patch is moving those *_POS() macros to arch/x86/kvm/lapic.c, now
> > this patch is doing rename-during-move to the new macros.
> >
> > Why can't you simply do the purely mechanical moves first and then do the
> > renames? Didn't I explain it the last time? Or is it still unclear?
> >
>
> I thought it was clear to me when you explained last time. However, I did this
> rename-during-move because of below reason. Please correct me if I am wrong here.
>
> VEC_POS, REG_POS are kvm-internal wrappers for APIC_VECTOR_TO_BIT_NUMBER/
> APIC_VECTOR_TO_REG_OFFSET macros which got defined in patch 01/32. Prior to patch
> 06/32, these macros were defined in kvm-internal header arch/x86/kvm/lapic.h. Using
> VEC_POS, REG_POS kvm-internal macros in x86 common header file (arch/x86/include/asm/apic.h)
> in this patch did not look correct to me and as APIC_VECTOR_TO_BIT_NUMBER/APIC_VECTOR_TO_REG_OFFSET
> are already defined in arch/x86/include/asm/apic.h, I used them.
>
> Is adding this information in commit log of this patch sufficient or do you have some
> other suggestion for doing this?
I agree that moving VEC_POS/REG_POS to common code would be weird/undesirable,
but I also agree with Boris' underlying point that doing renames as part of code
movement is also undesirable. And you're doing that all over this series.
So, just one patch at the beginning of the series to replace VEC_POS/REG_POS with
APIC_VECTOR_TO_BIT_NUMBER/APIC_VECTOR_TO_REG_OFFSET, but *only* in the functions
you intended to move out of KVM. That way you separate code movement and rename
patches.
Actually, looking at the end usage, just drop VEC_POS/REG_POS entirely. IIRC, I
suggested keeping the shorthand versions for KVM, but I didn't realize there would
literally be two helpers left. At that point, keeping VEC_POS and REG_POS is
pure stubborness :-)
1. Rename VEC_POS/REG_POS => APIC_VECTOR_TO_BIT_NUMBER/APIC_VECTOR_TO_REG_OFFSET
2. Rename all of the KVM helpers you intend to move out of KVM.
3. Move all of the helpers out of KVM.
That way #1 and #2 are pure KVM changes, and the code review movement is easy to
review because it'll be _just_ code movement.
Actually (redux), we should probably kill off __apic_test_and_set_vector() and
__apic_test_and_clear_vector(), because the _only_ register that's safe to modify
with a non-atomic operation is ISR, because KVM isn't running the vCPU, i.e.
hardware can't service an IRQ or process an EOI for the relevant (virtual) APIC.
So this on top somewhere? (completely untested)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 8ecc3e960121..95921e5c3eb2 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -104,16 +104,6 @@ bool kvm_apic_pending_eoi(struct kvm_vcpu *vcpu, int vector)
apic_test_vector(vector, apic->regs + APIC_IRR);
}
-static inline int __apic_test_and_set_vector(int vec, void *bitmap)
-{
- return __test_and_set_bit(VEC_POS(vec), (bitmap) + REG_POS(vec));
-}
-
-static inline int __apic_test_and_clear_vector(int vec, void *bitmap)
-{
- return __test_and_clear_bit(VEC_POS(vec), (bitmap) + REG_POS(vec));
-}
-
__read_mostly DEFINE_STATIC_KEY_FALSE(kvm_has_noapic_vcpu);
EXPORT_SYMBOL_GPL(kvm_has_noapic_vcpu);
@@ -706,9 +696,15 @@ void kvm_apic_clear_irr(struct kvm_vcpu *vcpu, int vec)
}
EXPORT_SYMBOL_GPL(kvm_apic_clear_irr);
+static void *apic_vector_to_isr(int vec, struct kvm_lapic *apic)
+{
+ return apic->regs + APIC_ISR + APIC_VECTOR_TO_REG_OFFSET(vec);
+}
+
static inline void apic_set_isr(int vec, struct kvm_lapic *apic)
{
- if (__apic_test_and_set_vector(vec, apic->regs + APIC_ISR))
+ if (__test_and_set_bit(APIC_VECTOR_TO_BIT_NUMBER(vec),
+ apic_vector_to_isr(vec, apic)))
return;
/*
@@ -751,7 +747,8 @@ static inline int apic_find_highest_isr(struct kvm_lapic *apic)
static inline void apic_clear_isr(int vec, struct kvm_lapic *apic)
{
- if (!__apic_test_and_clear_vector(vec, apic->regs + APIC_ISR))
+ if (!__test_and_clear_bit(APIC_VECTOR_TO_BIT_NUMBER(vec),
+ apic_vector_to_isr(vec, apic)))
return;
/*
next prev parent reply other threads:[~2025-06-06 18:47 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-14 7:17 [RFC PATCH v6 00/32] AMD: Add Secure AVIC Guest Support Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 01/32] x86/apic: KVM: Deduplicate APIC vector => register+bit math Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 02/32] KVM: x86: Move find_highest_vector() to a common header Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 03/32] KVM: x86: Move lapic get/set_reg() helpers to common code Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 04/32] KVM: x86: Move lapic get/set_reg64() " Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 05/32] KVM: x86: Move lapic set/clear_vector() " Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 06/32] KVM: x86: Move {REG,VEC}_POS() macros to lapic.c Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 07/32] KVM: x86: apic_test_vector() to common code Neeraj Upadhyay
2025-05-24 12:12 ` Borislav Petkov
2025-05-26 3:00 ` Neeraj Upadhyay
2025-06-06 18:47 ` Sean Christopherson [this message]
2025-06-06 18:56 ` Sean Christopherson
2025-06-10 4:26 ` Neeraj Upadhyay
2025-06-10 4:25 ` Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 08/32] x86/apic: Remove redundant parentheses around 'bitmap' Neeraj Upadhyay
2025-05-24 12:14 ` Borislav Petkov
2025-05-26 3:01 ` Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 09/32] x86/apic: Rename 'reg_off' to 'reg' Neeraj Upadhyay
2025-06-09 6:35 ` Tianyu Lan
2025-05-14 7:17 ` [RFC PATCH v6 10/32] x86/apic: Change apic_*_vector() vector param to unsigned Neeraj Upadhyay
2025-05-24 12:15 ` Borislav Petkov
2025-05-26 3:01 ` Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 11/32] x86/apic: Change get/set reg operations reg " Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 12/32] x86/apic: Unionize apic regs for 32bit/64bit access w/o type casting Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 13/32] x86/apic: Simplify bitwise operations on apic bitmap Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 14/32] x86/apic: Move apic_update_irq_cfg() calls to apic_update_vector() Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 15/32] x86/apic: Add new driver for Secure AVIC Neeraj Upadhyay
2025-06-10 6:52 ` Tianyu Lan
2025-05-14 7:17 ` [RFC PATCH v6 16/32] x86/apic: Initialize Secure AVIC APIC backing page Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 17/32] x86/apic: Populate .read()/.write() callbacks of Secure AVIC driver Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 18/32] x86/apic: Initialize APIC ID for Secure AVIC Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 19/32] x86/apic: Add update_vector() callback for apic drivers Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 20/32] x86/apic: Add update_vector() callback for Secure AVIC Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 21/32] x86/apic: Add support to send IPI " Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 22/32] x86/apic: Support LAPIC timer " Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 23/32] x86/sev: Initialize VGIF for secondary VCPUs " Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 24/32] x86/apic: Add support to send NMI IPI " Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 25/32] x86/apic: Allow NMI to be injected from hypervisor " Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 26/32] x86/sev: Enable NMI support " Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 27/32] x86/apic: Read and write LVT* APIC registers from HV for SAVIC guests Neeraj Upadhyay
2025-05-14 7:17 ` [RFC PATCH v6 28/32] x86/apic: Handle EOI writes for Secure AVIC guests Neeraj Upadhyay
2025-05-14 7:18 ` [RFC PATCH v6 29/32] x86/apic: Add kexec support for Secure AVIC Neeraj Upadhyay
2025-05-14 7:18 ` [RFC PATCH v6 30/32] x86/apic: Enable Secure AVIC in Control MSR Neeraj Upadhyay
2025-05-14 7:18 ` [RFC PATCH v6 31/32] x86/sev: Prevent SECURE_AVIC_CONTROL MSR interception for Secure AVIC guests Neeraj Upadhyay
2025-06-09 7:40 ` Tianyu Lan
2025-05-14 7:18 ` [RFC PATCH v6 32/32] x86/sev: Indicate SEV-SNP guest supports Secure AVIC Neeraj Upadhyay
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=aEM3rBrlxHMk6Mct@google.com \
--to=seanjc@google.com \
--cc=David.Kaplan@amd.com \
--cc=Neeraj.Upadhyay@amd.com \
--cc=Santosh.Shukla@amd.com \
--cc=Suravee.Suthikulpanit@amd.com \
--cc=Thomas.Lendacky@amd.com \
--cc=Vasant.Hegde@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=francescolavra.fl@gmail.com \
--cc=hpa@zytor.com \
--cc=huibo.wang@amd.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=naveen.rao@amd.com \
--cc=nikunj@amd.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tiala@microsoft.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).