RE: [RFC] Adding the A64FX's HPC funtions.

[address@hidden]

Hi, Richard.

> Well, Peter disagreed with having them enabled by default in -cpu max, so we
> might need at least one extra property.  I see no reason to have three
> properties -- one property a64fx-hpc should be sufficient.  But we might not
> want any command-line properties, see below...

I understood.

> For comparison, in the Arm Cortex-A76 manual,
>    https://developer.arm.com/documentation/100798/0301/
> section B2.4 "AArch64 registers by functional group", there is a concise
> listing of all of the system registers and their reset values.

Thank you for the information.

> The most important of these for QEMU to create '-cpu a64fx' are the
> ID_AA64{ISAR,MMFR,PFR} and MIDR values.  These values determine all of
> the
> standard architectural features,

The values of ID_AA64{ISAR,MMFR,PFR} and MIDR are not listed in the 
specifications published at this time. 
Of course, they are listed in the A64FX specification document managed within 
Fujitsu,
but we cannot tell how far these setting values can be disclosed 
without checking with the A64FX specification staff within Fujitsu.

In order to make the "-cpu a64fx" option, the above problem needs to be solved.
When the necessary register specifications are released,
it will be possible to implement the "-cpu a64fx" option,
but I thought it would be better to implement the "-cpu max" option as a first 
step,
partly because I don't know when it will be possible to solve this problem.

However, MIDR.partnum can be found in "CPU implementer" of /proc/cpuinfo,
and CPU FEAT is partially displayed in kernel boot messages.
It is true that there are some values that are publicly known in a sense from 
Linux on A64FX-equipped machines,
even if they are not listed in the existing public A64FX|specification.

To what extent ID_AA64{ISAR,MMFR,PFR} can be made public needs to be confirmed 
with the A64FX specification staff. As for the MIDR register values,
I think they can be implemented in QEMU as publicly known information that can 
be recognized by the OS.

When considering implementation with the "-cpu a64fx" option,
is there any problem to define only the value of MIDR,
using a temporary value for now until the information of ID_AA64{ISAR,MMFR,PFR} 
can be disclosed?

> Peter is suggesting that if full support for -cpu a64fx apart from the hpc
> extensions is close, then we shouldn't implementing a property for -cpu max,
> but only implement -cpu a64fx.  (Because how does the OS detect the hpc
> feature, apart from the MIDR value?)

The HPC extension is implemented as an impldef register as a unique feature for 
HPC in the A64FX processor.
the existence of the HPC extension would be determined from the fact that 
MIDR.partnum is A64FX (0x46).

Best regards.

> -----Original Message-----
> From: Richard Henderson <richard.henderson@linaro.org>
> Sent: Friday, June 4, 2021 5:08 AM
> To: Ishii, Shuuichirou/石井 周一郎 <ishii.shuuichir@fujitsu.com>; Peter
> Maydell <peter.maydell@linaro.org>
> Cc: qemu-arm@nongnu.org; qemu-devel@nongnu.org
> Subject: Re: [RFC] Adding the A64FX's HPC funtions.
> 
> On 6/3/21 1:17 AM, ishii.shuuichir@fujitsu.com wrote:
> > Hi, Richard.
> >
> > Thank you for your comment.
> >
> >> My first thought is that -cpu max can simply enable the extensions,
> >> without extra flags.  The max cpu has all of the features that we can
> >> enable, and as I see it this is just one more.
> >
> > Let me confirm a few things about the above comment.
> > Does it mean that I don't need to explicitly enable individual
> > extensions such as a64fx-hpc-sec, a64fx-hpc-hwpf, and a64fx-hpc-hwb,
> > since all extensions can be enabled by specifying -cpu max?
> 
> Well, Peter disagreed with having them enabled by default in -cpu max, so we
> might need at least one extra property.  I see no reason to have three
> properties -- one property a64fx-hpc should be sufficient.  But we might not
> want any command-line properties, see below...
> 
> >
> >> The microarchitectural document provided does not list all of the system
> >> register reset values for the A64FX, and I would be surprised if there were
> an
> >> architectural id register that specified a non-standard extension like 
> >> this.
> >> Thus I would expect to add ARM_FEATURE_A64FX with which to enable
> these
> >> extensions in helper.c.
> >
> > As you said,
> > some of the published specifications do not describe the reset values of the
> registers.
> > I would like to implement this in QEMU by referring to a real machine with
> A64FX.
> 
> I presume there exists some documentation for this somewhere, though
> possibly
> only internal to Fujitsu so far.
> 
> For comparison, in the Arm Cortex-A76 manual,
>    https://developer.arm.com/documentation/100798/0301/
> section B2.4 "AArch64 registers by functional group", there is a concise
> listing of all of the system registers and their reset values.
> 
> The most important of these for QEMU to create '-cpu a64fx' are the
> ID_AA64{ISAR,MMFR,PFR} and MIDR values.  These values determine all of
> the
> standard architectural features, and from them we can tell what QEMU may (or
> may not) be missing for proper emulation of the cpu.  For comparison, look at
> aarch64_a72_initfn in target/arm/cpu64.c.
> 
> Peter is suggesting that if full support for -cpu a64fx apart from the hpc
> extensions is close, then we shouldn't implementing a property for -cpu max,
> but only implement -cpu a64fx.  (Because how does the OS detect the hpc
> feature, apart from the MIDR value?)
> 
> 
> r~