Re: [PATCH v3 3/6] target/riscv: add remaining named features

[Conor Dooley]

> > 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.

signature.asc
Description: PGP signature