[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
Re: [Qemu-devel] [RFC] vhost-user: introduce F_NEED_ALL_IOTLB protocol feature, Jason Wang, 2018/04/11
- Re: [Qemu-devel] [RFC] vhost-user: introduce F_NEED_ALL_IOTLB protocol feature, Tiwei Bie, 2018/04/11
- Re: [Qemu-devel] [RFC] vhost-user: introduce F_NEED_ALL_IOTLB protocol feature, Jason Wang, 2018/04/11
- Re: [Qemu-devel] [RFC] vhost-user: introduce F_NEED_ALL_IOTLB protocol feature, Michael S. Tsirkin, 2018/04/11
- Re: [Qemu-devel] [RFC] vhost-user: introduce F_NEED_ALL_IOTLB protocol feature, Jason Wang, 2018/04/11
- Re: [Qemu-devel] [RFC] vhost-user: introduce F_NEED_ALL_IOTLB protocol feature, Michael S. Tsirkin, 2018/04/11
- Re: [Qemu-devel] [RFC] vhost-user: introduce F_NEED_ALL_IOTLB protocol feature, Jason Wang, 2018/04/11
Re: [Qemu-devel] [RFC] vhost-user: introduce F_NEED_ALL_IOTLB protocol feature, Michael S. Tsirkin, 2018/04/11
Re: [Qemu-devel] [RFC] vhost-user: introduce F_NEED_ALL_IOTLB protocol feature, Tiwei Bie, 2018/04/11
Re: [Qemu-devel] [RFC] vhost-user: introduce F_NEED_ALL_IOTLB protocol feature, Jason Wang, 2018/04/12