All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [PATCH] target-arm: Do not reset sysregs marked as ALIAS
@ 2015-06-17 15:25 Sergey Fedorov
  2015-06-18 20:46 ` Peter Maydell
  0 siblings, 1 reply; 5+ messages in thread
From: Sergey Fedorov @ 2015-06-17 15:25 UTC (permalink / raw)
  To: qemu-devel; +Cc: Peter Maydell, Sergey Fedorov

cp_reg_reset() is called from g_hash_table_foreach() which does not
define a specific ordering of the hash table iteration. Thus doing reset
for registers marked as ALIAS would give an ambiguous result when
resetvalue is different for original and alias resisters. Exit
cp_reg_reset() early when passed an alias register. Then clean up alias
register definitions from needless resetvalue and resetfn.

Signed-off-by: Sergey Fedorov <serge.fdrv@gmail.com>
---
 target-arm/cpu.c    |  2 +-
 target-arm/cpu.h    |  4 ++--
 target-arm/helper.c | 28 +++++++++-------------------
 3 files changed, 12 insertions(+), 22 deletions(-)

diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index 7496983..4bb821b 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -55,7 +55,7 @@ static void cp_reg_reset(gpointer key, gpointer value, gpointer opaque)
     ARMCPRegInfo *ri = value;
     ARMCPU *cpu = opaque;
 
-    if (ri->type & ARM_CP_SPECIAL) {
+    if (ri->type & (ARM_CP_SPECIAL | ARM_CP_ALIAS)) {
         return;
     }
 
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index c9d2330..2f59058 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -1116,8 +1116,8 @@ static inline uint64_t cpreg_to_kvm_id(uint32_t cpregid)
  * old must have the OVERRIDE bit set.
  * ALIAS indicates that this register is an alias view of some underlying
  * state which is also visible via another register, and that the other
- * register is handling migration; registers marked ALIAS will not be migrated
- * but may have their state set by syncing of register state from KVM.
+ * register is handling migration and reset; registers marked ALIAS will not be
+ * migrated but may have their state set by syncing of register state from KVM.
  * NO_RAW indicates that this register has no underlying state and does not
  * support raw access for state saving/loading; it will not be used for either
  * migration or KVM state synchronization. (Typically this is for "registers"
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 00509b1..fbf20b6 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -984,7 +984,7 @@ static const ARMCPRegInfo v7_cp_reginfo[] = {
     { .name = "PMINTENCLR", .cp = 15, .crn = 9, .crm = 14, .opc1 = 0, .opc2 = 2,
       .access = PL1_RW, .type = ARM_CP_ALIAS,
       .fieldoffset = offsetof(CPUARMState, cp15.c9_pminten),
-      .resetvalue = 0, .writefn = pmintenclr_write, },
+      .writefn = pmintenclr_write, },
     { .name = "VBAR", .state = ARM_CP_STATE_BOTH,
       .opc0 = 3, .crn = 12, .crm = 0, .opc1 = 0, .opc2 = 0,
       .access = PL1_RW, .writefn = vbar_write,
@@ -1323,7 +1323,6 @@ static const ARMCPRegInfo generic_timer_cp_reginfo[] = {
       .type = ARM_CP_ALIAS,
       .access = PL1_RW | PL0_R, .accessfn = gt_cntfrq_access,
       .fieldoffset = offsetoflow32(CPUARMState, cp15.c14_cntfrq),
-      .resetfn = arm_cp_reset_ignore,
     },
     { .name = "CNTFRQ_EL0", .state = ARM_CP_STATE_AA64,
       .opc0 = 3, .opc1 = 3, .crn = 14, .crm = 0, .opc2 = 0,
@@ -1344,7 +1343,6 @@ static const ARMCPRegInfo generic_timer_cp_reginfo[] = {
       .accessfn = gt_ptimer_access,
       .fieldoffset = offsetoflow32(CPUARMState,
                                    cp15.c14_timer[GTIMER_PHYS].ctl),
-      .resetfn = arm_cp_reset_ignore,
       .writefn = gt_ctl_write, .raw_writefn = raw_write,
     },
     { .name = "CNTP_CTL_EL0", .state = ARM_CP_STATE_AA64,
@@ -1360,7 +1358,6 @@ static const ARMCPRegInfo generic_timer_cp_reginfo[] = {
       .accessfn = gt_vtimer_access,
       .fieldoffset = offsetoflow32(CPUARMState,
                                    cp15.c14_timer[GTIMER_VIRT].ctl),
-      .resetfn = arm_cp_reset_ignore,
       .writefn = gt_ctl_write, .raw_writefn = raw_write,
     },
     { .name = "CNTV_CTL_EL0", .state = ARM_CP_STATE_AA64,
@@ -1422,7 +1419,7 @@ static const ARMCPRegInfo generic_timer_cp_reginfo[] = {
       .access = PL1_RW | PL0_R,
       .type = ARM_CP_64BIT | ARM_CP_IO | ARM_CP_ALIAS,
       .fieldoffset = offsetof(CPUARMState, cp15.c14_timer[GTIMER_PHYS].cval),
-      .accessfn = gt_ptimer_access, .resetfn = arm_cp_reset_ignore,
+      .accessfn = gt_ptimer_access,
       .writefn = gt_cval_write, .raw_writefn = raw_write,
     },
     { .name = "CNTP_CVAL_EL0", .state = ARM_CP_STATE_AA64,
@@ -1437,7 +1434,7 @@ static const ARMCPRegInfo generic_timer_cp_reginfo[] = {
       .access = PL1_RW | PL0_R,
       .type = ARM_CP_64BIT | ARM_CP_IO | ARM_CP_ALIAS,
       .fieldoffset = offsetof(CPUARMState, cp15.c14_timer[GTIMER_VIRT].cval),
-      .accessfn = gt_vtimer_access, .resetfn = arm_cp_reset_ignore,
+      .accessfn = gt_vtimer_access,
       .writefn = gt_cval_write, .raw_writefn = raw_write,
     },
     { .name = "CNTV_CVAL_EL0", .state = ARM_CP_STATE_AA64,
@@ -1714,12 +1711,10 @@ static const ARMCPRegInfo pmsav5_cp_reginfo[] = {
     { .name = "DATA_AP", .cp = 15, .crn = 5, .crm = 0, .opc1 = 0, .opc2 = 0,
       .access = PL1_RW, .type = ARM_CP_ALIAS,
       .fieldoffset = offsetof(CPUARMState, cp15.pmsav5_data_ap),
-      .resetvalue = 0,
       .readfn = pmsav5_data_ap_read, .writefn = pmsav5_data_ap_write, },
     { .name = "INSN_AP", .cp = 15, .crn = 5, .crm = 0, .opc1 = 0, .opc2 = 1,
       .access = PL1_RW, .type = ARM_CP_ALIAS,
       .fieldoffset = offsetof(CPUARMState, cp15.pmsav5_insn_ap),
-      .resetvalue = 0,
       .readfn = pmsav5_insn_ap_read, .writefn = pmsav5_insn_ap_write, },
     { .name = "DATA_EXT_AP", .cp = 15, .crn = 5, .crm = 0, .opc1 = 0, .opc2 = 2,
       .access = PL1_RW,
@@ -1851,8 +1846,7 @@ static const ARMCPRegInfo vmsa_pmsa_cp_reginfo[] = {
     { .name = "DFSR", .cp = 15, .crn = 5, .crm = 0, .opc1 = 0, .opc2 = 0,
       .access = PL1_RW, .type = ARM_CP_ALIAS,
       .bank_fieldoffsets = { offsetoflow32(CPUARMState, cp15.dfsr_s),
-                             offsetoflow32(CPUARMState, cp15.dfsr_ns) },
-      .resetfn = arm_cp_reset_ignore, },
+                             offsetoflow32(CPUARMState, cp15.dfsr_ns) }, },
     { .name = "IFSR", .cp = 15, .crn = 5, .crm = 0, .opc1 = 0, .opc2 = 1,
       .access = PL1_RW, .resetvalue = 0,
       .bank_fieldoffsets = { offsetoflow32(CPUARMState, cp15.ifsr_s),
@@ -1890,7 +1884,7 @@ static const ARMCPRegInfo vmsa_cp_reginfo[] = {
       .fieldoffset = offsetof(CPUARMState, cp15.tcr_el[1]) },
     { .name = "TTBCR", .cp = 15, .crn = 2, .crm = 0, .opc1 = 0, .opc2 = 2,
       .access = PL1_RW, .type = ARM_CP_ALIAS, .writefn = vmsa_ttbcr_write,
-      .resetfn = arm_cp_reset_ignore, .raw_writefn = vmsa_ttbcr_raw_write,
+      .raw_writefn = vmsa_ttbcr_raw_write,
       .bank_fieldoffsets = { offsetoflow32(CPUARMState, cp15.tcr_el[3]),
                              offsetoflow32(CPUARMState, cp15.tcr_el[1])} },
     REGINFO_SENTINEL
@@ -2109,12 +2103,12 @@ static const ARMCPRegInfo lpae_cp_reginfo[] = {
       .access = PL1_RW, .type = ARM_CP_64BIT | ARM_CP_ALIAS,
       .bank_fieldoffsets = { offsetof(CPUARMState, cp15.ttbr0_s),
                              offsetof(CPUARMState, cp15.ttbr0_ns) },
-      .writefn = vmsa_ttbr_write, .resetfn = arm_cp_reset_ignore },
+      .writefn = vmsa_ttbr_write, },
     { .name = "TTBR1", .cp = 15, .crm = 2, .opc1 = 1,
       .access = PL1_RW, .type = ARM_CP_64BIT | ARM_CP_ALIAS,
       .bank_fieldoffsets = { offsetof(CPUARMState, cp15.ttbr1_s),
                              offsetof(CPUARMState, cp15.ttbr1_ns) },
-      .writefn = vmsa_ttbr_write, .resetfn = arm_cp_reset_ignore },
+      .writefn = vmsa_ttbr_write, },
     REGINFO_SENTINEL
 };
 
@@ -2641,7 +2635,6 @@ static const ARMCPRegInfo el2_cp_reginfo[] = {
       .fieldoffset = offsetof(CPUARMState, cp15.ttbr0_el[2]) },
     { .name = "HTTBR", .cp = 15, .opc1 = 4, .crm = 2,
       .access = PL2_RW, .type = ARM_CP_64BIT | ARM_CP_ALIAS,
-      .resetvalue = 0,
       .fieldoffset = offsetof(CPUARMState, cp15.ttbr0_el[2]) },
     { .name = "TLBI_ALLE2", .state = ARM_CP_STATE_AA64,
       .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 7, .opc2 = 0,
@@ -2666,7 +2659,7 @@ static const ARMCPRegInfo el3_cp_reginfo[] = {
     { .name = "SCR",  .type = ARM_CP_ALIAS,
       .cp = 15, .opc1 = 0, .crn = 1, .crm = 1, .opc2 = 0,
       .access = PL3_RW, .fieldoffset = offsetoflow32(CPUARMState, cp15.scr_el3),
-      .resetfn = arm_cp_reset_ignore, .writefn = scr_write },
+      .writefn = scr_write },
     { .name = "SDER32_EL3", .state = ARM_CP_STATE_AA64,
       .opc0 = 3, .opc1 = 6, .crn = 1, .crm = 1, .opc2 = 1,
       .access = PL3_RW, .resetvalue = 0,
@@ -2761,8 +2754,7 @@ static const ARMCPRegInfo debug_cp_reginfo[] = {
       .cp = 14, .opc0 = 2, .opc1 = 0, .crn = 0, .crm = 1, .opc2 = 0,
       .type = ARM_CP_ALIAS,
       .access = PL1_R,
-      .fieldoffset = offsetof(CPUARMState, cp15.mdscr_el1),
-      .resetfn = arm_cp_reset_ignore },
+      .fieldoffset = offsetof(CPUARMState, cp15.mdscr_el1), },
     /* We define a dummy WI OSLAR_EL1, because Linux writes to it. */
     { .name = "OSLAR_EL1", .state = ARM_CP_STATE_BOTH,
       .cp = 14, .opc0 = 2, .opc1 = 0, .crn = 1, .crm = 0, .opc2 = 4,
@@ -3721,14 +3713,12 @@ static void add_cpreg_to_hashtable(ARMCPU *cpu, const ARMCPRegInfo *r,
             if ((r->state == ARM_CP_STATE_BOTH && ns) ||
                 (arm_feature(&cpu->env, ARM_FEATURE_V8) && !ns)) {
                 r2->type |= ARM_CP_ALIAS;
-                r2->resetfn = arm_cp_reset_ignore;
             }
         } else if ((secstate != r->secure) && !ns) {
             /* The register is not banked so we only want to allow migration of
              * the non-secure instance.
              */
             r2->type |= ARM_CP_ALIAS;
-            r2->resetfn = arm_cp_reset_ignore;
         }
 
         if (r->state == ARM_CP_STATE_BOTH) {
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [Qemu-devel] [PATCH] target-arm: Do not reset sysregs marked as ALIAS
  2015-06-17 15:25 [Qemu-devel] [PATCH] target-arm: Do not reset sysregs marked as ALIAS Sergey Fedorov
@ 2015-06-18 20:46 ` Peter Maydell
  2015-06-18 20:57   ` Sergey Fedorov
  0 siblings, 1 reply; 5+ messages in thread
From: Peter Maydell @ 2015-06-18 20:46 UTC (permalink / raw)
  To: Sergey Fedorov; +Cc: QEMU Developers

On 17 June 2015 at 16:25, Sergey Fedorov <serge.fdrv@gmail.com> wrote:
> cp_reg_reset() is called from g_hash_table_foreach() which does not
> define a specific ordering of the hash table iteration. Thus doing reset
> for registers marked as ALIAS would give an ambiguous result when
> resetvalue is different for original and alias resisters.

Was this actually the case for any of our registers? ie, is this
patch fixing a bug, or just cleaning up a potential cause of
confusion?

> Exit
> cp_reg_reset() early when passed an alias register. Then clean up alias
> register definitions from needless resetvalue and resetfn.
>
> Signed-off-by: Sergey Fedorov <serge.fdrv@gmail.com>

I've applied it to target-arm.next, but if this is fixing a bug
it would be nice if I could update the commit message to say so.

thanks
-- PMM

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Qemu-devel] [PATCH] target-arm: Do not reset sysregs marked as ALIAS
  2015-06-18 20:46 ` Peter Maydell
