Re: [EXTERNAL] [PATCH] x86/io-apic: fix directed EOI when using AMd-Vi interrupt remapping

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On Mon, 2024-10-21 at 12:38 +0100, Andrew Cooper wrote:
> On 21/10/2024 12:10 pm, Andrew Cooper wrote:
> > On 18/10/2024 9:08 am, Roger Pau Monne wrote:
> > 
> > > 
> > > +/*
> > > + * Store the EOI handle when using interrupt remapping.
> > > + *
> > > + * If using AMD-Vi interrupt remapping the IO-APIC redirection entry 
> > > remapped
> > > + * format repurposes the vector field to store the offset into the 
> > > Interrupt
> > > + * Remap table.  This causes directed EOI to longer work, as the CPU 
> > > vector no
> > > + * longer matches the contents of the RTE vector field.  Add a 
> > > translation
> > > + * table so that directed EOI uses the value in the RTE vector field when
> > > + * interrupt remapping is enabled.
> > > + *
> > > + * Note Intel VT-d Xen code still stores the CPU vector in the RTE 
> > > vector field
> > > + * when using the remapped format, but use the translation table 
> > > uniformly in
> > > + * order to avoid extra logic to differentiate between VT-d and AMD-Vi.
> > > + */
> > > +static unsigned int **apic_pin_eoi;
> > I think we can get away with this being uint8_t rather than unsigned
> > int, especially as we're allocating memory when not strictly necessary.
> > 
> > The only sentinel value we use is IRQ_VECTOR_UNASSIGNED which is -1.
> > 
> > Vector 0xff is strictly SPIV and not allocated for anything else, so can
> > be reused as a suitable sentinel here.
> 
> Actually, vectors 0 thru 0x0f are also strictly invalid, and could be
> used as sentinels.  That's probably better than trying to play integer
> promotion games between IRQ_VECTOR_UNASSIGNED and uint8_t.

I don't quite follow how you need a sentinel value. How could you ever
*not* know it, given that you have to write it to the RTE?

(And you should *also* just use the pin# like Linux does, as I said).

Attachment: smime.p7s
Description: S/MIME cryptographic signature