On Fri, Apr 29, 2022 at 04:00:14PM +1000, David Gibson wrote: > > But I don't have a use case in mind? The simplified things I know > > about want to attach their devices then allocate valid IOVA, they > > don't really have a notion about what IOVA regions they are willing to > > accept, or necessarily do hotplug. > > The obvious use case is qemu (or whatever) emulating a vIOMMU. The > emulation code knows the IOVA windows that are expected of the vIOMMU > (because that's a property of the emulated platform), and requests > them of the host IOMMU. If the host can supply that, you're good > (this doesn't necessarily mean the host windows match exactly, just > that the requested windows fit within the host windows). If not, > you report an error. This can be done at any point when the host > windows might change - so try to attach a device that can't support > the requested windows, and it will fail. Attaching a device which > shrinks the windows, but still fits the requested windows within, and > you're still good to go. We were just talking about this in another area - Alex said that qemu doesn't know the IOVA ranges? Is there some vIOMMU cases where it does? Even if yes, qemu is able to manage this on its own - it doesn't use the kernel IOVA allocator, so there is not a strong reason to tell the kernel what the narrowed ranges are. > > That is one possibility, yes. qemu seems to be using this to establish > > a clone ioas of an existing operational one which is another usage > > model. > > Right, for qemu (or other hypervisors) the obvious choice would be to > create a "staging" IOAS where IOVA == GPA, then COPY that into the various > emulated bus IOASes. For a userspace driver situation, I'm guessing > you'd map your relevant memory pool into an IOAS, then COPY to the > IOAS you need for whatever specific devices you're using. qemu seems simpler, it juggled multiple containers so it literally just copies when it instantiates a new container and does a map in multi-container. Jason
