On 3/14/22 5:49 PM, Jason Gunthorpe wrote:
On Mon, Mar 14, 2022 at 03:44:48PM -0400, Matthew Rosato wrote:
The DTSM, or designation type supported mask, indicates what IOAT formats
are available to the guest. For an interpreted device, userspace will not
know what format(s) the IOAT assist supports, so pass it via the
capability chain. Since the value belongs to the Query PCI Function Group
clp, let's extend the existing capability with a new version.
Why is this on the VFIO device?
Current vfio_pci_zdev support adds a series of capability chains to the
VFIO_DEVICE_GET_INFO ioctl. These capability chains are all related to
output values associated with what are basically s390x query instructions.
The capability chain being modified by this patch is used to populate a
response to the 'query this zPCI group' instruction.
Maybe I don't quite understand it right, but the IOAT is the
'userspace page table'?
IOAT = I/O Address Translation tables; the head of which is called the
IOTA (translation anchor). But yes, this would generally refer to the
guest DMA tables.
Specifically here we are only talking about the DTSM which is the
formats that the guest is allowed to use for their address translation
tables, because the hardware (or in our case the intermediary kvm iommu)
can only operate on certain formats.
That is something that should be modeled as a nested iommu domain.
Querying the formats and any control logic for this should be on the
iommu side not built into VFIO.
I agree that the DTSM is really controlled by what the IOMMU domain can
support (e.g. what guest table formats it can actually operate on) and
so the DTSM value should come from there vs out of KVM; but is there
harm in including the query response data here along with the rest of
the response information for 'query this zPCI group'?
