On 10.08.26 23:42, Michael S. Tsirkin wrote: > On Mon, Aug 10, 2026 at 07:14:09PM +0000, Graf (AWS), Alexander wrote: >> Maybe I'm missing the real point you're trying to make? :) > At least one point is not to have text like "intepret every address as > an offset" in the spec and actually make it an address.
I am genuinely unable to see how we can make it prettier. What I'm trying to transmit is that each device should live in its own address space, with the host specifying which boundary an address space has. I agree that on surface it sounds a bit like an IOMMU. And yes, we can combine that with virtio-iommu, but that's really just punting the problem down one layer and makes it more difficult to recreate the ties that a native per-device mechanism already gives us. With a pure virtio-iommu implementation, the most obvious way to create a private memory region (not RAM, because this region should never be used by anything as RAM) via an SHM region to the virtio-iommu device. Now we're moving the wording in the spec from "Device DMA is routed to a private address space which is backed by the DMB SHM region" into "Virtio-iommu has the ability to target a special address space, backed by an SHM region". And we then need to find a way to size that region, dynamically slice it (for hotplug support) and communicate between all components where and how to use the virtio-iommu SHM region instead. If we don't want to use a virtio-iommu SHM region, but punt it down one layer to virtio-mem, it gets even more difficult. We'd have all of the problems that we get when using virtio-iommu, but on top of that we now need to enlighten virtio-mem with a special "private" memory region that is not RAM. And then connect that back into virtio-iommu. So while I understand your concern, I fail to see a path towards an actually viable, genuinely better (prettier / more maintainable / easier / less error prone / etc) implementation with virtio-iommu. Alex
