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

Re: [PATCH v4] xen/arm: Allow QEMU platform to be built with GICv2



Hi,

On 19/01/2022 15:30, Dongjiu Geng wrote:
Bertrand Marquis <Bertrand.Marquis@xxxxxxx> 于2022年1月18日周二 17:17写道:

Hi Dongju,

On 18 Jan 2022, at 08:58, Dongjiu Geng <gengdongjiu1@xxxxxxxxx> wrote:

Bertrand Marquis <Bertrand.Marquis@xxxxxxx> 于2022年1月18日周二 16:48写道:

Hi Dongju,

On 18 Jan 2022, at 08:45, Dongjiu Geng <gengdongjiu1@xxxxxxxxx> wrote:

Julien Grall <julien@xxxxxxx> 于2022年1月17日周一 22:16写道:

Hi,

On 17/01/2022 10:40, Dongjiu Geng wrote:
It turns out that QEMU has been supporting GICv2 virtualization since
v3.1.0. So remove the dependencies on GICv3.


Technically, the current form of CONFIG_QEMU allows the same binary to
boot on QEMU with GICv2 or GICv3.

If we want to use GICv3,
we can select the QEMU_LEGACY configuration.

AFAIK, GICv3 is not a legacy feature... So it feels a bit odd to name it
like that (see more below).

Legacy means QEMU platform only supports GICV3, now it can support
both GICv2 and GICv3. The scope of support has been expanded
Not mean GICv3 is a legacy feature.

You might be misleading a bit here.
In the current configuration, Xen support GICv2, GICv3 and vgic.
The only thing not supported is actually the new VGIC but this is an 
unsupported feature not fully functional which shall be used with caution.

What issue exactly do you have in Qemu configured for gicv2 when you use the 
default configuration ?

I want to use NEW_VGIC with GICv2, but QEMU only select GICV3,  when
GICv3 is select, the NEW_VGIC can not be used.   I try the NEW_VGIC
with GICv2, not found issue. so I want to remove this limitation.
If  you think we should not support NEW_VGIC feature,  we can ignore
this patch.  thanks!

Supporting GICv2 makes sense but using NEW_VGIC in Xen might not as it is not 
security supported and does not support ITS and MSIs.
    It is surely that NEW_VGIC not support ITS and MSI.  but I think
QEMU platform should not limit user select it.

The goal of the option CONFIG_<platform> is to select the minimal set of CONFIG_* to allow booting on a given platform. Given that QEMU is supporting both GICv2 and GICv3, then I think it is correct to select both options.

 Selecting GICv2、GICv3
or NEW_VGIC may be chosen by users. But I find user can select it at
all.


Do you have a reason to use the NEW_VGIC implementation instead of the standard 
one ?

I add some features which is ported from KVM,  NEW_VGIC is refereed to
KVM,so it easily integrate

Ok. So why does this needs to be done with CONFIG_QEMU? Can't you use defconfig + select the NEW_VGIC by hand?

Cheers,

--
Julien Grall



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.