Re: [RFC] /dev/ioasid uAPI proposal

Paolo Bonzini
2021-06-04T15:40:50Z

On 04/06/21 17:26, Alex Williamson wrote:
> Let's make sure the KVM folks are part of this decision; a re-cap for
> them, KVM currently automatically enables wbinvd emulation when
> potentially non-coherent devices are present which is determined solely
> based on the IOMMU's (or platform's, as exposed via the IOMMU) ability
> to essentially force no-snoop transactions from a device to be cache
> coherent. This synchronization is triggered via the kvm-vfio device,
> where QEMU creates the device and adds/removes vfio group fd
> descriptors as an additionally layer to prevent the user from enabling
> wbinvd emulation on a whim.
>
> IIRC, this latter association was considered a security/DoS issue to
> prevent a malicious guest/userspace from creating a disproportionate
> system load.
>
> Where would KVM stand on allowing more direct userspace control of
> wbinvd behavior? Would arbitrary control be acceptable or should we
> continue to require it only in association to a device requiring it for
> correct operation.

Extending the scenarios where WBINVD is not a nop is not a problem for
me. If possible I wouldn't mind keeping the existing kvm-vfio
connection via the device, if only because then the decision remains in
the VFIO camp (whose judgment I trust more than mine on this kind of issue).

For example, would it make sense if *VFIO* (not KVM) gets an API that
says "I am going to do incoherent DMA"? Then that API causes WBINVD to
become not-a-nop even on otherwise coherent platforms. (Would this make
sense at all without a hypervisor that indirectly lets userspace execute
WBINVD? Perhaps VFIO would benefit from a WBINVD ioctl too).

Paolo