qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael Clark
Subject: Re: [Qemu-devel] [patches] Re: [PULL] RISC-V QEMU Port Submission
Date: Thu, 1 Mar 2018 09:40:10 +1300

On Thu, Mar 1, 2018 at 12:53 AM, Peter Maydell <address@hidden>
wrote:

> On 28 February 2018 at 00:09, Michael Clark <address@hidden> wrote:
> > I've just talked to SiFive about this. They have agreed that we can
> remove
> > the sifive_e300 and sifive_u500 boards from the patch series that we are
> > going to submit upstream again later this week or early next week. These
> > machines and their devices are pretty easy for us to maintain in the
> riscv
> > or a sifive repo. This trims the number of machines from 5 to 3 and lets
> us
> > remove the SiFiveUART and SiFivePRCI from the next patch series we are
> > going to submit. e.g. v8
>
> Models of boards which people actively want and are using are fine
> (though indeed you can save them for a later round of patches if you
> like). And it sounds like the 1.9.1 stuff is genuinely wanted, so
> thanks for the clarification there. What I want to avoid is boards
> going into QEMU just because you happened to have them already. Once
> a board model goes into QEMU it's a commitment to supporting it for
> the long term, and getting rid of it again is hard.


Most folk in the community at large are interested in the 'spike' and
'virt' machines. Well, the linux distributors are currently targetting
'virt' as it has working network and block storage.

It's mostly SiFive customers that are interested in the SiFive machines.

SiFive do intend to submit their machines upstream however we've decided
that we want to review the naming of the machine/board/SOC in light of
several new models, as there are infact more MCU/SOC models than are
currently represented in the RISC-V QEMU port (E21, E31, E51, U54, U54MC).
Those are the SOCs and then there are boards like the HiFive1, the LoFive,
the HiFive Unleashed and several others (the 7th RISC-V Foundation Workshop
had an electronic badge with the FE310 designed by antmicro). SiFive might
like to review the naming and re-jig the SOC / board relationship.
Presently we created two generic boards to represent the MMU-less E-series
(sifive_e300) and the U-series (sifive_u500) however that doesn't cover the
E21 and E51. As well as silicon, there are soft-cores, including soft-cores
from other vendors (who have not yet submitted anything to the QEMU port).
After reflecting on this we don't think the naming of the two sifive
machines is quite right and they are not yet complete emulations. The
sifive_u500
is supposed to model the HiFive Unleashed however we don't have device
emulation for all of the hardware widgets yet, and some of the drivers are
not yet in upstream Linux. Linus essentially accepted the generic core,
which is what we are now suggesting for QEMU. We are totally happy to
submit them if folk don't mind us potentially renaming them later. This is
2 patches for 2 machines and 2 or 3 devices. It would reduce the patch
series from 23 patches to 18 patches and we'd maintain the 5 files and
associated headers out-of tree until things firm up. The core of the port
is pretty solid as Fedora have build stage 4 images using SMP on the 'virt'
machine.


> > However I'm inclined to leave it as it is, at this point. It is not
> > something that we can't change in the future once the code is in-tree.
>
> With my 'upstream dev' hat on, I tend to be suspicious of this
> line of argument, because in a lot of cases what tends to happen
> is that the code for some new target or device goes in-tree, and
> then the people who worked on submitting it disappear, or never
> actually do get round to refactoring[*]. You get more leeway for
> making this argument the longer you've been around and participating
> in QEMU development, because then you have a track record of
> following up on things.
>
> [*] in fact we're currently discussing deleting support for
> a couple of target architectures that were basically "once the
> code went into mainline nothing further was ever done to it except
> global-refactorings and other tree wide maintenance by other
> QEMU developers".


I might explore coalescing the two spike boards before the v8 spin then.

I was thinking about using a global to enable the backwards compatibility
mode. It seems -global is for driver properties? Is it appropriate to use a
global property to change the behaviour of a machine?

Okay, I see raspi.c contains raspi, raspi 2, raspi 3, and it just defines
multiple machines in the same file and passes a version number to routines
that are shared. We could go with that approach.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]