[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 13/14] hw/arm: Prefer arm_feature(AARCH64) over object_pro
|
From: |
Marc Zyngier |
|
Subject: |
Re: [PATCH v3 13/14] hw/arm: Prefer arm_feature(AARCH64) over object_property_find(aarch64) |
|
Date: |
Thu, 11 Jan 2024 09:47:56 +0000 |
|
User-agent: |
Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (Gojō) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) |
On Thu, 11 Jan 2024 09:39:18 +0000,
Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>
> On 10/1/24 20:53, Philippe Mathieu-Daudé wrote:
> > The "aarch64" property is added to ARMCPU when the
> > ARM_FEATURE_AARCH64 feature is available. Rather than
> > checking whether the QOM property is present, directly
> > check the feature.
> >
> > Suggested-by: Markus Armbruster <armbru@redhat.com>
> > Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> > ---
> > hw/arm/virt.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> > index 49ed5309ff..a43e87874c 100644
> > --- a/hw/arm/virt.c
> > +++ b/hw/arm/virt.c
> > @@ -2140,7 +2140,7 @@ static void machvirt_init(MachineState *machine)
> > numa_cpu_pre_plug(&possible_cpus->cpus[cs->cpu_index],
> > DEVICE(cpuobj),
> > &error_fatal);
> > - aarch64 &= object_property_get_bool(cpuobj, "aarch64",
> > NULL);
> > + aarch64 &= arm_feature(cpu_env(cs), ARM_FEATURE_AARCH64);
>
> So after this patch there are no more use of the ARMCPU "aarch64"
> property from code. Still it is exposed via the qom-tree. Thus it
> can be set (see aarch64_cpu_set_aarch64). I could understand one
> flip this feature to create a custom CPU (as a big-LITTLE setup
> as Marc mentioned on IRC), but I don't understand what is the
> expected behavior when this is flipped at runtime. Can that
> happen in real hardware (how could the guest react to that...)?
I don't think it makes any sense to do that while a guest is running
(and no HW I'm aware of would do this). However, it all depends what
you consider "run time". You could imagine creating a skeletal VM with
all features, and then apply a bunch of changes before the guest
actually runs.
I don't know enough about the qom-tree and dynamic manipulation of
these properties though, and I'm likely to be wrong about the expected
usage model.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
- [PATCH v3 05/14] hw/arm: Prefer arm_feature(M_SECURITY) over object_property_find(), (continued)
- [PATCH v3 05/14] hw/arm: Prefer arm_feature(M_SECURITY) over object_property_find(), Philippe Mathieu-Daudé, 2024/01/10
- [PATCH v3 06/14] hw/arm: Prefer arm_feature(THUMB_DSP) over object_property_find(dsp), Philippe Mathieu-Daudé, 2024/01/10
- [PATCH v3 07/14] hw/arm: Prefer arm_feature(V7) over object_property_find(pmsav7-dregion), Philippe Mathieu-Daudé, 2024/01/10
- [PATCH v3 08/14] hw/arm: Prefer arm_feature(EL3) over object_property_find(has_el3), Philippe Mathieu-Daudé, 2024/01/10
- [PATCH v3 09/14] hw/arm: Prefer arm_feature(EL2) over object_property_find(has_el2), Philippe Mathieu-Daudé, 2024/01/10
- [PATCH v3 10/14] hw/arm: Prefer arm_feature(CBAR*) over object_property_find(reset-cbar), Philippe Mathieu-Daudé, 2024/01/10
- [PATCH v3 11/14] hw/arm: Prefer arm_feature(PMU) over object_property_find(pmu), Philippe Mathieu-Daudé, 2024/01/10
- [PATCH v3 12/14] hw/arm: Prefer arm_feature(GENERIC_TMR) over 'kvm-no-adjvtime' property, Philippe Mathieu-Daudé, 2024/01/10
- [PATCH v3 13/14] hw/arm: Prefer arm_feature(AARCH64) over object_property_find(aarch64), Philippe Mathieu-Daudé, 2024/01/10
[PATCH v3 14/14] hw/arm: Prefer cpu_isar_feature(aa64_mte) over property_find(tag-memory), Philippe Mathieu-Daudé, 2024/01/10
Re: [PATCH v3 00/14] hw/arm: Prefer arm_feature() over object_property_find(), Peter Maydell, 2024/01/13