qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 1/1] target/arm: calculate cache sizes properly


From: Marcin Juszkiewicz
Subject: Re: [PATCH 1/1] target/arm: calculate cache sizes properly
Date: Thu, 11 Jul 2024 12:45:05 +0200
User-agent: Mozilla Thunderbird

On 11.07.2024 12:19, Peter Maydell wrote:
On Wed, 10 Jul 2024 at 18:35, Marcin Juszkiewicz
<marcin.juszkiewicz@linaro.org> wrote:

Neoverse-V1 TRM says that NumSets are [27:13] not :32 like in code.

NumSets in fields [27:13] is the 32-bit CCSIDR_EL1 format
(i.e. what you have when FEAT_CCIDX is not implemented).
The make_ccsidr64() function provides the 64-bit CCSIDR_EL1
format (i.e. the one when FEAT_CCIDX is implemented).

I would suspect this is an accidental error in the Neoverse-V1
TRM -- if you have access to the real hardware and can dump
the CCSIDR_EL1 value I would expect you'll see it matches
what QEMU is implementing here (and that ID_AA64MMFR2_EL1.CCIDX
also says that FEAT_CCIDX is implemented). See also the comment
"The Neoverse-V1 r1p2 TRM lists 32-bit format CCSIDR_EL1 values"
in aarch64_neoverse_v1_initfn() where we document that we
don't trust what the TRM is saying here.

How did you run into this? Is there some guest software
which is assuming the old 32-bit format and not checking
ID_AA64MMFR2_EL1.CCIDX to see if it needs to use the new one?

I started adding cpu cache info into PPTT and so far the only code I used was old 32-bit format one:

https://openfw.io/edk2-devel/20240710-acpi65-v4-6-bc32224e4be4@linaro.org/


Will check for CCIDX and adapt proper way. But that has to wait for August due to vacation plans.



reply via email to

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