[GSOC] bhyve port on ARM - weekly status report

Mihai Carabas mihai.carabas at gmail.com
Mon Jul 13 20:34:35 UTC 2015

Hi everyone,

>> In the last week I've started writing low-level ASM code which is
> saving/restoring the guest/host state. I've created a logic for a full
> pass from the host to the guest and back [1]:
> - when the host is calling the "HYP" instruction, causes a trap in
> hyp-mode where it can run different functions specific to this mode. An
> example is hyp_enter_guest function which saves the host state, loads the
> guest state and jumps to the guest pc with an eret instruction (back to svc
> mode basically)
> - when the guest executes an instruction that causes a trap (e.g. wfi
> which was configured by us) the code is saving the guest state, loading the
> host state and than is returning to host svc-mode with the exception of the
> guest to manage it
> - I've also implemented a call to panic function in host if the abort
> exceptions in hyp-mode are raised.
> There are still some configuration registers that need to be tackled (like
> VCTBR - defines the guest configuration for the stage 2 address
> translation).
> In the next week I have to write the C code which is calling the ASM
> methods in arm_vmrun and the init code which allocates the context
> structure (arm_vminit) and maps it in HYP-Mode. I will try to integrate
> these operations with bhyve userspace tools to ease the development.
> 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).


More information about the soc-status mailing list