On 20.11.2025 19:30, Andrew Cooper wrote: > On 20/11/2025 2:27 pm, Jan Beulich wrote: >> 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). > > Since when? > > Even in the oldest manuals I can find, it's a single field called > destination, and who's contents is interpreted differently depending on > the logical mode bit.
And these two different meanings are reflected in the union-ized definition in Xen. Which I still think is fair to describe as "overlapping". And the use of a union itself isn't buggy imo; it's some of the code using it which is. Jan
