qemu-devel
[Top][All Lists]
Advanced

[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: Michael S. Tsirkin
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 12:00:08 -0500

On Sat, Dec 22, 2018 at 08:41:37AM +0800, Yu Zhang wrote:
> On Fri, Dec 21, 2018 at 01:10:13PM -0500, Michael S. Tsirkin wrote:
> > On Sat, Dec 22, 2018 at 01:34:01AM +0800, Yu Zhang wrote:
> > > On Fri, Dec 21, 2018 at 12:15:26PM -0500, Michael S. Tsirkin wrote:
> > > > On Sat, Dec 22, 2018 at 12:19:20AM +0800, Yu Zhang wrote:
> > > > > > I'd like to avoid poking at the CPU from VTD code. That's all.
> > > > > 
> > > > > OK. So for the short term´╝îhow about I remove the check of host cpu, 
> > > > > and add a TODO
> > > > > in the comments in vtd_decide_config()? 
> > > > 
> > > > My question would be what happens on an incorrect use?
> > > 
> > > I believe the vfio_dma_map will return failure for an incorrect use.
> > > 
> > > > And how does user figure out which values to set?
> > > 
> > > Well, for now I don't think user can figure out. E.g. if we expose a 
> > > vIOMMU with
> > > 48-bit IOVA capability, yet host only supports 39-bit IOVA, vfio shall 
> > > return failure,
> > > but the user does not know whose fault it is.
> > > > 
> > > > > 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.
> > 
> > 
> > Things like live migration (e.g. after hot removal of the vfio device)
> > are also concerns.
> 
> Sorry, why live migration shall be a problem? I mean, if the DMA address
> width of vIOMMU does not match the host IOMMU's, we can just stop creating
> the VM, there's no live migration. 

I don't see code like this though.

Also management needs to somehow be able to figure out that migration
will fail. It's not nice to transfer all memory and then have it fail
when viommu is migrated.  So from that POV a flag is better. It can be
validated agains host capabilities.

We can still have something like aw=host just like cpu host.

> > 
> > > > 
> > > > > I still do not quite know
> > > > > how to do it for now...
> > > > > 
> > > > > [...]
> > > > > 
> > > > > 
> > > > > B.R.
> > > > > Yu
> > > > 
> > > > 
> > > > 
> > > > -- 
> > > > MST
> > > 
> > > B.R.
> > > Yu
> 
> B.R.
> Yu



reply via email to

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