[Qemu-devel] [PATCH v1 00/27] Add RISC-V Hypervisor Extension

Alistair Francis posted 27 patches 4 years, 9 months ago
Failed in applying to current master (apply log)
hw/riscv/sifive_plic.c                        |  24 +-
include/hw/riscv/sifive_plic.h                |   3 -
target/riscv/cpu.c                            |  31 ++
target/riscv/cpu.h                            |  32 +-
target/riscv/cpu_bits.h                       |  32 +-
target/riscv/cpu_helper.c                     | 443 ++++++++++++++++--
target/riscv/csr.c                            | 216 ++++++++-
target/riscv/insn32.decode                    |  23 +-
.../riscv/insn_trans/trans_privileged.inc.c   |  40 ++
target/riscv/op_helper.c                      |  71 ++-
target/riscv/translate.c                      |  26 +
11 files changed, 839 insertions(+), 102 deletions(-)
[Qemu-devel] [PATCH v1 00/27] Add RISC-V Hypervisor Extension
Posted by Alistair Francis 4 years, 9 months ago
This patch series adds the RISC-V Hypervisor extension 0.3. This is the
latest draft spec of the Hypervisor extension.

The Hypervisor extension is disabled by default, so this series should
result in no changes to anyone using QEMU unless they enable the
extension. The extention can be enabled with the -cpu property (see
below).

At the moment the spec does not include information about the mstatush
register. As it is not in the spec I haven't added it to QEMU. This
means the extension won't work correctly for 32-bit guests. This should
be a small fix to add the CSR once the spec is updated.

All testing of this implementation has been done by using the baremetal
Xvisor Hypervisor. We are able to run two Linux guests (that's all I
have tried) as guests.

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?

Thanks to Anup for doing the initial port of Xvisor. The port is avaliable here:
https://github.com/avpatel/xvisor-next and will run on QEMU.

Also thanks to Atish for implementing the SBI call support in Xvisor and
for lots of help debugging.

To run this yourself:
 1. Apply this patch series to QEMU. The latest branch can be found here:
      https://github.com/alistair23/qemu/tree/mainline/alistair/riscv-hyp-work.next
 2. Get the version of OpenSBI that supports the H extension. This can
    be found here:
      https://github.com/riscv/opensbi/tree/hyp_ext_changes_v1
 3. Build the next release of Xvisor. It is available here:
      https://github.com/avpatel/xvisor-next
 4. Make sure you build the Xvisor tests, see here for details:
      https://github.com/avpatel/xvisor-next/tree/master/tests/riscv/virt64/linux
 5. Run QEMU:
     ./riscv64-softmmu/qemu-system-riscv64 -nographic \
       -machine virt -cpu rv64,h=true\
       -serial mon:stdio -serial null -m 4G \
       -device loader,file=vmm.bin,addr=0x80200000 \
       -kernel fw_jump.elf \
       -initrd vmm-disk-linux.img \
       -append "vmm.console=uart@10000000 vmm.bootcmd=\"vfs mount initrd /;vfs run /boot.xscript;vfs cat /system/banner.txt\""

   Once you get to the prompt you can start the geust by running:
     guest kick guest0
   You can then bind to the serial port using:
     vserial bind guest0/uart0
   Then you can start Linux using:
     autoexec

 This was all tested with the mainline 5.1 kernel. I don't know if it
 will work on older kernels.

So far all of the QEMU work has been tested on Xvisor.

Known Issues/TODO:
 - Add mstatush to support 32-bit Hypervisors
 - Fix the random hang that sometimes appears when running a Hypervisor guest (~5%)

There is also on going work from Anup to port KVM.
We have code complete implementation of RISC-V KVM kernel module and
RISC-V KVMTOOL. Currently, we are debugging KVM on QEMU and we will
send-out RFC PATCHES for KVM in June/July 2019.
The KVM RISC-V kernel module is available in riscv_kvm_v1
branch at: https://github.com/avpatel/linux.git
The KVMTOOL RISC-V port is available in riscv_v1 branch of
https://github.com/avpatel/kvmtool.git

There is very early work on a Xen port as well which is avaliable here:
https://github.com/alistair23/xen/tree/alistair/riscv-port

