linux-kernel - Re: [RFC v2 13/17] x86/apic: Handle EOI writes for SAVIC guests

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: <Z-VeW0IuqMI8dYlH@google.com>
Date: Thu, 27 Mar 2025 07:19:07 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Thomas Gleixner <tglx@...utronix.de>
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, Thomas Gleixner wrote:
> 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.

IIUC, the suggestion is to use find_last_bit() to walk the entire 128-byte range
covered by ISR registers, under the assumption that the holes are guaranteed to
be zero.  I suppose that works for Secure AVIC, but I don't want to do that for
KVM since KVM can't guarantee the holes are zero (userspace can stuff APIC state).