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

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

[Peter Maydell]

It looks like you didn't get any responses because something went
wrong and your email never went out to the mailing lists.
I only got it because I was cc'd directly. I'll try effectively
resending it like this to see if that works better. You might want
to check whether the mail server at your end actually sent the
email or if you got a bounce mail or something.

thanks
-- PMM

On Tue, 1 Jun 2021 at 05:53, ishii.shuuichir@fujitsu.com
<ishii.shuuichir@fujitsu.com> wrote:
>
> Ping?
> I'd appreciate any comments.
>
> Best regards,
> Shuuichirou Ishii
>
> > -----Original Message-----
> > From: Ishii, Shuuichirou/石井 周一郎 <ishii.shuuichir@fujitsu.com>
> > Sent: Wednesday, May 26, 2021 4:57 PM
> > To: 'peter.maydell@linaro.org' <peter.maydell@linaro.org>;
> > 'qemu-arm@nongnu.org' <qemu-arm@nongnu.org>;
> > 'qemu-devel@nongnu.org' <qemu-devel@nongnu.org>
> > Cc: Ishii, Shuuichirou/石井 周一郎 <ishii.shuuichir@fujitsu.com>
> > Subject: [RFC] Adding the A64FX's HPC funtions.
> >
> > Hi all!
> >
> > I'm thinking of implementing A64FX HPC extension in qemu.
> > A64FX [1] is a CPU developed by Fujitsu that implements armv8+SVE.
> >
> > [1]
> > https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_Microarchitecture
> > _Manual_en_1.4.pdf
> >
> > A64FX is a CPU developed for HPC (High Performance Computing), and HPC
> > extensions [2] are implemented to improve the performance of user programs.
> >
> > [2]
> > https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_Specification_HP
> > C_Extension_v1_EN.pdf
> >
> > The details of each function are described in [2], and the HPC extensions
> > include
> > 1) Tag address override
> > 2) Sector cache
> > 3) Hardware barrier
> > 4) Hardware prefetch assist
> > are implemented.
> >
> > The A64FX has been installed in systems such as the supercomputer Fugaku,
> > FX700, and FX1000, but since the A64FX functions have not yet been
> > implemented in QEMU, we would like to be able to develop programs in QEMU
> > to use the HPC extensions.
> >
> > Currently, the register specifications for the HPC extensions have been
> > published in [2],  so we would like to implement these registers in QEMU and
> > make them accessible.
> > Eventually, we would also like to consider a mechanism that allows HPC
> > extensions  to operate within the scope of the published information.
> >
> > We would like your comments on the following points in this RFC.
> >
> > 1) Is target/arm/helper.c enough to implement the register (ARMCPRegInfo
> > structure) of HPC extension function of A64FX?
> >
> > 2) Is it OK to specify the option to set the HPC extension of A64FX as follows,
> > for example?
> >
> > -M virt -cpu max,a64fx-hpc-sec=on (*sector cache function) -M virt -cpu
> > max,a64fx-hpc-hwpf=on (*hardware prefetvh assist function) -M virt -cpu
> > max,a64fx-hpc-hwb=on (*hardware barrier function)
> >
> > It is also possible to implement something like -cpu a64fx, but since we don't
> > know if we can implement it immediately, we assume that we will use the -cpu
> > max option first.
> >
> > Since there is no example of A64FX function implemented in QEMU, we would
> > appreciate your comments before we post a patch.
> >
> > Best regards.

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

[Richard Henderson]

On 6/1/21 8:21 AM, Peter Maydell wrote:
>>> I'm thinking of implementing A64FX HPC extension in qemu.
>>> A64FX [1] is a CPU developed by Fujitsu that implements armv8+SVE.
>>>
>>> [1]
>>> https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_Microarchitecture
>>> _Manual_en_1.4.pdf
>>>
>>> A64FX is a CPU developed for HPC (High Performance Computing), and HPC
>>> extensions [2] are implemented to improve the performance of user programs.
>>>
>>> [2]
>>> https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_Specification_HP
>>> C_Extension_v1_EN.pdf
>>>
>>> The details of each function are described in [2], and the HPC extensions
>>> include
>>> 1) Tag address override
>>> 2) Sector cache
>>> 3) Hardware barrier
>>> 4) Hardware prefetch assist
>>> are implemented.

Thanks for the pointers.  It looks to me that it'll be easy to implement these 
in qemu.  We'll need to implement the registers, so that the OS can read back 
the values, but we do not need to actually do anything with them.

>>> 1) Is target/arm/helper.c enough to implement the register (ARMCPRegInfo
>>> structure) of HPC extension function of A64FX?

Yes.

>>> 2) Is it OK to specify the option to set the HPC extension of A64FX as follows,
>>> for example?
>>>
>>> -M virt -cpu max,a64fx-hpc-sec=on (*sector cache function) -M virt -cpu
>>> max,a64fx-hpc-hwpf=on (*hardware prefetvh assist function) -M virt -cpu
>>> max,a64fx-hpc-hwb=on (*hardware barrier function)
>>>
>>> It is also possible to implement something like -cpu a64fx, but since we don't
>>> know if we can implement it immediately, we assume that we will use the -cpu
>>> max option first.

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.

I would like to add -cpu a64fx at some point.  But as you say, that need not 
happen right away.

>>> Since there is no example of A64FX function implemented in QEMU, we would
>>> appreciate your comments before we post a patch.

We endeavor to enable features by the architectural id registers when possible. 
  Thus the cpu_isar_feature() checks in helper.c.

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.

I can certainly help you with this.


r~

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

[Peter Maydell]

On Wed, 2 Jun 2021 at 20:02, Richard Henderson
<richard.henderson@linaro.org> wrote:
> On 6/1/21 8:21 AM, Peter Maydell wrote:
> >>> 2) Is it OK to specify the option to set the HPC extension of A64FX as follows,
> >>> for example?
> >>>
> >>> -M virt -cpu max,a64fx-hpc-sec=on (*sector cache function) -M virt -cpu
> >>> max,a64fx-hpc-hwpf=on (*hardware prefetvh assist function) -M virt -cpu
> >>> max,a64fx-hpc-hwb=on (*hardware barrier function)
> >>>
> >>> It is also possible to implement something like -cpu a64fx, but since we don't
> >>> know if we can implement it immediately, we assume that we will use the -cpu
> >>> max option first.
>
> 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.

I dunno, because it's not an architectural feature, it's an implementation
feature. We can rely on architectural features not to step on each others'
toes, but there's no guarantee that some other impdef feature might not
clash with these a64fx ones.

Also, how does the guest OS typically detect the presence of these
features? If it does it by looking for MIDR etc values that say
"this is an A64FX" then -cpu max won't trigger that.

> I would like to add -cpu a64fx at some point.  But as you say, that need not
> happen right away.

I think it would be worth scoping out how much work the a64fx CPU
would require (ie what else does it need beyond these extensions
and whatever features we currently implement?). If that's not a
lot of work it might be simpler to just add it (possibly even
add it but with one or two of its features as not-yet-implemented.)

thanks
-- PMM

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

[ishii.shuuichir]

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?

> 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 can certainly help you with this.

I am not familiar with this, and I apologize for any inconvenience this may cause,
but I appreciate your cooperation.

Best regards.

> -----Original Message-----
> From: Richard Henderson <richard.henderson@linaro.org>
> Sent: Thursday, June 3, 2021 4:02 AM
> To: Peter Maydell <peter.maydell@linaro.org>; Ishii, Shuuichirou/石井 周一郎
> <ishii.shuuichir@fujitsu.com>
> Cc: qemu-arm@nongnu.org; qemu-devel@nongnu.org
> Subject: Re: [RFC] Adding the A64FX's HPC funtions.
> 
> On 6/1/21 8:21 AM, Peter Maydell wrote:
> >>> I'm thinking of implementing A64FX HPC extension in qemu.
> >>> A64FX [1] is a CPU developed by Fujitsu that implements armv8+SVE.
> >>>
> >>> [1]
> >>>
> https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_Microarchitec
> >>> ture
> >>> _Manual_en_1.4.pdf
> >>>
> >>> A64FX is a CPU developed for HPC (High Performance Computing), and
> >>> HPC extensions [2] are implemented to improve the performance of user
> programs.
> >>>
> >>> [2]
> >>>
> https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_Specification
> >>> _HP
> >>> C_Extension_v1_EN.pdf
> >>>
> >>> The details of each function are described in [2], and the HPC
> >>> extensions include
> >>> 1) Tag address override
> >>> 2) Sector cache
> >>> 3) Hardware barrier
> >>> 4) Hardware prefetch assist
> >>> are implemented.
> 
> Thanks for the pointers.  It looks to me that it'll be easy to implement these in
> qemu.  We'll need to implement the registers, so that the OS can read back the
> values, but we do not need to actually do anything with them.
> 
> >>> 1) Is target/arm/helper.c enough to implement the register
> >>> (ARMCPRegInfo
> >>> structure) of HPC extension function of A64FX?
> 
> Yes.
> 
> >>> 2) Is it OK to specify the option to set the HPC extension of A64FX
> >>> as follows, for example?
> >>>
> >>> -M virt -cpu max,a64fx-hpc-sec=on (*sector cache function) -M virt
> >>> -cpu max,a64fx-hpc-hwpf=on (*hardware prefetvh assist function) -M
> >>> virt -cpu max,a64fx-hpc-hwb=on (*hardware barrier function)
> >>>
> >>> It is also possible to implement something like -cpu a64fx, but
> >>> since we don't know if we can implement it immediately, we assume
> >>> that we will use the -cpu max option first.
> 
> 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.
> 
> I would like to add -cpu a64fx at some point.  But as you say, that need not
> happen right away.
> 
> >>> Since there is no example of A64FX function implemented in QEMU, we
> >>> would appreciate your comments before we post a patch.
> 
> We endeavor to enable features by the architectural id registers when possible.
>   Thus the cpu_isar_feature() checks in helper.c.
> 
> 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.
> 
> I can certainly help you with this.
> 
> 
> r~

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

[ishii.shuuichir]

Hi, peter.

Thank you for your comment.

> I think it would be worth scoping out how much work the a64fx CPU would
> require (ie what else does it need beyond these extensions and whatever
> features we currently implement?). If that's not a lot of work it might be simpler
> to just add it (possibly even add it but with one or two of its features as
> not-yet-implemented.)

I don't think it will take much effort if you just implement the A64FX extended function register. 
As you pointed out, we are investigating the possibility of adding function processing, 
but in that case, we think it will take some time to verify, including the creation of test tools. 

Also, as we proceed with the implementation of the "-cpu max" option as the first step, 
we expect to receive useful comments from the community. 
If there are no problems, we would like to implement the -cpu max option in the first step.
What do you think?

Best regards.

> -----Original Message-----
> From: Peter Maydell <peter.maydell@linaro.org>
> Sent: Thursday, June 3, 2021 4:11 AM
> To: Richard Henderson <richard.henderson@linaro.org>
> Cc: Ishii, Shuuichirou/石井 周一郎 <ishii.shuuichir@fujitsu.com>;
> qemu-arm@nongnu.org; qemu-devel@nongnu.org
> Subject: Re: [RFC] Adding the A64FX's HPC funtions.
> 
> On Wed, 2 Jun 2021 at 20:02, Richard Henderson
> <richard.henderson@linaro.org> wrote:
> > On 6/1/21 8:21 AM, Peter Maydell wrote:
> > >>> 2) Is it OK to specify the option to set the HPC extension of
> > >>> A64FX as follows, for example?
> > >>>
> > >>> -M virt -cpu max,a64fx-hpc-sec=on (*sector cache function) -M virt
> > >>> -cpu max,a64fx-hpc-hwpf=on (*hardware prefetvh assist function) -M
> > >>> virt -cpu max,a64fx-hpc-hwb=on (*hardware barrier function)
> > >>>
> > >>> It is also possible to implement something like -cpu a64fx, but
> > >>> since we don't know if we can implement it immediately, we assume
> > >>> that we will use the -cpu max option first.
> >
> > 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.
> 
> I dunno, because it's not an architectural feature, it's an implementation
> feature. We can rely on architectural features not to step on each others'
> toes, but there's no guarantee that some other impdef feature might not clash
> with these a64fx ones.
> 
> Also, how does the guest OS typically detect the presence of these features? If
> it does it by looking for MIDR etc values that say "this is an A64FX" then -cpu
> max won't trigger that.
> 
> > I would like to add -cpu a64fx at some point.  But as you say, that
> > need not happen right away.
> 
> I think it would be worth scoping out how much work the a64fx CPU would
> require (ie what else does it need beyond these extensions and whatever
> features we currently implement?). If that's not a lot of work it might be simpler
> to just add it (possibly even add it but with one or two of its features as
> not-yet-implemented.)
> 
> thanks
> -- PMM

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

[Richard Henderson]

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~

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

[ishii.shuuichir]

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~

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

[Peter Maydell]

On Fri, 4 Jun 2021 at 09:29, ishii.shuuichir@fujitsu.com
<ishii.shuuichir@fujitsu.com> wrote:
>
> 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.

If somebody has access to A64 hardware they could write a minor kernel
patch to just print the values...

-- PMM

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

[ishii.shuuichir]

> If somebody has access to A64 hardware they could write a minor kernel
> patch to just print the values...

Yes, it's an ARM standard system register, so it's information that
users can find by checking. As you said, it is possible to check it that way,
and we would like to consider implementing the "-cpu a64fx" option based on
that information.

Thank you for your advice.

Best regards.


> -----Original Message-----
> From: Peter Maydell <peter.maydell@linaro.org>
> Sent: Friday, June 4, 2021 6:00 PM
> To: Ishii, Shuuichirou/石井 周一郎 <ishii.shuuichir@fujitsu.com>
> Cc: Richard Henderson <richard.henderson@linaro.org>;
> qemu-arm@nongnu.org; qemu-devel@nongnu.org
> Subject: Re: [RFC] Adding the A64FX's HPC funtions.
> Importance: High
> 
> On Fri, 4 Jun 2021 at 09:29, ishii.shuuichir@fujitsu.com
> <ishii.shuuichir@fujitsu.com> wrote:
> >
> > 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.
> 
> If somebody has access to A64 hardware they could write a minor kernel
> patch to just print the values...
> 
> -- PMM

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

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Fri, 4 Jun 2021 at 09:29, ishii.shuuichir@fujitsu.com
> <ishii.shuuichir@fujitsu.com> wrote:
>>
>> 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.
>
> If somebody has access to A64 hardware they could write a minor kernel
> patch to just print the values...

We do have access to some a64fx hardware I think... or at least there is
some in the lab that tcwg can get access to.

>
> -- PMM


-- 
Alex Bennée