KVM/hypervisor support?


#1

Will the HiKey board (eventually) be able to run KVM or other hypervisors? I’ve read about bootloader issues precluding this on other hardware.

Thanks,
Arun


#2

All best are off. So far, the so called bootloader actively prevents KVM or Xen to be used, as it enters the kernel at EL1-NS instead of EL2 (which is the recommended way to enter Linux).

It also lacks any form of init of CNTFRQ_EL1, which will completely panic VMs unless you perform some horrible hacking.

I’m currently working on binary patching the firmware to allow KVM to run, but need to verify this approach actually works before publishing anything.

Cheers,

Marc.


#3

Bummer, thanks for wrestling with the firmware. I assume the forthcoming Enterprise board will come with hypervisor-friendly firmware?

Arun


#4

Your bet is as good as mine, and I’m not holding my breath.

Marc.


#5

There’s a pretty good chance the upcoming rewritten (UEFI compliant) bootloader for the HiKey board is going to fix it even for the first board.

I don’t have any details about the Enterprise board(s) yet, but it would be somewhat odd to release an Enterprise board without proper hypervisor support.


#6

Well, I’d say that it’s already quite odd that the first shipping implementation is not even compliant with the very basic booting convention for the Linux kernel and requires hacks to be sprinkled over’s the DT just to be able to boot.

The hypervisor issue is just icing on the cake.

Thinking that enterprise is different is a gross misconception. We have one architecture, one way to boot a system, and any deviation from that just fragments the ecosystem and sends the exact wrong message to the community.

M.


#7

Just for my education, is Documentation/arm64/booting.txt the best description of the Linux/arm64 booting convention? And also the ARM Server Base Boot Requirements doc?


#8

The booting.txt document describes how the Linux kernel should be entered (the bare minimum you have to do before jumping to the kernel).

SBBR describes the interactions of UEFI and ACPI with a given operating system, not necessarily Linux, and is largely out of the scope of the HiKey board (which is far from being SBSA compliant anyway).

Just having the firmware to follow booting.txt to the letter would be a huge improvement…

M.


#9

Maz:

Do you have any update on the hypervisor since UEFI bootloader with source code has been available form sometime. Is it possible now to start hypervisor development on Hikey?

Thanks
Joey


#10

Your timing is impeccable.

After fighting fastboot, a broken mmc driver, an overheating board and my left leg in a cast, I have mainline (plus about 40 hikey patches) running on the board today (I’ve pushed out a branch).

And yes, KVM just works.

M.


#11

Hi. Great work Marc!

I just wanted to clarify which branch the hikey patches are in? So KVM ARM works using HYP on the HiKey board?

Thanks,
Jon


#12

Hi Jon,

There wasn’t any work to do at all once the firmware was done the right way (KVM works out of the box in this case). So kudos to the guys who ported ATF+UEFI to this board, that was the right thing to do.

The branch I was mentioning:

git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git hikey

is now fairly outdated but is enough to get things going (don’t use the MMC for anything but loading the kernel, it is broken - USB is your only hope). Oh, and you’ll need to fiddle with the device-tree, because it is utterly broken.

Unfortunately, the way development is done for this board makes it impossible to follow (the git tree is an absolute mess), the mainlining effort seems to progress at a glacial pace, and this looks more and more like a RPi-like effort (no, this is not a compliment).

M.