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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan

>> 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.