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
