From: Fabiano Rosas <farosas@suse.de>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org, Thomas Huth <thuth@redhat.com>,
Peter Xu <peterx@redhat.com>, qemu-arm <qemu-arm@nongnu.org>
Subject: Re: [PULL 02/20] target/arm: Correct encoding of Debug Communications Channel registers
Date: Tue, 29 Jul 2025 21:32:03 -0300 [thread overview]
Message-ID: <87bjp24iyk.fsf@suse.de> (raw)
In-Reply-To: <87ms8s3rpx.fsf@suse.de>
Fabiano Rosas <farosas@suse.de> writes:
> Fabiano Rosas <farosas@suse.de> writes:
>
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>>> On Wed, 23 Jul 2025 at 23:20, Fabiano Rosas <farosas@suse.de> wrote:
>>>>
>>>> Peter Maydell <peter.maydell@linaro.org> writes:
>>>>
>>>> > We don't implement the Debug Communications Channel (DCC), but
>>>> > we do attempt to provide dummy versions of its system registers
>>>> > so that software that tries to access them doesn't fall over.
>>>> >
>>>> > However, we got the tx/rx register definitions wrong. These
>>>> > should be:
>>>> >
>>>> > AArch32:
>>>> > DBGDTRTX p14 0 c0 c5 0 (on writes)
>>>> > DBGDTRRX p14 0 c0 c5 0 (on reads)
>>>> >
>>>> > AArch64:
>>>> > DBGDTRTX_EL0 2 3 0 5 0 (on writes)
>>>> > DBGDTRRX_EL0 2 3 0 5 0 (on reads)
>>>> > DBGDTR_EL0 2 3 0 4 0 (reads and writes)
>>>> >
>>>> > where DBGDTRTX and DBGDTRRX are effectively different names for the
>>>> > same 32-bit register, which has tx behaviour on writes and rx
>>>> > behaviour on reads. The AArch64-only DBGDTR_EL0 is a 64-bit wide
>>>> > register whose top and bottom halves map to the DBGDTRRX and DBGDTRTX
>>>> > registers.
>>>> >
>>>> > Currently we have just one cpreg struct, which:
>>>> > * calls itself DBGDTR_EL0
>>>> > * uses the DBGDTRTX_EL0/DBGDTRRX_EL0 encoding
>>>> > * is marked as ARM_CP_STATE_BOTH but has the wrong opc1
>>>> > value for AArch32
>>>> > * is implemented as RAZ/WI
>>>> >
>>>> > Correct the encoding so:
>>>> > * we name the DBGDTRTX/DBGDTRRX register correctly
>>>> > * we split it into AA64 and AA32 versions so we can get the
>>>> > AA32 encoding right
>>>> > * we implement DBGDTR_EL0 at its correct encoding
>>>> >
>>>> > Cc: qemu-stable@nongnu.org
>>>> > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2986
>>>> > Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>>>> > Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
>>>> > Message-id: 20250708141049.778361-1-peter.maydell@linaro.org
>>>> > ---
>>>> > target/arm/debug_helper.c | 13 +++++++++++--
>>>> > 1 file changed, 11 insertions(+), 2 deletions(-)
>>>> >
>>>> > diff --git a/target/arm/debug_helper.c b/target/arm/debug_helper.c
>>>> > index 69fb1d0d9ff..aee06d4d426 100644
>>>> > --- a/target/arm/debug_helper.c
>>>> > +++ b/target/arm/debug_helper.c
>>>> > @@ -988,11 +988,20 @@ static const ARMCPRegInfo debug_cp_reginfo[] = {
>>>> > .opc0 = 2, .opc1 = 0, .crn = 0, .crm = 3, .opc2 = 2,
>>>> > .access = PL1_RW, .accessfn = access_tdcc,
>>>> > .type = ARM_CP_CONST, .resetvalue = 0 },
>>>> > - /* DBGDTRTX_EL0/DBGDTRRX_EL0 depend on direction */
>>>> > - { .name = "DBGDTR_EL0", .state = ARM_CP_STATE_BOTH, .cp = 14,
>>>> > + /* Architecturally DBGDTRTX is named DBGDTRRX when used for reads */
>>>> > + { .name = "DBGDTRTX_EL0", .state = ARM_CP_STATE_AA64,
>>>> > .opc0 = 2, .opc1 = 3, .crn = 0, .crm = 5, .opc2 = 0,
>>>> > .access = PL0_RW, .accessfn = access_tdcc,
>>>> > .type = ARM_CP_CONST, .resetvalue = 0 },
>>>> > + { .name = "DBGDTRTX", .state = ARM_CP_STATE_AA32, .cp = 14,
>>>> > + .opc1 = 0, .crn = 0, .crm = 5, .opc2 = 0,
>>>> > + .access = PL0_RW, .accessfn = access_tdcc,
>>>> > + .type = ARM_CP_CONST, .resetvalue = 0 },
>>>> > + /* This is AArch64-only and is a combination of DBGDTRTX and DBGDTRRX */
>>>> > + { .name = "DBGDTR_EL0", .state = ARM_CP_STATE_AA64,
>>>> > + .opc0 = 2, .opc1 = 3, .crn = 0, .crm = 4, .opc2 = 0,
>>>> > + .access = PL0_RW, .accessfn = access_tdcc,
>>>> > + .type = ARM_CP_CONST, .resetvalue = 0 },
>>>> > /*
>>>> > * OSECCR_EL1 provides a mechanism for an operating system
>>>> > * to access the contents of EDECCR. EDECCR is not implemented though,
>>>>
>>>> Hi, this patch breaks migration. I'm leaving for the day and will take a
>>>> closer look in the morning. But since we have timezones, here it is:
>>>
>>> Thanks for the report; I can repro this. It happens because
>>> the loop in cpu_post_load hits the "register in their list but
>>> not ours" check, because the source VM has the AArch32
>>> {.cp = 14, .opc0 = 2, .opc1 = 3, .crn = 0, .crm = 5, .opc2 = 0}
>>> register which should never have existed.
>>>
>>
>> My debugging (in dst) shows:
>>
>> (gdb) x/16x 0x555557ad5d20 //cpu->cpreg_vmstate_indexes[0x18 to 0x1c]
>> 0x555557ad5d20: 0x200e0205 0x40200000 0x200e0284< 0x40200000
>> 0x555557ad5d30: 0x200e0285 0x40200000 0x200e0298 0x40200000
>> 0x555557ad5d40: 0x200e0302 0x40200000 0x200e0380 0x40200000
>> 0x555557ad5d50: 0x200e0800 0x40200000 0x200e0838 0x40200000
>>
>> (gdb) x/16x 0x555557ad4ac0 //cpu->cpreg_indexes[0x18 to 0x1c]
>> p0x555557ad4ac0: 0x200e0205 0x40200000 0x200e0280< 0x40200000
>> 0x555557ad4ad0: 0x200e0284 0x40200000 0x200e0285 0x40200000
>> 0x555557ad4ae0: 0x200e0302 0x40200000 0x200e0380 0x40200000
>> 0x555557ad4af0: 0x200e0800 0x40200000 0x200e0838 0x40200000
>>
>>
>>> I'm not sure how to handle this, as we have no mechanism for
>>> "ignore this incoming register value, it is bogus". I'm surprised
>>> we've never run into this before...
>>>
>>
>> I was thinking the same.
>>
>> I actually don't understand what the encoding in cpu->cpreg_indexes is
>> supposed to represent. How does comparing the indexes implies "in our
>> list"/"in their list"? Is there some sort of ISA level assumption?
>>
>> if (cpu->cpreg_vmstate_indexes[v] > cpu->cpreg_indexes[i]) {
>> /* register in our list but not incoming : skip it */
>> continue;
>> }
>> if (cpu->cpreg_vmstate_indexes[v] < cpu->cpreg_indexes[i]) {
>> /* register in their list but not ours: fail migration */
>> return -1;
>> }
>>
>
> Ok, I spotted the sorting now.
Turns out the backward migration is also broken because this patch adds
an extra register:
qemu-system-aarch64: Invalid value 292 expecting positive value <= 291
qemu-system-aarch64: Failed to load cpu:cpreg_vmstate_array_len
We'll need to develop some proper compat machinery that takes the
machine version in consideration. For the 10.0 -> 10.1 migration,
something like (messy code, just a PoC):
-->8--
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index e2b2337399..8eba2d178c 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1453,6 +1453,9 @@ static void arm_cpu_initfn(Object *obj)
cpu->cp_regs = g_hash_table_new_full(g_direct_hash, g_direct_equal,
NULL, g_free);
+ cpu->compat_regs = g_hash_table_new_full(g_direct_hash, g_direct_equal,
+ NULL, g_free);
+
QLIST_INIT(&cpu->pre_el_change_hooks);
QLIST_INIT(&cpu->el_change_hooks);
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index dc9b6dce4c..463ef686e1 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -911,6 +911,7 @@ struct ArchCPU {
/* Coprocessor information */
GHashTable *cp_regs;
+ GHashTable *compat_regs;
/* For marshalling (mostly coprocessor) register state between the
* kernel and QEMU (for KVM) and between two QEMUs (for migration),
* we use these arrays.
diff --git a/target/arm/debug_helper.c b/target/arm/debug_helper.c
index aee06d4d42..05607fc082 100644
--- a/target/arm/debug_helper.c
+++ b/target/arm/debug_helper.c
@@ -17,6 +17,8 @@
#define HELPER_H "tcg/helper.h"
#include "exec/helper-proto.h.inc"
+#include "hw/boards.h"
+
#ifdef CONFIG_TCG
/* Return the Exception Level targeted by debug exceptions. */
static int arm_debug_target_el(CPUARMState *env)
@@ -1077,6 +1079,14 @@ static const ARMCPRegInfo debug_cp_reginfo[] = {
.fieldoffset = offsetof(CPUARMState, cp15.dbgclaim) },
};
+static uint64_t compat_cp_reginfo_virt_10_0[] = {
+ /*
+ * { .name = "DBGDTRTX", .state = ARM_CP_STATE_AA32,
+ * .cp = 14, .crn = 0, .crm = 5, .opc1 = 3, .opc2 = 0 }
+ */
+ ENCODE_CP_REG(14, 0, 1, 0, 5, 3, 0),
+};
+
/* These are present only when EL1 supports AArch32 */
static const ARMCPRegInfo debug_aa32_el1_reginfo[] = {
/*
@@ -1235,6 +1245,15 @@ void define_debug_regs(ARMCPU *cpu)
assert(ctx_cmps <= brps);
define_arm_cp_regs(cpu, debug_cp_reginfo);
+
+ {
+ MachineState *machine = MACHINE(qdev_get_machine());
+ MachineClass *mc = MACHINE_GET_CLASS(machine);
+
+ g_hash_table_insert(cpu->compat_regs, mc->name,
+ (gpointer)compat_cp_reginfo_virt_10_0);
+ }
+
if (cpu_isar_feature(aa64_aa32_el1, cpu)) {
define_arm_cp_regs(cpu, debug_aa32_el1_reginfo);
}
diff --git a/target/arm/machine.c b/target/arm/machine.c
index 6986915bee..e8b83b62e8 100644
--- a/target/arm/machine.c
+++ b/target/arm/machine.c
@@ -10,6 +10,9 @@
#include "migration/vmstate.h"
#include "target/arm/gtimer.h"
+#include "target/arm/cpregs.h"
+#include "hw/boards.h"
+
static bool vfp_needed(void *opaque)
{
ARMCPU *cpu = opaque;
@@ -987,10 +990,27 @@ static int cpu_post_load(void *opaque, int version_id)
}
if (cpu->cpreg_vmstate_indexes[v] < cpu->cpreg_indexes[i]) {
/* register in their list but not ours: fail migration */
+
+ MachineState *machine = MACHINE(qdev_get_machine());
+ MachineClass *mc = MACHINE_GET_CLASS(machine);
+ uint64_t *compat_regs = g_hash_table_lookup(cpu->compat_regs,
+ mc->name);
+
+ for (int j = 0; j < G_N_ELEMENTS(compat_regs); j++) {
+ if (cpu->cpreg_vmstate_indexes[v] == cpreg_to_kvm_id(compat_regs[j])) {
+ /*
+ * ...unless the extra register is being explicitly
+ * ignored for migration compatibility purposes.
+ */
+ i--;
+ goto next;
+ }
+ }
return -1;
}
/* matching register, copy the value over */
cpu->cpreg_values[i] = cpu->cpreg_vmstate_values[v];
+ next:
v++;
}
diff --git a/tests/qtest/migration/framework.c b/tests/qtest/migration/framework.c
index 407c9023c0..0ccb4a6c67 100644
--- a/tests/qtest/migration/framework.c
+++ b/tests/qtest/migration/framework.c
@@ -317,7 +317,7 @@ int migrate_start(QTestState **from, QTestState **to, const char *uri,
memory_size = "150M";
machine_alias = "virt";
machine_opts = "gic-version=3";
- arch_opts = g_strdup_printf("-cpu max -kernel %s", bootpath);
+ arch_opts = g_strdup_printf("-cpu neoverse-n1 -kernel %s", bootpath);
start_address = ARM_TEST_MEM_START;
end_address = ARM_TEST_MEM_END;
} else {
--
2.35.3
next prev parent reply other threads:[~2025-07-30 0:58 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-21 13:26 [PULL 00/20] target-arm queue Peter Maydell
2025-07-21 13:26 ` [PULL 01/20] hvf: arm: Remove $pc from trace_hvf_data_abort() Peter Maydell
2025-07-21 13:26 ` [PULL 02/20] target/arm: Correct encoding of Debug Communications Channel registers Peter Maydell
2025-07-23 22:20 ` Fabiano Rosas
2025-07-25 18:02 ` Peter Maydell
2025-07-25 19:10 ` Fabiano Rosas
2025-07-25 21:06 ` Fabiano Rosas
2025-07-30 0:32 ` Fabiano Rosas [this message]
2025-07-31 10:04 ` Peter Maydell
2025-07-31 13:32 ` Fabiano Rosas
2025-07-21 13:27 ` [PULL 03/20] hw/misc/ivshmem-pci: Improve error handling Peter Maydell
2025-07-21 13:27 ` [PULL 04/20] target/arm: Provide always-false kvm_arm_*_supported() stubs for usermode Peter Maydell
2025-07-21 13:27 ` [PULL 05/20] host-utils: Drop workaround for buggy Apple Clang __builtin_subcll() Peter Maydell
2025-07-21 13:27 ` [PULL 06/20] hw/misc/max78000_aes: Comment Internal Key Storage Peter Maydell
2025-07-21 13:27 ` [PULL 07/20] docs: Fix Aspeed title Peter Maydell
2025-07-21 13:27 ` [PULL 08/20] target/arm: Add BFADD, BFSUB, BFMUL (unpredicated) Peter Maydell
2025-07-21 13:27 ` [PULL 09/20] target/arm: Add BFADD, BFSUB, BFMUL, BFMAXNM, BFMINNM (predicated) Peter Maydell
2025-07-21 13:27 ` [PULL 10/20] target/arm: Add BFMIN, BFMAX (predicated) Peter Maydell
2025-07-21 13:27 ` [PULL 11/20] target/arm: Add BFMUL (indexed) Peter Maydell
2025-07-21 13:27 ` [PULL 12/20] target/arm: Add BFMLA, BFMLS (vectors) Peter Maydell
2025-07-21 13:27 ` [PULL 13/20] target/arm: Add BFMLA, BFMLS (indexed) Peter Maydell
2025-07-21 13:27 ` [PULL 14/20] target/arm: Correct sense of FPCR.AH test for FMAXQV and FMINQV Peter Maydell
2025-07-21 13:27 ` [PULL 15/20] target/arm: Don't nest H() macro calls in SVE DO_REDUCE Peter Maydell
2025-07-21 13:27 ` [PULL 16/20] target/arm: Honour FPCR.AH=1 default NaN value in FMAXNMQV, FMINNMQV Peter Maydell
2025-07-21 13:27 ` [PULL 17/20] target/arm: Make LD1Q decode and trans fn agree about a->u Peter Maydell
2025-07-21 13:27 ` [PULL 18/20] hvf: arm: Add permission check in GIC sysreg handlers Peter Maydell
2025-07-21 13:27 ` [PULL 19/20] hvf: arm: Emulate ICC_RPR_EL1 accesses properly Peter Maydell
2025-07-21 13:27 ` [PULL 20/20] accel/hvf: Display executable bit as 'X' Peter Maydell
2025-07-21 18:31 ` [PULL 00/20] target-arm queue Stefan Hajnoczi
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=87bjp24iyk.fsf@suse.de \
--to=farosas@suse.de \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/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).