Changes from RFC:
 - Rebase on latest master
 - Add floating point changes from Hypervisor extension

Alistair Francis (27):
  target/riscv: Don't set write permissions on dirty PTEs
  target/riscv: Add the Hypervisor extension
  target/riscv: Add the virtulisation mode
  target/riscv: Add the force HS exception mode
  target/riscv: Add the Hypervisor CSRs to CPUState
  target/riscv: Dump Hypervisor registers if enabled
  target/riscv: Remove strict perm checking for CSR R/W
  target/riscv: Create function to test if FP is enabled
  target/riscv: Add support for background interrupt setting
  target/riscv: Add Hypervisor CSR access functions
  target/riscv: Add background CSRs accesses
  target/riscv: Add background register swapping function
  target/ricsv: Flush the TLB on virtulisation mode changes
  target/riscv: Generate illegal instruction on WFI when V=1
  riscv: plic: Remove unused interrupt functions
  riscv: plic: Always set sip.SEIP bit for HS
  target/riscv: Add hypvervisor trap support
  target/riscv: Add Hypervisor trap return support
  target/riscv: Add hfence instructions
  target/riscv: Disable guest FP support based on backgrond status
  target/riscv: Mark both sstatus and bsstatus as dirty
  target/riscv: Respect MPRV and SPRV for floating point ops
  target/riscv: Allow specifying MMU stage
  target/riscv: Allow specifying number of MMU stages
  target/riscv: Implement second stage MMU
  target/riscv: Call the second stage MMU in virtualisation mode
  target/riscv: Allow enabling the Hypervisor extension

 hw/riscv/sifive_plic.c                        |  24 +-
 include/hw/riscv/sifive_plic.h                |   3 -
 target/riscv/cpu.c                            |  31 ++
 target/riscv/cpu.h                            |  32 +-
 target/riscv/cpu_bits.h                       |  32 +-
 target/riscv/cpu_helper.c                     | 443 ++++++++++++++++--
 target/riscv/csr.c                            | 216 ++++++++-
 target/riscv/insn32.decode                    |  23 +-
 .../riscv/insn_trans/trans_privileged.inc.c   |  40 ++
 target/riscv/op_helper.c                      |  71 ++-
 target/riscv/translate.c                      |  26 +
 11 files changed, 839 insertions(+), 102 deletions(-)

-- 
2.21.0


Re: [Qemu-devel] [PATCH v1 00/27] Add RISC-V Hypervisor Extension
Posted by Chih-Min Chao 4 years, 8 months ago
On Sat, Jun 8, 2019 at 6:03 AM Alistair Francis <alistair.francis@wdc.com>
wrote:

