On 07/06/21 19:59, Jason Gunthorpe wrote:
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).
The problem is we are talking about adding a new /dev/ioasid FD and it
won't fit into the existing KVM VFIO FD interface. There are lots of
options here, one is to add new ioctls that specifically use the new
FD, the other is to somehow use VFIO as a proxy to carry things to the
/dev/ioasid FD code.
Exactly.
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.
The simplest is KVM_ENABLE_WBINVD(<fd security proof>) and be done
with it.
The simplest one is KVM_DEV_VFIO_GROUP_ADD/DEL, that already exists and
also covers hot-unplug. The second simplest one is KVM_DEV_IOASID_ADD/DEL.
It need not be limited to wbinvd support, it's just a generic "let VMs
do what userspace can do if it has access to this file descriptor".
That it enables guest WBINVD is an implementation detail.
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:
Why does KVM need to know abut IOASID's? I don't think it can do
anything with this general information.
Indeed, it only uses them as the security proofs---either VFIO or IOASID
file descriptors can be used as such.
Paolo
