Re: [PATCH for-4.20?] x86/dom0: be less restrictive with the Interrupt Address Range

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

On Mon, Feb 17, 2025 at 09:49:18AM +0100, Jan Beulich wrote:
> On 14.02.2025 14:57, Roger Pau Monné wrote:
> > On Fri, Feb 14, 2025 at 02:01:09PM +0100, Jan Beulich wrote:
> >> On 12.02.2025 16:38, Roger Pau Monne wrote:
> >>> There's also the following restriction noted in Intel VT-d:
> >>>
> >>>> Software must not program paging-structure entries to remap any address 
> >>>> to
> >>>> the interrupt address range. Untranslated requests and translation 
> >>>> requests
> >>>> that result in an address in the interrupt range will be blocked with
> >>>> condition code LGN.4 or SGN.8. Translated requests with an address in the
> >>>> interrupt address range are treated as Unsupported Request (UR).
> >>>
> >>> However this restriction doesn't apply to the identity mappings possibly
> >>> created for dom0, since the interrupt address range is never subject to 
> >>> DMA
> >>> remapping.
> >>
> >> Coming back to this also with your on-demand-p2m-populating patch in mind:
> >> I'm having some trouble following your comment on this quotation. The doc
> >> text is quite clear that page table entries must not point at the interrupt
> >> address range. They don't make an exception for identity mappings. And we
> >> don't know how the IOMMUs internally work, e.g. what sanity checks they do
> >> (and what failure thereof would result in).
> > 
> > My understanding is that address translation will never happen for the
> > interrupt address range, so whatever gets mapped on that range will
> > never be translated by the IOMMU.  Hence for the specific case here,
> > there will never be untranslated request that result in an address in
> > the interrupt address range, because translation is not done for input
> > addresses in the interrupt address range.
> > 
> > Sorry, hope the above makes sense, I'm having a hard time trying to
> > write down what I understand happens when the IOMMU handles accesses
> > to the interrupt address range.
> > 
> > Maybe a diagram would be easier.  This is my understanding of how
> > translation works in the IOMMU:
> > 
> >  input address -> translation -> output address
> > 
> > However input addresses that are in the interrupt address range are
> > not subject to translation, and hence there's no output address that
> > can be subject to the quoted VT-d paragraph.
> 
> I agree this is a possible (and plausible) interpretation of that text.
> I'm merely unconvinced it's the only possible one.

The AMD-Vi specification mentions the following regarding the
interrupt address range:

> 2.1.4.2 Interrupt Address Range
>
> Accesses to the interrupt address range (Table 3) are defined to go
> through the interrupt remapping portion of the IOMMU and not through
> address translation processing. Therefore, when a transaction is being
> processed as an interrupt remapping operation, the transaction
> attribute of pretranslated or untranslated is ignored.
>
> Software Note: The IOMMU should not be configured such that an address
> translation results in a special address such as the interrupt address
> range.

Which I interpret in the same way as VT-d: input addresses that belong
to the interrupt address range are not subject to translation.  Output
addresses that belong to the interrupt address range are not allowed,
otherwise the IOMMU will raise a fault.

I've added the following chunk to Xen:

diff --git a/xen/drivers/passthrough/x86/iommu.c 
b/xen/drivers/passthrough/x86/iommu.c
index 8b1e0596b84a..20aa46e305a3 100644
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -480,6 +480,9 @@ void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
     if ( rc )
         panic("IOMMU failed to remove Interrupt Address Range: %d\n", rc);
 
+    rc = rangeset_add_range(map, 0xfee01, 0xfeeff);
+    BUG_ON(rc);
+
     /* If emulating IO-APIC(s) make sure the base address is unmapped. */
     if ( has_vioapic(d) )
     {

And run a basic test on each server microarchitecture (AMD Naples to
Genoa, Intel Haswell to Emerald Rapids) available on XenRT, everything
seems to be OK, no IOMMU faults, but still running.

Would you agree to allowing mappings to the interrupt address range if
the above test raises no issues?  I know it's not every possible piece
of hardware out there, but it's quite good coverage.

IMO Xen should allow the creation of mappings on the interrupt address
range, otherwise I don't see how we can deal with Thinkpad issue.  And
this issue we known about, but sadly we have no visibility of what
firmware might put in that range.

Thanks, Roger.