On Thu, Mar 09, 2017 at 01:28:09PM +0100, Paolo Bonzini wrote: > > > On 09/03/2017 13:11, Marcel Apfelbaum wrote: > > On 03/09/2017 01:13 PM, Paolo Bonzini wrote: > >> > >> > >> On 09/03/2017 00:59, Michael S. Tsirkin wrote: > >>> Allow forcing a specific order of initialization on > >>> devices created with -device. > >>> Helpful e.g. for built-in devices such as IOMMUs which must > >>> exist before all other devices. > >>> > >>> Signed-off-by: Michael S. Tsirkin <m...@redhat.com> > >>> --- > >>> > >>> Looks like we have a ton of problems because devices > >>> are initialized in a random order, while we > >>> really want e.g. iommu to be initialized > >>> earlier than devices. > >>> > >>> This will be helpful for other things, e.g. > >>> real hardware often is initialized in a specific order, > >>> creating built-in devices for the board often > >>> has to happen in a specific order, etc. > >> > >> In the specific case of PCI bus_master_as there is a simple workaround > >> by placing a dummy container (which lets us build the AddressSpace) and > >> then adding the alias region at machine_done time. > >> > >> This is exactly how MemoryListener is supposed to work, so I would start > >> from there. > >> > > > > Hi Paolo, > > > > This will certainly solve virtio-pci ordering issue, but I am not sure > > it solves the vfio-pci problem. Here is a link to Alex's explanation: > > > > http://www.mail-archive.com/qemu-devel@nongnu.org/msg432365.html > > Right, VFIO is more complicated (hence "in the specific case of PCI > bus_master_as"). I answered in that thread.
If we keep allowing vfio-pci to use pci_device_iommu_address_space() (IMHO that's exactly the right thing to do there, rather than using bus_master_as), this patch should work for vfio-pci as well? Since vfio_realize() will get a correct iommu_fn, and that looks to be enough. Thanks, -- peterx
