Re: [Qemu-devel] [PATCH 2/3] s390x/pci: fixup global refresh

[Pierre Morel]

On 31/01/2018 12:35, Cornelia Huck wrote:
> On Tue, 30 Jan 2018 10:47:14 +0100
> Yi Min Zhao <address@hidden> wrote:
>
> > The VFIO common code doesn't provide the possibility to modify a
> > previous mapping entry in another way than unmapping and mapping again
> > with new properties.
> I'm wondering why other architectures don't need that. Is this
> refreshing an unique ability on s390 (due to that instruction)?

It is not specific to S390 but to the iommu_type1.

May be we should have different VFIO_IOMMU for mediated devices and
architectures with SR_IOV capabilities to suppress this restriction.

Other architectures using vfio_iommu_spapr_tce do not seem to have
the problem (AFAIU the code).

> > To avoid -EEXIST DMA mapping error, this we introduce a GHashTable to
> s/this//
>
> > store S390IOTLBEntry instances in order to cache the mapped entries.
> > When intercepting rpcit instruction, ignore the identical mapped
> > entries to avoid doing map operations multiple times and do unmap and
> > re-map operations for the case of updating the valid entries. To
> > achieve that goal, we also export the DMA walking function and
> > optimize the code handling errors in rpcit handler.
> How often does such a thing happen in practice?

It depends on the size of the guest memory and of the guest OS.
Linux allows an IOMMU IOVA size up to the minimal of high_memory, iommu 
aperture
and maximal size of RT IOMMU entry.
Linux guest use lazy TLB flush and waits for the allowed IOMMU size is 
used to
flush the TLB.
When the flush is done it is a global flush not a global invalidation, 
it follows
that some entries in the IOTLB are still valid and must be kept while other
are to be invalidated.

Since we have no possibility to know which the entries of the IOMMU TLB
have been modified, we must check all entries.

When does the -EEXIST error happen?
- Linux before lazy flush : (c60d1ae4e 2014... we did not have zPCI at 
that time)
    never
- Linux with lazy flush and new IOMMU_TYPE1:
    always as soon as the global flush occurs
    which depends of the number of allowed IOMMU IOVA size and mapped 
entries in IOTLB

When does the implemented cache be used and avoid errors?
- an entry in the cache exist for all mapped IOTLB entries
- a miss -> add the entry and issue a DMA_MAP to the host
- a hit for IOMMU_NONE -> issue a DMA_UNMAP and remove the entry
- a hit for valid unmodified entry -> do nothing (already mapped)
- hit for a valid but nmodified entry -> issue UNMAP/MAP update the entry

Regards,

Pierre


--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany