On Fri, Jan 27, 2023 at 9:17 PM Michael S. Tsirkin <m...@redhat.com> wrote:
>
> On Mon, Jan 16, 2023 at 03:06:44PM +0800, Jason Wang wrote:
> > On Mon, Jan 16, 2023 at 7:30 AM Viktor Prutyanov <vik...@daynix.com> wrote:
> > >
> > > On Tue, Nov 29, 2022 at 11:10 AM Jason Wang <jasow...@redhat.com> wrote:
> > > >
> > > > Hi All:
> > > >
> > > > According to ATS, device should work if ATS is disabled. This is not
> > > > correctly implemented in the current intel-iommu since it doesn't
> > > > handle the UNMAP notifier correctly. This breaks the vhost-net +
> > > > vIOMMU without dt.
> > > >
> > > > The root casue is that the when there's a device IOTLB miss (note that
> > > > it's not specific to PCI so it can work without ATS), Qemu doesn't
> > > > build the IOVA tree, so when guest start an IOTLB invalidation, Qemu
> > > > won't trigger the UNMAP notifier.
> > > >
> > > > Fixing by build IOVA tree during IOMMU translsation.
> > > >
> > > > Thanks
> > > >
> > > > Jason Wang (3):
> > > >   intel-iommu: fail MAP notifier without caching mode
> > > >   intel-iommu: fail DEVIOTLB_UNMAP without dt mode
> > > >   intel-iommu: build iova tree during IOMMU translation
> > > >
> > > >  hw/i386/intel_iommu.c | 58 ++++++++++++++++++++++++-------------------
> > > >  1 file changed, 33 insertions(+), 25 deletions(-)
> > > >
> > > > --
> > > > 2.25.1
> > > >
> > >
> > > Hi Jason,
> > >
> > > I've tried the series with Windows Server 2022 guest with vhost and
> > > intel-iommu (device-iotlb=off) and now networking on this system has
> > > become working.
> > > So, as we discussed, I'm waiting for the series to be accepted in some
> > > form to continue my work about supporting guests who refuse Device-TLB
> > > on systems with device-iotlb=on.
> > >
> > > Tested-by: Viktor Prutyanov <vik...@daynix.com>
> >
> > Great, Peter has some comments on this series, so I will probably send
> > a new version (probably after the chinese new year).
> >
> > Thanks
>
> Were you going to post a new version?

Yes.

Thanks

>
> > >
> > > Best regards,
> > > Viktor Prutyanov
> > >
>


Reply via email to