Re: [Qemu-devel] [PATCH v3 2/2] intel-iommu: extend VTD emulation to allow 57-bit IOVA address width.

[Yu Zhang <yu.c.zhang@linux.intel.com>]

On Tue, Dec 25, 2018 at 12:00:08PM -0500, Michael S. Tsirkin wrote:
> 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.

Well, I think vIOMMU's requirement is kind of different:
1> the vIOMMU could be an emulated one, and there can be no physical
IOMMU underneath. And the emulated device can still use this vIOMMU;
2> there might be multiple physical IOMMUs on one platform, I am not
sure if all these IOMMUs will have the same capability setting.

So I think we should have a more generic solution, to check the host
capability, e.g. like Kevin's and Peter's suggestion. It's not just
about 5-level vIOMMU, existing 4-level vIOMMU and future virtual SVM
have similar requirement. :)

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

B.R.
Yu