qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 0/3] s390x/pci: fixup and optimize IOTLB code


From: Cornelia Huck
Subject: Re: [Qemu-devel] [PATCH v2 0/3] s390x/pci: fixup and optimize IOTLB code
Date: Wed, 7 Feb 2018 12:17:14 +0100

On Wed, 7 Feb 2018 10:56:01 +0800
Yi Min Zhao <address@hidden> wrote:

> 在 2018/2/6 下午6:23, Cornelia Huck 写道:
> > On Mon,  5 Feb 2018 15:22:55 +0800
> > Yi Min Zhao <address@hidden> wrote:
> >  
> >> This series contains three patches,
> >> 1) optimizes the code including walking DMA tables and rpcit handler
> >> 2) fixes the issue caused by IOTLB global refresh
> >> 3) uses the right pal and pba when registering ioat
> >>
> >> The issue mentioned above was found when we tested SMC-r tools. This
> >> behavior has been introduced when linux guest started using a global
> >> refresh to purge the whole IOTLB of invalid entries in a lazy fashion
> >> instead of flushing each entry when invalidating table entries.
> >>
> >> The previous QEMU implementation didn't keep track of the mapping,
> >> didn't handle correctly the global flush demand from the guest and a
> >> major part of the IOTLB entries were not flushed.
> >>
> >> Consequently linux kernel on the host keeping the previous mapping
> >> reports, as it should, -EEXIST DMA mapping error on the next mapping
> >> with the same IOVA. The second patch fixes this issue.  
> > Introducing a local tracking mechanism still feels a bit awkward to me
> > (even though it works, of course). If nobody else needs such a thing,
> > our best choice is to do it like that, though.  
> Caching iotlb entries is also helpful for us to support 2G mapping in 
> future.

OK, that makes sense.

> >  
> >> During the investigation, we noticed that the current code walking
> >> PCI IOMMU page tables didn't check important flags of table entries,
> >> including:
> >> 1) protection bit
> >> 2) table length
> >> 3) table offset
> >> 4) intermediate tables' invalid bit
> >> 5) format control bit
> >>
> >> We implement the checking in the first patch before handling the
> >> IOTLB global refresh issue. To keep track of the mapped IOTLB entries
> >> and be able to check if the host IOTLB entries need to be refreshed
> >> we implement a IOTLB cache in QEMU, and introduce some helper
> >> functions to check these bits. All S390IOTLBEntry instances are stored
> >> in a new hashtable which are indexed by IOVA. Each PCI device has its
> >> own IOMMU. Therefore each IOMMU also has its own hashtable caching
> >> corresponding PCI device's DMA entries. Finally, we split 1M
> >> contiguous DMA range into 4K pages to do DMA map, and the code about
> >> error notification is also optimized.
> >>
> >> Change log:
> >> v1->v2:
> >> 1) update commit messages
> >> 2) move some changes from the 2nd patch to the 1st patch
> >> 3) define macros for 'ett' in the 1st patch
> >>
> >> Yi Min Zhao (3):
> >>    s390x/pci: fixup the code walking IOMMU tables
> >>    s390x/pci: fixup global refresh
> >>    s390x/pci: use the right pal and pba in reg_ioat()
> >>
> >>   hw/s390x/s390-pci-bus.c  | 233 
> >> ++++++++++++++++++++++++++++++++++++++---------
> >>   hw/s390x/s390-pci-bus.h  |  17 ++++
> >>   hw/s390x/s390-pci-inst.c | 103 ++++++++++++++-------
> >>   3 files changed, 275 insertions(+), 78 deletions(-)
> >>  
> > I have played with these patches and some virtio-pci devices (since I
> > don't have access to real zpci cards), and it worked both under kvm and
> > under tcg. So I'm inclined to apply this (I can't review further due to
> > missing documentation), unless the pci folks have further comments.  
> Thanks!

Applied to s390-next, thanks.



reply via email to

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