On 05/03/2025 1:56 pm, Jan Beulich wrote: > On 03.03.2025 19:53, Andrew Cooper wrote: >> The exact behaviour of LVTERR interrupt generation is implementation >> specific. >> >> * Newer Intel CPUs generate an interrupt when pending_esr becomes >> nonzero. >> >> * Older Intel and all AMD CPUs generate an interrupt when any >> individual bit in pending_esr becomes nonzero. >> >> Neither vendor documents their behaviour very well. Xen implements >> the per-bit behaviour and has done since support was added. >> >> Importantly, the per-bit behaviour can be expressed using the atomic >> operations available in the x86 architecture, whereas the >> former (interrupt only on pending_esr becoming nonzero) cannot. >> >> With vlapic->hw.pending_esr held outside of the main regs page, it's >> much easier to use atomic operations. >> >> Use xchg() in vlapic_reg_write(), and *set_bit() in vlapic_error(). >> >> The only interesting change is that vlapic_error() now needs to take a >> single bit only, rather than a mask, but this fine for all current >> callers and forseable changes. >> >> No practical change. > From a guest perspective that is. > >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > Reviewed-by: Jan Beulich <jbeul...@suse.com>
Thanks. > >> @@ -124,15 +126,12 @@ static void vlapic_error(struct vlapic *vlapic, >> unsigned int errmask) >> if ( (lvterr & APIC_VECTOR_MASK) >= 16 ) >> inj = true; > I wouldn't, btw, mind if you also corrected this indentation screw-up of > mine along with you doing so ... > >> else >> - errmask |= APIC_ESR_RECVILL; >> + set_bit(ilog2(APIC_ESR_RECVILL), &vlapic->hw.pending_esr); > ... here. Both fixed. ~Andrew
