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.
Cheers,
Daniel
Thanks,
drew
