On Wed, Jul 17, 2019 at 8:17 AM Alistair Francis <
address@hidden> wrote:
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.
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
Hi Peter,
I agree that unfrozen extension should't be merged into master but I think the patch set is more like RFC version.
Some part of the patches have been merged in into master and will be available in 4.1. So my intention is to be
familiar with present h-extension by reviewing the Alistair's great work and help the work when new patch set are ready
for 4.2 cycle.
chihmin.chao