On 5/8/2026 2:31 PM, Andrew Jones wrote:
On Fri, May 08, 2026 at 01:59:51PM -0300, Daniel Henrique Barboza wrote:
On 5/7/2026 4:23 PM, Andrew Jones wrote:
On Fri, May 01, 2026 at 01:27:41PM +1000, Alistair Francis wrote:
...
[1] https://github.com/riscv-non-isa/riscv-server-platform
The first line of the README says:
"""
This document is capturing discussions at the Server Platform TG.
These are not official specifications and everything in this document
may change.
"""
The README should have said frozen instead of "everything may change".
It was my fault for not having updated it. I have updated it now, though,
but not to frozen, because v1.0 is now ratified.
So this machine needs to start out with version support (like the ARM
virt board)
I'm happy to follow ARM's reference board's lead on this, at least for
now. I only wonder if we may not want to use the QEMU machine versioning
support to bind machine model versions to ratified and experimental
platform specifications at some point. For example,
rv-server-ref -- new, bleeding edge platform implementation which
may include experimental bits
rv-server-ref-v1.0 -- versioning ensures the implementation matches v1.0
of the spec
rv-server-ref-v2.0 -- versioning ensures the implementation matches v2.0
of the spec - likely backward compatible with v1.0,
but not necessarily
I'm not sure if [ab]using the QEMU machine versioning support in this way
would cause confusion or other problems though.
IMO we shouldn't use the QEMU machine versioning in this case. We can
instantiate a new board in the same server_platform_ref.c file that has a
different init(), memmaps and etc that would reflect the new spec. We can
do that once every time a new major spec version is created (so ... once
every 2+ years?) instead of having to cope with the all the compat_props
machinery from the regular QEMU versioning design every single QEMU
release.
Sounds good to me. And the rv-server-ref cpu models can do the same. We'll
need to get the version number into the name, which means this series
should name the board and cpu models something like rv-server-1-0-ref or
whatever works best. I'm not sure if we just want to do this for major
numbers, e.g. rv-server-v1-ref, it seems like someone may want to target
a minor release.
Hmm, how about yet another idea. The name stays rv-server-ref, but then we
have properties for each spec major.minor that get ratified. So, for
starters, -machine rv-server-ref,spec_1_0=on and eventually we can also
have -machine rv-server-ref,spec_1_1=on and
-machine rv-server-ref,spec_2_0=on. Without providing a property it would
default to the latest ratified spec version.
Seems good to me too. For now let's leave the code as is since we're
supporting just 1.0 and add the required boilerplate for these properties
when we change the board to support a newer version.
Cheers,
Daniel
Thanks,
drew
