Re: [Xen-devel] HPET interrupt remapping during boot

[Jan Beulich <jbeulich@xxxxxxxx>]

On 09.10.2019 15:56, Roger Pau Monné  wrote:
> On Wed, Oct 09, 2019 at 02:03:12PM +0200, Jan Beulich wrote:
>> On 09.10.2019 13:29, Roger Pau Monné  wrote:
>>> Right, then I guess we either mask all the io-apic pins or we setup
>>> proper remapping entries for non-masked pins? (in order to avoid iommu
>>> faults)
>>
>> Making the ExtInt entry is at least worth an experiment, to
>> (hopefully) confirm that this would take care of the IOMMU
>> fault. But I'm afraid (as per above) it's not an option in
>> general. What I could see us doing is mask the entry if all
>> legacy IRQs are handled through the IO-APIC. This would take
>> care of spurious interrupts, as these are the only ones
>> which can make it through when the PIC mask bits are all set.
>> However, maybe it is legitimate to mask the ExtInt entry
>> when an IOMMU comes into play.
> 
> That was my thinking, ie: make sure every io-apic pin is masked before
> enabling iommu interrupt remapping. Nothing useful can happen of
> having io-apic pins unmasked, as the remapping is not setup anyway.
> If/when those pins get used a proper remapping entry is going to be
> setup, and the pin would then be unmasked.

Well, this isn't the only option. Another would be to transform
all unmasked entries to be translated.

>> As to "proper" remapping entries: I'll have to look at the
>> spec what they say about this. There's only one IRT index
>> that we can put in the RTE, yet this would need to serve all
>> 15 IRQs potentially coming through the PIC. Recall that the
>> vector gets supplied by the PIC in the ExtInt case, not by
>> the IO-APIC RTE.
> 
> You can set the delivery mode of the IRTE to ExtINT, much like how this
> is done on the io-apic, and then poke the PIC to figure out which IRQ
> triggered?

Hmm, yes - it didn't even occur to me that VT-d might allow
ExtInt as delivery mode; too much AMD IOMMU work recently,
where the only way to deal with ExtInt is a "don't remap"
flag in the device table entry.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel