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

[Peter Xu <peterx@redhat.com>]

On Wed, Feb 22, 2017 at 08:24:51PM -0700, Alex Williamson wrote:

[...]

> > Now Jintack reported another issue, that we may have two default
> > devices there if not specifying "-nodefaults", and that two devices
> > will always be the first ones to be inited.
> > 
> > How about here we just explicitly check against vfio-pci devices, so
> > we just make sure vfio-pci devices will be put after intel-iommu?
> > Since actually vfio-pci devices are the only ones that we know we need
> > to be inited explicitly after the VT-d device.
> 
> I was afraid you were going to come to this conclusion.  That works,
> BUT it just means the problem gets ignored as a vfio problem when
> really vfio is doing nothing wrong other than caring about the device
> address space during its initialization.  Then users have a perfectly
> working config, add a vfio-pci device and things explode.  If you want
> to impose a user ordering requirement, do it consistently.  Thanks,

We cannot guarantee that guest won't "explode" only if we
automatically order the device init, but that's something I am not
quite sure about that we will need now, especially I don't know
whether it would be a 2.9 material, considering that 2.9 soft freeze
should be on Feb 28th. :(

I kind of understand your concern, but would that really a so-called
explosion? The user will just be warned that he/she should move the
intel-iommu line slightly higher. Imho that's tolerable, since the
user is definitely adding something new to the parameters, and it's
possible the new command line just don't work. Also, imho it's not
anyone's fault if it happens, it's just a new rule that we need to
make sure things work properly...

I just want to know what would be the most feasible approach that we
can safely have the vtd vfio series in before 2.9. Any further input
would be welcomed.

Thanks,

-- peterx