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

From: Jan Beulich <jbeulich@suse.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] HPET interrupt remapping during boot
Date: Wed, 9 Oct 2019 16:59:24 +0200	[thread overview]
Message-ID: <438eba9b-3ae1-abbd-08b4-95fc78816271@suse.com> (raw)
In-Reply-To: <20191009135645.GD1389@Air-de-Roger.citrite.net>

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel