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).
