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.
