On Tue, 27 Feb 2024 at 22:24, Joe Komlodi <koml...@google.com> wrote: > This adds requester IDs to ARM CPUs and adds a "user-defined" memory > attribute. > > The requester ID on ARM CPUs is there because I've seen some cases where > there's an IOMMU between a CPU and memory that uses the CPU's requester > ID to look up how it should translate, such as an SMMU TBU or some other > IOMMU-like device. > For a specific downstream example I've seen, Xilinx overrides CPU > attributes with ones passed in by an object property in order to have > their IOMMUs work: > https://github.com/Xilinx/qemu/blob/23b643ba1683a47ef49447a45643fe2172d6f8ca/accel/tcg/cputlb.c#L1127. > The object property with the memory attributes is declared here, for > reference: > https://github.com/Xilinx/qemu/blob/23b643ba1683a47ef49447a45643fe2172d6f8ca/target/arm/cpu.c#L1310. > > The user-defined attribute represents optional user signals that are a > part of AMBA-AXI. As the name suggests, these are defined > per-implementation and devices that receive these have their own > interpretation of what the user-defined attribute means. > > We add them in CPUs and PCI transactions, because some of their > attributes are set in functions in ways that are not user-facing. DMAs > or other devices that set attributes (using address_space_rw or some > other means), can add them on a per-device basis.
So as far as I can see, this patchset defines a bunch of mechanism, but no actual users: no device looks at these new memattrs, no board code sets the properties. I don't really want to add this without an upstream usecase for it. thanks -- PMM
