[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87y0wqycj8.ffs@tglx>
Date: Thu, 27 Mar 2025 11:48:43 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Neeraj Upadhyay <Neeraj.Upadhyay@....com>, linux-kernel@...r.kernel.org,
bp@...en8.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
Subject: Re: [RFC v2 13/17] x86/apic: Handle EOI writes for SAVIC guests
On Fri, Mar 21 2025 at 10:11, Sean Christopherson wrote:
> On Fri, Mar 21, 2025, Thomas Gleixner wrote:
>>
>> Congrats. You managed to re-implement find_last_bit() in the most
>> incomprehesible way.
>
> Heh, having burned myself quite badly by trying to use find_last_bit() to get
> pending/in-service IRQs in KVM code...
>
> Using find_last_bit() doesn't work because the ISR chunks aren't contiguous,
> they're 4-byte registers at 16-byte strides.
Which is obvious to solve with trivial integer math:
bit = vector + 32 * (vector / 32);
ergo
vector = bit - 16 * (bit / 32);
No?
> That said, copy+pasting the aforementioned KVM code is absurd. Please extract
> KVM's find_highest_vector() to common code.
No. Reimplement this with find_last_bit() and the trivial adjustment
above and remove find_highest_vector() as there is no point to
proliferate a bad reimplementation of find_last_bit().
Thanks,
tglx
Powered by blists - more mailing lists