[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [EXTERNAL] [PATCH] x86/io-apic: fix directed EOI when using AMd-Vi interrupt remapping
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.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |