[lkml]   [2022]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v1] KVM: x86: add KVM_CAP_DEVICE_CTRL
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.

 \ /
  Last update: 2023-03-26 23:15    [W:0.090 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site