> This patch series adds the RISC-V Hypervisor extension 0.3. This is the
> latest draft spec of the Hypervisor extension.
>
> The Hypervisor extension is disabled by default, so this series should
> result in no changes to anyone using QEMU unless they enable the
> extension. The extention can be enabled with the -cpu property (see
> below).
>
> At the moment the spec does not include information about the mstatush
> register. As it is not in the spec I haven't added it to QEMU. This
> means the extension won't work correctly for 32-bit guests. This should
> be a small fix to add the CSR once the spec is updated.
>
> All testing of this implementation has been done by using the baremetal
> Xvisor Hypervisor. We are able to run two Linux guests (that's all I
> have tried) as guests.
>
> 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?
>
> Thanks to Anup for doing the initial port of Xvisor. The port is avaliable
> here:
> https://github.com/avpatel/xvisor-next and will run on QEMU.
>
> Also thanks to Atish for implementing the SBI call support in Xvisor and
> for lots of help debugging.
>
> To run this yourself:
>  1. Apply this patch series to QEMU. The latest branch can be found here:
>
> https://github.com/alistair23/qemu/tree/mainline/alistair/riscv-hyp-work.next
>  2. Get the version of OpenSBI that supports the H extension. This can
>     be found here:
>       https://github.com/riscv/opensbi/tree/hyp_ext_changes_v1
>  3. Build the next release of Xvisor. It is available here:
>       https://github.com/avpatel/xvisor-next
>  4. Make sure you build the Xvisor tests, see here for details:
>
> https://github.com/avpatel/xvisor-next/tree/master/tests/riscv/virt64/linux
>  5. Run QEMU:
>      ./riscv64-softmmu/qemu-system-riscv64 -nographic \
>        -machine virt -cpu rv64,h=true\
>        -serial mon:stdio -serial null -m 4G \
>        -device loader,file=vmm.bin,addr=0x80200000 \
>        -kernel fw_jump.elf \
>        -initrd vmm-disk-linux.img \
>        -append "vmm.console=uart@10000000 vmm.bootcmd=\"vfs mount initrd
> /;vfs run /boot.xscript;vfs cat /system/banner.txt\""
>
>    Once you get to the prompt you can start the geust by running:
>      guest kick guest0
>    You can then bind to the serial port using:
>      vserial bind guest0/uart0
>    Then you can start Linux using:
>      autoexec
>
>  This was all tested with the mainline 5.1 kernel. I don't know if it
>  will work on older kernels.
>
> So far all of the QEMU work has been tested on Xvisor.
>
> Known Issues/TODO:
>  - Add mstatush to support 32-bit Hypervisors
>  - Fix the random hang that sometimes appears when running a Hypervisor
> guest (~5%)
>
> There is also on going work from Anup to port KVM.
> We have code complete implementation of RISC-V KVM kernel module and
> RISC-V KVMTOOL. Currently, we are debugging KVM on QEMU and we will
> send-out RFC PATCHES for KVM in June/July 2019.
> The KVM RISC-V kernel module is available in riscv_kvm_v1
> branch at: https://github.com/avpatel/linux.git
> The KVMTOOL RISC-V port is available in riscv_v1 branch of
> https://github.com/avpatel/kvmtool.git
>
> There is very early work on a Xen port as well which is avaliable here:
> https://github.com/alistair23/xen/tree/alistair/riscv-port
>
> Changes from RFC:
>  - Rebase on latest master
>  - Add floating point changes from Hypervisor extension
>
> Alistair Francis (27):
>   target/riscv: Don't set write permissions on dirty PTEs
>   target/riscv: Add the Hypervisor extension
>   target/riscv: Add the virtulisation mode
>   target/riscv: Add the force HS exception mode
>   target/riscv: Add the Hypervisor CSRs to CPUState
>   target/riscv: Dump Hypervisor registers if enabled
>   target/riscv: Remove strict perm checking for CSR R/W
>   target/riscv: Create function to test if FP is enabled
>   target/riscv: Add support for background interrupt setting
>   target/riscv: Add Hypervisor CSR access functions
>   target/riscv: Add background CSRs accesses
>   target/riscv: Add background register swapping function
>   target/ricsv: Flush the TLB on virtulisation mode changes
>   target/riscv: Generate illegal instruction on WFI when V=1
>   riscv: plic: Remove unused interrupt functions
>   riscv: plic: Always set sip.SEIP bit for HS
>   target/riscv: Add hypvervisor trap support
>   target/riscv: Add Hypervisor trap return support
>   target/riscv: Add hfence instructions
>   target/riscv: Disable guest FP support based on backgrond status
>   target/riscv: Mark both sstatus and bsstatus as dirty
>   target/riscv: Respect MPRV and SPRV for floating point ops
>   target/riscv: Allow specifying MMU stage
>   target/riscv: Allow specifying number of MMU stages
>   target/riscv: Implement second stage MMU
>   target/riscv: Call the second stage MMU in virtualisation mode
>   target/riscv: Allow enabling the Hypervisor extension
>
>  hw/riscv/sifive_plic.c                        |  24 +-
>  include/hw/riscv/sifive_plic.h                |   3 -
>  target/riscv/cpu.c                            |  31 ++
>  target/riscv/cpu.h                            |  32 +-
>  target/riscv/cpu_bits.h                       |  32 +-
>  target/riscv/cpu_helper.c                     | 443 ++++++++++++++++--
>  target/riscv/csr.c                            | 216 ++++++++-
>  target/riscv/insn32.decode                    |  23 +-
>  .../riscv/insn_trans/trans_privileged.inc.c   |  40 ++
>  target/riscv/op_helper.c                      |  71 ++-
>  target/riscv/translate.c                      |  26 +
>  11 files changed, 839 insertions(+), 102 deletions(-)
>
> --
> 2.21.0
>
>
  tested with Linux kernel v5.2 and related opensbi/xvisor branches
