On Mon, Jul 15, 2019 at 5:00 AM Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Fri, 7 Jun 2019 at 23:03, Alistair Francis <alistair.fran...@wdc.com> > 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. Alistair > > 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
