Re: [Qemu-devel] [patches] Re: [PULL] RISC-V QEMU Port Submission

[Peter Maydell]

On 27 February 2018 at 15:50, Stef O'Rear <address@hidden> wrote:
> On Tue, Feb 27, 2018 at 6:01 AM, Peter Maydell <address@hidden> wrote:
>> On 27 February 2018 at 00:15, Michael Clark <address@hidden> 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