On Thu, Mar 09, 2017 at 01:31:45PM +0100, Paolo Bonzini wrote: > > > On 23/02/2017 16:35, Alex Williamson wrote: > > It's the architecture of vfio, the user only gets access to the device > > when the container has iommu protection, therefore vfio needs to look > > at the device address space to determine if it can share a container > > with other devices. Without an iommu all devices share the system > > address space and use the same container. With an iommu, each device > > is in a separate address space and each gets its own container. > > Without a container, the user doesn't get access to the device. > > Deferring the address space to machine done would essentially defer the > > entire vfio device initialization or else we'd need to close the > > device and re-open and initialize it through a new container at that > > time. Thanks, > > If you used only one container you could still provide a working VFIO > configuration to the guest, even if the guest had an IOMMU. All devices > ending up in one IOMMU domain is not particularly useful, but it would work. > > If VFIO had an iommu property, to be used like "-device > intel_iommu,id=iommu0 -device vfio-pci,iommu=iommu0", It could tell VFIO > to use separate containers and also ensure proper ordering of command > line arguments. > > Paolo
Lots of guests can't handle arbitrary stuff like this though. Normally IOMMU attaches to a bus and that's the only bus it can handle and that's the only IOMMU that can handle the devices on this bus. It's a fact of life that not all hardware dependencies are in a form of a bus-device relashionship, while modelling it as a bus internally might be feasible exposing that to users seems risky and confusing as that's our artifact. -- MST
