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