On 04/06/21 19:22, Jason Gunthorpe wrote:
4) The KVM interface is the very simple enable/disable WBINVD.
Possessing a FD that can do IOMMU_EXECUTE_WBINVD is required
to enable WBINVD at KVM.
The KVM interface is the same kvm-vfio device that exists already. The
userspace API does not need to change at all: adding one VFIO file
descriptor with WBINVD enabled to the kvm-vfio device lets the VM use
WBINVD functionality (see kvm_vfio_update_coherency).
Alternatively you can add a KVM_DEV_IOASID_{ADD,DEL} pair of ioctls.
But it seems useless complication compared to just using what we have
now, at least while VMs only use IOASIDs via VFIO.
Either way, there should be no policy attached to the add/delete
operations. KVM users want to add the VFIO (or IOASID) file descriptors
to the device independent of WBINVD. If userspace wants/needs to apply
its own policy on whether to enable WBINVD or not, they can do it on the
VFIO/IOASID side:
1) When the device is attached to the IOASID via VFIO_ATTACH_IOASID
it communicates its no-snoop configuration:
- 0 enable, allow WBINVD
- 1 automatic disable, block WBINVD if the platform
IOMMU can police it (what we do today)
- 2 force disable, do not allow BINVD ever
Though, like Alex, it's also not clear to me whether force-disable is
useful. Instead userspace can query the IOMMU or the device to ensure
it's not enabled.
Paolo
