[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87msd6y8a7.ffs@tglx>
Date: Thu, 27 Mar 2025 13:20:32 +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 Thu, Mar 27 2025 at 11:48, Thomas Gleixner wrote:
> 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?
Actually no. As this is for 8 byte alignment. For 16 byte it's
bit = vector + 96 * (vector / 32);
ergo
vector = bit - 24 * (bit / 32);
Which is still just shifts and add/sub.
Powered by blists - more mailing lists