Re: [PATCH] x86/vlapic: Don't change ICR on x2APIC SELF_IPI write

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 19/10/2026 10:09 pm, Andrew Cooper wrote:
> On 19/10/2026 3:26 pm, Teddy Astie wrote:
>> The Intel SDM (Vol 3A-13.12.11, June 2026) says
>>
>>> The semantics of sending a self-IPI via the SELF IPI register
>>> are identical to sending a self targeted edge triggered fixed
>>> interrupt with the specified vector.
>> However, this is not expected to alter the ICR register.
>>
>> Fix the Xen behavior by sending the Self-IPI directly instead of
>> emulating it by modifying ICR register.
>>
>> Fixes: 21c4d089ba2a ("x86 hvm: x2APIC emulation")
>> Assisted-by: Claude Fable 5.1
>> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
> What matters is the behaviour on real hardware.
>
> If we're taking a strict interpretation, then "identical" means that ICR
> does get mutated.
>
> GNR:
>
>     (XEN) '1' pressed -> Extreme debugging in progress...
>     (XEN) *** Testing self-IPI
>     (XEN)   Before: ICR 00000000000010ff, IRR 00000000
>     (XEN)    After: ICR 00000000000400fc, IRR 90000000
>     (XEN) *** SPIV
>
> Turin:
>
>     (XEN) '1' pressed -> Extreme debugging in progress...
>     (XEN) *** Testing self-IPI
>     (XEN)   Before: ICR 00000000000000ff, IRR 80000000
>     (XEN)    After: ICR 00000000000000ff, IRR 90000000
>     (XEN) *** SPIV
>
>
> So, AMD doesn't mutate ICR.  Intel does.
>
> Weirdly, Intel reads back ICR_BUSY which shouldn't exist in x2APIC,
> while AMD fails to read back the shorthand.
>
> See the attached patch.  The test sends SPIV to CPU0 using ICR, then a
> self EVENT_CHECK sampling ICR and IRR before and after.  The SPIV
> printk() only gets serviced later, which is why it's the last of the
> printk()s

https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2965354494

It looks like it's a behavioural difference between Core and Atom.  Core
modify ICR, while Atom do not.

Also Atom look to be delivering the "SPIV" IPI too early.  That will be
a separate bug.

~Andrew