On Wed, 2023-01-04 at 08:16 -0400, Jason Gunthorpe wrote: > On Wed, Jan 04, 2023 at 10:52:55AM +0100, Niklas Schnelle wrote: > > > The problem manifests only with ISM devices which are a special s390 > > virtual PCI device that is implemented in the machine hypervisor. This > > device is used for high speed cross-LPAR (Logical Partition) > > communication, basically it allows two LPARs that previously exchanged > > an authentication token to memcpy between their partitioned memory > > using the virtual device. For copying a receiving LPAR will IOMMU map a > > region of memory for the ISM device that it will allow DMAing into > > (memcpy by the hypervisor). All other regions remain unmapped and thus > > inaccessible. In preparation the device emulation in the machine > > hypervisor intercepts the IOTLB flush and looks at the IOMMU > > translation tables performing e.g. size and alignment checks I presume, > > one of these checks against the start/end DMA boundaries. This check > > fails which leads to the virtual ISM device being put into an error > > state. Being in an error state it then fails to be initialized by the > > guest driver later on. > > You could rephrase this as saying that the S390 map operation doesn't > check for bounds so mapping in a reserved region doesn't fail, but > errors the HW. > > Which seems reasonable to me > > Jason Kind of yes, before the recent IOMMU changes the IOMMU code did check on map failing early but now handles the limits via reserved regions. The IOMMU hardware would only check the limits once an actual DMA uses them but of course no DMA will be triggered for this test mapping. For this specific virtual device though there is an extra check as part of an intercepted IOTLB flush (RPCIT instruction in S390).
