qemu-devel
[Top][All Lists]
Advanced

[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: Peter Xu
Subject: Re: [Qemu-devel] [PATCH v2] intel_iommu: check misordered init when realize
Date: Wed, 1 Mar 2017 10:36:35 +0800
User-agent: Mutt/1.5.24 (2015-08-30)

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.

Yes. Thanks,

-- peterx



reply via email to

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