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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
