On Fri, May 24, 2019 at 4:47 PM 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.
Argh! I forgot to CC Atish and Anup, they are CCed now.
Just an FYI I will be on vacation next week, so any replys to this
series might be a little delayed.
Alistair
>
> This series applies ontop of the RISC-V tree as it requires the previous
> Hypervisor extension patches as well as the CPU parsing patches, both of
> which have been accepted to the RISC-V tree. The full Hypervisor support
> is avaliable at my GitHub (see below) which includes all required patches.
> This series won't apply ontop of master.
>
> 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 extenstion. This can
> be found here:
> https://github.com/riscv/opensbi/tree/hyp_ext_changes_v1
> 3. Build the next release of Xvisor. It is avaliable 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
> - Add support for bsstatus.FS and sstatus.FS from the Hypervisor spec
> - Fix the random hang that sometimes appears when running a Hypervisor guest
>
> 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
>
> Alistair Francis (23):
> 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: 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: 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 | 26 ++
> target/riscv/cpu_bits.h | 32 +-
> target/riscv/cpu_helper.c | 430 ++++++++++++++++--
> target/riscv/csr.c | 194 +++++++-
> target/riscv/insn32.decode | 23 +-
> .../riscv/insn_trans/trans_privileged.inc.c | 40 ++
> target/riscv/op_helper.c | 71 ++-
> 10 files changed, 782 insertions(+), 92 deletions(-)
>
> --
> 2.21.0
>