On Wed, Feb 26, 2014 at 09:48:43PM +0000, Leif Lindholm wrote:
On Wed, Feb 26, 2014 at 08:55:58PM +0100, Arnd Bergmann wrote:
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?
I believe it comes down to how much extra overhead pl011-access-trap would be over virtio-console. If low, then sure. (Since there are certain things we cannot provide SBSA-compliant in the guest anyway, I wouldn't consider lack of pl011 to be a big issue.)
I don't think it's about overhead, sure pl011 may be slower, but it's a serial port, does anyone care about performance of a console? pl011 should be good enough for sure.
I think the issue is that Xen does no real device emulation today at all, they don't use QEMU etc. That being said, adding a pl011 emulation in the Xen tools doesn't seem like the worst idea in the world, but I will let them chime in on why they are opposed to it.
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.
The point is that if we need to share any real hw then we need to use whatever the host has.
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.
In which case we would be making an active call to ban anything other than virtio/xen-pv devices for 32-bit guests on hardware without DT.
However, I see the case of a 32-bit guest on 64-bit hypervisor as less likely in the server space than in mobile, and ACPI in mobile as unlikely, so it may end up not being a big issue.
But you may want a networking applicance, for example, built on ARM 64-bit hardware, with an ARM 64-bit hypervisor on there, and you wish to run some 32-bit system in a VM. If the hardware is ACPI based, it would be a shame if the VM implementation (or the virtual firmware) couldn't provide a useable 32-bit FDT. We may want to call that case out in this document?
Thanks, -Christoffer