qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] intel_iommu: make sure its init before PCI dev


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH] intel_iommu: make sure its init before PCI dev
Date: Thu, 9 Mar 2017 17:29:12 +0200

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]