[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
Re: [Qemu-riscv] [Qemu-devel] [PATCH v1 00/27] Add RISC-V Hypervisor Extension
Tue, 16 Jul 2019 17:14:19 -0700
On Mon, Jul 15, 2019 at 5:00 AM Peter Maydell <address@hidden> wrote:
> 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
Yep, these are off by default.
> * 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
Sounds good, I'll rename the property in the next version.
> 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.
> -- PMM