On Mon, May 03, 2021 at 01:05:30PM -0300, Jason Gunthorpe wrote: > On Thu, Apr 29, 2021 at 01:20:22PM +1000, David Gibson wrote: > > > There is a certain appeal to having some > > > 'PPC_TCE_CREATE_SPECIAL_IOASID' entry point that has a wack of extra > > > information like windows that can be optionally called by the viommu > > > driver and it remains well defined and described. > > > > Windows really aren't ppc specific. They're absolutely there on x86 > > and everything else as well - it's just that people are used to having > > a window at 0..<something largish> that you can often get away with > > treating it sloppily. > > My point is this detailed control seems to go on to more than just > windows. As you say the vIOMMU is emulating specific HW that needs to > have kernel interfaces to match it exactly. It's really not that bad. The case of emulating the PAPR vIOMMU on something else is relatively easy, because all updates to the IO page tables go through hypercalls. So, as long as the backend IOMMU can map all the IOVAs that the guest IOMMU can, then qemu's implementation of those hypercalls just needs to put an equivalent mapping in the backend, which it can do with a generic VFIO_DMA_MAP. vIOMMUs with page tables in guest memory are harder, but only really in the usual ways that a vIOMMU of that type is harder (needs cache mode or whatever). At whatever point you need to shadow from the guest IO page tables to the host backend, you can again do that with generic maps, as long as the backend supports the necessary IOVAs, and has an IO page size that's equal to or a submultiple of the vIOMMU page size. > I'm remarking that trying to unify every HW IOMMU implementation that > ever has/will exist into a generic API complete enough to allow the > vIOMMU to be created is likely to result in an API too complicated to > understand.. Maybe not every one, but I think we can get a pretty wide range with a reasonable interface. Explicitly handling IOVA windows does most of it. And we kind of need to handle that anyway to expose what ranges the IOMMU is capable of translating anyway. I think making handling valid IOVA windows explicit makes things simpler than having per-backend-family interfaces to expose the limits of their translation ranges, which is what's likely to happen without it. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
