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: Fri, 24 Feb 2017 01:26:15 +0200

On Thu, Feb 23, 2017 at 01:42:34PM +0800, Peter Xu wrote:
> 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.

And that part is broken at this stage.  We can add a flag
"uses_address_space_in_init". Would that be better?


>  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.

This is not a new thing however. vfio previously did not work with
an iommu either. It seems reasonable to make sure iommu
is initialized first.

But it also seems reasonable to enable that gradually
and not require removing ordering requirements upfront.


>  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



reply via email to

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