On Thu, 2020-10-08 at 11:12 +0200, Peter Zijlstra wrote: > On Wed, Oct 07, 2020 at 01:20:44PM +0100, David Woodhouse wrote: > > @@ -1861,7 +1863,8 @@ static void ioapic_configure_entry(struct irq_data *irqd) > > * ioapic chip to verify that. > > */ > > if (irqd->chip == &ioapic_chip) { > > - mpd->entry.dest = cfg->dest_apicid; > > + mpd->entry.dest = cfg->dest_apicid & 0xff; > > + mpd->entry.ext_dest = cfg->dest_apicid >> 8; > > mpd->entry.vector = cfg->vector; > > } > > for_each_irq_pin(entry, mpd->irq_2_pin) > > All the other sites did memset(0) before the assignment, and this the > extra unconditional write of 0 to ext_dest is harmless. > > This might be true for this site too, but it wasn't immediately obvious. Yeah. Really, that whole 16-bit field ought to be called 'msi_addr_bits_19_to_4' since there's no interpretation by the IOAPIC and it's *just* passed on in the MSI cycle. See my later patch which stops making them up for ourselves in the IOAPIC code and *just* swizzles them out of the MSI message which is composed for us by upstream. In this case, since this piece of code is based on the knowledge that the upstream controller is accepting MSI in the x86 Compatibility Format, those seven bits are never going to have been used for anything else.