[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v6 06/12] target/riscv/tcg: add user flag for profile support
|
From: |
Alistair Francis |
|
Subject: |
Re: [PATCH v6 06/12] target/riscv/tcg: add user flag for profile support |
|
Date: |
Mon, 30 Oct 2023 13:47:56 +1000 |
On Sat, Oct 28, 2023 at 8:44 PM Andrew Jones <ajones@ventanamicro.com> wrote:
>
> On Sat, Oct 28, 2023 at 05:54:21AM -0300, Daniel Henrique Barboza wrote:
> > The TCG emulation implements all the extensions described in the
> > RVA22U64 profile, both mandatory and optional. The mandatory extensions
> > will be enabled via the profile flag. We'll leave the optional
> > extensions to be enabled by hand.
> >
> > Given that this is the first profile we're implementing in TCG we'll
> > need some ground work first:
> >
> > - all profiles declared in riscv_profiles[] will be exposed to users.
> > TCG is the main accelerator we're considering when adding profile
> > support in QEMU, so for now it's safe to assume that all profiles in
> > riscv_profiles[] will be relevant to TCG;
> >
> > - we'll not support user profile settings for vendor CPUs. The flags
> > will still be exposed but users won't be able to change them. The idea
> > is that vendor CPUs in the future can enable profiles internally in
> > their cpu_init() functions, showing to the external world that the CPU
> > supports a certain profile. But users won't be able to enable/disable
> > it;
> >
> > - Setting a profile to 'true' means 'enable all mandatory extensions of
> > this profile, setting it to 'false' means 'do not enable all mandatory
> > extensions for this profile'.
>
> While this definition of profile=off looks appealing at first, it's really
> just saying 'do not do anything', which means it's limiting the potential
> of the property. But, I'll stop talking about this now, as I have another
This seems like the way to go to me
> design suggestion instead:
>
> Since profiles are like G, and other shorthand extensions (just without an
> official shorthand extension name), then I believe they should behave like
> shorthand extensions. Also, since shorthand extensions can be derived from
> their parts, then I think shorthand extensions should behave like
> synthetic extensions. For example, zic64b starts 'false', but, at realize
> time, if all its conditions are present, then it turns 'true'. Shorthand
> extensions should be able to do that too by detecting that each of the
> extensions they represent is present.
>
> So, I think we should automatically turn G and profiles (and future
> shorthand extensions) on when all their respective extensions are present.
I think that's a good idea and something we should support
Alistair
>
> Thanks,
> drew
>
- [PATCH v6 01/12] target/riscv: add zicbop extension flag, (continued)
- [PATCH v6 01/12] target/riscv: add zicbop extension flag, Daniel Henrique Barboza, 2023/10/28
- [PATCH v6 03/12] riscv-qmp-cmds.c: expose named features in cpu_model_expansion, Daniel Henrique Barboza, 2023/10/28
- [PATCH v6 04/12] target/riscv: add rva22u64 profile definition, Daniel Henrique Barboza, 2023/10/28
- [PATCH v6 05/12] target/riscv/kvm: add 'rva22u64' flag as unavailable, Daniel Henrique Barboza, 2023/10/28
- [PATCH v6 06/12] target/riscv/tcg: add user flag for profile support, Daniel Henrique Barboza, 2023/10/28
- [PATCH v6 07/12] target/riscv/tcg: add MISA user options hash, Daniel Henrique Barboza, 2023/10/28
- [PATCH v6 09/12] target/riscv/tcg: handle profile MISA bits, Daniel Henrique Barboza, 2023/10/28
- [PATCH v6 08/12] target/riscv/tcg: add riscv_cpu_write_misa_bit(), Daniel Henrique Barboza, 2023/10/28
- [PATCH v6 10/12] target/riscv/tcg: add hash table insert helpers, Daniel Henrique Barboza, 2023/10/28
- [PATCH v6 11/12] target/riscv/tcg: honor user choice for G MISA bits, Daniel Henrique Barboza, 2023/10/28
- [PATCH v6 12/12] target/riscv/tcg: warn if profile exts are disabled, Daniel Henrique Barboza, 2023/10/28