[RESEND PATCH 0/7] Mitigation of "failed to load cpu:cpreg_vmstate_array_len" migration failures

[RESEND PATCH 0/7] Mitigation of "failed to load cpu:cpreg_vmstate_array_len" migration failures

[Eric Auger]

When migrating ARM guests accross same machines with different host
kernels we are likely to encounter failures such as:

"failed to load cpu:cpreg_vmstate_array_len"

This is due to the fact KVM exposes a different number of registers
to qemu on source and destination. When trying to migrate a bigger
register set to a smaller one, qemu cannot save the CPU state.

For example, recently we faced such kind of situations with:
- unconditionnal exposure of KVM_REG_ARM_VENDOR_HYP_BMAP_2 FW pseudo
  register from v6.16 onwards. Causes backward migration failure.
- removal of unconditionnal exposure of TCR2_EL1, PIRE0_EL1, PIR_EL1
  from v6.13 onwards. Causes forward migration failure.

This situation is really problematic for distributions which want to
guarantee forward and backward migration of a given machine type
between different releases.

This small series tries to address that issue by introducing CPU
array properties that list the registers to ignore or to fake according
to the situation. An example is given to illustrate how those props
could be used to apply compats for machine types supposed to "see" the
same register set accross various host kernels.

The first patch improves the tracing so that we can quickly detect
which registers are unexpected and cause the migration failure. Missing
registers are also traced. Those do not fail migration but their default
value is kept on the destination.

Then we introduce the infrastructure to handle 'hidden' registers and
'fake' registers.

Eric Auger (7):
  target/arm/machine: Improve traces on register mismatch during
    migration
  target/arm/kvm: Introduce the concept of hidden KVM regs
  target/arm/kvm: Introduce the concept of enforced/fake registers
  kvm-all: Add the capability to blacklist some KVM regs
  target/arm/cpu: Implement hide_reg callback()
  target/arm/kvm: Expose kvm-hidden-regs and kvm-fake-regs properties
  hw/arm/virt: [DO NOT UPSTREAM] Enforce compatibility with older
    kernels

 include/hw/core/cpu.h   |  2 ++
 target/arm/cpu.h        | 42 ++++++++++++++++++++++++
 accel/kvm/kvm-all.c     | 12 +++++++
 hw/arm/virt.c           | 19 +++++++++++
 target/arm/cpu.c        | 12 +++++++
 target/arm/kvm.c        | 73 ++++++++++++++++++++++++++++++++++++++++-
 target/arm/machine.c    | 71 +++++++++++++++++++++++++++++++++++----
 target/arm/trace-events | 11 +++++++
 8 files changed, 235 insertions(+), 7 deletions(-)

-- 
2.49.0

[RESEND PATCH 1/7] target/arm/machine: Improve traces on register mismatch during migration

[Eric Auger]

Currently whenthe number of KVM registers exposed by the source is
larger than the one exposed on the destination, the migration fails
with: "failed to load cpu:cpreg_vmstate_array_len"

This gives no information about which registers are causing the trouble.

This patches rework the target/arm/machine code so that it becomes
able to handle an input stream with a larger set of registers than
the destination and print useful information about which registers
are causing the trouble. The migration outcome is unchanged:
- unexpected registers still will fail the migration
- missing ones are print but will not fail the migration, as done today.

The input stream can contain MAX_CPREG_VMSTATE_ANOMALIES(10) extra
registers compared to what exists on the target.

If there are more registers we will still hit the previous
"load cpu:cpreg_vmstate_array_len" error.

At most, MAX_CPREG_VMSTATE_ANOMALIES missing registers
and MAX_CPREG_VMSTATE_ANOMALIES unexpected registers are print.

Example:

qemu-system-aarch64: kvm_arm_cpu_post_load Missing register in input stream: 0 0x6030000000160003 fw feat reg 3
qemu-system-aarch64: kvm_arm_cpu_post_load Unexpected register in input stream: 0 0x603000000013c103 op0:3 op1:0 crn:2 crm:0 op2:3
qemu-system-aarch64: kvm_arm_cpu_post_load Unexpected register in input stream: 1 0x603000000013c512 op0:3 op1:0 crn:10 crm:2 op2:2
qemu-system-aarch64: kvm_arm_cpu_post_load Unexpected register in input stream: 2 0x603000000013c513 op0:3 op1:0 crn:10 crm:2 op2:3
qemu-system-aarch64: error while loading state for instance 0x0 of device 'cpu'
qemu-system-aarch64: load of migration failed: Operation not permitted

