[Top][All Lists]

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

Re: [PATCH] hw/intc/arm_gic_kvm: Don't assume kernel can provide a GICv2

From: Auger Eric
Subject: Re: [PATCH] hw/intc/arm_gic_kvm: Don't assume kernel can provide a GICv2
Date: Wed, 26 Feb 2020 18:09:18 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

Hi Peter,

On 2/26/20 12:58 PM, Auger Eric wrote:
> Hi Peter,
> On 2/26/20 10:17 AM, Andrew Jones wrote:
>> On Wed, Feb 26, 2020 at 08:56:03AM +0000, Peter Maydell wrote:
>>> On Wed, 26 Feb 2020 at 08:52, Andrew Jones <address@hidden> wrote:
>>>> Although, many QEMU command line users still won't know what to do
>>>> without an explicit "Try -machine gic-version=host" hint, so that
>>>> might be nice to add too.
>>> In the GIC code we don't know if the machine even has a
>>> gic-version property, so we're not in the right place to try to
>>> produce that message.
>> Ah yes, we use qdev_init_nofail() in virt::create_gic(), so there's
>> no chance to append another hint at the machine level.
>> And what about when machine.gic-version is not provided and KVM is
>> in use? Shouldn't we try version '2', as we do now, but then also
>> '3', if '2' fails, before erroring out?
> In case of KVM accelerated mode we could effectively probe v2 first and
> if not supported choose v3, as mentioned by Drew.
> Couldn't kvm_arm_vgic_probe() return a bitmap by calling
> kvm_create_device on both versions in dryrun mode?

I sent an RFC prototyping what we had in mind - I think - together with

[RFC 0/2] hw/arm/virt: kvm: allow gicv3 by default if host does not
support v2

This was discussed earlier in that thread:

It should not break any compatibility as the only case we are supposed
to change here was aborting before.


> Thanks
> Eric
>> Thanks,
>> drew

reply via email to

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