From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgydZ-0002s4-U2 for qemu-devel@nongnu.org; Tue, 29 Sep 2015 13:24:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgydW-0005Zx-Gm for qemu-devel@nongnu.org; Tue, 29 Sep 2015 13:24:21 -0400 Received: from mail-la0-x22b.google.com ([2a00:1450:4010:c03::22b]:35305) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgydW-0005Zb-3r for qemu-devel@nongnu.org; Tue, 29 Sep 2015 13:24:18 -0400 Received: by laer8 with SMTP id r8so17089089lae.2 for ; Tue, 29 Sep 2015 10:24:17 -0700 (PDT) References: <1443436639-6603-1-git-send-email-serge.fdrv@gmail.com> <560AC6E2.6030005@gmail.com> From: Sergey Fedorov Message-ID: <560AC93F.3060505@gmail.com> Date: Tue, 29 Sep 2015 20:24:15 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] target-arm: Add MDCR_EL2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers On 29.09.2015 20:19, Peter Maydell wrote: > On 29 September 2015 at 18:14, Sergey Fedorov wrote: >> On 29.09.2015 12:33, Peter Maydell wrote: >>> On 28 September 2015 at 11:37, Sergey Fedorov 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 :)