@ 2015-06-18 20:57   ` Sergey Fedorov
  2015-06-18 21:01     ` Peter Maydell
  0 siblings, 1 reply; 5+ messages in thread
From: Sergey Fedorov @ 2015-06-18 20:57 UTC (permalink / raw)
  To: Peter Maydell; +Cc: QEMU Developers

On 18.06.2015 23:46, Peter Maydell wrote:
> On 17 June 2015 at 16:25, Sergey Fedorov <serge.fdrv@gmail.com> wrote:
>> cp_reg_reset() is called from g_hash_table_foreach() which does not
>> define a specific ordering of the hash table iteration. Thus doing reset
>> for registers marked as ALIAS would give an ambiguous result when
>> resetvalue is different for original and alias resisters.
> Was this actually the case for any of our registers? ie, is this
> patch fixing a bug, or just cleaning up a potential cause of
> confusion?

Peter, I discovered such a confusing behavior for PMCR register and
decided to sort this out.

>
>> Exit
>> cp_reg_reset() early when passed an alias register. Then clean up alias
>> register definitions from needless resetvalue and resetfn.
>>
>> Signed-off-by: Sergey Fedorov <serge.fdrv@gmail.com>
> I've applied it to target-arm.next, but if this is fixing a bug
> it would be nice if I could update the commit message to say so.
>
> thanks
> -- PMM

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Qemu-devel] [PATCH] target-arm: Do not reset sysregs marked as ALIAS
  2015-06-18 20:57   ` Sergey Fedorov
@ 2015-06-18 21:01     ` Peter Maydell
  2015-06-18 21:03       ` Sergey Fedorov
  0 siblings, 1 reply; 5+ messages in thread
From: Peter Maydell @ 2015-06-18 21:01 UTC (permalink / raw)
  To: Sergey Fedorov; +Cc: QEMU Developers

On 18 June 2015 at 21:57, Sergey Fedorov <serge.fdrv@gmail.com> wrote:
> On 18.06.2015 23:46, Peter Maydell wrote:
>> On 17 June 2015 at 16:25, Sergey Fedorov <serge.fdrv@gmail.com> wrote:
>>> cp_reg_reset() is called from g_hash_table_foreach() which does not
>>> define a specific ordering of the hash table iteration. Thus doing reset
>>> for registers marked as ALIAS would give an ambiguous result when
>>> resetvalue is different for original and alias resisters.
>> Was this actually the case for any of our registers? ie, is this
>> patch fixing a bug, or just cleaning up a potential cause of
>> confusion?
>
> Peter, I discovered such a confusing behavior for PMCR register and
> decided to sort this out.

Ah yes, nice catch. I'll fix up the commit message.

-- PMM

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Qemu-devel] [PATCH] target-arm: Do not reset sysregs marked as ALIAS
  2015-06-18 21:01     ` Peter Maydell
