qemu-devel
[Top][All Lists]
Advanced

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

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


From: Tiwei Bie
Subject: Re: [Qemu-devel] [RFC] vhost-user: introduce F_NEED_ALL_IOTLB protocol feature
Date: Wed, 11 Apr 2018 17:25:47 +0800
User-agent: NeoMutt/20170113 (1.7.2)

On Wed, Apr 11, 2018 at 05:16:47PM +0800, Peter Xu wrote:
> 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.

It looks pretty helpful in my case! Thank you so much!

Best regards,
Tiwei Bie

> 
> -- 
> Peter Xu



reply via email to

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