On Mon, Dec 19, 2022, Wang, Wei W wrote: > On Saturday, December 17, 2022 1:13 AM, Sean Christopherson wrote: > > Rather than hardcode this in x86, I think it would be better to add an #ifdef'd > > version in the generic check. E.g. if MIPS or RISC-V ever gains KVM_VFIO > > support then they'll need to enumerate KVM_CAP_DEVICE_CTRL too, and odds > > are we'll forget to to do. ... > > The other potentially bad idea would be to detect the presence of a > > device_ops and delete all of the arch hooks, e.g. > Yes, it looks better to move it to the generic check, but I'm not sure if it > would be necessary to do the per-device check here either via CONFIG_KVM_VFIO > (for example, if more non-arch-specific usages are added, we would end up > with lots of such #ifdef to be added, which doesn't seem nice) or > kvm_device_ops_table. > > I think fundamentally KVM_CAP_DEVICE_CTRL is used to check if the generic > kvm_device framework (e.g. KVM_CREATE_DEVICE) is supported by KVM (older KVM > before 2013 doesn't have it). The per-device type (KVM_DEV_TYPE_VFIO, > KVM_DEV_TYPE_ARM_PV_TIME etc.) support can be checked via KVM_CREATE_DEVICE, > which reports -ENODEV if the device type doesn't have an entry in > kvm_device_ops_table. If that's how we want to retroactively define things, then KVM should unconditionally return 1/true for KVM_CAP_DEVICE_CTRL since KVM_CREATE_DEVICE is provided by generic code.
