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 * 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
