mbox series

[0/3] Fix UNMAP notifier for intel-iommu

Message ID 20221129081037.12099-1-jasowang@redhat.com (mailing list archive)
Headers show
Series Fix UNMAP notifier for intel-iommu | expand

Message

Jason Wang Nov. 29, 2022, 8:10 a.m. UTC
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(-)

Comments

Michael S. Tsirkin Nov. 30, 2022, 4:37 p.m. UTC | #1
On Tue, Nov 29, 2022 at 04:10:34PM +0800, Jason Wang 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

Any changes of Fixes tags? this is 8.0 yes?

> 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
Jason Wang Dec. 1, 2022, 8:29 a.m. UTC | #2
On Thu, Dec 1, 2022 at 12:38 AM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Tue, Nov 29, 2022 at 04:10:34PM +0800, Jason Wang 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
>
> Any changes of Fixes tags? this is 8.0 yes?

Yes, it's for 8.0.

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
>
Michael S. Tsirkin Dec. 20, 2022, 1:53 p.m. UTC | #3
On Tue, Nov 29, 2022 at 04:10:34PM +0800, Jason Wang 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


IIUC you were going to post v2? At least commit log fixes.

> 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
Jason Wang Dec. 21, 2022, 3:17 a.m. UTC | #4
On Tue, Dec 20, 2022 at 9:53 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Tue, Nov 29, 2022 at 04:10:34PM +0800, Jason Wang 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
>
>
> IIUC you were going to post v2? At least commit log fixes.

Yes.

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
>
Viktor Prutyanov Jan. 15, 2023, 11:30 p.m. UTC | #5
On Tue, Nov 29, 2022 at 11:10 AM Jason Wang <jasowang@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 <viktor@daynix.com>

Best regards,
Viktor Prutyanov
Jason Wang Jan. 16, 2023, 7:06 a.m. UTC | #6
On Mon, Jan 16, 2023 at 7:30 AM Viktor Prutyanov <viktor@daynix.com> wrote:
>
> On Tue, Nov 29, 2022 at 11:10 AM Jason Wang <jasowang@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 <viktor@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

>
> Best regards,
> Viktor Prutyanov
>
Michael S. Tsirkin Jan. 27, 2023, 1:17 p.m. UTC | #7
On Mon, Jan 16, 2023 at 03:06:44PM +0800, Jason Wang wrote:
> On Mon, Jan 16, 2023 at 7:30 AM Viktor Prutyanov <viktor@daynix.com> wrote:
> >
> > On Tue, Nov 29, 2022 at 11:10 AM Jason Wang <jasowang@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 <viktor@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?

> >
> > Best regards,
> > Viktor Prutyanov
> >
Jason Wang Jan. 29, 2023, 5:43 a.m. UTC | #8
On Fri, Jan 27, 2023 at 9:17 PM Michael S. Tsirkin <mst@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 <viktor@daynix.com> wrote:
> > >
> > > On Tue, Nov 29, 2022 at 11:10 AM Jason Wang <jasowang@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 <viktor@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
> > >
>