[why did you drop everyone from cc here?]

On 26 February 2014 11:42, Dennis Gilmore dennis@gilmore.net.au wrote:

On Wed, 26 Feb 2014 10:34:54 -0800 Christoffer Dall christoffer.dall@linaro.org wrote:

...

ARM VM System Specification

Goal

The goal of this spec is to allow suitably-built OS images to run on all ARM virtualization solutions, such as KVM or Xen.

Recommendations in this spec are valid for aarch32 and aarch64 alike, and they aim to be hypervisor agnostic.

Note that simply adhering to the SBSA [2] is not a valid approach, for example because the SBSA mandates EL2, which will not be available for VMs. Further, the SBSA mandates peripherals like the pl011, which may be controversial for some ARM VM implementations to support. This spec also covers the aarch32 execution mode, not covered in the SBSA.

Image format

The image format, as presented to the VM, needs to be well-defined in order for prepared disk images to be bootable across various virtualization implementations.

The raw disk format as presented to the VM must be partitioned with a GUID Partition Table (GPT). The bootable software must be placed in the EFI System Partition (ESP), using the UEFI removable media path, and must be an EFI application complying to the UEFI Specification 2.4 Revision A [6].

The ESP partition's GPT entry's partition type GUID must be C12A7328-F81F-11D2-BA4B-00A0C93EC93B and the file system must be formatted as FAT32/vfat as per Section 12.3.1.1 in [6].

The removable media path is \EFI\BOOT\BOOTARM.EFI for the aarch32 execution state and is \EFI\BOOT\BOOTAA64.EFI for the aarch64 execution state.

This ensures that tools for both Xen and KVM can load a binary UEFI firmware which can read and boot the EFI application in the disk image.

A typical scenario will be GRUB2 packaged as an EFI application, which mounts the system boot partition and boots Linux.

Virtual Firmware

The VM system must be able to boot the EFI application in the ESP. It is recommended that this is achieved by loading a UEFI binary as the first software executed by the VM, which then executes the EFI application. The UEFI implementation should be compliant with UEFI Specification 2.4 Revision A [6] or later.

This document strongly recommends that the VM implementation supports persistent environment storage for virtual firmware implementation in order to ensure probable use cases such as adding additional disk images to a VM or running installers to perform upgrades.

The binary UEFI firmware implementation should not be distributed as part of the VM image, but is specific to the VM implementation.

I disagree here, 32 bit should use u-boot and look like an existing 32 bit system. there is no reason why 32 bit arm should look different as a guest from the host

Why? It will look different if you use virtio devices and mach-virt. Sure, you can emulate a vexpress or something else real, but you have to ask yourself why. The main use case we have for 32 bit ARM at the moment is networking use cases and those use cases need virtio block, virtio net, and device passthrough.

Also, I'm afraid "u-boot and look like an existing 32 bit system" is not much of a spec. How does a distro vendor ship an image based on that description that they can be sure will boot?

If you can write up a more concrete suggestion for something u-boot based that you'd like to have considered instead, we can see what people say.

Personally I think keeping things uniform across both 32-bit and 64-bit is better, and the GTP/EFI image is a modern standard that should work well.

-Christoffer