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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
