On 29.09.2015 12:33, Peter Maydell wrote: > On 28 September 2015 at 11:37, Sergey Fedorov <serge.f...@gmail.com> wrote: >> Signed-off-by: Sergey Fedorov <serge.f...@gmail.com> >> --- >> >> This patch is a prerequisite for a debug exception routing patch: >> https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg03542.html >> >> target-arm/cpu-qom.h | 1 + >> target-arm/cpu.c | 1 + >> target-arm/cpu.h | 1 + >> target-arm/cpu64.c | 1 + >> target-arm/helper.c | 13 +++++++++++++ >> 5 files changed, 17 insertions(+) >> >> diff --git a/target-arm/cpu-qom.h b/target-arm/cpu-qom.h >> index 25fb1ce..d2b0769 100644 >> --- a/target-arm/cpu-qom.h >> +++ b/target-arm/cpu-qom.h >> @@ -167,6 +167,7 @@ typedef struct ARMCPU { >> uint64_t id_aa64mmfr0; >> uint64_t id_aa64mmfr1; >> uint32_t dbgdidr; >> + uint32_t mdcr; > This field should be named mdcr_el2 if we have it, but: > the reset value for this register is defined architecturally, > so we don't need to specify it per CPU. (It's "all 0s, except > the bottom field resets to the same value as PMCR.N". Strictly > speaking some fields are defined to be architecturally > unknown and so might differ per CPU, but only in ways which > a guest doesn't care about. We typically model these in > the same way for all guest CPUs in QEMU.) >
We reset PMCR_EL0 to cpu->midr & 0xff000000. So if we want to reset MDCR_EL2.N with PMCR_EL0.N we should reset PMCR_EL0.N to the proper value somehow first. I think we could reset PMCR_EL0 with its own reset value from a dedicated ARMCPU structure field independent from MIDR_EL1 reset value. This makes sense considering that most of PMCR_EL0's fields are RO/UNKNOWN. What do you think? Best regards, Sergey