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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Oct 21, 2024 at 01:02:31PM +0100, David Woodhouse wrote:
> On Mon, 2024-10-21 at 12:53 +0100, Andrew Cooper wrote:
> > 
> > > 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.
> 
> Don't you still have to mask the interrupts when enabling the IOMMU and
> then re-enable them by writing the new values to the RTE once remapping
> is turned on? So at any given moment, surely it's still the case that
> you know what was written to the RTE?
> 
> But OK, i don't really want to know... :)

It's possible that __io_apic_eoi() gets called before the EOI handler
array is allocated, as part of clear_IO_APIC_pin() that is done ahead
setup_IO_APIC() (so with apic_pin_eoi == NULL).

Whether Xen can get into __io_apic_eoi() with the EOI handler array
allocated but some entries not initialized, it's not clear to me.
However I prefer to act on the safe side and allow the fallback of
fetching the field from the RTE itself.  This is a swamp I don't want
to drain right now (as I'm busy with other stuff).

Thanks, Roger.