[Top][All Lists]

[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: Chih-Min Chao
Subject: Re: [Qemu-riscv] [Qemu-devel] [PATCH v1 00/27] Add RISC-V Hypervisor Extension
Date: Wed, 17 Jul 2019 11:55:39 +0800

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.


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


reply via email to

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