On 2/8/22 3:40 PM, Jason Gunthorpe wrote:
On Tue, Feb 08, 2022 at 03:33:58PM -0500, Matthew Rosato wrote:
Is the purpose of IOAT to associate the device to a set of KVM page
tables? That seems like a container or future iommufd operation. I
Yes, here we are establishing a relationship with the DMA table in the guest
so that once mappings are established guest PCI operations (handled via
special instructions in s390) don't need to go through the host but can be
directly handled by firmware (so, effectively guest can keep running on its
vcpu vs breaking out).
Oh, well, certainly sounds like a NAK on that - anything to do with
the DMA translation of a PCI device must go through the iommu layer,
not here.
Lets not repeat the iommu subsytem bypass mess power made please.
It's more that non-KVM userspace doesn't care about what these ioctls are
doing... The enabling of 'interp, aif, ioat' is only pertinent when there
is a KVM userspace, specifically because the information being shared /
actions being performed as a result are only relevant to properly enabling
zPCI features when the zPCI device is being passed through to a VM
guest.
Then why are they KVM ioctls?
Well, the primary reason I ended up here was that I need to ensure the
the operation is only performed when guest X owns host zPCI device Y.
The vfio-pci device ioctl had the benefit of acting on device
granularity + also already being aware of the host PCI (and thus zPCI)
device association -- so I already know exactly what hostdev is being
referenced for the operation. All that was needed was the KVM notifier
to ensure the vfio device was associated to a KVM guest.
I think moving over to a KVM ioctl is doable; I might still need to rely
on VFIO_GROUP_NOTIFY_SET_KVM though, not sure yet.
Based on prior comments in this thread I'm assuming Alex shares that
view too (don't use vfio device ioctl for something only being used for
VM passthrough) so I'll start looking at using KVM ioctls instead.
