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> > @@ -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. Jan
