[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v3 2/2] intel-iommu: extend VTD emulation to all

From: Tian, Kevin
Subject: Re: [Qemu-devel] [PATCH v3 2/2] intel-iommu: extend VTD emulation to allow 57-bit IOVA address width.
Date: Tue, 25 Dec 2018 01:59:07 +0000

> From: Yu Zhang
> Sent: Saturday, December 22, 2018 1:34 AM
> >
> > > As to the check against hardware IOMMU, Peter once had a proposal in
> > > http://lists.nongnu.org/archive/html/qemu-devel/2018-
> 11/msg02281.html
> > >
> > > Do you have any comment or suggestion on Peter's proposal?
> >
> > Sounds reasonable to me. Do we do it on vfio attach or unconditionally?
> >
> I guess on vfio attach? Will need more thinking in it.

either way is not perfect. Unconditional check doesn't make sense if
there is no vfio device attached, while vfio attach might happen late
(e.g. hotplug) after vIOMMU is initialized...

Basically there are two checks to be concerned. One is the check at 
boot time, which decides vIOMMU capabilities. The other is the check 
at vfio attach, which decides whether attachment can succeed (i.e.
whether the vIOMMU capabilities which are used by device are indeed
supported by hardware). 

Possibly we can make boot-time check configurable. 

If boot-time check is turned on, vIOMMU capabilities are always a 
subset of pIOMMU regardless of whether vfio device is attached. 
check on vfio attach may be skipped since it will always pass. virtual 
devices also bear with same limitation of pIOMMU. 

If boot-time check is off, vIOMMU capabilities are always specified 
by end user, which might be different from pIOMMU. virtual devices 
can use any capability, but vfio attach may fail if required vIOMMU
capabilities are not supported by pIOMMU.

btw 5 level is just one example of demanding check with pIOMMU. 
There are more when emulating VT-d scalable mode (+Yi).


reply via email to

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