Re: [PATCH v2 00/35] Add RISC-V Hypervisor Extension v0.5

[Alistair Francis]

On Mon, Feb 10, 2020 at 10:50 AM Palmer Dabbelt
<address@hidden> wrote:
>
> On Fri, 31 Jan 2020 17:01:35 PST (-0800), Alistair Francis wrote:
> > This patch series adds the RISC-V Hypervisor extension v0.5. 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).
> >
> > 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 in 64-bit. In 32-bit so far I can only run
> > baremetal guests, but I think this is a baremetal boot loader issue and
> > not an issue in QEMU.
> >
> > The RISC-V KVM implementation was also written using these patches. The
> > KVM implementation is currently under review.
> >
> > 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.
> >
> > 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-ext-v0.5.next
> >  2. Get the version of OpenSBI that supports the H extension. This can
> >     be found here:
> >       https://github.com/avpatel/opensbi/tree/riscv_hyp_ext_0_5_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,x-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.2/5.3 kernels.
> >
> > There is very early work on a Xen port as well which is avaliable here:
> > https://github.com/alistair23/xen/tree/alistair/riscv-port
> >
> > ToDo/Issues
> >  - Get 32-bit fully working
> >
> > v2:
> >  - Don't use riscv_cpu_set_force_hs_excep() for 2nd stage MMU fauls as
> >    the v0.5 spec has a specific fault
> >  - Address review comments
> >  - Rebase on master
> >  - Remove pointers for mstatus
> >
> > Alistair Francis (35):
> >   target/riscv: Convert MIP CSR to target_ulong
> >   target/riscv: Add the Hypervisor extension
> >   target/riscv: Add the Hypervisor CSRs to CPUState
> >   target/riscv: Add support for the new execption numbers
> >   target/riscv: Rename the H irqs to VS irqs
> >   target/riscv: Add the virtulisation mode
> >   target/riscv: Add the force HS exception mode
> >   target/riscv: Fix CSR perm checking for HS mode
> >   target/riscv: Print priv and virt in disas log
> >   target/riscv: Dump Hypervisor registers if enabled
> >   target/riscv: Add Hypervisor CSR access functions
> >   target/riscv: Add Hypervisor virtual CSRs accesses
> >   target/riscv: Add Hypervisor machine CSRs accesses
> >   target/riscv: Add virtual register swapping function
> >   target/riscv: Set VS bits in mideleg for Hyp extension
> >   target/riscv: Extend the MIE CSR to support virtulisation
> >   target/riscv: Extend the SIP CSR to support virtulisation
> >   target/riscv: Add support for virtual interrupt setting
> >   target/ricsv: Flush the TLB on virtulisation mode changes
> >   target/riscv: Generate illegal instruction on WFI when V=1
> >   target/riscv: Add hypvervisor trap support
> >   target/riscv: Add Hypervisor trap return support
> >   target/riscv: Add hfence instructions
> >   target/riscv: Remove the hret instruction
> >   target/riscv: Only set TB flags with FP status if enabled
> >   target/riscv: Disable guest FP support based on virtual status
> >   target/riscv: Mark both sstatus and msstatus_hs as dirty
> >   target/riscv: Respect MPRV and SPRV for floating point ops
> >   target/riscv: Allow specifying MMU stage
> >   target/riscv: Implement second stage MMU
> >   target/riscv: Raise the new execptions when 2nd stage translation
> >     fails
> >   target/riscv: Set htval and mtval2 on execptions
> >   target/riscv: Add support for the 32-bit MSTATUSH CSR
> >   target/riscv: Add the MSTATUS_MPV_ISSET helper macro
> >   target/riscv: Allow enabling the Hypervisor extension
> >
> >  target/riscv/cpu.c                            |  57 ++-
> >  target/riscv/cpu.h                            |  58 ++-
> >  target/riscv/cpu_bits.h                       | 111 ++--
> >  target/riscv/cpu_helper.c                     | 481 ++++++++++++++++--
> >  target/riscv/csr.c                            | 369 +++++++++++++-
> >  target/riscv/gdbstub.c                        |  11 +-
> >  target/riscv/insn32.decode                    |  22 +-
> >  .../riscv/insn_trans/trans_privileged.inc.c   |  45 +-
> >  target/riscv/op_helper.c                      |  71 ++-
> >  target/riscv/translate.c                      |  34 ++
> >  10 files changed, 1130 insertions(+), 129 deletions(-)
>
> Thanks.  I'm going to send out the current queue, just to make sure it doesn't
> get blocked, and then dig through all this.  It should be essentially ready to
> go, IIRC there were just a few patches that changed enough to warrant a 
> review.

Sounds good.

This series should be pretty straight forward to review. It's very
similar to the previous one.

Alistair