qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: qemu-devel@nongnu.org, "Alex Bennée" <alex.bennee@linaro.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"Igor Mitsyanko" <i.mitsyanko@gmail.com>,
	"Radoslaw Biernacki" <rad@semihalf.com>,
	qemu-arm@nongnu.org, "Leif Lindholm" <quic_llindhol@quicinc.com>,
	"Rob Herring" <robh@kernel.org>,
	"Alistair Francis" <alistair@alistair23.me>,
	"Marcin Juszkiewicz" <marcin.juszkiewicz@linaro.org>,
	"Markus Armbruster" <armbru@redhat.com>
Subject: Re: [RFC PATCH] hw/arm: Prefer arm_feature() over object_property_find()
Date: Mon, 18 Dec 2023 09:54:07 +0000	[thread overview]
Message-ID: <CAFEAcA8fmzv6qkN=N9TZoYVox+uQ0m5iLkGPQpcRDVA8eDEujg@mail.gmail.com> (raw)
In-Reply-To: <20231214171447.44025-1-philmd@linaro.org>

On Thu, 14 Dec 2023 at 17:14, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>
> QOM properties are added on the ARM vCPU object when a
> feature is present. Rather than checking the property
> is present, check the feature.
>
> Suggested-by: Markus Armbruster <armbru@redhat.com>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> ---
> RFC: If there is no objection on this patch, I can split
>      as a per-feature series if necessary.
>
> Based-on: <20231123143813.42632-1-philmd@linaro.org>
>   "hw: Simplify accesses to CPUState::'start-powered-off' property"
> ---
>  hw/arm/armv7m.c       | 21 ++++++++++++---------
>  hw/arm/exynos4210.c   |  4 ++--
>  hw/arm/highbank.c     |  3 ++-
>  hw/arm/integratorcp.c |  5 ++---
>  hw/arm/realview.c     |  2 +-
>  hw/arm/sbsa-ref.c     |  3 ++-
>  hw/arm/versatilepb.c  |  5 ++---
>  hw/arm/vexpress.c     |  6 ++++--
>  hw/arm/virt.c         | 27 +++++++++++++++------------
>  hw/arm/xilinx_zynq.c  |  2 +-
>  hw/cpu/a15mpcore.c    | 17 +++++++++++------
>  hw/cpu/a9mpcore.c     |  6 +++---
>  12 files changed, 57 insertions(+), 44 deletions(-)
>
> diff --git a/hw/arm/armv7m.c b/hw/arm/armv7m.c
> index 3a6d72b0f3..932061c11a 100644
> --- a/hw/arm/armv7m.c
> +++ b/hw/arm/armv7m.c
> @@ -302,28 +302,29 @@ static void armv7m_realize(DeviceState *dev, Error **errp)
>
>      object_property_set_link(OBJECT(s->cpu), "memory", OBJECT(&s->container),
>                               &error_abort);
> -    if (object_property_find(OBJECT(s->cpu), "idau")) {
> +    if (arm_feature(&s->cpu->env, ARM_FEATURE_M_SECURITY)) {
>          object_property_set_link(OBJECT(s->cpu), "idau", s->idau,
>                                   &error_abort);
> -    }
> -    if (object_property_find(OBJECT(s->cpu), "init-svtor")) {
>          if (!object_property_set_uint(OBJECT(s->cpu), "init-svtor",
>                                        s->init_svtor, errp)) {
>              return;
>          }
>      }
> -    if (object_property_find(OBJECT(s->cpu), "init-nsvtor")) {
> +    if (arm_feature(&s->cpu->env, ARM_FEATURE_M)) {

This doesn't make sense as a check -- we shouldn't be able to get
here if the CPU isn't M-profile.

>          if (!object_property_set_uint(OBJECT(s->cpu), "init-nsvtor",
>                                        s->init_nsvtor, errp)) {
>              return;
>          }
>      }
> -    if (object_property_find(OBJECT(s->cpu), "vfp")) {
> -        if (!object_property_set_bool(OBJECT(s->cpu), "vfp", s->vfp, errp)) {
> -            return;
> +    if (arm_feature(&s->cpu->env, ARM_FEATURE_AARCH64)) {

Similarly this can't possibly be an AArch64 CPU, so this is
not the correct condition to check.

> +        if (cpu_isar_feature(aa64_fp_simd, s->cpu)) {
> +            if (!object_property_set_bool(OBJECT(s->cpu), "vfp", s->vfp, errp)) {
> +                return;
> +            }
>          }
>      }
> -    if (object_property_find(OBJECT(s->cpu), "dsp")) {
> +    if (arm_feature(&s->cpu->env, ARM_FEATURE_M) &&
> +        arm_feature(&s->cpu->env, ARM_FEATURE_THUMB_DSP)) {
>          if (!object_property_set_bool(OBJECT(s->cpu), "dsp", s->dsp, errp)) {

Another unnecessary "is this M-profile?" check. This also is
introducing a point of potential future failure because now
we have the condition for "do we have a dsp property" in two
places: in the CPU object where we add it, and then again here
when we set it. Now they can get out of sync.

Most of the others are similar. There might be places where we're
using the "does property X check" to do something more than just
guard "now set property X"; those are probably worth looking at
to see if they should be checking something else.

thanks
-- PMM


      parent reply	other threads:[~2023-12-18  9:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-14 17:14 [RFC PATCH] hw/arm: Prefer arm_feature() over object_property_find() Philippe Mathieu-Daudé
2023-12-14 17:25 ` Peter Maydell
2023-12-18  7:26   ` Markus Armbruster
2023-12-18  9:48     ` Peter Maydell
2024-01-02 12:28       ` Philippe Mathieu-Daudé
2023-12-27  9:49     ` Philippe Mathieu-Daudé
2023-12-18  9:54 ` Peter Maydell [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFEAcA8fmzv6qkN=N9TZoYVox+uQ0m5iLkGPQpcRDVA8eDEujg@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=alex.bennee@linaro.org \
    --cc=alistair@alistair23.me \
    --cc=armbru@redhat.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=i.mitsyanko@gmail.com \
    --cc=marcin.juszkiewicz@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quic_llindhol@quicinc.com \
    --cc=rad@semihalf.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).