On Tue, Nov 18, 2025 at 05:15:54PM -0300, Daniel Henrique Barboza wrote: > > > On 11/11/25 8:36 PM, Andrew Jones wrote: > > On Tue, Nov 11, 2025 at 03:29:42PM -0300, Daniel Henrique Barboza wrote: > > > From: Fei Wu <[email protected]> > > ... > > > +static char *rvsp_ref_get_aia_guests(Object *obj, Error **errp) > > > +{ > > > + RVSPMachineState *s = RVSP_REF_MACHINE(obj); > > > + char val[32]; > > > + > > > + sprintf(val, "%d", s->aia_guests); > > > + return g_strdup(val); > > > +} > > > + > > > +static void rvsp_ref_set_aia_guests(Object *obj, const char *val, Error > > > **errp) > > > +{ > > > + RVSPMachineState *s = RVSP_REF_MACHINE(obj); > > > + > > > + s->aia_guests = atoi(val); > > > + if (s->aia_guests < 0 || s->aia_guests > RVSP_IRQCHIP_MAX_GUESTS) { > > > > The minimum is 5 for the server platform, so we should enforce that. Also > > I suggest we bump RVSP_IRQCHIP_MAX_GUESTS since it's only 7 right now. > > > > > + error_setg(errp, "Invalid number of AIA IMSIC guests"); > > > + error_append_hint(errp, "Valid values be between 0 and %d.\n", > > > + RVSP_IRQCHIP_MAX_GUESTS); > > > + } > > > +} > > > + > > > +static void rvsp_ref_machine_class_init(ObjectClass *oc, const void > > > *data) > > > +{ > > > + char str[128]; > > > + MachineClass *mc = MACHINE_CLASS(oc); > > > + static const char * const valid_cpu_types[] = { > > > + TYPE_RISCV_CPU_RVSP_REF, > > > + }; > > > + > > > + mc->desc = "RISC-V Server SoC Reference board (EXPERIMENTAL)"; > > > > We could (and probably should) version this machine type from the get go. > > If we do that, then we could simply give it a version 0.9, which would > > match the current spec. When the spec is ratified and this model is > > complete, then it can be bumped to 1.0. Going that route would allow us > > to avoid the EXPERIMENTAL "flag". > > There has been some discussions offline on this and I'll bring them here. > > A minor point: it was suggested to rename the board to 'rvserver' instead > of 'rvsp-ref'. I like this idea mostly because I keep misspelling rvsp-ref > as rsvp-ref.
I do like the '-ref' suffix though. > > As for the "version this machine type": in this case is different with what > we do > with other QEMU machines. They have a new version for every QEMU release, e.g. > ARM's newest virt board is virt-10.2, in the next QEMU release it will be > virt-11.0 > and so on. We wouldn't do the same thing here - 'versioning' in this case is > name > the board in a way that makes reference to the spec it implements. So this > current > emulation would be named 'rvsp-ref-0.9', with an alias 'rvsp-ref' pointing to > it. > > Changing the emulation to comply with spec version 1.0 will create a > rvsp-ref-1.0 > board while keeping rvsp-ref-0.9 as is. Usually QEMU does that by using > compat flags > that changes the behavior of the board, and we'll probably go this route. Yes, as long as we point out what the version numbers mean somewhere, e.g. in the machine description, then I guess people will get it. I'm not sure I want a 0.9 board to live on after a ratified 1.0 is released, though. So maybe an 'experimental' board makes more sense if we need to call it that in order to reserve the right to delete it. > > One thing worth considering is that we can't just version stamp the board, we > need to > do the same with the CPU. So we would have a rvsp-ref-cpu-0.9, > rvsp-ref-cpu-1.0 and > an alias to point to the newest available emulation. ack > > Also note that we're not 0.9 compliant either since we're missing sdext. So > unless > we're willing to name this current board as rvsp-ref-0.9-beta or something > like that, > maybe it's a good idea to postpone this work until we have 'sdext' > implemented. Yes, let's prioritize sdext so we can match the current spec (which is unlikely to change much before ratification) before we merge the reference board at all. Thanks, drew
