On Wed, Mar 01, 2017 at 10:36:35AM +0800, Peter Xu wrote: > On Tue, Feb 28, 2017 at 04:42:25PM +0200, Marcel Apfelbaum wrote: > > On 02/24/2017 06:29 AM, Peter Xu wrote: > > >Intel vIOMMU devices are created with "-device" parameter, while here > > >actually we need to make sure the dmar device be created before other > > >PCI devices (like vfio-pci) so that we know iommu_fn will be setup > > >correctly before realizations of those PCI devices (it is sensible that > > >PCI device fetch these info during its realization). Now this ordering > > >yet cannot be achieved elsewhere, and devices will be created in the > > >order that user specified. That might be dangerous. > > > > > >Here we add one more function to detect this kind of misordering issue, > > >then report to guest. Currently, the only known device that is affected > > >by this VT-d defect is the vfio-pci typed devices. So for now we just > > >check against it to make sure we are safe. > > > > > > > Hi, > > I can't say that I like it but if we want it for 2.9 maybe we don't have a > > choice. > > > > I mentioned in another thread other idea: > > Maybe we should follow the same "template" as disk/drive, nic/netdev ? > > I mean something like -device iommu,id=i1, -device vfio-pci,iommu=e1 . > > You are able to change the order, I didn't look how it is done. > > I suppose that's done by using different keywords. For example: > > -netdev user,id=net0 -device e1000,netdev=net0 > > Here we are using "netdev" for the backend and "device" for the > frontend. > > Since we have this difference, we can just make sure the ordering by > init netdev first (in net_init_clients()), then the devices (in > device_init_func()). > > > > > A nice side effect is that you can: > > 1. Limit the iommu scope only to the devices you want to protect (tweaking > > APCI tables) > > 2. In the future we can support multiple iommu devices.
Unfortunately AFAIK this needs a bunch of work in practice: host and guest side. So this opens a can of worms: you can all too easily create configurations that we don't support. > > Yes. Thanks, > > -- peterx While I agree this fixes the specific problem, we have the ordering issue in many other places. For example, this is one of the reasons we don't create built-in PC devices using QOM composition. So I think that support for dependencies does make a lot of sense generally. -- MST
