qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v7 4/6] Introduce irqchip type specification for


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v7 4/6] Introduce irqchip type specification for KVM
Date: Tue, 28 Jul 2015 18:37:41 +0100

On 26 July 2015 at 14:46, Pavel Fedin <address@hidden> wrote:
>  Unfortunately, this is how qemu is designed. kvm_irqchip_create() is
> called long before machine model's init code (machvirt_init() in our
> case) is called. So, if we want to check for the right thing, we have
> to know it before machine model actually starts to instantiate its
> components.
>
>  I don't see how to change this in a more or less simple way. This
> routine, except capability testing, does one more important thing
> on old kernels. There it actually creates vGICv2 using
> KVM_CREATE_IRQCHIP ioctl.

Right, but all we really need to do in kvm_irqchip_create()
is confirm whether we can use the new API later; we don't
actually need to care whether we will later be creating a
GICv2 or a GICv3 (or whether the kernel supports GICv3).

Rather than having kvm_irqchip_create() pile up a list of
every irqchip type we might want later, I think it's probably
better to just have it do the check for KVM_CAP_DEVICE_CTRL.
If that check fails, we are on an old kernel, and should
return 0 so we do the old-style KVM_CREATE_IRQCHIP. If it succeeds,
then we're on a new kernel, and can postpone doing any GIC
init until the GIC device object is created. Then the GIC
device object should just try to do the kvm_create_device()
for the relevant kind of GIC. If we're trying to create a
GICv3 on a kernel that only knows about a GICv2 then this
will fail at this point and we can display a suitable error
message.

Christoffer: was there a particular reason you wrote kvm_irqchip_create()
to do a test device-create as well as check the capability bit?

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]