[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2] Add virt-v3 machine that uses GIC-500
From: |
Pavel Fedin |
Subject: |
Re: [Qemu-devel] [PATCH v2] Add virt-v3 machine that uses GIC-500 |
Date: |
Tue, 12 May 2015 14:15:46 +0300 |
Hello!
> We are not. Support for GICv2 vs v3 should be dealt with
> by suitable machine properties
I don't remember whether i clearly wrote about it... First i added a property,
like -machine virt,gicv3=on. But then i decided to stick back to different
machine name because libvirt does not have mechanism for passing machine
options.
> (and by figuring out how
> we handle probing for which of the two the host kernel
> can provide us).
This is tricky. I thought about it.
Kernel offers us only KVM_CAP_IRQCHIP Boolean. But it does not tell us which
irqchip. Possible variants are:
a) Host with GICv2 - this can only be v2.
b) Host with GICv3 with backwards compatibility option - this can be both
b) Host with GICv3 without compatibility option - this can only be v3.
Perhaps we could do a probe in kvm_arch_irqchip_create(), however i'm not
sure what happens in the kernel when this is called. This call actually
instantiates the device, but drops its fd. I suggest, the device is still
created, and next attempt to do it will just return the same fd. And i don't
know what happens if we create both GICs (i cannot test because i don't have
machine capable of doing it).
OTOH, if we don't have in-kernel acceleration, perhaps the good idea is stick
to what the user wants, and use emulation. Yes, i know about problems with
generic timer in this case, but this if different issue which can also be fixed.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia