QEMU/KVM on MIPS (was Re: Fiasco.OC-UX on MIPS?)
Paul Boddie
paul at boddie.org.uk
Mon Sep 30 16:31:34 CEST 2019
On Tuesday 10. September 2019 12.42.36 Paul Boddie wrote:
>
> P.S. I have also been pursuing the user mode kernel work, which for various
> reasons has been proceeding slowly. Aside from errors I have introduced
> myself, there have been plenty of challenges getting things like data
> structures allocated and initialised, and it feels like guesswork at times.
I haven't been really able to dedicate myself to the above work recently, but
on a somewhat related topic, I did try and get KVM to work with QEMU on MIPS.
The intention was to take advantage of the native architecture and to delegate
only privileged operations to KVM and/or QEMU.
On the MIPS Creator CI20, the only real option for KVM is the trap-and-emulate
mode, partly because the JZ4780 SoC does not have VZ support, also because the
last kernel properly supporting the hardware (3.18) only has KVM support to
this level. In principle, starting a payload in QEMU should only see a trap to
the kernel occur when a privileged operation takes place, and this does indeed
seem to be what happens.
Since Fiasco (or other privileged code) would normally run in the kernel
address space (KSEG0), a curious arrangement is involved in MIPS KVM where
such kernel code has to run in a special "guest KSEG0" space (starting at
0x40000000 instead of 0x80000000). This gives such code a chance to run in
user mode until it performs a privileged instruction or accesses memory
regions that are privileged. Meanwhile, code running in the truncated user
address space is presumably prevented from accessing "guest KSEG0" using
normal memory mapping techniques.
Sadly, I couldn't get KVM to work for me. I recompiled the Linux kernel to
enable KVM and recompiled the Fiasco kernel having changed references to
KSEG0, the kernel load address, and so on. I also changed L4Re to take the
revised KSEG0 address into account. However, within QEMU, the built-in
bootloader for the Malta platform would fail to read the first faulting
instruction accessing I/O memory. In effect, QEMU would direct the execution
of the code, a trap would occur for an access to I/O memory, but the KVM code
would fail to access the memory containing the instruction.
There is a caveat noted in the MIPS KVM support in the Linux kernel which
indicates that a 16K page size is required both in the host and guest kernels.
I recompiled Linux and Fiasco to comply with this, and I then briefly saw the
QEMU-directed execution enter the L4Re bootstrap code, only to see the same
problem occurring with the instruction stream. A subsequent attempt saw the
problem occur once again within the Malta bootloader, suggesting some
intermittent issue. I think the KVM code was refactored somewhat in later
Linux kernels.
I don't know if anyone else has tried any of this at any point. It seems to me
that there are few enough people using native MIPS systems for development
that there can hardly be any at all using KVM on MIPS and perhaps no-one who
has tried to boot Fiasco in this way. But it seems reasonable to see if anyone
gave it any consideration (or even uses KVM on other architectures).
Paul
More information about the l4-hackers
mailing list