qemu-riscv
[Top][All Lists]
Advanced

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

Re: [Qemu-riscv] [Qemu-devel] [PATCH v1 00/27] Add RISC-V Hypervisor Ext


From: Peter Maydell
Subject: Re: [Qemu-riscv] [Qemu-devel] [PATCH v1 00/27] Add RISC-V Hypervisor Extension
Date: Mon, 15 Jul 2019 12:59:57 +0100

On Fri, 7 Jun 2019 at 23:03, Alistair Francis <address@hidden> wrote:
> At the moment this spec is in a draft state and is subject to change. As
> QEMU is extreamly useful in early bring up I think it makes sense for
> QEMU to support non-frozen extensions. I would like to decide with this
> series how QEMU will handle all future non-frozen extensions. That is a
> standard way that QEMU users can test future RISC-V extensions while
> still understanding things will change. One idea is just to disable it by
> default, another option is to maybe use the Kconfig to make it a compile
> time option which developers can use. Should we also display a warning
> when running non-frozen extensions?

We had an instance of this for Arm (though in fact the
relevant patches to QEMU didn't end up getting into master
before the spec was finalized in the end). My suggestion
would be at minimum:
 * by default non-frozen extensions should not be provided
 * they should be enabled via a command line option (cpu
   property) whose name starts with "x-", which is our standard
   way of flagging properties that are experimental and subject
   to change or removal in future QEMU versions

That way end-users know they're doing something non-standard
that won't necessarily be supported in future by newer versions
of QEMU, and if people copy recipes/commandlines/random guest
images off old blog posts there'll be a hint that there's a
reason why they don't work on newer QEMU that adheres to the
final spec.

thanks
-- PMM



reply via email to

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