On 8 October 2015 at 10:56, Sergey Fedorov <serge.f...@gmail.com> wrote: > On 29.09.2015 20:24, Sergey Fedorov wrote: >> On 29.09.2015 20:19, Peter Maydell wrote: >>> On 29 September 2015 at 18:14, Sergey Fedorov <serge.f...@gmail.com> wrote: >>>> On 29.09.2015 12:33, Peter Maydell wrote: >>>>> On 28 September 2015 at 11:37, Sergey Fedorov <serge.f...@gmail.com> >>>>> wrote: >>>>> 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? >>> At the moment we don't implement any perf counters except >>> the cycle counter, so I think PMCR_EL0.N is already being >>> reset to the proper value... >> Seems like I should just simply use zero as a reset value for MDCR_EL2 >> register :) > > Peter, would be okay to use zero as a reset value for MDCR_EL2 in this > patch?
Yes; you could add a brief comment that this assumes there are no other performance counters. -- PMM