Signed-off-by: Eric Auger <eric.auger@redhat.com>
---
 target/arm/cpu.h        |  6 +++++
 target/arm/kvm.c        | 23 ++++++++++++++++
 target/arm/machine.c    | 58 ++++++++++++++++++++++++++++++++++++-----
 target/arm/trace-events |  7 +++++
 4 files changed, 88 insertions(+), 6 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index bf221e6f97..a7ed3f34f8 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -936,6 +936,12 @@ struct ArchCPU {
     uint64_t *cpreg_vmstate_values;
     int32_t cpreg_vmstate_array_len;
 
+    #define MAX_CPREG_VMSTATE_ANOMALIES 10
+    uint64_t cpreg_vmstate_missing_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
+    int32_t cpreg_vmstate_missing_indexes_array_len;
+    uint64_t cpreg_vmstate_unexpected_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
+    int32_t cpreg_vmstate_unexpected_indexes_array_len;
+
     DynamicGDBFeatureInfo dyn_sysreg_feature;
     DynamicGDBFeatureInfo dyn_svereg_feature;
     DynamicGDBFeatureInfo dyn_smereg_feature;
diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index 0d57081e69..58c6075a9e 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -1023,6 +1023,29 @@ void kvm_arm_cpu_pre_save(ARMCPU *cpu)
 
 bool kvm_arm_cpu_post_load(ARMCPU *cpu)
 {
+    int i;
+
+    for (i = 0; i < cpu->cpreg_vmstate_missing_indexes_array_len; i++) {
+        gchar *name;
+
+        name = kvm_print_register_name(cpu->cpreg_vmstate_missing_indexes[i]);
+        trace_kvm_arm_cpu_post_load_missing_reg(name);
+        g_free(name);
+    }
+
+    for (i = 0; i < cpu->cpreg_vmstate_unexpected_indexes_array_len; i++) {
+        gchar *name;
+
+        name = kvm_print_register_name(cpu->cpreg_vmstate_unexpected_indexes[i]);
+        error_report("%s Unexpected register in input stream: %i 0x%"PRIx64" %s",
+                     __func__, i, cpu->cpreg_vmstate_unexpected_indexes[i], name);
+        g_free(name);
+    }
+    /* Fail the migration if we detect unexpected registers */
+    if (cpu->cpreg_vmstate_unexpected_indexes_array_len) {
+        return false;
+    }
+
     if (!write_list_to_kvmstate(cpu, KVM_PUT_FULL_STATE)) {
         return false;
     }
diff --git a/target/arm/machine.c b/target/arm/machine.c
index 44a0cf844b..b7a655b066 100644
--- a/target/arm/machine.c
+++ b/target/arm/machine.c
@@ -9,6 +9,7 @@
 #include "migration/qemu-file-types.h"
 #include "migration/vmstate.h"
 #include "target/arm/gtimer.h"
+#include "trace.h"
 
 static bool vfp_needed(void *opaque)
 {
@@ -989,7 +990,13 @@ static int cpu_pre_load(void *opaque)
 {
     ARMCPU *cpu = opaque;
     CPUARMState *env = &cpu->env;
+    int arraylen = cpu->cpreg_vmstate_array_len + MAX_CPREG_VMSTATE_ANOMALIES;
 
+    cpu->cpreg_vmstate_indexes = g_renew(uint64_t, cpu->cpreg_vmstate_indexes,
+                                         arraylen);
+    cpu->cpreg_vmstate_values = g_renew(uint64_t, cpu->cpreg_vmstate_values,
+                                        arraylen);
+    cpu->cpreg_vmstate_array_len = arraylen;
     /*
      * In an inbound migration where on the source FPSCR/FPSR/FPCR are 0,
      * there will be no fpcr_fpsr subsection so we won't call vfp_set_fpcr()
@@ -1022,7 +1029,7 @@ static int cpu_post_load(void *opaque, int version_id)
 {
     ARMCPU *cpu = opaque;
     CPUARMState *env = &cpu->env;
-    int i, v;
+    int i = 0, j = 0, k = 0, v = 0;
 
     /*
      * Handle migration compatibility from old QEMU which didn't
@@ -1050,27 +1057,66 @@ static int cpu_post_load(void *opaque, int version_id)
      * entries with the right slots in our own values array.
      */
 
-    for (i = 0, v = 0; i < cpu->cpreg_array_len
-             && v < cpu->cpreg_vmstate_array_len; i++) {
+    trace_cpu_post_load_len(cpu->cpreg_array_len, cpu->cpreg_vmstate_array_len);
+    for (; i < cpu->cpreg_array_len && v < cpu->cpreg_vmstate_array_len;) {
+        trace_cpu_post_load(i, v , cpu->cpreg_indexes[i]);
         if (cpu->cpreg_vmstate_indexes[v] > cpu->cpreg_indexes[i]) {
             /* register in our list but not incoming : skip it */
+            trace_cpu_post_load_missing(i, cpu->cpreg_indexes[i], v);
+            if (j < MAX_CPREG_VMSTATE_ANOMALIES) {
+                cpu->cpreg_vmstate_missing_indexes[j++] = cpu->cpreg_indexes[i];
+            }
+            i++;
             continue;
         }
         if (cpu->cpreg_vmstate_indexes[v] < cpu->cpreg_indexes[i]) {
-            /* register in their list but not ours: fail migration */
-            return -1;
+            /* register in their list but not ours: those will fail migration */
+            trace_cpu_post_load_unexpected(v, cpu->cpreg_vmstate_indexes[v], i);
+            if (k < MAX_CPREG_VMSTATE_ANOMALIES) {
+                cpu->cpreg_vmstate_unexpected_indexes[k++] =
+                    cpu->cpreg_vmstate_indexes[v];
+            }
+            v++;
+            continue;
         }
         /* matching register, copy the value over */
         cpu->cpreg_values[i] = cpu->cpreg_vmstate_values[v];
         v++;
+        i++;
     }
+    /*
+     * if we have reached the end of the incoming array but there are
+     * still regs in cpreg, continue parsing the regs which are missing
+     * in the input stream
+     */
+    for ( ; i < cpu->cpreg_array_len; i++) {
+        if (j < MAX_CPREG_VMSTATE_ANOMALIES) {
+            trace_cpu_post_load_missing(i, cpu->cpreg_indexes[i], v);
+            cpu->cpreg_vmstate_missing_indexes[j++] = cpu->cpreg_indexes[i];
+        }
+    }
+    /*
+     * if we have reached the end of the cpreg array but there are
+     * still regs in the input stream, continue parsing the vmstate array
+     */
+    for ( ; v < cpu->cpreg_vmstate_array_len; v++) {
+        if (k < MAX_CPREG_VMSTATE_ANOMALIES) {
+            trace_cpu_post_load_unexpected(v, cpu->cpreg_vmstate_indexes[v], i);
+            cpu->cpreg_vmstate_unexpected_indexes[k++] =
+                cpu->cpreg_vmstate_indexes[v];
+        }
+    }
+
+    cpu->cpreg_vmstate_missing_indexes_array_len = j;
+    cpu->cpreg_vmstate_unexpected_indexes_array_len = k;
 
     if (kvm_enabled()) {
         if (!kvm_arm_cpu_post_load(cpu)) {
             return -1;
         }
     } else {
-        if (!write_list_to_cpustate(cpu)) {
+        if (cpu->cpreg_vmstate_unexpected_indexes_array_len ||
+            !write_list_to_cpustate(cpu)) {
             return -1;
         }
     }
diff --git a/target/arm/trace-events b/target/arm/trace-events
index 72a2c7d096..c497df8fe7 100644
--- a/target/arm/trace-events
+++ b/target/arm/trace-events
@@ -13,6 +13,7 @@ arm_gt_update_irq(int timer, int irqstate) "gt_update_irq: timer %d irqstate %d"
 
 # kvm.c
 kvm_arm_fixup_msi_route(uint64_t iova, uint64_t gpa) "MSI iova = 0x%"PRIx64" is translated into 0x%"PRIx64
+kvm_arm_cpu_post_load_missing_reg(char *name) "Missing register in input stream: %s"
 
 # cpu.c
 arm_cpu_reset(uint64_t mp_aff) "cpu %" PRIu64
@@ -23,3 +24,9 @@ arm_powerctl_set_cpu_on(uint64_t mp_aff, unsigned target_el, const char *mode, u
 arm_powerctl_set_cpu_on_and_reset(uint64_t mp_aff) "cpu %" PRIu64
 arm_powerctl_set_cpu_off(uint64_t mp_aff) "cpu %" PRIu64
 arm_powerctl_reset_cpu(uint64_t mp_aff) "cpu %" PRIu64
+
+# machine.c
+cpu_post_load_len(int cpreg_array_len, int cpreg_vmstate_array_len) "cpreg_array_len=%d cpreg_vmstate_array_len=%d"
+cpu_post_load(int i, int v, uint64_t regidx) "i=%d v=%d regidx=0x%"PRIx64
+cpu_post_load_missing(int i, uint64_t regidx, int v) "missing register in input stream: i=%d index=0x%"PRIx64" (v=%d)"
+cpu_post_load_unexpected(int v, uint64_t regidx, int i) "unexpected register in input stream: v=%d index=0x%"PRIx64" (i=%d)"
-- 
2.49.0

[RESEND PATCH 2/7] target/arm/kvm: Introduce the concept of hidden KVM regs

[Eric Auger]

More recent kernels sometimes expose new registers in an
unconditionnal manner. This situation breaks backward migration
as qemu notices there are more registers in the input stream
than supported on the destination host. This leads to a
"failed to load cpu:cpreg_vmstate_array_len" error.

A good example is the introduction of KVM_REG_ARM_VENDOR_HYP_BMAP_2
pseudo FW register in v6.16 by commit C0000e58c74e (“KVM: arm64:
Introduce KVM_REG_ARM_VENDOR_HYP_BMAP_2”). Trying to do backward
migration from a host kernel that features the commit to a destination
host that doesn't, fail with above error.

Currently QEMU is not using that feature so ignoring this latter
is not a problem. An easy way to fix the migration issue is to teach
qemu we don't care about that register and we can simply ignore it
when syncing its state during migration.

This patch introduces an array of such hidden registers. Soon it will
be settable through an array property.

If hidden, the register is moved out of the array of cpreg which is
built in kvm_arm_init_cpreg_list(). That way their state won't be
synced.

Signed-off-by: Eric Auger <eric.auger@redhat.com>

---

v1 -> v2:
- Move the property in a separate patch
- improve the commit msg
- change the trace point to just print info in
  kvm_arm_init_cpreg_list()
- improve comment in cpu.h (Connie)
---
 target/arm/cpu.h        | 11 +++++++++++
 target/arm/kvm.c        | 31 ++++++++++++++++++++++++++++++-
 target/arm/trace-events |  2 ++
 3 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index a7ed3f34f8..75cf7ee506 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1041,6 +1041,17 @@ struct ArchCPU {
     /* KVM steal time */
     OnOffAuto kvm_steal_time;
 
+    /*
+     * KVM registers that must be ignored/hidden. While they may be
+     * exposed by KVM to userspace, they are not intended to be used
+     * by qemu and more importantly we don't want them to be migrated
+     * to another host which wouldn't expose them. This would break
+     * the migration. This may be useful to allow backward migration to
+     * older kernels with less features.
+     */
+    uint64_t *kvm_hidden_regs;
+    uint32_t nr_kvm_hidden_regs;
+
     /* Uniprocessor system with MP extensions */
     bool mp_is_up;
 
diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index 58c6075a9e..60fb743423 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -754,6 +754,25 @@ static bool kvm_arm_reg_syncs_via_cpreg_list(uint64_t regidx)
     }
 }
 
+/**
+ * kvm_vcpu_compat_hidden_reg:
+ * @cpu: ARMCPU
+ * @regidx: index of the register to check
+ *
+ * Depending on the CPU compat returns true if @regidx must be
+ * ignored during sync & migration
+ */
+static inline bool
+kvm_vcpu_compat_hidden_reg(ARMCPU *cpu, uint64_t regidx)
+{
+    for (int i = 0; i < cpu->nr_kvm_hidden_regs; i++) {
+        if (cpu->kvm_hidden_regs[i] == regidx) {
+            return true;
+        }
+    }
+    return false;
+}
+
 /**
  * kvm_arm_init_cpreg_list:
  * @cpu: ARMCPU
@@ -788,7 +807,10 @@ static int kvm_arm_init_cpreg_list(ARMCPU *cpu)
     qsort(&rlp->reg, rlp->n, sizeof(rlp->reg[0]), compare_u64);
 
     for (i = 0, arraylen = 0; i < rlp->n; i++) {
-        if (!kvm_arm_reg_syncs_via_cpreg_list(rlp->reg[i])) {
+        uint64_t regidx = rlp->reg[i];
+
+        if (!kvm_arm_reg_syncs_via_cpreg_list(regidx) ||
+            kvm_vcpu_compat_hidden_reg(cpu, regidx)) {
             continue;
         }
         switch (rlp->reg[i] & KVM_REG_SIZE_MASK) {
@@ -804,6 +826,8 @@ static int kvm_arm_init_cpreg_list(ARMCPU *cpu)
         arraylen++;
     }
 
+    trace_kvm_arm_init_cpreg_list_arraylen(arraylen);
+
     cpu->cpreg_indexes = g_renew(uint64_t, cpu->cpreg_indexes, arraylen);
     cpu->cpreg_values = g_renew(uint64_t, cpu->cpreg_values, arraylen);
     cpu->cpreg_vmstate_indexes = g_renew(uint64_t, cpu->cpreg_vmstate_indexes,
@@ -815,9 +839,14 @@ static int kvm_arm_init_cpreg_list(ARMCPU *cpu)
 
     for (i = 0, arraylen = 0; i < rlp->n; i++) {
         uint64_t regidx = rlp->reg[i];
+
         if (!kvm_arm_reg_syncs_via_cpreg_list(regidx)) {
             continue;
         }
+        if (kvm_vcpu_compat_hidden_reg(cpu, regidx)) {
+            trace_kvm_arm_init_cpreg_list_skip_hidden_reg(rlp->reg[i]);
+            continue;
+        }
         cpu->cpreg_indexes[arraylen] = regidx;
         arraylen++;
     }
diff --git a/target/arm/trace-events b/target/arm/trace-events
index c497df8fe7..31386cc1f2 100644
--- a/target/arm/trace-events
+++ b/target/arm/trace-events
@@ -14,6 +14,8 @@ arm_gt_update_irq(int timer, int irqstate) "gt_update_irq: timer %d irqstate %d"
 # kvm.c
 kvm_arm_fixup_msi_route(uint64_t iova, uint64_t gpa) "MSI iova = 0x%"PRIx64" is translated into 0x%"PRIx64
 kvm_arm_cpu_post_load_missing_reg(char *name) "Missing register in input stream: %s"
+kvm_arm_init_cpreg_list_arraylen(uint32_t arraylen) "arraylen=%d"
+kvm_arm_init_cpreg_list_skip_hidden_reg(uint64_t regidx) "hidden 0x%"PRIx64" is skipped"
 
 # cpu.c
 arm_cpu_reset(uint64_t mp_aff) "cpu %" PRIu64
-- 
2.49.0

[RESEND PATCH 3/7] target/arm/kvm: Introduce the concept of enforced/fake registers

[Eric Auger]

Newer kernels may revoke exposure of KVM regs to userspace. This can
happen when one notices that some registers were unconditionnally
exposed whether they shall be conditionnally exposed for example.

An example of such situation is: TCR2_EL1, PIRE0_EL1,  PIR_EL1.
Associated kernel commits were:
0fcb4eea5345  KVM: arm64: Hide TCR2_EL1 from userspace when disabled for guests
a68cddbe47ef  KVM: arm64: Hide S1PIE registers from userspace when disabled for guests

Those commits were actual fixes but the cons is that is breaks forward
migration on some HW. Indeed when migrating from an old kernel that
does not feature those commits to a more recent one, destination
qemu detects there are more KVM regs in the input migration stream than
exposed by the destination host and the migration fails with:
"failed to load cpu:cpreg_vmstate_array_len"

This patchs adds the capability to defined an array of enforced
register indexes that teaches QEMU that some registers must exist.
If they are not exposed by KVM qemu fakes their presence in the
preload phase by adjusting the size of the cpreg_vmstate arrays.
On postload we make sure to ignore them when analyzing potential
mismatch between registers. The actual cpreg array is never altered
meaning those registers are never accessed nor saved.

The array will be populated with a deficated array property.

Signed-off-by: Eric Auger <eric.auger@redhat.com>

---

v1 -> v2:
- improve comment in target/arm/cpu.h (Connie)
---
 target/arm/cpu.h        | 23 +++++++++++++++++++++++
 target/arm/kvm.c        | 24 ++++++++++++++++++++++++
 target/arm/machine.c    | 31 ++++++++++++++++++++++---------
 target/arm/trace-events |  2 ++
 4 files changed, 71 insertions(+), 9 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 75cf7ee506..30d59a51d6 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1052,6 +1052,19 @@ struct ArchCPU {
     uint64_t *kvm_hidden_regs;
     uint32_t nr_kvm_hidden_regs;
 
+    /*
+     * KVM registers whose presence must be enforced
+     * Either they must be exposed to user space by KVM or
+     * they must be faked for migration sake because the source does
+     * feature them.
+     */
+    uint64_t *kvm_enforced_regs;
+    uint32_t nr_kvm_enforced_regs;
+
+    /* registers that must be be faked */
+    uint64_t *kvm_fake_regs;
+    uint32_t nr_kvm_fake_regs;
+
     /* Uniprocessor system with MP extensions */
     bool mp_is_up;
 
@@ -2652,6 +2665,16 @@ static inline uint64_t *aa64_vfp_qreg(CPUARMState *env, unsigned regno)
 /* Shared between translate-sve.c and sve_helper.c.  */
 extern const uint64_t pred_esz_masks[5];
 
+static inline bool is_fake_reg(ARMCPU *cpu, uint64_t regidx)
+{
+    for (int i = 0; i < cpu->nr_kvm_fake_regs; i++) {
+        if (regidx == cpu->kvm_fake_regs[i]) {
+            return true;
+        }
+    }
+    return false;
+}
+
 /*
  * AArch64 usage of the PAGE_TARGET_* bits for linux-user.
  * Note that with the Linux kernel, PROT_MTE may not be cleared by mprotect
diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index 60fb743423..7551c43e79 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -788,6 +788,7 @@ static int kvm_arm_init_cpreg_list(ARMCPU *cpu)
     struct kvm_reg_list rl;
     struct kvm_reg_list *rlp;
     int i, ret, arraylen;
+    int nr_fake_regs = 0;
     CPUState *cs = CPU(cpu);
 
     rl.n = 0;
@@ -801,6 +802,29 @@ static int kvm_arm_init_cpreg_list(ARMCPU *cpu)
     if (ret) {
         goto out;
     }
+
+    /*
+     * Identify which registers belonging to the enforced list
+     * need to be faked because they are not exposed to userspace
+     * by KVM
+     */
+    cpu->kvm_fake_regs = g_new(uint64_t, cpu->nr_kvm_enforced_regs);
+    for (int j = 0; j < cpu->nr_kvm_enforced_regs; j++) {
+        uint64_t v64;
+        int r;
+
+        r = kvm_get_one_reg(cs, cpu->kvm_enforced_regs[j], &v64);
+        if (errno != ENOENT) {
+            /* enforced register exists, no need to fake */
+            trace_kvm_arm_init_cpreg_exposed(cpu->kvm_enforced_regs[j], v64, r);
+            continue;
+        }
+        cpu->kvm_fake_regs[nr_fake_regs] = cpu->kvm_enforced_regs[j];
+        trace_kvm_arm_init_cpreg_fake(cpu->kvm_fake_regs[nr_fake_regs]);
+        nr_fake_regs++;
+    }
+    cpu->nr_kvm_fake_regs = nr_fake_regs;
+
     /* Sort the list we get back from the kernel, since cpreg_tuples
      * must be in strictly ascending order.
      */
diff --git a/target/arm/machine.c b/target/arm/machine.c
index b7a655b066..fcf2dd8315 100644
--- a/target/arm/machine.c
+++ b/target/arm/machine.c
@@ -990,7 +990,8 @@ static int cpu_pre_load(void *opaque)
 {
     ARMCPU *cpu = opaque;
     CPUARMState *env = &cpu->env;
-    int arraylen = cpu->cpreg_vmstate_array_len + MAX_CPREG_VMSTATE_ANOMALIES;
+    int arraylen = cpu->cpreg_vmstate_array_len +
+                   cpu->nr_kvm_fake_regs + MAX_CPREG_VMSTATE_ANOMALIES;
 
     cpu->cpreg_vmstate_indexes = g_renew(uint64_t, cpu->cpreg_vmstate_indexes,
                                          arraylen);
@@ -1057,6 +1058,10 @@ static int cpu_post_load(void *opaque, int version_id)
      * entries with the right slots in our own values array.
      */
 
+    /*
+     * at this point cpu->cpreg_vmstate_array_len was migrated with the
+     * actual length saved on source
+     */
     trace_cpu_post_load_len(cpu->cpreg_array_len, cpu->cpreg_vmstate_array_len);
     for (; i < cpu->cpreg_array_len && v < cpu->cpreg_vmstate_array_len;) {
         trace_cpu_post_load(i, v , cpu->cpreg_indexes[i]);
@@ -1071,10 +1076,14 @@ 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: those will fail migration */
-            trace_cpu_post_load_unexpected(v, cpu->cpreg_vmstate_indexes[v], i);
-            if (k < MAX_CPREG_VMSTATE_ANOMALIES) {
-                cpu->cpreg_vmstate_unexpected_indexes[k++] =
-                    cpu->cpreg_vmstate_indexes[v];
+            if (is_fake_reg(cpu, cpu->cpreg_vmstate_indexes[v])) {
+                /* this absence was expected as the reg was tagged as fake */
+            } else {
+                trace_cpu_post_load_unexpected(v, cpu->cpreg_vmstate_indexes[v], i);
+                if (k < MAX_CPREG_VMSTATE_ANOMALIES) {
+                    cpu->cpreg_vmstate_unexpected_indexes[k++] =
+                        cpu->cpreg_vmstate_indexes[v];
+                }
             }
             v++;
             continue;
@@ -1100,10 +1109,14 @@ static int cpu_post_load(void *opaque, int version_id)
      * still regs in the input stream, continue parsing the vmstate array
      */
     for ( ; v < cpu->cpreg_vmstate_array_len; v++) {
-        if (k < MAX_CPREG_VMSTATE_ANOMALIES) {
-            trace_cpu_post_load_unexpected(v, cpu->cpreg_vmstate_indexes[v], i);
-            cpu->cpreg_vmstate_unexpected_indexes[k++] =
-                cpu->cpreg_vmstate_indexes[v];
+        if (is_fake_reg(cpu, cpu->cpreg_vmstate_indexes[v])) {
+            /* this absence was expected as the reg was tagged as fake */
+        } else {
+            if (k < MAX_CPREG_VMSTATE_ANOMALIES) {
+                trace_cpu_post_load_unexpected(v, cpu->cpreg_vmstate_indexes[v], i);
+                cpu->cpreg_vmstate_unexpected_indexes[k++] =
+                    cpu->cpreg_vmstate_indexes[v];
+            }
         }
     }
 
diff --git a/target/arm/trace-events b/target/arm/trace-events
index 31386cc1f2..fa9d721339 100644
--- a/target/arm/trace-events
+++ b/target/arm/trace-events
@@ -16,6 +16,8 @@ kvm_arm_fixup_msi_route(uint64_t iova, uint64_t gpa) "MSI iova = 0x%"PRIx64" is
 kvm_arm_cpu_post_load_missing_reg(char *name) "Missing register in input stream: %s"
 kvm_arm_init_cpreg_list_arraylen(uint32_t arraylen) "arraylen=%d"
 kvm_arm_init_cpreg_list_skip_hidden_reg(uint64_t regidx) "hidden 0x%"PRIx64" is skipped"
+kvm_arm_init_cpreg_exposed(uint64_t regidx, uint64_t val, int ret) "enforced reg 0x%"PRIx64" is already exposed by KVM: value=0x%"PRIx64 " ret=%d: nothing to do"
+kvm_arm_init_cpreg_fake(uint64_t regidx) "register 0x%"PRIx64 " is not exposed and is faked"
 
 # cpu.c
 arm_cpu_reset(uint64_t mp_aff) "cpu %" PRIu64
-- 
2.49.0

[RESEND PATCH 4/7] kvm-all: Add the capability to blacklist some KVM regs

[Eric Auger]

On ARM we want to be able to blacklist registers that are exposed
by KVM. To mitigate some mitigation failures that occur when a new
register is exposed and does not exist on the destination, some
registers are tagged "hidden" and their state won't be saved. As the
state is not saved and they are expected not to be used, we want to
enforce they aren't. So let's check this. The new CPUClass hide_reg()
callback is optional and will be implemented on ARM in a subsequent
patch.

Signed-off-by: Eric Auger <eric.auger@redhat.com>
---
 include/hw/core/cpu.h |  2 ++
 accel/kvm/kvm-all.c   | 12 ++++++++++++
 2 files changed, 14 insertions(+)

diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
index e79e8e0a8e..8efd555f36 100644
--- a/include/hw/core/cpu.h
+++ b/include/hw/core/cpu.h
@@ -142,6 +142,7 @@ struct SysemuCPUOps;
  * the caller will not g_free() it.
  * @disas_set_info: Setup architecture specific components of disassembly info
  * @adjust_watchpoint_address: Perform a target-specific adjustment to an
+ * @hide_reg: Check if a register must be hidden (optional)
  * address before attempting to match it against watchpoints.
  * @deprecation_note: If this CPUClass is deprecated, this field provides
  *                    related information.
@@ -167,6 +168,7 @@ struct CPUClass {
     int (*gdb_read_register)(CPUState *cpu, GByteArray *buf, int reg);
     int (*gdb_write_register)(CPUState *cpu, uint8_t *buf, int reg);
     vaddr (*gdb_adjust_breakpoint)(CPUState *cpu, vaddr addr);
+    bool (*hide_reg)(CPUState *cpu, uint64_t regidex);
 
     const char *gdb_core_xml_file;
     const char * (*gdb_arch_name)(CPUState *cpu);
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 56031925c4..610f05fd0d 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -3783,9 +3783,15 @@ bool kvm_device_supported(int vmfd, uint64_t type)
 
 int kvm_set_one_reg(CPUState *cs, uint64_t id, void *source)
 {
+    CPUClass *cc = CPU_GET_CLASS(cs);
     struct kvm_one_reg reg;
     int r;
 
+    if (cc->hide_reg && cc->hide_reg(cs, id)) {
+        error_report("%s reg 0x%"PRIx64" is hidden and shall never been accessed",
+                     __func__, id);
+        g_assert_not_reached();
+    }
     reg.id = id;
     reg.addr = (uintptr_t) source;
     r = kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, &reg);
@@ -3797,9 +3803,15 @@ int kvm_set_one_reg(CPUState *cs, uint64_t id, void *source)
 
 int kvm_get_one_reg(CPUState *cs, uint64_t id, void *target)
 {
+    CPUClass *cc = CPU_GET_CLASS(cs);
     struct kvm_one_reg reg;
     int r;
 
+    if (cc->hide_reg && cc->hide_reg(cs, id)) {
+        error_report("%s reg 0x%"PRIx64" is hidden and shall never been accessed",
+                     __func__, id);
+        g_assert_not_reached();
+    }
     reg.id = id;
     reg.addr = (uintptr_t) target;
     r = kvm_vcpu_ioctl(cs, KVM_GET_ONE_REG, &reg);
-- 
2.49.0

[RESEND PATCH 5/7] target/arm/cpu: Implement hide_reg callback()

[Eric Auger]

Checks if the register is hidden.

Signed-off-by: Eric Auger <eric.auger@redhat.com>
---
 target/arm/cpu.h |  2 ++
 target/arm/cpu.c | 12 ++++++++++++
 target/arm/kvm.c | 23 ++---------------------
 3 files changed, 16 insertions(+), 21 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 30d59a51d6..3ae4d65422 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -2687,4 +2687,6 @@ static inline bool is_fake_reg(ARMCPU *cpu, uint64_t regidx)
 #define LOG2_TAG_GRANULE 4
 #define TAG_GRANULE      (1 << LOG2_TAG_GRANULE)
 
+bool arm_cpu_hide_reg(CPUState *s, uint64_t regidx);
+
 #endif
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 3b556f1404..60eee82742 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -2366,6 +2366,17 @@ static const TCGCPUOps arm_tcg_ops = {
 };
 #endif /* CONFIG_TCG */
 
+bool arm_cpu_hide_reg(CPUState *s, uint64_t regidx)
+{
+    ARMCPU *cpu = ARM_CPU(s);
+    for (int i = 0; i < cpu->nr_kvm_hidden_regs; i++) {
+        if (cpu->kvm_hidden_regs[i] == regidx) {
+            return true;
+        }
+    }
+    return false;
+}
+
 static void arm_cpu_class_init(ObjectClass *oc, const void *data)
 {
     ARMCPUClass *acc = ARM_CPU_CLASS(oc);
@@ -2394,6 +2405,7 @@ static void arm_cpu_class_init(ObjectClass *oc, const void *data)
     cc->gdb_get_core_xml_file = arm_gdb_get_core_xml_file;
     cc->gdb_stop_before_watchpoint = true;
     cc->disas_set_info = arm_disas_set_info;
+    cc->hide_reg = arm_cpu_hide_reg;
 
 #ifdef CONFIG_TCG
     cc->tcg_ops = &arm_tcg_ops;
diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index 7551c43e79..1a95e2c667 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -754,25 +754,6 @@ static bool kvm_arm_reg_syncs_via_cpreg_list(uint64_t regidx)
     }
 }
 
-/**
- * kvm_vcpu_compat_hidden_reg:
- * @cpu: ARMCPU
- * @regidx: index of the register to check
- *
- * Depending on the CPU compat returns true if @regidx must be
- * ignored during sync & migration
- */
-static inline bool
-kvm_vcpu_compat_hidden_reg(ARMCPU *cpu, uint64_t regidx)
-{
-    for (int i = 0; i < cpu->nr_kvm_hidden_regs; i++) {
-        if (cpu->kvm_hidden_regs[i] == regidx) {
-            return true;
-        }
-    }
-    return false;
-}
-
 /**
  * kvm_arm_init_cpreg_list:
  * @cpu: ARMCPU
@@ -834,7 +815,7 @@ static int kvm_arm_init_cpreg_list(ARMCPU *cpu)
         uint64_t regidx = rlp->reg[i];
 
         if (!kvm_arm_reg_syncs_via_cpreg_list(regidx) ||
-            kvm_vcpu_compat_hidden_reg(cpu, regidx)) {
+            arm_cpu_hide_reg(&cpu->parent_obj, regidx)) {
             continue;
         }
         switch (rlp->reg[i] & KVM_REG_SIZE_MASK) {
@@ -867,7 +848,7 @@ static int kvm_arm_init_cpreg_list(ARMCPU *cpu)
         if (!kvm_arm_reg_syncs_via_cpreg_list(regidx)) {
             continue;
         }
-        if (kvm_vcpu_compat_hidden_reg(cpu, regidx)) {
+        if (arm_cpu_hide_reg(&cpu->parent_obj, regidx)) {
             trace_kvm_arm_init_cpreg_list_skip_hidden_reg(rlp->reg[i]);
             continue;
         }
-- 
2.49.0

[RESEND PATCH 6/7] target/arm/kvm: Expose kvm-hidden-regs and kvm-fake-regs properties

[Eric Auger]

Allows to set the kvm-hidden-regs and kvm-fake-regs array properties.
This will allow to define such compat machine props like:

    static GlobalProperty arm_virt_kernel_compat_10_1[] = {
        /* KVM_REG_ARM_VENDOR_HYP_BMAP_2 */
        { TYPE_ARM_CPU, "kvm-hidden-regs", "0x6030000000160003" },
        { TYPE_ARM_CPU, "kvm-enforced-regs",
          /* TCR_EL1, PIRE0_EL1, PIR_EL1 */
          "0x603000000013c103, 0x603000000013c512, 0x603000000013c513" },
    }

Signed-off-by: Eric Auger <eric.auger@redhat.com>
---
 target/arm/kvm.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index 1a95e2c667..d103d4293d 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -39,6 +39,8 @@
 #include "qemu/log.h"
 #include "hw/acpi/acpi.h"
 #include "hw/acpi/ghes.h"
+#include "hw/qdev-properties.h"
+#include "hw/qdev-properties-system.h"
 #include "target/arm/gtimer.h"
 #include "migration/blocker.h"
 
@@ -484,6 +486,15 @@ static void kvm_steal_time_set(Object *obj, bool value, Error **errp)
     ARM_CPU(obj)->kvm_steal_time = value ? ON_OFF_AUTO_ON : ON_OFF_AUTO_OFF;
 }
 
+static const Property arm_cpu_kvm_compat_hidden_regs_property =
+    DEFINE_PROP_ARRAY("kvm-hidden-regs", ARMCPU,
+                      nr_kvm_hidden_regs, kvm_hidden_regs, qdev_prop_uint64, uint64_t);
+
+static const Property arm_cpu_kvm_compat_enforced_regs_property =
+    DEFINE_PROP_ARRAY("kvm-enforced-regs", ARMCPU,
+                      nr_kvm_enforced_regs, kvm_enforced_regs,
+                      qdev_prop_uint64, uint64_t);
+
 /* KVM VCPU properties should be prefixed with "kvm-". */
 void kvm_arm_add_vcpu_properties(ARMCPU *cpu)
 {
@@ -505,6 +516,9 @@ void kvm_arm_add_vcpu_properties(ARMCPU *cpu)
                              kvm_steal_time_set);
     object_property_set_description(obj, "kvm-steal-time",
                                     "Set off to disable KVM steal time.");
+
+    qdev_property_add_static(DEVICE(obj), &arm_cpu_kvm_compat_hidden_regs_property);
+    qdev_property_add_static(DEVICE(obj), &arm_cpu_kvm_compat_enforced_regs_property);
 }
 
 bool kvm_arm_pmu_supported(void)
-- 
2.49.0

[RESEND PATCH 7/7] hw/arm/virt: [DO NOT UPSTREAM] Enforce compatibility with older kernels

[Eric Auger]

This is an example on how to use the new CPU options. This catters to
distributions who want machines to be migratable (forward and backward)
accross different host kernel versions in case KVM registers exposed
to qemu vary accross kernels. This patch is not meant to be upstreamed
as it is really kernel dependent. The goal is to illustrate how this
would be used.

In this example, For 10_1 machines types and older we apply the following
host kernel related compats:

1) Make sure the KVM_REG_ARM_VENDOR_HYP_BMAP_2 exposed from v6.15 onwards
   is ignored/hidden.
2) Make sure TCR_EL1, PIRE0_EL1, PIR_EL1 are always seen by qemu
   although not exposed by KVM. They were unconditionnally exposed before
   v6.13 while from v6.13 they are only exposed if supported by the guest.

This will allow 10_1 machines types and older machines to migrate
forward and backward from old downstream kernels that do not feature
those changes to newer kernels (>= v6.15).

Signed-off-by: Eric Auger <eric.auger@redhat.com>
---
 hw/arm/virt.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 175023897a..c4f9b82c38 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -97,6 +97,23 @@ static GlobalProperty arm_virt_compat[] = {
 };
 static const size_t arm_virt_compat_len = G_N_ELEMENTS(arm_virt_compat);
 
+/*
+ * if a 10_1 machine type or older is used:
+ * 1) make sure TCR_EL1, PIRE0_EL1, PIR_EL1 are enforced, even if they are not
+ *    exposed by the kernel
+ * 2) hide KVM_REG_ARM_VENDOR_HYP_BMAP_2
+ */
+static GlobalProperty arm_virt_kernel_compat_10_1[] = {
+    /* KVM_REG_ARM_VENDOR_HYP_BMAP_2 */
+    { TYPE_ARM_CPU, "kvm-hidden-regs", "0x6030000000160003" },
+    /* TCR_EL1, PIRE0_EL1, PIR_EL1 */
+    { TYPE_ARM_CPU, "kvm-enforced-regs",
+      "0x603000000013c103, 0x603000000013c512, 0x603000000013c513" },
+};
+static const size_t arm_virt_kernel_compat_10_1_len =
+    G_N_ELEMENTS(arm_virt_kernel_compat_10_1);
+
+
 /*
  * This cannot be called from the virt_machine_class_init() because
  * TYPE_VIRT_MACHINE is abstract and mc->compat_props g_ptr_array_new()
@@ -3539,6 +3556,8 @@ static void virt_machine_10_1_options(MachineClass *mc)
     virt_machine_10_2_options(mc);
     mc->smbios_memory_device_size = 2047 * TiB;
     compat_props_add(mc->compat_props, hw_compat_10_1, hw_compat_10_1_len);
+    compat_props_add(mc->compat_props,
+                     arm_virt_kernel_compat_10_1, arm_virt_kernel_compat_10_1_len);
 }
 DEFINE_VIRT_MACHINE(10, 1)
 
-- 
2.49.0

Re: [RESEND PATCH 1/7] target/arm/machine: Improve traces on register mismatch during migration

[Cornelia Huck]

On Thu, Oct 16 2025, Eric Auger <eric.auger@redhat.com> wrote:

More information is really valuable here. I have some nits :)

> Currently whenthe number of KVM registers exposed by the source is

s/whenthe/when the/

> larger than the one exposed on the destination, the migration fails
> with: "failed to load cpu:cpreg_vmstate_array_len"
>
> This gives no information about which registers are causing the trouble.
>
> This patches rework the target/arm/machine code so that it becomes

s/patches rework/patch reworks/

> able to handle an input stream with a larger set of registers than
> the destination and print useful information about which registers
> are causing the trouble. The migration outcome is unchanged:
> - unexpected registers still will fail the migration
> - missing ones are print but will not fail the migration, as done today.

s/print/printed/

>
> The input stream can contain MAX_CPREG_VMSTATE_ANOMALIES(10) extra
> registers compared to what exists on the target.
>
> If there are more registers we will still hit the previous
> "load cpu:cpreg_vmstate_array_len" error.
>
> At most, MAX_CPREG_VMSTATE_ANOMALIES missing registers
> and MAX_CPREG_VMSTATE_ANOMALIES unexpected registers are print.

s/print/printed/

If we really get tons of register discrepancies, I'd expect the reason for
that to be something more obvious, so limiting should be fine.

>
> Example:
>
> qemu-system-aarch64: kvm_arm_cpu_post_load Missing register in input stream: 0 0x6030000000160003 fw feat reg 3
> qemu-system-aarch64: kvm_arm_cpu_post_load Unexpected register in input stream: 0 0x603000000013c103 op0:3 op1:0 crn:2 crm:0 op2:3
> qemu-system-aarch64: kvm_arm_cpu_post_load Unexpected register in input stream: 1 0x603000000013c512 op0:3 op1:0 crn:10 crm:2 op2:2
> qemu-system-aarch64: kvm_arm_cpu_post_load Unexpected register in input stream: 2 0x603000000013c513 op0:3 op1:0 crn:10 crm:2 op2:3
> qemu-system-aarch64: error while loading state for instance 0x0 of device 'cpu'
> qemu-system-aarch64: load of migration failed: Operation not permitted
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> ---
>  target/arm/cpu.h        |  6 +++++
>  target/arm/kvm.c        | 23 ++++++++++++++++
>  target/arm/machine.c    | 58 ++++++++++++++++++++++++++++++++++++-----
>  target/arm/trace-events |  7 +++++
>  4 files changed, 88 insertions(+), 6 deletions(-)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index bf221e6f97..a7ed3f34f8 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -936,6 +936,12 @@ struct ArchCPU {
>      uint64_t *cpreg_vmstate_values;
>      int32_t cpreg_vmstate_array_len;
>  
> +    #define MAX_CPREG_VMSTATE_ANOMALIES 10
> +    uint64_t cpreg_vmstate_missing_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
> +    int32_t cpreg_vmstate_missing_indexes_array_len;
> +    uint64_t cpreg_vmstate_unexpected_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
> +    int32_t cpreg_vmstate_unexpected_indexes_array_len;

"indices"?

> +
>      DynamicGDBFeatureInfo dyn_sysreg_feature;
>      DynamicGDBFeatureInfo dyn_svereg_feature;
>      DynamicGDBFeatureInfo dyn_smereg_feature;

(...)

Re: [RESEND PATCH 1/7] target/arm/machine: Improve traces on register mismatch during migration

[Eric Auger]

Hi Connie,

On 10/17/25 4:59 PM, Cornelia Huck wrote:
> On Thu, Oct 16 2025, Eric Auger <eric.auger@redhat.com> wrote:
>
> More information is really valuable here. I have some nits :)
>
>> Currently whenthe number of KVM registers exposed by the source is
> s/whenthe/when the/
>
>> larger than the one exposed on the destination, the migration fails
>> with: "failed to load cpu:cpreg_vmstate_array_len"
>>
>> This gives no information about which registers are causing the trouble.
>>
>> This patches rework the target/arm/machine code so that it becomes
> s/patches rework/patch reworks/
>
>> able to handle an input stream with a larger set of registers than
>> the destination and print useful information about which registers
>> are causing the trouble. The migration outcome is unchanged:
>> - unexpected registers still will fail the migration
>> - missing ones are print but will not fail the migration, as done today.
> s/print/printed/
>
>> The input stream can contain MAX_CPREG_VMSTATE_ANOMALIES(10) extra
>> registers compared to what exists on the target.
>>
>> If there are more registers we will still hit the previous
>> "load cpu:cpreg_vmstate_array_len" error.
>>
>> At most, MAX_CPREG_VMSTATE_ANOMALIES missing registers
>> and MAX_CPREG_VMSTATE_ANOMALIES unexpected registers are print.
> s/print/printed/
>
> If we really get tons of register discrepancies, I'd expect the reason for
> that to be something more obvious, so limiting should be fine.
>
>> Example:
>>
>> qemu-system-aarch64: kvm_arm_cpu_post_load Missing register in input stream: 0 0x6030000000160003 fw feat reg 3
>> qemu-system-aarch64: kvm_arm_cpu_post_load Unexpected register in input stream: 0 0x603000000013c103 op0:3 op1:0 crn:2 crm:0 op2:3
>> qemu-system-aarch64: kvm_arm_cpu_post_load Unexpected register in input stream: 1 0x603000000013c512 op0:3 op1:0 crn:10 crm:2 op2:2
>> qemu-system-aarch64: kvm_arm_cpu_post_load Unexpected register in input stream: 2 0x603000000013c513 op0:3 op1:0 crn:10 crm:2 op2:3
>> qemu-system-aarch64: error while loading state for instance 0x0 of device 'cpu'
>> qemu-system-aarch64: load of migration failed: Operation not permitted
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>> ---
>>  target/arm/cpu.h        |  6 +++++
>>  target/arm/kvm.c        | 23 ++++++++++++++++
>>  target/arm/machine.c    | 58 ++++++++++++++++++++++++++++++++++++-----
>>  target/arm/trace-events |  7 +++++
>>  4 files changed, 88 insertions(+), 6 deletions(-)
>>
>> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
>> index bf221e6f97..a7ed3f34f8 100644
>> --- a/target/arm/cpu.h
>> +++ b/target/arm/cpu.h
>> @@ -936,6 +936,12 @@ struct ArchCPU {
>>      uint64_t *cpreg_vmstate_values;
>>      int32_t cpreg_vmstate_array_len;
>>  
>> +    #define MAX_CPREG_VMSTATE_ANOMALIES 10
>> +    uint64_t cpreg_vmstate_missing_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
>> +    int32_t cpreg_vmstate_missing_indexes_array_len;
>> +    uint64_t cpreg_vmstate_unexpected_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
>> +    int32_t cpreg_vmstate_unexpected_indexes_array_len;
> "indices"?

Thanks, all those will be fixed in next version.

Thanks

Eric
>
>> +
>>      DynamicGDBFeatureInfo dyn_sysreg_feature;
>>      DynamicGDBFeatureInfo dyn_svereg_feature;
>>      DynamicGDBFeatureInfo dyn_smereg_feature;
> (...)
>

Re: [RESEND PATCH 0/7] Mitigation of "failed to load cpu:cpreg_vmstate_array_len" migration failures

[Eric Auger]

On 10/16/25 3:59 PM, Eric Auger wrote:
> When migrating ARM guests accross same machines with different host
> kernels we are likely to encounter failures such as:
>
> "failed to load cpu:cpreg_vmstate_array_len"
>
> This is due to the fact KVM exposes a different number of registers
> to qemu on source and destination. When trying to migrate a bigger
> register set to a smaller one, qemu cannot save the CPU state.
>
> For example, recently we faced such kind of situations with:
> - unconditionnal exposure of KVM_REG_ARM_VENDOR_HYP_BMAP_2 FW pseudo
>   register from v6.16 onwards. Causes backward migration failure.
> - removal of unconditionnal exposure of TCR2_EL1, PIRE0_EL1, PIR_EL1
>   from v6.13 onwards. Causes forward migration failure.
>
> This situation is really problematic for distributions which want to
> guarantee forward and backward migration of a given machine type
> between different releases.
>
> This small series tries to address that issue by introducing CPU
> array properties that list the registers to ignore or to fake according
> to the situation. An example is given to illustrate how those props
> could be used to apply compats for machine types supposed to "see" the
> same register set accross various host kernels.
>
> The first patch improves the tracing so that we can quickly detect
> which registers are unexpected and cause the migration failure. Missing
> registers are also traced. Those do not fail migration but their default
> value is kept on the destination.
>
> Then we introduce the infrastructure to handle 'hidden' registers and
> 'fake' registers.
>
> Eric Auger (7):
>   target/arm/machine: Improve traces on register mismatch during
>     migration
>   target/arm/kvm: Introduce the concept of hidden KVM regs
>   target/arm/kvm: Introduce the concept of enforced/fake registers
>   kvm-all: Add the capability to blacklist some KVM regs
>   target/arm/cpu: Implement hide_reg callback()
>   target/arm/kvm: Expose kvm-hidden-regs and kvm-fake-regs properties
>   hw/arm/virt: [DO NOT UPSTREAM] Enforce compatibility with older
>     kernels

Gentle ping.

Any comments on the approach?

Thanks

Eric
>
>  include/hw/core/cpu.h   |  2 ++
>  target/arm/cpu.h        | 42 ++++++++++++++++++++++++
>  accel/kvm/kvm-all.c     | 12 +++++++
>  hw/arm/virt.c           | 19 +++++++++++
>  target/arm/cpu.c        | 12 +++++++
>  target/arm/kvm.c        | 73 ++++++++++++++++++++++++++++++++++++++++-
>  target/arm/machine.c    | 71 +++++++++++++++++++++++++++++++++++----
>  target/arm/trace-events | 11 +++++++
>  8 files changed, 235 insertions(+), 7 deletions(-)
>

Re: [RESEND PATCH 3/7] target/arm/kvm: Introduce the concept of enforced/fake registers

[Peter Maydell]

On Thu, 16 Oct 2025 at 15:01, Eric Auger <eric.auger@redhat.com> wrote:
>
> Newer kernels may revoke exposure of KVM regs to userspace. This can
> happen when one notices that some registers were unconditionnally
> exposed whether they shall be conditionnally exposed for example.
>
> An example of such situation is: TCR2_EL1, PIRE0_EL1,  PIR_EL1.
> Associated kernel commits were:
> 0fcb4eea5345  KVM: arm64: Hide TCR2_EL1 from userspace when disabled for guests
> a68cddbe47ef  KVM: arm64: Hide S1PIE registers from userspace when disabled for guests
>
> Those commits were actual fixes but the cons is that is breaks forward
> migration on some HW. Indeed when migrating from an old kernel that
> does not feature those commits to a more recent one, destination
> qemu detects there are more KVM regs in the input migration stream than
> exposed by the destination host and the migration fails with:
> "failed to load cpu:cpreg_vmstate_array_len"
>
> This patchs adds the capability to defined an array of enforced
> register indexes that teaches QEMU that some registers must exist.
> If they are not exposed by KVM qemu fakes their presence in the
> preload phase by adjusting the size of the cpreg_vmstate arrays.
> On postload we make sure to ignore them when analyzing potential
> mismatch between registers. The actual cpreg array is never altered
> meaning those registers are never accessed nor saved.

It's not really clear to me what we mean by "faking" these
registers. It's definitely not the case that we want QEMU
to think these registers must exist -- they really don't,
and for migration from a new kernel to a new kernel we
shouldn't include these registers. We just would like to be
able to ignore them in the input migration stream so we can
handle the inbound migration from an older kernel.

thanks
-- PMM

Re: [RESEND PATCH 7/7] hw/arm/virt: [DO NOT UPSTREAM] Enforce compatibility with older kernels

[Peter Maydell]

On Thu, 16 Oct 2025 at 15:01, Eric Auger <eric.auger@redhat.com> wrote:
>
> This is an example on how to use the new CPU options. This catters to
> distributions who want machines to be migratable (forward and backward)
> accross different host kernel versions in case KVM registers exposed
> to qemu vary accross kernels. This patch is not meant to be upstreamed
> as it is really kernel dependent. The goal is to illustrate how this
> would be used.
>
> In this example, For 10_1 machines types and older we apply the following
> host kernel related compats:
>
> 1) Make sure the KVM_REG_ARM_VENDOR_HYP_BMAP_2 exposed from v6.15 onwards
>    is ignored/hidden.
> 2) Make sure TCR_EL1, PIRE0_EL1, PIR_EL1 are always seen by qemu
>    although not exposed by KVM. They were unconditionnally exposed before
>    v6.13 while from v6.13 they are only exposed if supported by the guest.
>
> This will allow 10_1 machines types and older machines to migrate
> forward and backward from old downstream kernels that do not feature
> those changes to newer kernels (>= v6.15).
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> ---
>  hw/arm/virt.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 175023897a..c4f9b82c38 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -97,6 +97,23 @@ static GlobalProperty arm_virt_compat[] = {
>  };
>  static const size_t arm_virt_compat_len = G_N_ELEMENTS(arm_virt_compat);
>
> +/*
> + * if a 10_1 machine type or older is used:
> + * 1) make sure TCR_EL1, PIRE0_EL1, PIR_EL1 are enforced, even if they are not
> + *    exposed by the kernel
> + * 2) hide KVM_REG_ARM_VENDOR_HYP_BMAP_2
> + */
> +static GlobalProperty arm_virt_kernel_compat_10_1[] = {
> +    /* KVM_REG_ARM_VENDOR_HYP_BMAP_2 */
> +    { TYPE_ARM_CPU, "kvm-hidden-regs", "0x6030000000160003" },
> +    /* TCR_EL1, PIRE0_EL1, PIR_EL1 */
> +    { TYPE_ARM_CPU, "kvm-enforced-regs",
> +      "0x603000000013c103, 0x603000000013c512, 0x603000000013c513" },

Strings which are lists of long hex numbers? Is there a
more readable way to do this?

-- PMM

Re: [RESEND PATCH 0/7] Mitigation of "failed to load cpu:cpreg_vmstate_array_len" migration failures

[Peter Maydell]

On Tue, 28 Oct 2025 at 10:05, Eric Auger <eric.auger@redhat.com> wrote:
>
>
>
> On 10/16/25 3:59 PM, Eric Auger wrote:
> > When migrating ARM guests accross same machines with different host
> > kernels we are likely to encounter failures such as:
> >
> > "failed to load cpu:cpreg_vmstate_array_len"
> >
> > This is due to the fact KVM exposes a different number of registers
> > to qemu on source and destination. When trying to migrate a bigger
> > register set to a smaller one, qemu cannot save the CPU state.
> >
> > For example, recently we faced such kind of situations with:
> > - unconditionnal exposure of KVM_REG_ARM_VENDOR_HYP_BMAP_2 FW pseudo
> >   register from v6.16 onwards. Causes backward migration failure.
> > - removal of unconditionnal exposure of TCR2_EL1, PIRE0_EL1, PIR_EL1
> >   from v6.13 onwards. Causes forward migration failure.

> Gentle ping.
>
> Any comments on the approach?

A couple of general remarks:

(1) This isn't KVM specific -- see e.g. commit 4f2b82f60
where we had to add back a fake cpreg to un-break forward
migration of TCG CPUs. So our handling of this kind of problem
shouldn't be restricted to only working with KVM.

(2) essentially we're re-inventing the migration compat
support that VMStateDescriptions provide. That's kind of
unavoidable because of the way I implemented cpreg migration
years ago, but is there anything we can learn in terms of
(a) required feature set and (b) trying to keep parallels
between the two for the way things work ?

thanks
-- PMM

Re: [RESEND PATCH 3/7] target/arm/kvm: Introduce the concept of enforced/fake registers

[Eric Auger]

Hi Peter,
On 10/28/25 11:35 AM, Peter Maydell wrote:
> On Thu, 16 Oct 2025 at 15:01, Eric Auger <eric.auger@redhat.com> wrote:
>> Newer kernels may revoke exposure of KVM regs to userspace. This can
>> happen when one notices that some registers were unconditionnally
>> exposed whether they shall be conditionnally exposed for example.
>>
>> An example of such situation is: TCR2_EL1, PIRE0_EL1,  PIR_EL1.
>> Associated kernel commits were:
>> 0fcb4eea5345  KVM: arm64: Hide TCR2_EL1 from userspace when disabled for guests
>> a68cddbe47ef  KVM: arm64: Hide S1PIE registers from userspace when disabled for guests
>>
>> Those commits were actual fixes but the cons is that is breaks forward
>> migration on some HW. Indeed when migrating from an old kernel that
>> does not feature those commits to a more recent one, destination
>> qemu detects there are more KVM regs in the input migration stream than
>> exposed by the destination host and the migration fails with:
>> "failed to load cpu:cpreg_vmstate_array_len"
>>
>> This patchs adds the capability to defined an array of enforced
>> register indexes that teaches QEMU that some registers must exist.
>> If they are not exposed by KVM qemu fakes their presence in the
>> preload phase by adjusting the size of the cpreg_vmstate arrays.
>> On postload we make sure to ignore them when analyzing potential
>> mismatch between registers. The actual cpreg array is never altered
>> meaning those registers are never accessed nor saved.
> It's not really clear to me what we mean by "faking" these
> registers. It's definitely not the case that we want QEMU
> to think these registers must exist -- they really don't,
> and for migration from a new kernel to a new kernel we
> shouldn't include these registers. We just would like to be
> able to ignore them in the input migration stream so we can
> handle the inbound migration from an older kernel.

yes maybe I should use a different terminology. Those registers are
"faked" from a migration pov only.

among the provided enforced regs, we first identify those which are not
actually exposed by KVM. For those only, which I named "fake regs", we
tag them as "they will be missing in the input mig stream but that's
expected and OK". We make sure we provision extra space for them in
cpu->cpreg_vmstate_indexes/values on preload. And in post load when we
compare the input stream indices with available inidices, if they are
identified as missing, we just ignore the error. That's it.

Hope this helps

Eric
>
> thanks
> -- PMM
>

Re: [RESEND PATCH 7/7] hw/arm/virt: [DO NOT UPSTREAM] Enforce compatibility with older kernels

[Eric Auger]

Hi Peter,

On 10/28/25 11:37 AM, Peter Maydell wrote:
> On Thu, 16 Oct 2025 at 15:01, Eric Auger <eric.auger@redhat.com> wrote:
>> This is an example on how to use the new CPU options. This catters to
>> distributions who want machines to be migratable (forward and backward)
>> accross different host kernel versions in case KVM registers exposed
>> to qemu vary accross kernels. This patch is not meant to be upstreamed
>> as it is really kernel dependent. The goal is to illustrate how this
>> would be used.
>>
>> In this example, For 10_1 machines types and older we apply the following
>> host kernel related compats:
>>
>> 1) Make sure the KVM_REG_ARM_VENDOR_HYP_BMAP_2 exposed from v6.15 onwards
>>    is ignored/hidden.
>> 2) Make sure TCR_EL1, PIRE0_EL1, PIR_EL1 are always seen by qemu
>>    although not exposed by KVM. They were unconditionnally exposed before
>>    v6.13 while from v6.13 they are only exposed if supported by the guest.
>>
>> This will allow 10_1 machines types and older machines to migrate
>> forward and backward from old downstream kernels that do not feature
>> those changes to newer kernels (>= v6.15).
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>> ---
>>  hw/arm/virt.c | 19 +++++++++++++++++++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index 175023897a..c4f9b82c38 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -97,6 +97,23 @@ static GlobalProperty arm_virt_compat[] = {
>>  };
>>  static const size_t arm_virt_compat_len = G_N_ELEMENTS(arm_virt_compat);
>>
>> +/*
>> + * if a 10_1 machine type or older is used:
>> + * 1) make sure TCR_EL1, PIRE0_EL1, PIR_EL1 are enforced, even if they are not
>> + *    exposed by the kernel
>> + * 2) hide KVM_REG_ARM_VENDOR_HYP_BMAP_2
>> + */
>> +static GlobalProperty arm_virt_kernel_compat_10_1[] = {
>> +    /* KVM_REG_ARM_VENDOR_HYP_BMAP_2 */
>> +    { TYPE_ARM_CPU, "kvm-hidden-regs", "0x6030000000160003" },
>> +    /* TCR_EL1, PIRE0_EL1, PIR_EL1 */
>> +    { TYPE_ARM_CPU, "kvm-enforced-regs",
>> +      "0x603000000013c103, 0x603000000013c512, 0x603000000013c513" },
> Strings which are lists of long hex numbers? Is there a
> more readable way to do this?
for sysregs, we could use the reg name string directly once we have
script generated list of regs from json description. However for some
regs it won't be possible, like pseudo FW regs.
As those props are really supposed to be used by very informed users
(distro staff) who need to know the kvm indices, I thought it could be
acceptable. Maybe we can rely on defines to make it more readable.

Thanks

Eric
>
> -- PMM
>

Re: [RESEND PATCH 7/7] hw/arm/virt: [DO NOT UPSTREAM] Enforce compatibility with older kernels

[Eric Auger]

On 10/28/25 11:37 AM, Peter Maydell wrote:
> On Thu, 16 Oct 2025 at 15:01, Eric Auger <eric.auger@redhat.com> wrote:
>> This is an example on how to use the new CPU options. This catters to
>> distributions who want machines to be migratable (forward and backward)
>> accross different host kernel versions in case KVM registers exposed
>> to qemu vary accross kernels. This patch is not meant to be upstreamed
>> as it is really kernel dependent. The goal is to illustrate how this
>> would be used.
>>
>> In this example, For 10_1 machines types and older we apply the following
>> host kernel related compats:
>>
>> 1) Make sure the KVM_REG_ARM_VENDOR_HYP_BMAP_2 exposed from v6.15 onwards
>>    is ignored/hidden.
>> 2) Make sure TCR_EL1, PIRE0_EL1, PIR_EL1 are always seen by qemu
>>    although not exposed by KVM. They were unconditionnally exposed before
>>    v6.13 while from v6.13 they are only exposed if supported by the guest.
>>
>> This will allow 10_1 machines types and older machines to migrate
>> forward and backward from old downstream kernels that do not feature
>> those changes to newer kernels (>= v6.15).
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>> ---
>>  hw/arm/virt.c | 19 +++++++++++++++++++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index 175023897a..c4f9b82c38 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -97,6 +97,23 @@ static GlobalProperty arm_virt_compat[] = {
>>  };
>>  static const size_t arm_virt_compat_len = G_N_ELEMENTS(arm_virt_compat);
>>
>> +/*
>> + * if a 10_1 machine type or older is used:
>> + * 1) make sure TCR_EL1, PIRE0_EL1, PIR_EL1 are enforced, even if they are not
>> + *    exposed by the kernel
>> + * 2) hide KVM_REG_ARM_VENDOR_HYP_BMAP_2
>> + */
>> +static GlobalProperty arm_virt_kernel_compat_10_1[] = {
>> +    /* KVM_REG_ARM_VENDOR_HYP_BMAP_2 */
>> +    { TYPE_ARM_CPU, "kvm-hidden-regs", "0x6030000000160003" },
>> +    /* TCR_EL1, PIRE0_EL1, PIR_EL1 */
>> +    { TYPE_ARM_CPU, "kvm-enforced-regs",
>> +      "0x603000000013c103, 0x603000000013c512, 0x603000000013c513" },
> Strings which are lists of long hex numbers? Is there a
> more readable way to do this?

forgot to mention that we could use x- prefix for those properties to
enphasize they are rather experimental and not meant to be used commonly.

Eric
>
> -- PMM
>

Re: [RESEND PATCH 0/7] Mitigation of "failed to load cpu:cpreg_vmstate_array_len" migration failures

[Eric Auger]

Hi Peter,

On 10/28/25 11:47 AM, Peter Maydell wrote:
> On Tue, 28 Oct 2025 at 10:05, Eric Auger <eric.auger@redhat.com> wrote:
>>
>>
>> On 10/16/25 3:59 PM, Eric Auger wrote:
>>> When migrating ARM guests accross same machines with different host
>>> kernels we are likely to encounter failures such as:
>>>
>>> "failed to load cpu:cpreg_vmstate_array_len"
>>>
>>> This is due to the fact KVM exposes a different number of registers
>>> to qemu on source and destination. When trying to migrate a bigger
>>> register set to a smaller one, qemu cannot save the CPU state.
>>>
>>> For example, recently we faced such kind of situations with:
>>> - unconditionnal exposure of KVM_REG_ARM_VENDOR_HYP_BMAP_2 FW pseudo
>>>   register from v6.16 onwards. Causes backward migration failure.
>>> - removal of unconditionnal exposure of TCR2_EL1, PIRE0_EL1, PIR_EL1
>>>   from v6.13 onwards. Causes forward migration failure.
>> Gentle ping.
>>
>> Any comments on the approach?
> A couple of general remarks:
>
> (1) This isn't KVM specific -- see e.g. commit 4f2b82f60
> where we had to add back a fake cpreg to un-break forward
> migration of TCG CPUs. So our handling of this kind of problem
> shouldn't be restricted to only working with KVM.

interesting. I will see how this can be extended to TCG
>
> (2) essentially we're re-inventing the migration compat
> support that VMStateDescriptions provide. That's kind of
> unavoidable because of the way I implemented cpreg migration
> years ago, but is there anything we can learn in terms of
> (a) required feature set and (b) trying to keep parallels
> between the two for the way things work ?

OK I will study that further.

Thank you for your suggestions!

Eric
>
> thanks
> -- PMM
>

Re: [RESEND PATCH 1/7] target/arm/machine: Improve traces on register mismatch during migration

[Eric Auger]

On 10/17/25 4:59 PM, Cornelia Huck wrote:
> On Thu, Oct 16 2025, Eric Auger <eric.auger@redhat.com> wrote:
>
> More information is really valuable here. I have some nits :)
>
>> Currently whenthe number of KVM registers exposed by the source is
> s/whenthe/when the/
>
>> larger than the one exposed on the destination, the migration fails
>> with: "failed to load cpu:cpreg_vmstate_array_len"
>>
>> This gives no information about which registers are causing the trouble.
>>
>> This patches rework the target/arm/machine code so that it becomes
> s/patches rework/patch reworks/
>
>> able to handle an input stream with a larger set of registers than
>> the destination and print useful information about which registers
>> are causing the trouble. The migration outcome is unchanged:
>> - unexpected registers still will fail the migration
>> - missing ones are print but will not fail the migration, as done today.
> s/print/printed/
>
>> The input stream can contain MAX_CPREG_VMSTATE_ANOMALIES(10) extra
>> registers compared to what exists on the target.
>>
>> If there are more registers we will still hit the previous
>> "load cpu:cpreg_vmstate_array_len" error.
>>
>> At most, MAX_CPREG_VMSTATE_ANOMALIES missing registers
>> and MAX_CPREG_VMSTATE_ANOMALIES unexpected registers are print.
> s/print/printed/
>
> If we really get tons of register discrepancies, I'd expect the reason for
> that to be something more obvious, so limiting should be fine.
>
>> Example:
>>
>> qemu-system-aarch64: kvm_arm_cpu_post_load Missing register in input stream: 0 0x6030000000160003 fw feat reg 3
>> qemu-system-aarch64: kvm_arm_cpu_post_load Unexpected register in input stream: 0 0x603000000013c103 op0:3 op1:0 crn:2 crm:0 op2:3
>> qemu-system-aarch64: kvm_arm_cpu_post_load Unexpected register in input stream: 1 0x603000000013c512 op0:3 op1:0 crn:10 crm:2 op2:2
>> qemu-system-aarch64: kvm_arm_cpu_post_load Unexpected register in input stream: 2 0x603000000013c513 op0:3 op1:0 crn:10 crm:2 op2:3
>> qemu-system-aarch64: error while loading state for instance 0x0 of device 'cpu'
>> qemu-system-aarch64: load of migration failed: Operation not permitted
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>> ---
>>  target/arm/cpu.h        |  6 +++++
>>  target/arm/kvm.c        | 23 ++++++++++++++++
>>  target/arm/machine.c    | 58 ++++++++++++++++++++++++++++++++++++-----
>>  target/arm/trace-events |  7 +++++
>>  4 files changed, 88 insertions(+), 6 deletions(-)
>>
>> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
>> index bf221e6f97..a7ed3f34f8 100644
>> --- a/target/arm/cpu.h
>> +++ b/target/arm/cpu.h
>> @@ -936,6 +936,12 @@ struct ArchCPU {
>>      uint64_t *cpreg_vmstate_values;
>>      int32_t cpreg_vmstate_array_len;
>>  
>> +    #define MAX_CPREG_VMSTATE_ANOMALIES 10
>> +    uint64_t cpreg_vmstate_missing_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
>> +    int32_t cpreg_vmstate_missing_indexes_array_len;
>> +    uint64_t cpreg_vmstate_unexpected_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
>> +    int32_t cpreg_vmstate_unexpected_indexes_array_len;
> "indices"?

Originally we had
   uint64_t *cpreg_vmstate_indexes;
so I reused the same terminology

As a non native english speaker I don't know if the usage is wrong. I
thought some references on the net though

Eric
>
>> +
>>      DynamicGDBFeatureInfo dyn_sysreg_feature;
>>      DynamicGDBFeatureInfo dyn_svereg_feature;
>>      DynamicGDBFeatureInfo dyn_smereg_feature;
> (...)
>

Re: [RESEND PATCH 1/7] target/arm/machine: Improve traces on register mismatch during migration

[Cornelia Huck]

On Thu, Nov 13 2025, Eric Auger <eric.auger@redhat.com> wrote:

>>> +    #define MAX_CPREG_VMSTATE_ANOMALIES 10
>>> +    uint64_t cpreg_vmstate_missing_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
>>> +    int32_t cpreg_vmstate_missing_indexes_array_len;
>>> +    uint64_t cpreg_vmstate_unexpected_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
>>> +    int32_t cpreg_vmstate_unexpected_indexes_array_len;
>> "indices"?
>
> Originally we had
>    uint64_t *cpreg_vmstate_indexes;
> so I reused the same terminology
>
> As a non native english speaker I don't know if the usage is wrong. I
> thought some references on the net though

Not a native English speaker, either; wiktionary says both are valid, so
probably a matter of taste.

Re: [RESEND PATCH 1/7] target/arm/machine: Improve traces on register mismatch during migration

[Peter Maydell]

On Thu, 13 Nov 2025 at 14:48, Cornelia Huck <cohuck@redhat.com> wrote:
>
> On Thu, Nov 13 2025, Eric Auger <eric.auger@redhat.com> wrote:
>
> >>> +    #define MAX_CPREG_VMSTATE_ANOMALIES 10
> >>> +    uint64_t cpreg_vmstate_missing_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
> >>> +    int32_t cpreg_vmstate_missing_indexes_array_len;
> >>> +    uint64_t cpreg_vmstate_unexpected_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
> >>> +    int32_t cpreg_vmstate_unexpected_indexes_array_len;
> >> "indices"?
> >
> > Originally we had
> >    uint64_t *cpreg_vmstate_indexes;
> > so I reused the same terminology
> >
> > As a non native english speaker I don't know if the usage is wrong. I
> > thought some references on the net though
>
> Not a native English speaker, either; wiktionary says both are valid, so
> probably a matter of taste.

Mmm. I tend to go with "indexes" as being clearer (especially
for non-native speakers) than "indices". Within QEMU sources
there are twice as many "indexes" as "indices".

thanks
-- PMM

Re: [RESEND PATCH 1/7] target/arm/machine: Improve traces on register mismatch during migration

[Eric Auger]

On 11/13/25 4:01 PM, Peter Maydell wrote:
> On Thu, 13 Nov 2025 at 14:48, Cornelia Huck <cohuck@redhat.com> wrote:
>> On Thu, Nov 13 2025, Eric Auger <eric.auger@redhat.com> wrote:
>>
>>>>> +    #define MAX_CPREG_VMSTATE_ANOMALIES 10
>>>>> +    uint64_t cpreg_vmstate_missing_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
>>>>> +    int32_t cpreg_vmstate_missing_indexes_array_len;
>>>>> +    uint64_t cpreg_vmstate_unexpected_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
>>>>> +    int32_t cpreg_vmstate_unexpected_indexes_array_len;
>>>> "indices"?
>>> Originally we had
>>>    uint64_t *cpreg_vmstate_indexes;
>>> so I reused the same terminology
>>>
>>> As a non native english speaker I don't know if the usage is wrong. I
>>> thought some references on the net though
>> Not a native English speaker, either; wiktionary says both are valid, so
>> probably a matter of taste.
> Mmm. I tend to go with "indexes" as being clearer (especially
> for non-native speakers) than "indices". Within QEMU sources
> there are twice as many "indexes" as "indices".
OK thanks. I will keep it.

Eric
>
> thanks
> -- PMM
>