On 20.11.2025 14:18, Andrew Cooper wrote: > On 20/11/2025 9:06 am, Roger Pau Monne wrote: >> The IO-APIC RTEs are unconditionally programmed with physical destination >> mode, and hence the field to set in the RTE is always physical_dest. >> >> Remove the mode parameter from SET_DEST() and take the opportunity to >> convert it into a function, there's no need for it to be a macro. >> >> This is a benign fix, because due to the endianness of x86 the start of the >> physical_dest and logical_dest fields on the RTE overlap. > > RTEs do not have overlapping fields; it's Xen's abstraction of the > IO-APIC which is buggy.
I wouldn't put it this negatively. In the old days, ... > For starters, Xen's IO_APIC_route_entry still only has a 4-bit > physical_dest field which hasn't been true since the Pentium 4 days. > This might explain some of the interrupt bugs we see. ... as you mention here, the two fields were distinct (and hence overlapping). In a number of places we passed "logical" to SET_DEST() as the middle argument, thus covering for the too narrow field width of physical_dest. Dropping that parameter and always using physical_dest requires that field to be widened, though (or else we'll end up chopping off the top 4 bits, as we already do in disable_IO_APIC() and unlock_ExtINT_logic() - both benign as long as the CPU used always has APIC ID 0, which will at least typically be the case, I think). Jan
