On 27 February 2018 at 15:50, Stef O'Rear <sore...@gmail.com> wrote: > On Tue, Feb 27, 2018 at 6:01 AM, Peter Maydell <peter.mayd...@linaro.org> > wrote: >> On 27 February 2018 at 00:15, Michael Clark <m...@sifive.com> wrote: >>> The spike_v1.9 >>> machine has been renamed to spike_v1.9.1 to match the privileged ISA >>> version and spike_v1.10 has been made the default machine. >> >> I'm confused about this. Generally QEMU boards should model >> hardware, and the board shouldn't care about the ISA versions. > > The spike boards model the Berkeley architectural simulator "spike" > (https://github.com/riscv/riscv-isa-sim), which does not have a formal > release process or version numbers so we are using the ISA version as > a proxy for spike's version. > > When physical boards are released with full documentation I presume we > will be adding board definitions for them, and they will imply > specific ISA versions. > >> Versioned board names in QEMU generally follow _QEMU_'s versioning, >> and indicate that a board is identical to whatever we modelled >> in that earlier QEMU version, for VM migration compatibility. > > In this case we're handling two logically distinct boards. We could > combine them and implement a parameter; I was having trouble finding a > suitable example to follow earlier but it looks like gic-version in > hw/arm/virt.c is one. This seems like a bad thing to change this late > in the review though?
You don't need to make them one board with a command line option if that doesn't suit -- for instance hw/arm/vexpress.c defines multiple board models that are variants on each other and share a lot of code. That said, see below... >> Board renames for minor ISA version bumps sounds like there's going >> to be a lot of churn and breakage -- is this stuff really ready? >> (Also, should we really have two different board source files >> for two different ISA versions? I would have expected these to >> share a source file to share code.) > > 1.10 is the version we have committed to long term support for; it > matches all public hardware the upstream Linux port, so it seems > appropriate to use for QEMU. > > 1.9.1 was the version supported by riscv-qemu at the time Michael > Clark took over maintainership; we have not removed support for it > because we cannot prove that there is nobody depending on it, although > I do not use it myself and do not know anyone else who does, so I > would not personably object to removing it if that were required. I would rather not have stray legacy old versions in QEMU just because we think maybe somebody might be using them. If 1.10 is the long-term-support committed version, then I think we should just have a model of that. Anybody who for some reason is still stuck on an older unsupported version gets to find out what "unsupported" means; they can always keep using whatever old QEMU code base they've been using up til now, presumably. thanks -- PMM