Re: [RFC] ARM VM System Sepcification

[Arnd Bergmann <arnd@arndb.de>]

On Wednesday 26 February 2014 10:34:54 Christoffer Dall 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.

I would prefer if we can stay as close as possible to SBSA for individual
hardware components, and only stray from it when there is a strong reason.
pl011-subset doesn't sound like a significant problem to implement,
especially as SBSA makes the DMA part of that optional. Can you
elaborate on what hypervisor would have a problem with that?

> Hardware Description
> --------------------
> The Linux kernel's proper entry point always takes a pointer to an FDT,
> regardless of the boot mechanism, firmware, and hardware description
> method.  Even on real hardware which only supports ACPI and UEFI, the kernel
> entry point will still receive a pointer to a simple FDT, generated by
> the Linux kernel UEFI stub, containing a pointer to the UEFI system
> table.  The kernel can then discover ACPI from the system tables.  The
> presence of ACPI vs. FDT is therefore always itself discoverable,
> through the FDT.
> 
> Therefore, the VM implementation must provide through its UEFI
> implementation, either:
> 
>   a complete FDT which describes the entire VM system and will boot
>   mainline kernels driven by device tree alone, or
> 
>   no FDT.  In this case, the VM implementation must provide ACPI, and
>   the OS must be able to locate the ACPI root pointer through the UEFI
>   system table.
> 
> For more information about the arm and arm64 boot conventions, see
> Documentation/arm/Booting and Documentation/arm64/booting.txt in the
> Linux kernel source tree.
> 
> For more information about UEFI and ACPI booting, see [4] and [5].

What's the point of having ACPI in a virtual machine? You wouldn't
need to abstract any of the hardware in AML since you already know
what the virtual hardware is, so I can't see how this would help
anyone.

However, as ACPI will not be supported by arm32, not having the
complete FDT will prevent you from running a 32-bit guest on
a 64-bit hypervisor, which I consider an important use case.

> VM Platform
> -----------
> The specification does not mandate any specific memory map.  The guest
> OS must be able to enumerate all processing elements, devices, and
> memory through HW description data (FDT, ACPI) or a bus-specific
> mechanism such as PCI.
> 
> The virtual platform must support at least one of the following ARM
> execution states:
>   (1) aarch32 virtual CPUs on aarch32 physical CPUs
>   (2) aarch32 virtual CPUs on aarch64 physical CPUs
>   (3) aarch64 virtual CPUs on aarch64 physical CPUs
> 
> It is recommended to support both (2) and (3) on aarch64 capable
> physical systems.

Isn't this more of a CPU capabilities question? Or maybe you
should just add 'if aarch32 mode supported is supported by
the host CPU'.

> 
> The virtual hardware platform must provide a number of mandatory
> peripherals:
> 
>   Serial console:  The platform should provide a console,
>   based on an emulated pl011, a virtio-console, or a Xen PV console.
> 
>   An ARM Generic Interrupt Controller v2 (GICv2) [3] or newer.  GICv2
>   limits the the number of virtual CPUs to 8 cores, newer GIC versions
>   removes this limitation.
> 
>   The ARM virtual timer and counter should be available to the VM as
>   per the ARM Generic Timers specification in the ARM ARM [1].
> 
>   A hotpluggable bus to support hotplug of at least block and network
>   devices.  Suitable buses include a virtual PCIe bus and the Xen PV
>   bus.

I think you should specify exactly what you want PCIe to look like,
if present. Otherwise you can get wildly incompatible bus discovery.

> Note that this platform specification is separate from the Linux kernel
> concept of mach-virt, which merely specifies a machine model driven
> purely from device tree, but does not mandate any peripherals or have any
> mention of ACPI.

Did you notice we are removing mach-virt now? Probably no point
mentioning it here.

	Arnd