On 2019/8/22 上午3:31, Palmer Dabbelt wrote:
On Thu, 15 Aug 2019 14:37:52 PDT (-0700), alistai...@gmail.com wrote:
On Thu, Aug 15, 2019 at 2:07 AM Peter Maydell
<peter.mayd...@linaro.org> wrote:
On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic
<aleksandar.m.m...@gmail.com> wrote:
>
> > We can accept draft
> > extensions in QEMU as long as they are disabled by default.
> Hi, Alistair, Palmer,
>
> Is this an official stance of QEMU community, or perhaps Alistair's
> personal judgement, or maybe a rule within risv subcomunity?
Alistair asked on a previous thread; my view was:
https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg03364.html
and nobody else spoke up disagreeing (summary: should at least be
disabled-by-default and only enabled by setting an explicit
property whose name should start with the 'x-' prefix).
Agreed!
In general QEMU does sometimes introduce experimental extensions
(we've had them in the block layer, for example) and so the 'x-'
property to enable them is a reasonably established convention.
I think it's a reasonable compromise to allow this sort of work
to start and not have to live out-of-tree for a long time, without
confusing users or getting into a situation where some QEMU
versions behave differently or to obsolete drafts of a spec
without it being clear from the command line that experimental
extensions are being enabled.
There is also an element of "submaintainer judgement" to be applied
here -- upstream is probably not the place for a draft extension
to be implemented if it is:
* still fast moving or subject to major changes of design direction
* major changes to the codebase (especially if it requires
changes to core code) that might later need to be redone
entirely differently
* still experimental
Yep, agreed. For RISC-V I think this would extend to only allowing
extensions that have backing from the foundation and are under active
discussion.
My general philosophy here is that we'll take anything written down in
an official RISC-V ISA manual (ie, the ones actually released by the
foundation). This provides a single source of truth for what an
extension name / version means, which is important to avoid
confusion. If it's a ratified extension then I see no reason not to
support it on my end. For frozen extensions we should probably just
wait the 45 days until they go up for a ratification vote, but I'd be
happy to start reviewing patches then (or earlier :)).
If the spec is a draft in the ISA manual then we need to worry about
the support burden, which I don't have a fixed criteria for --
generally there shouldn't be issues here, but early drafts can be in a
state where they're going to change extensively and are unlikely to be
used by anyone. There's also the question of "what is an official
release of a draft specification?".
That's a bit awkward right now: the current ratified ISA manual
contains version 0.3 of the hypervisor extension, but I just talked to
Andrew and the plan is to remove the draft extensions from the
ratified manuals because these drafts are old and the official manuals
update slowly. For now I guess we'll need an an-hoc way of
determining if a draft extension has been officially versioned or not,
which is a bit of a headache.
We already have examples of supporting draft extensions, including
priv-1.9.1. This does cause some pain for us on the QEMU side (CSR
bits have different semantics between the specs), but there's 1.9.1
hardware out there and the port continues to be useful so I'd be in
favor of keeping it around for now. I suppose there is an implicit
risk that draft extensions will be deprecated, but the "x-" prefix,
draft status, and long deprecation period should be sufficient to
inform users of the risk. I wouldn't be opposed to adding a "this is
a draft ISA" warning, but I feel like it might be a bit overkill.
Hi, Palmer
Maybe it is the headache of open source hardware. Everyone cooperates to
build a better architecture.
In my opinion, we should focus on the future. The code in QEMU mainline
should evolve to the ratified extension step by step, and only support
the best extension at last.
At that time, even many hardwares just support the deprecated draft
extension, the draft codes should be in the wild and maintained by the
hardware manufactures.
But before that, it is better to have a draft implementation. So that
We can work step by step to accelerate the coming of the ratified
extension.
Even at last draft extension implementation are deprecated, they are not
meaningless. The manufactures may use the history commit to support
their hardwares that
only support drafted extension.
Best Regards,
Zhiwei
Alistair
thanks
-- PMM
