[GSOC] bhyve port on ARM - weekly status report

[Mihai Carabas]

Hi everyone,

In the last week I've written the glue C code which is calling the ASM
> methods to run a VM. The logic flow starts from userspace from bhyvearm
> program (it's a duplicate of the normal bhyve due to its high dependency of
> x86) using ioctl's to run the VM.
>
> I've also written a simplified bhyveloadarm which maps the desired memory
> from the GPA indicated as a parameter (here I had to write the entire flow
> from userspace to kernel because there were empty functions - the MMAP
> ioctl). Than it loads the raw kernel image in the memory at a given
> address. In the end I set up the PC using also an ioctl.
>
> I've created a new ramdisk containing the bhyvearm* programs and the
> dynamic libraries they depend on. Then I've managed to make bhyveloadarm
> to copy a file which contains the bytecode for the "wfi" instruction in the
> guest memory and now I'm playing with bhyvearm to make the "guest" run that
> instruction. I'm investigating a bug in restoring the host state after the
> VM has run (the VM throws a data abort exception because I haven't
> configured the VTCR yet and I'm trying to send this exception back in
> bhyvearm userspace).
>
> Last week I fulfilled an important step: I've managed to execute an
instruction in the VirtualMachine and returning back with the HYP expection
caused by executing a "wfi" instruction (which is disabled by
configuration). Than I've added two more operations: mov r0,1 and add r4,
r0 , 4 and both are executing OK (tested even step-by-step in the debugger).

Further, I've read the exception status registers (HSR, HIFAR, HDFAR,
HPFAR) in hyp-mode just before returning to the host. I've read them all
even some of them are in state unknown depending on the exception type. I
will let the C code to verify this.

I also had a design issue and I had to read these registers in "struct
hypctx"  first and when returning in the host, copy them back to the
"vm_exit" structure which was stored in "struct vm" (which isn't mapped in
HYP-mode and even if I map it, I have to do a lot of index calculation to
place the values in the right place - so I've decided to duplicate the
info). So right now, when executing the WFI instruction, it causes a HYP
exception which sets VM_EXITCODE_HYP which will determine the userspace
utility to exit.

An issue that need to be tackled is the reset state of the coprocessor
registers. I need to take them one-by-one and set this reset state probably
using some state-table approach (like KVM is doing).

Thank you,
Mihai