How to boot a Fedora 21 aarch64 UEFI guest on x86_64

You can use virt-builder to make Fedora 21 aarch64 guests easily:

$ virt-builder --arch aarch64 fedora-21

but unless you have real aarch64 hardware, how do you boot them?

Well the latest qemu supports working system emulation for 64 bit ARM. So assuming you (a) have compiled a very new qemu-system-aarch64 (I recommend qemu from git), and (b) you have the AAVMF (UEFI for aarch64) firmware, then:

$ qemu-system-aarch64 \
    -nodefconfig -nodefaults -display none \
    -M virt -cpu cortex-a57 -machine accel=tcg -m 2048 \
    -drive if=pflash,format=raw,file=AAVMF_CODE.fd,readonly \
    -drive if=pflash,format=raw,file=vars.fd \
    -drive file=fedora-21.img,format=raw,if=none,id=hd0 \
    -device virtio-blk-device,drive=hd0 \
    -serial stdio

And that will boot the aarch64 guest.

Edit: If using Gerd’s AAVMF repo, replace AAVMF_CODE.fd with /usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw

100 core ARM 64 bit chip

http://www.prnewswire.com/news-releases/ezchip-introduces-tile-mx100-worlds-highest-core-count-arm-processor-optimized-for-high-performance-networking-applications-293647261.html

They claim “linear scaling of application performance” which I rather doubt unless your application is web serving.

virt-builder: Fedora 21 aarch64 image available

Why has wordpress.com decided to break all inline images in postings?

If you have ARM 64 bit hardware, you can now use virt-builder to create Fedora 21 guests …

$ virt-builder fedora-21
[   1.0] Downloading: http://libguestfs.org/download/builder/fedora-21-aarch64.xz
[   5.0] Planning how to build this image
[   5.0] Uncompressing
[  12.0] Opening the new disk
[  44.0] Setting a random seed
[  44.0] Setting passwords
virt-builder: Setting random password of root to JRjjjDxEfsZuCWca
[  47.0] Finishing off
                   Output file: fedora-21.img
                   Output size: 4.0G
                 Output format: raw
            Total usable space: 5.2G
                    Free space: 4.4G (85%)

I’m thankful to Pino Toscano for adding multi-architecture support to virt-builder a while back.

As shown above, virt-builder will pick the right architecture corresponding to the host, or you can override its choice by using --arch.

Cheerson CX-10 quadcopter

The Cheerson CX-10 is quite a cool little quadcopter. When I say little, it really is tiny, about 1.5″ across. They are very cheap — I got one for £18.69 including tax & delivery.

According to this interesting teardown, inside it has an ARM Cortex-M0-based SoC, ie. a small 32 bit processor. Incredible really.

Linaro ARM-64 development board

https://www.96boards.org/

The 64 bit board uses an 8-core SoC manufactured by HiSilicon. Unfortunately RAM is very limited (1 GB), although understandable given the very low price point.

Update: Greg K-H has photos. I’m going to hold off on this one because I know there will be many more 64 bit ARM boards coming this year.

Half-baked ideas: qemu -M container

For more half-baked ideas, see the ideas tag.

Containers offer a way to do limited virtualization with fewer resources. But a lot of people have belatedly realized that containers aren’t secure, and so there’s a trend for putting containers into real virtual machines.

Unfortunately qemu is not very well suited to just running a single instance of the Linux kernel, as we in the libguestfs community have long known. There are at least a couple of problems:

1. You have to allocate a fixed amount of RAM to the VM. This is basically a guess. Do you guess too large and have memory wasted in guest kernel structures, or do you guess too small and have the VM fail at random?
2. There’s a large amount of overhead — firmware, legacy device emulation and other nonsense — which is essentially irrelevant to the special case of running a Linux appliance in a VM.

Here’s the half-baked idea: Let’s make a qemu “container mode/machine” which is better for this one task.

Unlike other proposals in this area, I’m not suggesting that we throw away or rewrite qemu. That’s stupid, as qemu gives us lots of useful abilities.

Instead the right way to do this is to implement a special virtio-ram device where the guest kernel can start off with a very tiny amount of RAM and request more memory on demand. And an empty machine type which is just for running appliances (qemu on ARM already has this: mach-virt).

Libguestfs people and container people, all happy. What’s not to like?

Nexus 9 ssh on the go

The Nexus 9 is an odd, compromised tablet, and way too expensive, but combined with the folio keyboard & pocketwifi it makes a nice ssh terminal for use on the road.

Various ssh apps like ConnectBot have terrible external keyboard support. So I compiled a static dropbear binary and static busybox, and I’m using those with Android Terminal Emulator.

The tablet has a 64 bit ARM processor (actually it’s way stranger than that – it uses a proprietary VLIW core with Transmeta-style code morphing in software). I used my AArch64 Fedora machine to compile the static binaries which I copied across.

I changed the default shell to busybox ash and added a bunch of start-up scripts to make Android more bearable.
It all works except nsswitch (user & DNS resolution) because of glibc static brokenness.