On 21/10/2024 12:49 pm, David Woodhouse wrote: > 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).
Because Xen is insane and, for non-x2APIC cases, sets the system up normally and the turns the IOMMU on late. This really does need deleting, and everything merging into the early path. ~Andrew