@ 2015-06-18 21:03       ` Sergey Fedorov
  0 siblings, 0 replies; 5+ messages in thread
From: Sergey Fedorov @ 2015-06-18 21:03 UTC (permalink / raw)
  To: Peter Maydell; +Cc: QEMU Developers



On 19.06.2015 00:01, Peter Maydell wrote:
> On 18 June 2015 at 21:57, Sergey Fedorov <serge.fdrv@gmail.com> wrote:
>> On 18.06.2015 23:46, Peter Maydell wrote:
>>> On 17 June 2015 at 16:25, Sergey Fedorov <serge.fdrv@gmail.com> wrote:
>>>> cp_reg_reset() is called from g_hash_table_foreach() which does not
>>>> define a specific ordering of the hash table iteration. Thus doing reset
>>>> for registers marked as ALIAS would give an ambiguous result when
>>>> resetvalue is different for original and alias resisters.
>>> Was this actually the case for any of our registers? ie, is this
>>> patch fixing a bug, or just cleaning up a potential cause of
>>> confusion?
>> Peter, I discovered such a confusing behavior for PMCR register and
>> decided to sort this out.
> Ah yes, nice catch. I'll fix up the commit message.
>
> -- PMM

Thanks!

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-06-18 21:03 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-17 15:25 [Qemu-devel] [PATCH] target-arm: Do not reset sysregs marked as ALIAS Sergey Fedorov
2015-06-18 20:46 ` Peter Maydell
2015-06-18 20:57   ` Sergey Fedorov
2015-06-18 21:01     ` Peter Maydell
2015-06-18 21:03       ` Sergey Fedorov

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.