From: "Alex Bennée" <alex.bennee@linaro.org>
To: Andrew Jones <drjones@redhat.com>
Cc: peter.maydell@linaro.org, richard.henderson@linaro.org,
qemu-devel@nongnu.org, armbru@redhat.com, eric.auger@redhat.com,
qemu-arm@nongnu.org, imammedo@redhat.com, Dave.Martin@arm.com
Subject: Re: [PATCH v5 4/9] target/arm/cpu64: max cpu: Introduce sve<N> properties
Date: Mon, 07 Oct 2019 09:35:35 +0100 [thread overview]
Message-ID: <87d0f9j6lk.fsf@linaro.org> (raw)
In-Reply-To: <20191001125845.8793-5-drjones@redhat.com>
Andrew Jones <drjones@redhat.com> writes:
> Introduce cpu properties to give fine control over SVE vector lengths.
> We introduce a property for each valid length up to the current
> maximum supported, which is 2048-bits. The properties are named, e.g.
> sve128, sve256, sve384, sve512, ..., where the number is the number of
> bits. See the updates to docs/arm-cpu-features.rst for a description
> of the semantics and for example uses.
>
> Note, as sve-max-vq is still present and we'd like to be able to
> support qmp_query_cpu_model_expansion with guests launched with e.g.
> -cpu max,sve-max-vq=8 on their command lines, then we do allow
> sve-max-vq and sve<N> properties to be provided at the same time, but
> this is not recommended, and is why sve-max-vq is not mentioned in the
> document. If sve-max-vq is provided then it enables all lengths smaller
> than and including the max and disables all lengths larger. It also has
> the side-effect that no larger lengths may be enabled and that the max
> itself cannot be disabled. Smaller non-power-of-two lengths may,
> however, be disabled, e.g. -cpu max,sve-max-vq=4,sve384=off provides a
> guest the vector lengths 128, 256, and 512 bits.
>
> This patch has been co-authored with Richard Henderson, who reworked
> the target/arm/cpu64.c changes in order to push all the validation and
> auto-enabling/disabling steps into the finalizer, resulting in a nice
> LOC reduction.
>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> docs/arm-cpu-features.rst | 168 +++++++++++++++++++++++++++++++--
> include/qemu/bitops.h | 1 +
> target/arm/cpu.c | 19 ++++
> target/arm/cpu.h | 19 ++++
> target/arm/cpu64.c | 192 ++++++++++++++++++++++++++++++++++++-
> target/arm/helper.c | 10 +-
> target/arm/monitor.c | 12 +++
> tests/arm-cpu-features.c | 194 ++++++++++++++++++++++++++++++++++++++
> 8 files changed, 606 insertions(+), 9 deletions(-)
>
> diff --git a/docs/arm-cpu-features.rst b/docs/arm-cpu-features.rst
> index c79dcffb5556..2ea4d6e90c02 100644
> --- a/docs/arm-cpu-features.rst
> +++ b/docs/arm-cpu-features.rst
> @@ -48,18 +48,31 @@ block in the script for usage) is used to issue the QMP commands.
> (QEMU) query-cpu-model-expansion type=full model={"name":"max"}
> { "return": {
> "model": { "name": "max", "props": {
> - "pmu": true, "aarch64": true
> + "sve1664": true, "pmu": true, "sve1792": true, "sve1920": true,
> + "sve128": true, "aarch64": true, "sve1024": true, "sve": true,
> + "sve640": true, "sve768": true, "sve1408": true, "sve256": true,
> + "sve1152": true, "sve512": true, "sve384": true, "sve1536": true,
> + "sve896": true, "sve1280": true, "sve2048": true
Does having a list of VL's not have implications for the versioning of
the API? Do we need to tick a version each time a new vector length is
added?
--
Alex Bennée
next prev parent reply other threads:[~2019-10-07 8:36 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-01 12:58 [PATCH v5 0/9] target/arm/kvm: enable SVE in guests Andrew Jones
2019-10-01 12:58 ` [PATCH v5 1/9] target/arm/monitor: Introduce qmp_query_cpu_model_expansion Andrew Jones
2019-10-15 9:59 ` Beata Michalska
2019-10-15 10:56 ` Andrew Jones
2019-10-15 11:56 ` Beata Michalska
2019-10-16 13:24 ` Beata Michalska
2019-10-16 13:50 ` Andrew Jones
2019-10-16 15:16 ` Beata Michalska
2019-10-16 16:16 ` Andrew Jones
2019-10-21 15:07 ` Beata Michalska
2019-10-22 13:43 ` Andrew Jones
2019-10-22 15:49 ` Beata Michalska
2019-10-01 12:58 ` [PATCH v5 2/9] tests: arm: Introduce cpu feature tests Andrew Jones
2019-10-01 12:58 ` [PATCH v5 3/9] target/arm: Allow SVE to be disabled via a CPU property Andrew Jones
2019-10-01 12:58 ` [PATCH v5 4/9] target/arm/cpu64: max cpu: Introduce sve<N> properties Andrew Jones
2019-10-01 17:47 ` Richard Henderson
2019-10-07 7:22 ` Auger Eric
2019-10-07 8:35 ` Alex Bennée [this message]
2019-10-07 12:41 ` Andrew Jones
2019-10-09 14:01 ` Beata Michalska
2019-10-16 8:10 ` Andrew Jones
2019-10-01 12:58 ` [PATCH v5 5/9] target/arm/kvm64: Add kvm_arch_get/put_sve Andrew Jones
2019-10-01 13:52 ` Andrew Jones
2019-10-01 13:58 ` Andrew Jones
2019-10-01 17:52 ` Richard Henderson
2019-10-07 7:22 ` Auger Eric
2019-10-01 12:58 ` [PATCH v5 6/9] target/arm/kvm64: max cpu: Enable SVE when available Andrew Jones
2019-10-01 12:58 ` [PATCH v5 7/9] target/arm/kvm: scratch vcpu: Preserve input kvm_vcpu_init features Andrew Jones
2019-10-01 12:58 ` [PATCH v5 8/9] target/arm/cpu64: max cpu: Support sve properties with KVM Andrew Jones
2019-10-01 17:58 ` Richard Henderson
2019-10-01 12:58 ` [PATCH v5 9/9] target/arm/kvm: host cpu: Add support for sve<N> properties Andrew Jones
2019-10-01 17:59 ` Richard Henderson
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=87d0f9j6lk.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=Dave.Martin@arm.com \
--cc=armbru@redhat.com \
--cc=drjones@redhat.com \
--cc=eric.auger@redhat.com \
--cc=imammedo@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).