Hi Scott, thanks for looking at the patch. On 06/01/15 20:52, Scott Wood wrote: > On Tue, 2015-01-06 at 16:12 +0000, Andre Przywara wrote: >> While we can easily register and unregister KVM devices, there is >> currently no easy way of checking whether a device has been >> registered. >> Introduce kvm_check_device() for that purpose and use it in two >> existing functions. Also change the return code for an invalid >> type number from ENOSPC to EINVAL. >> This function will be later used by another patch set to check >> whether a KVM_CREATE_IRQCHIP ioctl is valid. > > You're checking whether a device type has been registered, not the > device itself -- so could you make it kvm_check_device_type()? Sure. If you are OK with the general approach, I will include the patch in my GICv3 KVM emulation series. >> Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx> >> --- >> Hi, >> >> can people comment whether there is an easier way to detect KVM >> device registration _outside_ of virt/kvm/kvm_main.c? Using the >> KVM_CREATE_DEVICE_TEST flag sounds like a fit, but >> kvm_ioctl_create_device() isn't exported. > > Out of curiosity, why do you need to test it from inside the kernel but > outside kvm_main.c? I need it from arch/arm/kvm/arm.c or alternatively virt/kvm/arm/vgic.c. The problem is that while KVM_CREATE_DEVICE works fine with checking the availability of the requested device, KVM_CREATE_IRQCHIP does not - and the latter is handled in the arch specific parts of the code. At the moment the GIC_V2 is the only IRQ chip, so it's all or nothing right now. But very soon there will be a GIC_V3, with GIC_V2 compatibility not always being available, so KVM_CREATE_IRQCHIP may fail although there is an in-kernel IRQ chip available. Instead of hacking something up I thought it would be cleaner to use the existing framework and just map KVM_CREATE_IRQCHIP to KVM_CREATE_DEVICE(KVM_DEV_TYPE_ARM_VGIC_V2). Thanks, Andre. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
