From: Conor Dooley <conor@kernel.org>
To: Alistair Francis <alistair23@gmail.com>
Cc: Andrew Jones <ajones@ventanamicro.com>,
Daniel Henrique Barboza <dbarboza@ventanamicro.com>,
qemu-devel@nongnu.org, qemu-riscv@nongnu.org,
alistair.francis@wdc.com, bmeng@tinylab.org, liwei1518@gmail.com,
zhiwei_liu@linux.alibaba.com, palmer@rivosinc.com
Subject: Re: [PATCH v3 3/6] target/riscv: add remaining named features
Date: Fri, 16 Feb 2024 15:08:25 +0000 [thread overview]
Message-ID: <20240216-fabulous-eraser-ffc4c2ed080f@spud> (raw)
In-Reply-To: <CAKmqyKPy8C9fz2c7RMnFL1bG1XHZf9kdduGOjgTGP+O6PB_fSg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3132 bytes --]
> > No they can't. For a "regular extension" you populate the DT with the
> > extension. For these extensions it has to put negated properties in the
> > DT, otherwise it is incorrectly describing the hardware it is emulating.
> > That is handling them differently in my book! If QEMU generates an
> > incorrect DT representation of the hardware it is emulating, that's a
> > QEMU bug.
>
> QEMU listing the extensions that it supports seems to me to be the
> correct approach.
>
> It's clunky that the list of "extensions" are constantly changing.
> There isn't much we can do about that from a QEMU perspective though.
>
> Listing the hardware and what it supports is the job of the DT.
>
> I see your concern about what happens if the "extensions" are disabled
> though. Realislity they probably never will be.
Yeah, it's something we can sweep under the rug unless/until someone
wants to disable these things.
> > > Linux or whatever software consuming
> > > the hardware descriptions may want to distrust the absence of newly
> > > named feature extensions and do their own checks, but that's not QEMU's
> > > concern.
> >
> > Software should be able to trust that the DT describes the system
> > correctly. I can only speak for Linux here, but validating the DT is not
> > the job of the running kernel - it should be a correct description.
>
> AFAIK the DT is correct. We are describing the hardware within the
> scope of the DT spec.
>
> If a new node exists that describes what the hardware does not support
> we can update to support that as well.
It won't be a new node property, it'll just be negated properties - eg
riscv,isa-extensions = ..., "no-zicclsm";
That's what I mean when I say that these will not be able to be treated
in the same way as any other extension, but it only applies iff someone
wants to disable them. This isn't just a QEMU problem, but QEMU is the
bleeding edge of "hardware" support, so it's cropping up here first (or
maybe only :))
> > > Actually, being able to disable these newly named features allows
> > > Linux and other software to test how they behave when the feature goes
> > > away.
> >
> > That's helpful sure, but it doesn't absolve QEMU of having to correctly
> > generate a DT.
>
> I'm pretty sure there isn't anything for us to do differently here
> right? It's just a bad situation that we are trying to support.
Until someone wants to turn them off, you can avoid doing anything
differently, just like this amazing ascii art I found:
_,-\/-,_
\ /
\_.._/
_,/ \,_
/ \ / \
,\ ) ( /,
(__/ .''. \__)
\,_|| /
| ||\ |
| /|| \|
() || ()
// || ||
// || ||
// || ||
// || /\
-- '' -'-' ^^' )( '^^-- '' -'-' miK
(==)
`~`
Hopefully posting ostriches on the QEMU list isn't grounds for a ban,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-02-16 15:08 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-02 15:21 [PATCH v3 0/6] riscv: named features riscv,isa, 'svade' rework Daniel Henrique Barboza
2024-02-02 15:21 ` [PATCH v3 1/6] target/riscv/tcg: set 'mmu' with 'satp' in cpu_set_profile() Daniel Henrique Barboza
2024-02-02 15:21 ` [PATCH v3 2/6] target/riscv: add riscv,isa to named features Daniel Henrique Barboza
2024-02-02 15:21 ` [PATCH v3 3/6] target/riscv: add remaining " Daniel Henrique Barboza
2024-02-05 14:04 ` Andrew Jones
2024-02-15 4:20 ` Alistair Francis
2024-02-15 13:33 ` Conor Dooley
2024-02-15 14:13 ` Daniel Henrique Barboza
2024-02-15 14:39 ` Andrew Jones
2024-02-15 14:26 ` Andrew Jones
2024-02-15 16:34 ` Conor Dooley
2024-02-15 19:11 ` Andrew Jones
2024-02-15 19:59 ` Conor Dooley
2024-02-16 0:12 ` Alistair Francis
2024-02-16 15:08 ` Conor Dooley [this message]
2024-02-02 15:21 ` [PATCH v3 4/6] target/riscv: Reset henvcfg to zero Daniel Henrique Barboza
2024-02-15 5:38 ` Alistair Francis
2024-02-02 15:21 ` [PATCH v3 5/6] target/riscv: Gate hardware A/D PTE bit updating Daniel Henrique Barboza
2024-02-15 5:46 ` Alistair Francis
2024-02-02 15:21 ` [PATCH v3 6/6] target/riscv: Promote svade to a normal extension Daniel Henrique Barboza
2024-02-15 5:41 ` Alistair Francis
2024-02-15 9:52 ` [PATCH v3 0/6] riscv: named features riscv,isa, 'svade' rework Alistair Francis
2024-02-15 21:28 ` Daniel Henrique Barboza
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=20240216-fabulous-eraser-ffc4c2ed080f@spud \
--to=conor@kernel.org \
--cc=ajones@ventanamicro.com \
--cc=alistair.francis@wdc.com \
--cc=alistair23@gmail.com \
--cc=bmeng@tinylab.org \
--cc=dbarboza@ventanamicro.com \
--cc=liwei1518@gmail.com \
--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 read-only IMAP folder(s) and NNTP newsgroup(s).