Re: [Qemu-devel] [RFC] vhost-user: introduce F_NEED_ALL_IOTLB protocol feature

[Peter Xu <peterx@redhat.com>]

On Wed, Apr 11, 2018 at 04:55:25PM +0800, Tiwei Bie wrote:
> On Wed, Apr 11, 2018 at 04:37:16PM +0800, Peter Xu wrote:
> > On Wed, Apr 11, 2018 at 04:25:56PM +0800, Tiwei Bie wrote:
> > > On Wed, Apr 11, 2018 at 04:00:36PM +0800, Peter Xu wrote:
> > > > On Wed, Apr 11, 2018 at 03:20:27PM +0800, Tiwei Bie wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > This is just a RFC for now. It seems that, it doesn't work
> > > > > as expected when guest is using kernel driver (To handle
> > > > > this case, it seems that some RAM regions' events also need
> > > > > to be listened). Any comments would be appreciated! Thanks!
> > > > 
> > > > Hi, Tiwei,
> > > > 
> > > > What's your kernel command line in the guest?  Is iommu=pt there?
> > > 
> > > Yeah, you are right! The related things in kernel command line are:
> > > 
> > > iommu=pt intel_iommu=on
> > > 
> > > Hmm, how will this param affect vIOMMU's behaviour?..
> > 
> > If iommu=pt is there, guest kernel will try to bypass IOMMU, the IOMMU
> > regions will be disabled completely in that case, hence it's very
> > possible that your IOMMU memory listeners won't get anything useful.
> > 
> > Maybe you can consider removing iommu=pt in the guest parameter to see
> > whether the guest kernel driver could work.
> 
> Cool. I'll give it a try! Considering we may also need to
> handle the iommu=pt case, is there any event in QEMU can
> be used to know whether the IOMMU regions are disabled
> or enabled by the guest?

You may consider to use similar way like below patch to detect that:

  https://patchwork.kernel.org/patch/9735739/

That was a patch trying to preheat the vhost cache.  It was refused at
that time, but IMHO the logic can be used.  You can just send the
updates only if your new flag set.  Then that won't be a preheat any
more, but a must for your hardwares to work.

-- 
Peter Xu