lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