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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 17.02.2025 10:47, Roger Pau Monné wrote:
> 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.

Yeah, I think that ought to be good enough.

Jan