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

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

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.

> Instead I'm now wondering whether we don't need to
> - prevent ept_set_entry() from propagating to the IOMMU mappings targeting
>   the interrupt range,
> - demand non-shared page tables if any such mapping is to be established
>   in the CPU page tables.
> 
> Then again I won't assert that my interpretation of that quoted text makes
> sense at all.

See above, *I think* the quoted paragraph only applies to output
addresses, and in the case of mappings created on the interrupt
address range there's simply no output address.

Thanks, Roger.