described above.

 Tested-by: Chih-Min Chao <chihmin.chao@sifive.com>
Re: [Qemu-devel] [PATCH v1 00/27] Add RISC-V Hypervisor Extension
Posted by Alistair Francis 4 years, 8 months ago
On Mon, Jul 15, 2019 at 4:50 AM Chih-Min Chao <chihmin.chao@sifive.com> wrote:
>
>
>
> On Sat, Jun 8, 2019 at 6:03 AM Alistair Francis <alistair.francis@wdc.com> wrote:
>>
>> This patch series adds the RISC-V Hypervisor extension 0.3. This is the
>> latest draft spec of the Hypervisor extension.
>>
>> The Hypervisor extension is disabled by default, so this series should
>> result in no changes to anyone using QEMU unless they enable the
>> extension. The extention can be enabled with the -cpu property (see
>> below).
>>
>> At the moment the spec does not include information about the mstatush
>> register. As it is not in the spec I haven't added it to QEMU. This
>> means the extension won't work correctly for 32-bit guests. This should
>> be a small fix to add the CSR once the spec is updated.
>>
>> All testing of this implementation has been done by using the baremetal
>> Xvisor Hypervisor. We are able to run two Linux guests (that's all I
>> have tried) as guests.
>>
>> 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?
>>
>> Thanks to Anup for doing the initial port of Xvisor. The port is avaliable here:
>> https://github.com/avpatel/xvisor-next and will run on QEMU.
>>
>> Also thanks to Atish for implementing the SBI call support in Xvisor and
>> for lots of help debugging.
>>
>> To run this yourself:
>>  1. Apply this patch series to QEMU. The latest branch can be found here:
>>       https://github.com/alistair23/qemu/tree/mainline/alistair/riscv-hyp-work.next
>>  2. Get the version of OpenSBI that supports the H extension. This can
>>     be found here:
>>       https://github.com/riscv/opensbi/tree/hyp_ext_changes_v1
>>  3. Build the next release of Xvisor. It is available here:
>>       https://github.com/avpatel/xvisor-next
>>  4. Make sure you build the Xvisor tests, see here for details:
>>       https://github.com/avpatel/xvisor-next/tree/master/tests/riscv/virt64/linux
>>  5. Run QEMU:
>>      ./riscv64-softmmu/qemu-system-riscv64 -nographic \
>>        -machine virt -cpu rv64,h=true\
>>        -serial mon:stdio -serial null -m 4G \
>>        -device loader,file=vmm.bin,addr=0x80200000 \
>>        -kernel fw_jump.elf \
>>        -initrd vmm-disk-linux.img \
>>        -append "vmm.console=uart@10000000 vmm.bootcmd=\"vfs mount initrd /;vfs run /boot.xscript;vfs cat /system/banner.txt\""
>>
>>    Once you get to the prompt you can start the geust by running:
>>      guest kick guest0
>>    You can then bind to the serial port using:
>>      vserial bind guest0/uart0
>>    Then you can start Linux using:
>>      autoexec
>>
>>  This was all tested with the mainline 5.1 kernel. I don't know if it
>>  will work on older kernels.
>>
>> So far all of the QEMU work has been tested on Xvisor.
>>
>> Known Issues/TODO:
>>  - Add mstatush to support 32-bit Hypervisors
>>  - Fix the random hang that sometimes appears when running a Hypervisor guest (~5%)
>>
>> There is also on going work from Anup to port KVM.
>> We have code complete implementation of RISC-V KVM kernel module and
>> RISC-V KVMTOOL. Currently, we are debugging KVM on QEMU and we will
>> send-out RFC PATCHES for KVM in June/July 2019.
>> The KVM RISC-V kernel module is available in riscv_kvm_v1
>> branch at: https://github.com/avpatel/linux.git
>> The KVMTOOL RISC-V port is available in riscv_v1 branch of
>> https://github.com/avpatel/kvmtool.git
>>
>> There is very early work on a Xen port as well which is avaliable here:
>> https://github.com/alistair23/xen/tree/alistair/riscv-port
>>
>> Changes from RFC:
>>  - Rebase on latest master
>>  - Add floating point changes from Hypervisor extension
>>
>> Alistair Francis (27):
>>   target/riscv: Don't set write permissions on dirty PTEs
>>   target/riscv: Add the Hypervisor extension
>>   target/riscv: Add the virtulisation mode
>>   target/riscv: Add the force HS exception mode
>>   target/riscv: Add the Hypervisor CSRs to CPUState
>>   target/riscv: Dump Hypervisor registers if enabled
>>   target/riscv: Remove strict perm checking for CSR R/W
>>   target/riscv: Create function to test if FP is enabled
>>   target/riscv: Add support for background interrupt setting
>>   target/riscv: Add Hypervisor CSR access functions
>>   target/riscv: Add background CSRs accesses
>>   target/riscv: Add background register swapping function
>>   target/ricsv: Flush the TLB on virtulisation mode changes
>>   target/riscv: Generate illegal instruction on WFI when V=1
>>   riscv: plic: Remove unused interrupt functions
>>   riscv: plic: Always set sip.SEIP bit for HS
>>   target/riscv: Add hypvervisor trap support
>>   target/riscv: Add Hypervisor trap return support
>>   target/riscv: Add hfence instructions
>>   target/riscv: Disable guest FP support based on backgrond status
>>   target/riscv: Mark both sstatus and bsstatus as dirty
>>   target/riscv: Respect MPRV and SPRV for floating point ops
>>   target/riscv: Allow specifying MMU stage
>>   target/riscv: Allow specifying number of MMU stages
>>   target/riscv: Implement second stage MMU
>>   target/riscv: Call the second stage MMU in virtualisation mode
>>   target/riscv: Allow enabling the Hypervisor extension
>>
>>  hw/riscv/sifive_plic.c                        |  24 +-
>>  include/hw/riscv/sifive_plic.h                |   3 -
>>  target/riscv/cpu.c                            |  31 ++
>>  target/riscv/cpu.h                            |  32 +-
>>  target/riscv/cpu_bits.h                       |  32 +-
>>  target/riscv/cpu_helper.c                     | 443 ++++++++++++++++--
>>  target/riscv/csr.c                            | 216 ++++++++-
>>  target/riscv/insn32.decode                    |  23 +-
>>  .../riscv/insn_trans/trans_privileged.inc.c   |  40 ++
>>  target/riscv/op_helper.c                      |  71 ++-
>>  target/riscv/translate.c                      |  26 +
>>  11 files changed, 839 insertions(+), 102 deletions(-)
>>
>> --
>> 2.21.0
>>
>
>   tested with Linux kernel v5.2 and related opensbi/xvisor branches described above.
>
>  Tested-by: Chih-Min Chao <chihmin.chao@sifive.com>

Thanks for testing!!!

Unfortunately I don't think this is going to be merged. It is too late
to have this in the 4.1 release and I'm about to start working on
upgrading this to the v0.4 Hypervisor spec. So hopefully we can have
that in 4.2.

Alistair

>

Re: [Qemu-devel] [PATCH v1 00/27] Add RISC-V Hypervisor Extension
Posted by Peter Maydell 4 years, 8 months ago
On Fri, 7 Jun 2019 at 23:03, Alistair Francis <alistair.francis@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

Re: [Qemu-devel] [PATCH v1 00/27] Add RISC-V Hypervisor Extension
Posted by Alistair Francis 4 years, 8 months ago
On Mon, Jul 15, 2019 at 5:00 AM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Fri, 7 Jun 2019 at 23:03, Alistair Francis <alistair.francis@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

Re: [Qemu-devel] [PATCH v1 00/27] Add RISC-V Hypervisor Extension
Posted by Chih-Min Chao 4 years, 8 months ago
On Wed, Jul 17, 2019 at 8:17 AM Alistair Francis <alistair23@gmail.com>
wrote:

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


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