[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH v2] intel_iommu: check misordered init when realize
Date: Wed, 1 Mar 2017 09:03:47 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1

On 03/01/2017 06:14 AM, Jason Wang wrote:

On 2017年03月01日 11:23, Michael S. Tsirkin wrote:
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.

I can't say that I like it but if we want it for 2.9 maybe we don't have a 

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.

Yes, just post a fix for virtio-pci with IOMMU. With this fix, we meet the 
exact issue as this patch, IOMMU needs to be created before any virtio-pci 

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 
If yes, this approach will also help you work.



  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

reply via email to

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