Re: [RFC PATCH] KVM: introduce kvm_check_device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Scott,

On 07/01/15 18:16, Scott Wood wrote:
> On Wed, 2015-01-07 at 18:11 +0000, Andre Przywara wrote:
>> On 07/01/15 17:45, Scott Wood wrote:
>>> On Wed, 2015-01-07 at 10:55 +0000, Andre Przywara wrote:
>>>> Hi Scott,
>>>>
>>>> thanks for looking at the patch.
>>>>
>>>> On 06/01/15 20:52, Scott Wood wrote:
>>>>> 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).
>>>
>>> In that case you'd need the full create_device functionality from
>>> arch/arm/kvm, not just testing whether a device type is present, right?
>>
>> Well, not really. On KVM_CREATE_IRQCHIP kvm_vgic_create is called, which
>> is also what the KVM device .create function for GIC_V2 does.
>> So yes, we don't fully use the KVM device framework, but just use the
>> same functionality.
>> Not sure if it would make sense to use more of the KVM device framework,
>> as currently there is no issue with the current approach and I just need
>> to know whether the GIC_V2 has been registered.
> 
> If you're communicating privately with the vgic code to create the
> irqchip, can't you also communicate privately to see if that
> functionality is available?  I'm not opposed to this patch, but it seems
> odd to use the device framework just for testing whether some other
> interface is available.

Mainly because I wanted to avoid a solution that is private to the VGIC
and ARM. Also hacking this into the VGIC code looks much uglier than
simply using kvm_check_device_type(). Currently I just register GIC_V2
or GIC_V3 according to the hardware's capabilities. Now I have to
duplicate this decision making in the VGIC code again.

I now worked around the issue without this patch now, but it looks quite
ugly. I will send out a new version of the patch series tomorrow and
will put you on CC: for the respective patches.
So if in doubt we can continue this discussion on those patches later.

Cheers,
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



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux