All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Henderson <richard.henderson@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>,
	"ishii.shuuichir@fujitsu.com" <ishii.shuuichir@fujitsu.com>
Cc: "qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [RFC] Adding the A64FX's HPC funtions.
Date: Wed, 2 Jun 2021 12:02:03 -0700	[thread overview]
Message-ID: <a56283b3-3bb2-d9a3-9a6e-8175cc17b376@linaro.org> (raw)
In-Reply-To: <CAFEAcA_fZ_jC640XrFUCSk6YxzoSmdwDaMDAXoX47mBFKdS9hg@mail.gmail.com>

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~


  reply	other threads:[~2021-06-02 19:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <OS3PR01MB61515F08F0709D9E22B8DDDFE9249@OS3PR01MB6151.jpnprd01.prod.outlook.com>
     [not found] ` <TYCPR01MB6160FB4A9712F3F5E14D8BBAE93E9@TYCPR01MB6160.jpnprd01.prod.outlook.com>
2021-06-01 15:21   ` [RFC] Adding the A64FX's HPC funtions Peter Maydell
2021-06-02 19:02     ` Richard Henderson [this message]
2021-06-02 19:10       ` Peter Maydell
2021-06-03  8:49         ` ishii.shuuichir
2021-06-03  8:17       ` ishii.shuuichir
2021-06-03 20:08         ` Richard Henderson
2021-06-04  8:29           ` ishii.shuuichir
2021-06-04  9:00             ` Peter Maydell
2021-06-07  8:52               ` ishii.shuuichir
2021-06-07 10:14               ` Alex Bennée

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a56283b3-3bb2-d9a3-9a6e-8175cc17b376@linaro.org \
    --to=richard.henderson@linaro.org \
    --cc=ishii.shuuichir@fujitsu.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.