Re: [PATCH v5 4/9] target/arm/cpu64: max cpu: Introduce sve<N> properties

From: Andrew Jones <drjones@redhat.com>
To: Beata Michalska <beata.michalska@linaro.org>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	qemu-devel@nongnu.org, armbru@redhat.com, eric.auger@redhat.com,
	qemu-arm@nongnu.org, imammedo@redhat.com,
	"Alex Bennée" <alex.bennee@linaro.org>,
	Dave.Martin@arm.com
Subject: Re: [PATCH v5 4/9] target/arm/cpu64: max cpu: Introduce sve<N> properties
Date: Wed, 16 Oct 2019 10:10:57 +0200	[thread overview]
Message-ID: <20191016081057.svdt6uvftshzzjkr@kamzik.brq.redhat.com> (raw)
In-Reply-To: <CADSWDzu2mUvTDYJj42747DgBAzWRDoMQRNgtepqyvv23OArHNQ@mail.gmail.com>

On Wed, Oct 09, 2019 at 03:01:15PM +0100, Beata Michalska wrote:
> On Tue, 1 Oct 2019 at 14:04, Andrew Jones <drjones@redhat.com> wrote:
> >
> > 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.
> >
> 
> I have most probably missed part of previous discussions around the vector
> lengths  so apologies if the question is not relevant anymore  but ...
> why the idea of having bitmap representation for those has been dropped ?

https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg03439.html

> Although the proposed solution provides indeed fine control over the vector
> lengths it also adds extra logic for handling corner cases and makes specifying
> those on the command line rather cumbersome in some cases.

Examples?

> What if we could re-consider bitmaps and add an option for sve with a 'help'
> switch to query available options and present them (or just a subset
> as an example)
> with additional information on how to interpret/modify it ? Smth like :
>            -cpu max,sve=help
> which would print the bitmap of available lengths with note on what each bit
> represents and which ones can be modified .
> Than it should be pretty straightforward to enable/disable selected lengths.
> This could potentially simplify things a bit....
> 

I won't be re-considering bitmaps, but arm is in need of better help text
for the cpu option. qemu-system-aarch64 -M virt -cpu help only produces a
list of available CPUs, which don't have descriptions. When checking '-cpu
help' on x86 we get descriptions, and we get another section "Recognized
CPUID flags". After this series is applied we could perhaps add a
"Recognized CPU features" section to arm's '-cpu help'. I don't intend
to do that myself, but I'll take a look at whatever you post :-)

Thanks,
drew