[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aFvxRctwWEtRde08@google.com>
Date: Wed, 25 Jun 2025 05:53:25 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Neeraj Upadhyay <Neeraj.Upadhyay@....com>
Cc: linux-kernel@...r.kernel.org, bp@...en8.de, tglx@...utronix.de,
mingo@...hat.com, dave.hansen@...ux.intel.com, Thomas.Lendacky@....com,
nikunj@....com, Santosh.Shukla@....com, Vasant.Hegde@....com,
Suravee.Suthikulpanit@....com, David.Kaplan@....com, x86@...nel.org,
hpa@...or.com, peterz@...radead.org, pbonzini@...hat.com, kvm@...r.kernel.org,
kirill.shutemov@...ux.intel.com, huibo.wang@....com, naveen.rao@....com,
francescolavra.fl@...il.com, tiala@...rosoft.com
Subject: Re: [RFC PATCH v7 01/37] KVM: lapic: Remove __apic_test_and_{set|clear}_vector()
"KVM: x86:" for the scope. That goes for all of the relevant shortlogs.
And for this one in particular, maybe something like:
KVM: x86: Open code setting/clearing of bits in the ISR
because seeing "Remove" in the shortlog reads like it's a straight deletion of
code.
On Tue, Jun 10, 2025, Neeraj Upadhyay wrote:
> Remove __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.
>
> No functional change intended.
>
> Suggested-by: Sean Christopherson <seanjc@...gle.com>
> [Neeraj: Add "inline" for apic_vector_to_isr()]
> Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@....com>
> ---
> Changes since v6:
>
> - New change.
>
> arch/x86/kvm/lapic.c | 19 +++++++------------
> 1 file changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 73418dc0ebb2..11e57f351ce5 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -125,16 +125,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);
>
> @@ -744,9 +734,14 @@ void kvm_apic_clear_irr(struct kvm_vcpu *vcpu, int vec)
> }
> EXPORT_SYMBOL_GPL(kvm_apic_clear_irr);
>
> +static inline void *apic_vector_to_isr(int vec, struct kvm_lapic *apic)
<formletter>
Do not use "inline" for functions that are visible only to the local compilation
unit. "inline" is just a hint, and modern compilers are smart enough to inline
functions when appropriate without a hint.
A longer explanation/rant here: https://lore.kernel.org/all/ZAdfX+S323JVWNZC@google.com
</formletter>
Ignoring the existing code below, there's lots of crusty old code in KVM (that
isn't "bad" per se, i.e. isn't worth fixing unless a prime opportunity arises).
> +{
> + return apic->regs + APIC_ISR + REG_POS(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(VEC_POS(vec), apic_vector_to_isr(vec, apic)))
> return;
>
> /*
> @@ -789,7 +784,7 @@ 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(VEC_POS(vec), apic_vector_to_isr(vec, apic)))
> return;
>
> /*
> --
> 2.34.1
>
Powered by blists - more mailing lists