From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Cc: qemu-devel@nongnu.org, qemu-riscv@nongnu.org,
alistair.francis@wdc.com, bmeng@tinylab.org,
liweiwei@iscas.ac.cn, zhiwei_liu@linux.alibaba.com,
palmer@rivosinc.com
Subject: Re: [PATCH 0/6] riscv: RVA22U64 profile support
Date: Fri, 29 Sep 2023 11:46:30 +0100 [thread overview]
Message-ID: <ZRarBuEeBi7WkS6K@redhat.com> (raw)
In-Reply-To: <20230926194951.183767-1-dbarboza@ventanamicro.com>
On Tue, Sep 26, 2023 at 04:49:44PM -0300, Daniel Henrique Barboza wrote:
> Based-on: 20230926183109.165878-1-dbarboza@ventanamicro.com
> ("[PATCH 0/2] riscv: add extension properties for all cpus")
>
> Hi,
>
> These patches implements the base profile support for qemu-riscv and the
> first profile, RVA22U64.
>
> As discussed in this thread [1] we're aiming for a flag that enables all
> mandatory extensions of a profile. Optional extensions were left behind
> and must be enabled by hand if desired. Since this is the first profile
> we're adding, we'll need to add the base framework as well.
>
> The RVA22U64 profile was chosen because qemu-riscv implements all its
> extensions, both mandatory and optional. That includes 'zicntr' and
> 'zihpm', which we support for awhile but aren't adverting to userspace.
>
> Other design decisions made:
>
> - disabling a profile flag does nothing, i.e. we won't mass disable
> mandatory extensions of the rva22U64 profile if the user sets
> rva22u64=false;
Why shouldn't this be allowed ?
IIUC, a profile is syntactic sugar for a group of features. If
we can disable individual features explicitly, why should we
not allow use of the profile as sugar to disable them en-mass ?
BTW, I would caution that the semantics of mixing groups of
features, with individual features in -cpu is likely to be
ill defined, as you cannot rely on left-to-right processing
of the -cpu arguments.
IOW, if you say -cpu $foo,$group=on,$feature=off
you might expect this to result in '$feature' being disabled
if it were implied by $group. This is not guaranteed as the
QDict processing of options could result in us effectively
processing -cpu $foo,$feature=off,$group=on
This brokeness with CPU feature groups and their interaction
with CPU feature flags already impacts s390x:
https://lists.nongnu.org/archive/html/qemu-devel/2023-09/msg00981.html
There is a possible way to fix it by declaring an ordering
such that all groups will be processed fully, before any
individual features are processed, and declaring that group
or feature names must not be repeated. This avoids a reliance
on left-to-right ordering:
https://lists.nongnu.org/archive/html/qemu-devel/2023-09/msg01005.html
that is still likely broken, however, if multiple different
groups are listed, and there is overlap in their feature
sets.
TL;DR: feature groups are pretty error prone if more than
one is listed by the user, or they're combined with individual
features.
>
> - profile support for vendor CPUs consists into checking if the CPU
> happens to have the mandatory extensions required for it. In case it
> doesn't we'll error out. This is done to follow the same prerogative
> we always had of not allowing extensions being enabled for vendor
> CPUs;
Why shouldn't this be allowed ?
> - the KVM driver doesn't support profiles. In theory we could apply the
> same logic as for the vendor CPUs, but KVM has a long way to go before
> that becomes a factor. We'll revisit this decision when KVM is able to
> support at least one profile.
>
> Patch 5 ("enable profile support for vendor CPUs") needs the following
> series to be applied beforehand:
>
> "[PATCH 0/2] riscv: add extension properties for all cpus"
>
> Otherwise we won't be able to add the profile flag to vendor CPUs.
>
> [1] https://lore.kernel.org/qemu-riscv/35a847a1-2720-14ab-61b0-c72d77d5f43b@ventanamicro.com/
>
> Daniel Henrique Barboza (6):
> target/riscv/cpu.c: add zicntr extension flag
> target/riscv/cpu.c: add zihpm extension flag
> target/riscv: add rva22u64 profile definition
> target/riscv/tcg: implement rva22u64 profile
> target/riscv/tcg-cpu.c: enable profile support for vendor CPUs
> target/riscv/kvm: add 'rva22u64' flag as unavailable
>
> target/riscv/cpu.c | 25 ++++++++++
> target/riscv/cpu.h | 10 ++++
> target/riscv/cpu_cfg.h | 2 +
> target/riscv/kvm/kvm-cpu.c | 5 +-
> target/riscv/tcg/tcg-cpu.c | 98 ++++++++++++++++++++++++++++++++++++++
> 5 files changed, 139 insertions(+), 1 deletion(-)
>
> --
> 2.41.0
>
>
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2023-09-29 10:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-26 19:49 [PATCH 0/6] riscv: RVA22U64 profile support Daniel Henrique Barboza
2023-09-26 19:49 ` [PATCH 1/6] target/riscv/cpu.c: add zicntr extension flag Daniel Henrique Barboza
2023-09-26 19:49 ` [PATCH 2/6] target/riscv/cpu.c: add zihpm " Daniel Henrique Barboza
2023-09-26 19:49 ` [PATCH 3/6] target/riscv: add rva22u64 profile definition Daniel Henrique Barboza
2023-09-26 19:49 ` [PATCH 4/6] target/riscv/tcg: implement rva22u64 profile Daniel Henrique Barboza
2023-09-26 19:49 ` [PATCH 5/6] target/riscv/tcg-cpu.c: enable profile support for vendor CPUs Daniel Henrique Barboza
2023-09-26 19:49 ` [PATCH 6/6] target/riscv/kvm: add 'rva22u64' flag as unavailable Daniel Henrique Barboza
2023-09-29 10:10 ` [PATCH 0/6] riscv: RVA22U64 profile support Andrea Bolognani
2023-09-29 10:46 ` Daniel P. Berrangé [this message]
2023-09-29 11:29 ` Daniel Henrique Barboza
2023-09-29 11:55 ` Daniel P. Berrangé
2023-09-29 12:49 ` Daniel Henrique Barboza
2023-09-29 12:52 ` Daniel P. Berrangé
2023-09-29 13:26 ` Daniel Henrique Barboza
2023-09-29 13:32 ` Daniel P. Berrangé
2023-10-09 2:32 ` Alistair Francis
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=ZRarBuEeBi7WkS6K@redhat.com \
--to=berrange@redhat.com \
--cc=alistair.francis@wdc.com \
--cc=bmeng@tinylab.org \
--cc=dbarboza@ventanamicro.com \
--cc=liweiwei@iscas.ac.cn \
--cc=palmer@rivosinc.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=zhiwei_liu@linux.alibaba.com \
/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).