From: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-arm@nongnu.org, qemu-devel@nongnu.org,
"Philippe Mathieu-Daudé" <philmd@linaro.org>
Subject: Re: [PATCH v2 3/7] hw/core/cpu-common: Don't init gdbstub until cpu_exec_realizefn()
Date: Tue, 29 Apr 2025 18:03:38 +0200 [thread overview]
Message-ID: <aBD4WuIP0MJ0OVpu@zapote> (raw)
In-Reply-To: <20250429132200.605611-4-peter.maydell@linaro.org>
On Tue, Apr 29, 2025 at 02:21:56PM +0100, Peter Maydell wrote:
> Currently we call gdb_init_cpu() in cpu_common_initfn(), which is
> very early in the CPU object's init->realize creation sequence. In
> particular this happens before the architecture-specific subclass's
> init fn has even run. This means that gdb_init_cpu() can only do
> things that depend strictly on the class, not on the object, because
> the CPUState* that it is passed is currently half-initialized.
>
> In commit a1f728ecc90cf6c6 we accidentally broke this rule, by adding
> a call to the gdb_get_core_xml_file method which takes the CPUState.
> At the moment we get away with this because the only implementation
> doesn't actually look at the pointer it is passed. However the whole
> reason we created that method was so that we could make the "which
> XML file?" decision based on a property of the CPU object, and we
> currently can't change the Arm implementation of the method to do
> what we want without causing wrong behaviour or a crash.
>
> The ordering restrictions here are:
> * we must call gdb_init_cpu before:
> - any call to gdb_register_coprocessor()
> - any use of the gdb_num_regs field (this is only used
> in code that's about to call gdb_register_coprocessor()
> and wants to know the first register number of the
> set of registers it's about to add)
> * we must call gdb_init_cpu after CPU properties have been
> set, which is to say somewhere in realize
>
> The function cpu_exec_realizefn() meets both of these requirements,
> as it is called by the architecture-specific CPU realize function
> early in realize, before any calls ot gdb_register_coprocessor().
> Move the gdb_init_cpu() call to there.
Sounds good to me:
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> hw/core/cpu-common.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw/core/cpu-common.c b/hw/core/cpu-common.c
> index 92c40b6bf83..39e674aca21 100644
> --- a/hw/core/cpu-common.c
> +++ b/hw/core/cpu-common.c
> @@ -234,6 +234,8 @@ bool cpu_exec_realizefn(CPUState *cpu, Error **errp)
> return false;
> }
>
> + gdb_init_cpu(cpu);
> +
> /* Wait until cpu initialization complete before exposing cpu. */
> cpu_list_add(cpu);
>
> @@ -304,7 +306,6 @@ static void cpu_common_initfn(Object *obj)
> /* cache the cpu class for the hotpath */
> cpu->cc = CPU_GET_CLASS(cpu);
>
> - gdb_init_cpu(cpu);
> cpu->cpu_index = UNASSIGNED_CPU_INDEX;
> cpu->cluster_index = UNASSIGNED_CLUSTER_INDEX;
> cpu->as = NULL;
> --
> 2.43.0
>
next prev parent reply other threads:[~2025-04-29 16:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-29 13:21 [PATCH v2 0/7] target/arm: Remove TYPE_AARCH64_CPU class Peter Maydell
2025-04-29 13:21 ` [PATCH v2 1/7] target/microblaze: Use 'obj' in DEVICE() casts in mb_cpu_initfn() Peter Maydell
2025-04-29 14:59 ` Philippe Mathieu-Daudé
2025-04-29 15:59 ` Edgar E. Iglesias
2025-04-30 17:19 ` Richard Henderson
2025-04-29 13:21 ` [PATCH v2 2/7] target/microblaze: Delay gdb_register_coprocessor() to realize Peter Maydell
2025-04-29 16:00 ` Edgar E. Iglesias
2025-04-30 17:19 ` Richard Henderson
2025-05-01 19:40 ` Philippe Mathieu-Daudé
2025-04-29 13:21 ` [PATCH v2 3/7] hw/core/cpu-common: Don't init gdbstub until cpu_exec_realizefn() Peter Maydell
2025-04-29 16:03 ` Edgar E. Iglesias [this message]
2025-04-30 17:19 ` Richard Henderson
2025-05-01 13:09 ` Alex Bennée
2025-05-01 19:39 ` Philippe Mathieu-Daudé
2025-04-29 13:21 ` [PATCH v2 4/7] target/arm: Present AArch64 gdbstub based on ARM_FEATURE_AARCH64 Peter Maydell
2025-04-30 17:19 ` Richard Henderson
2025-04-29 13:21 ` [PATCH v2 5/7] target/arm: Move aarch64 CPU property code to TYPE_ARM_CPU Peter Maydell
2025-04-30 17:21 ` Richard Henderson
2025-04-29 13:21 ` [PATCH v2 6/7] target/arm/kvm: don't check TYPE_AARCH64_CPU Peter Maydell
2025-04-30 17:21 ` Richard Henderson
2025-04-29 13:22 ` [PATCH v2 7/7] target/arm: Remove TYPE_AARCH64_CPU Peter Maydell
2025-04-30 17:21 ` Richard Henderson
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=aBD4WuIP0MJ0OVpu@zapote \
--to=edgar.iglesias@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.