Re: [Qemu-devel] [PATCH v2] intel_iommu: check misordered init when realize

[Peter Xu <peterx@redhat.com>]

On Wed, Mar 01, 2017 at 11:29:47AM +0200, Marcel Apfelbaum wrote:
> On 03/01/2017 11:18 AM, Peter Xu wrote:
> >On Wed, Mar 01, 2017 at 09:03:47AM +0200, Marcel Apfelbaum wrote:
> >>On 03/01/2017 06:14 AM, Jason Wang wrote:
> >
> >[...]
> >
> >>Hi Jason,
> >>
> >>I am not saying we don't need to create the IOMMU before some other device,
> >>I just don't think that the command line order should matter to user.
> >>
> >>BTW, are you working on a way to limit the IOMMU scope to a specific set of devices?
> >>If yes, this approach will also help you work.
> >
> >Marcel,
> >
> >Do you have any plan after 2.9 to re-arrange the init order thing a
> >bit? In general, maybe we need an ordering support for devices.
> 
> I don;t know when I'll start it, but yes, I am thinking about
> taking this project. We need the ordering in order to be able
> to have less "built-in" devices.

That'll be great!

> 
> >Besides that, I am thinking whether it would be wise that we just init
> >the IOMMUs during machine init just like before, but keep the
> >"-device" interface? After all, at least the root IOMMU device should
> >be with root complex, and it feels a little strange we just split the
> >init process apart (we delay the IOMMU init into device
> >initializations).
> >
> 
> Keeping the IOMMU creation as part of the Root Complex is problematic.
> What happens if we want to limit the IOMMU scope to a subset of devices?
> How will the command line look? Also we may want/need multiple iommu
> devices per system. It will not happen tomorrow, but we don't want to loose
> this possibility.

I think that won't be a big problem. E.g., I don't see big problem if
we just create all these vIOMMUs along with machine init. Is there?

IMHO we can just pick these vIOMMU "devices" out of the device list,
and we can avoid doing that again in general device_init_func().

> 
> The device re-ordering is not 2.9 material of course, and we need your patch.
> The only thing we can do better is to take out the "vfio-pci" in another header
> file and and have it in a array of devices that should be checked
> (in order to avoid polluting the IOMMU code with a not related device)
> 
> I can try and send a patch for it if you prefer.

IMHO it'll be okay we "pollute" vtd code for a short while. We can
revert my patch (or any workarounds, like Jason's just posted one)
when we have device ordering support, and when we have a correct
bus_master_as when device init.

Thanks,

-- peterx