[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2] intel_iommu: check misordered init when real
Michael S. Tsirkin
Re: [Qemu-devel] [PATCH v2] intel_iommu: check misordered init when realize
Wed, 1 Mar 2017 05:23:44 +0200
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
> Since we have this difference, we can just make sure the ordering by
> init netdev first (in net_init_clients()), then the devices (in
> > 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
Re: [Qemu-devel] [PATCH v2] intel_iommu: check misordered init when realize, Marcel Apfelbaum, 2017/02/28