On 23/06/2025 3:15 pm, Peter Xu wrote: > Caution: External email. Do not open attachments or click links, unless this > email comes from a known sender and you know the content is safe. > > > On Mon, Jun 23, 2025 at 05:43:06AM +0000, CLEMENT MATHIEU--DRIF wrote: >> Hi Peter >> >> On 20/06/2025 4:35 pm, Peter Xu wrote: >>> Caution: External email. Do not open attachments or click links, unless >>> this email comes from a known sender and you know the content is safe. >>> >>> >>> On Fri, Jun 20, 2025 at 05:56:49AM +0000, CLEMENT MATHIEU--DRIF wrote: >>>> This short series adds the 'address type' bit (concept from PCIe) to the >>>> memory attributes and extends the IOMMUAccessFlags enum. This >>>> will be required to implement ATS support for the virtual IOMMUs. >>>> >>>> Address type: Field present in the PCIe R/W requests, it allows devices to >>>> tell the IOMMU if the address provided in the request is physical or not. >>>> In other words, it allows the devices to use a physical address obtained >>>> via ATS and to prevent the IOMMU from trying to remap it on the fly. >>> >>> Two pure questions on the flags, could be relevant to spec: >>> >>>> >>>> Additional IOMMU access flags: >>>> - Execute Requested >>> >>> Does this mean that we can start to put code into DMA regions so that >>> device can run some day (even if the device may have a core that is totally >>> different arch v.s. the host's >> AFAIU, the spec is so nonrestrictive about this flag that heterogeneous >> arch should not be an issue. >> >> "The definition of what it means for a Function to execute code is >> outside the scope of this specification" >> >>> >>>> - Privileged Mode Requested >>>> - Global >>>> - Untranslated Only (cannot be used with 'Address type = translated') >>> >>> I can understand this with patch 1, but not yet with patch 2. >>> >>> Patch 1 makes sense to me, IIUC it means the addresses to be used in a pcie >>> request will be translated addresses which should bypass IOMMU DMAR. >>> >>> OTOH, patch 2 added it into iotlb access permissions, which I'm not sure >>> what does it mean. Perhaps those addresses can only be translated by ATS >>> pre-translation requests, so that DMA on top of them (in IOVA address >>> space) will directly fail? >> >> I put this here because the ATS API returns IOMMUTLBEntry structures, >> which contain these flags. >> >> The untranslated-only bit is set in ATS responses to inform the device >> that the requested address cannot be pre-translated and should be >> translated on the fly by the DMA remapping engine. The interrupt range >> commonly falls into this category. > > Ah I see. Yes this makes sense. > >> >>> >>> Side note, it might still be more reasonable to put these changes into the >>> ATS series as the first user of flags. >> >> Yes, I can do that. >> However, the ATS series will contain ~10/~12 patches, is it a concern? > > Considering the size of this series, IMHO it should be better to stick with > when they're uesd.
Ok, will do! Thanks Peter >cmd > > Thanks, > > -- > Peter Xu >
