qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] target-arm: Add MDCR_EL2


From: Sergey Fedorov
Subject: Re: [Qemu-devel] [PATCH] target-arm: Add MDCR_EL2
Date: Thu, 8 Oct 2015 12:56:56 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

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 <address@hidden> wrote:
>>> On 29.09.2015 12:33, Peter Maydell wrote:
>>>> On 28 September 2015 at 11:37, Sergey Fedorov <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]