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? Best regards, Sergey
