* [RFC v2] ARM VM System Specification @ 2014-03-28 18:45 ` Christoffer Dall 0 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-03-28 18:45 UTC (permalink / raw) To: cross-distro, linux-arm-kernel, kvmarm, kvm, xen-devel Cc: Michael Casadevall, Rob Herring, Peter Maydell, marc.zyngier, Grant Likely, Leif Lindholm, Robie Basak, Stefano Stabellini, Ian Campbell 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, 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 as specified in Section 3.3 (3.3 (Boot Option Variables Default Boot Behavior) and 3.4.1.1 (Removable Media Boot Behavior) in [6]. 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 UEFI compliant in order to 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. This document strongly recommends that VM implementations implement persistent variable storage for their UEFI implementation. Persistent variable storage shall be a property of a VM instance, but shall not be stored as part of a portable disk image. Portable disk images shall conform to the UEFI removable disk requirements from the UEFI spec and cannot rely on on a pre-configured UEFI environment. The binary UEFI firmware implementation should not be distributed as part of the VM image, but is specific to the VM implementation. Hardware Description -------------------- The VM system must be UEFI compliant and therefore the UEFI system table will provide a means to access hardware description data. The VM implementation must provide through its UEFI implementation: a complete FDT which describes the entire VM system and will boot mainline kernels driven by device tree alone 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 booting, see [4] and [5]. 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) or a bus-specific mechanism such as PCI. If aarch64 physical CPUs implement support for the aarch32 execution state in EL1 and EL0 execution, it is recommended that the VM implementation supports booting the VM at EL1 in both aarch32 and aarch64 execution states. 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]. It is strongly recommended that the VM implementation provides 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. For the VM image to be compliant with this spec, the following applies for the guest OS in the VM image: The guest OS must include support for pl011 UART, virtio-console, and the Xen PV console. The guest OS must include support for GICv2 and any available newer version of the GIC architecture to maintain compatibility with older VM implementations. It is strongly recommended to include support for all available (block, network, console, balloon) virtio-pci, virtio-mmio, and Xen PV drivers in the guest OS kernel or initial ramdisk. Other common peripherals for block devices, networking, and more can (and typically will) be provided, but OS software written and compiled to run on ARM VMs cannot make any assumptions about which variations of these should exist or which implementation they use (e.g. VirtIO or Xen PV). See "Hardware Description" above. Changes from previous versions of this RFC ------------------------------------------ Changes v1-v2: - Clearly specify that the guest must support the pl011, virtio-console, and Xen PV console. (Note that it was discussed to mandate a pl011 during Linaro Connect Asia 2014, but that was under the impression that the SBSA specification was an output-only no-irq serial port, which is not the case. The only two benefits from mandating a specific serial type was to handle "console=ttyAMA0" kernel command line parameters and earlyprintk; Grant Likely has submitted patches to avoid the need for "console=" parameters, and Rob Herring has submitted patches for paravirtualized earlyprintk consoles.) - Reference EFI specification for bootable paths. - Remove discussion on ACPI boot methods and do not suggest ACPI support in VMs. - Add specification about UEFI persistent variable storage and portability. References ---------- [1]: The ARM Architecture Reference Manual, ARMv8, Issue A.b http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html [2]: ARM Server Base System Architecture http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029/index.html [3]: The ARM Generic Interrupt Controller Architecture Specifications v2.0 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html [4]: http://www.secretlab.ca/archives/27 [5]: https://git.linaro.org/people/leif.lindholm/linux.git/blob/refs/heads/uefi-for-upstream:/Documentation/arm/uefi.txt [6]: UEFI Specification 2.4 Revision A http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-03-28 18:45 ` Christoffer Dall 0 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-03-28 18:45 UTC (permalink / raw) To: linux-arm-kernel 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, 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 as specified in Section 3.3 (3.3 (Boot Option Variables Default Boot Behavior) and 3.4.1.1 (Removable Media Boot Behavior) in [6]. 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 UEFI compliant in order to 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. This document strongly recommends that VM implementations implement persistent variable storage for their UEFI implementation. Persistent variable storage shall be a property of a VM instance, but shall not be stored as part of a portable disk image. Portable disk images shall conform to the UEFI removable disk requirements from the UEFI spec and cannot rely on on a pre-configured UEFI environment. The binary UEFI firmware implementation should not be distributed as part of the VM image, but is specific to the VM implementation. Hardware Description -------------------- The VM system must be UEFI compliant and therefore the UEFI system table will provide a means to access hardware description data. The VM implementation must provide through its UEFI implementation: a complete FDT which describes the entire VM system and will boot mainline kernels driven by device tree alone 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 booting, see [4] and [5]. 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) or a bus-specific mechanism such as PCI. If aarch64 physical CPUs implement support for the aarch32 execution state in EL1 and EL0 execution, it is recommended that the VM implementation supports booting the VM at EL1 in both aarch32 and aarch64 execution states. 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]. It is strongly recommended that the VM implementation provides 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. For the VM image to be compliant with this spec, the following applies for the guest OS in the VM image: The guest OS must include support for pl011 UART, virtio-console, and the Xen PV console. The guest OS must include support for GICv2 and any available newer version of the GIC architecture to maintain compatibility with older VM implementations. It is strongly recommended to include support for all available (block, network, console, balloon) virtio-pci, virtio-mmio, and Xen PV drivers in the guest OS kernel or initial ramdisk. Other common peripherals for block devices, networking, and more can (and typically will) be provided, but OS software written and compiled to run on ARM VMs cannot make any assumptions about which variations of these should exist or which implementation they use (e.g. VirtIO or Xen PV). See "Hardware Description" above. Changes from previous versions of this RFC ------------------------------------------ Changes v1-v2: - Clearly specify that the guest must support the pl011, virtio-console, and Xen PV console. (Note that it was discussed to mandate a pl011 during Linaro Connect Asia 2014, but that was under the impression that the SBSA specification was an output-only no-irq serial port, which is not the case. The only two benefits from mandating a specific serial type was to handle "console=ttyAMA0" kernel command line parameters and earlyprintk; Grant Likely has submitted patches to avoid the need for "console=" parameters, and Rob Herring has submitted patches for paravirtualized earlyprintk consoles.) - Reference EFI specification for bootable paths. - Remove discussion on ACPI boot methods and do not suggest ACPI support in VMs. - Add specification about UEFI persistent variable storage and portability. References ---------- [1]: The ARM Architecture Reference Manual, ARMv8, Issue A.b http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html [2]: ARM Server Base System Architecture http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029/index.html [3]: The ARM Generic Interrupt Controller Architecture Specifications v2.0 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html [4]: http://www.secretlab.ca/archives/27 [5]: https://git.linaro.org/people/leif.lindholm/linux.git/blob/refs/heads/uefi-for-upstream:/Documentation/arm/uefi.txt [6]: UEFI Specification 2.4 Revision A http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-03-28 18:45 ` Christoffer Dall (?) @ 2014-03-30 22:10 ` Olof Johansson -1 siblings, 0 replies; 111+ messages in thread From: Olof Johansson @ 2014-03-30 22:10 UTC (permalink / raw) To: Christoffer Dall Cc: Peter Maydell, Ian Campbell, kvm, cross-distro, marc.zyngier, Michael Casadevall, Rob Herring, xen-devel, Stefano Stabellini, Grant Likely, kvmarm, linux-arm-kernel On Fri, Mar 28, 2014 at 11:45 AM, Christoffer Dall <christoffer.dall@linaro.org> wrote: > ARM VM System Specification > =========================== [not quoting the whole spec here] This looks very sane to me, and aligns very well with non-virtualized images. For what it's worth, even though it's not a patch: Acked-by: Olof Johansson <olof@lixom.net> What's the plan on how to lock this in? Where's this document going to live? In the kernel sources under Documentation/, or external? -Olof ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-03-28 18:45 ` Christoffer Dall @ 2014-03-30 22:10 ` Olof Johansson -1 siblings, 0 replies; 111+ messages in thread From: Olof Johansson @ 2014-03-30 22:10 UTC (permalink / raw) To: Christoffer Dall Cc: Peter Maydell, Ian Campbell, kvm, cross-distro, marc.zyngier, Michael Casadevall, Rob Herring, xen-devel, Stefano Stabellini, Grant Likely, kvmarm, linux-arm-kernel On Fri, Mar 28, 2014 at 11:45 AM, Christoffer Dall <christoffer.dall@linaro.org> wrote: > ARM VM System Specification > =========================== [not quoting the whole spec here] This looks very sane to me, and aligns very well with non-virtualized images. For what it's worth, even though it's not a patch: Acked-by: Olof Johansson <olof@lixom.net> What's the plan on how to lock this in? Where's this document going to live? In the kernel sources under Documentation/, or external? -Olof ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-03-30 22:10 ` Olof Johansson 0 siblings, 0 replies; 111+ messages in thread From: Olof Johansson @ 2014-03-30 22:10 UTC (permalink / raw) To: linux-arm-kernel On Fri, Mar 28, 2014 at 11:45 AM, Christoffer Dall <christoffer.dall@linaro.org> wrote: > ARM VM System Specification > =========================== [not quoting the whole spec here] This looks very sane to me, and aligns very well with non-virtualized images. For what it's worth, even though it's not a patch: Acked-by: Olof Johansson <olof@lixom.net> What's the plan on how to lock this in? Where's this document going to live? In the kernel sources under Documentation/, or external? -Olof ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-03-30 22:10 ` Olof Johansson (?) @ 2014-03-31 17:26 ` Christoffer Dall -1 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-03-31 17:26 UTC (permalink / raw) To: Olof Johansson Cc: Peter Maydell, Ian Campbell, kvm, cross-distro, marc.zyngier, Michael Casadevall, Rob Herring, xen-devel, Stefano Stabellini, Grant Likely, kvmarm, linux-arm-kernel On Sun, Mar 30, 2014 at 03:10:50PM -0700, Olof Johansson wrote: > On Fri, Mar 28, 2014 at 11:45 AM, Christoffer Dall > <christoffer.dall@linaro.org> wrote: > > ARM VM System Specification > > =========================== > > [not quoting the whole spec here] > > This looks very sane to me, and aligns very well with non-virtualized images. > > For what it's worth, even though it's not a patch: > > Acked-by: Olof Johansson <olof@lixom.net> Thanks, appreciate it. > > What's the plan on how to lock this in? Where's this document going to > live? In the kernel sources under Documentation/, or external? > There were talks during LCA14 about publishing it as a Linaro white-paper, but I would like it to be hosted by the open-source projects that relate to it, for example the Linux kernel under Documentaiton/ to represent both the guest and KVM side, and the Xen sources too. However, that may be a pain to update so the preferred method could be to host it in either its current form (clear-text) or publish some versioned PDF somewhere and simply point to it from the compliant software pieces. Suggestions or input welcome. -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-03-30 22:10 ` Olof Johansson @ 2014-03-31 17:26 ` Christoffer Dall -1 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-03-31 17:26 UTC (permalink / raw) To: Olof Johansson Cc: cross-distro, linux-arm-kernel, kvmarm, kvm, xen-devel, Peter Maydell, Ian Campbell, Michael Casadevall, marc.zyngier, Rob Herring, Stefano Stabellini, Grant Likely On Sun, Mar 30, 2014 at 03:10:50PM -0700, Olof Johansson wrote: > On Fri, Mar 28, 2014 at 11:45 AM, Christoffer Dall > <christoffer.dall@linaro.org> wrote: > > ARM VM System Specification > > =========================== > > [not quoting the whole spec here] > > This looks very sane to me, and aligns very well with non-virtualized images. > > For what it's worth, even though it's not a patch: > > Acked-by: Olof Johansson <olof@lixom.net> Thanks, appreciate it. > > What's the plan on how to lock this in? Where's this document going to > live? In the kernel sources under Documentation/, or external? > There were talks during LCA14 about publishing it as a Linaro white-paper, but I would like it to be hosted by the open-source projects that relate to it, for example the Linux kernel under Documentaiton/ to represent both the guest and KVM side, and the Xen sources too. However, that may be a pain to update so the preferred method could be to host it in either its current form (clear-text) or publish some versioned PDF somewhere and simply point to it from the compliant software pieces. Suggestions or input welcome. -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-03-31 17:26 ` Christoffer Dall 0 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-03-31 17:26 UTC (permalink / raw) To: linux-arm-kernel On Sun, Mar 30, 2014 at 03:10:50PM -0700, Olof Johansson wrote: > On Fri, Mar 28, 2014 at 11:45 AM, Christoffer Dall > <christoffer.dall@linaro.org> wrote: > > ARM VM System Specification > > =========================== > > [not quoting the whole spec here] > > This looks very sane to me, and aligns very well with non-virtualized images. > > For what it's worth, even though it's not a patch: > > Acked-by: Olof Johansson <olof@lixom.net> Thanks, appreciate it. > > What's the plan on how to lock this in? Where's this document going to > live? In the kernel sources under Documentation/, or external? > There were talks during LCA14 about publishing it as a Linaro white-paper, but I would like it to be hosted by the open-source projects that relate to it, for example the Linux kernel under Documentaiton/ to represent both the guest and KVM side, and the Xen sources too. However, that may be a pain to update so the preferred method could be to host it in either its current form (clear-text) or publish some versioned PDF somewhere and simply point to it from the compliant software pieces. Suggestions or input welcome. -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-03-31 17:26 ` Christoffer Dall (?) @ 2014-04-01 9:49 ` Ian Campbell -1 siblings, 0 replies; 111+ messages in thread From: Ian Campbell @ 2014-04-01 9:49 UTC (permalink / raw) To: Christoffer Dall Cc: cross-distro, kvm, Peter Maydell, marc.zyngier, Michael Casadevall, Rob Herring, xen-devel, Grant Likely, Stefano Stabellini, Olof Johansson, kvmarm, linux-arm-kernel On Mon, 2014-03-31 at 10:26 -0700, Christoffer Dall wrote: > However, that may be a pain to update Very much, and there would be nothing worse than having multiple divergent copies of the spec. > so the preferred method could be > to host it in either its current form (clear-text) or publish some > versioned PDF somewhere and simply point to it from the compliant > software pieces. I think that would be best. I'm at a loss to suggest a suitable neutral home though I'm afraid. Ian. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-03-31 17:26 ` Christoffer Dall @ 2014-04-01 9:49 ` Ian Campbell -1 siblings, 0 replies; 111+ messages in thread From: Ian Campbell @ 2014-04-01 9:49 UTC (permalink / raw) To: Christoffer Dall Cc: Olof Johansson, cross-distro, linux-arm-kernel, kvmarm, kvm, xen-devel, Peter Maydell, Michael Casadevall, marc.zyngier, Rob Herring, Stefano Stabellini, Grant Likely On Mon, 2014-03-31 at 10:26 -0700, Christoffer Dall wrote: > However, that may be a pain to update Very much, and there would be nothing worse than having multiple divergent copies of the spec. > so the preferred method could be > to host it in either its current form (clear-text) or publish some > versioned PDF somewhere and simply point to it from the compliant > software pieces. I think that would be best. I'm at a loss to suggest a suitable neutral home though I'm afraid. Ian. ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-04-01 9:49 ` Ian Campbell 0 siblings, 0 replies; 111+ messages in thread From: Ian Campbell @ 2014-04-01 9:49 UTC (permalink / raw) To: linux-arm-kernel On Mon, 2014-03-31 at 10:26 -0700, Christoffer Dall wrote: > However, that may be a pain to update Very much, and there would be nothing worse than having multiple divergent copies of the spec. > so the preferred method could be > to host it in either its current form (clear-text) or publish some > versioned PDF somewhere and simply point to it from the compliant > software pieces. I think that would be best. I'm at a loss to suggest a suitable neutral home though I'm afraid. Ian. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-04-01 9:49 ` Ian Campbell (?) @ 2014-04-01 9:57 ` Michael Casadevall -1 siblings, 0 replies; 111+ messages in thread From: Michael Casadevall @ 2014-04-01 9:57 UTC (permalink / raw) To: Ian Campbell, Christoffer Dall Cc: cross-distro, kvm, Peter Maydell, marc.zyngier, Rob Herring, xen-devel, Grant Likely, Stefano Stabellini, Olof Johansson, kvmarm, linux-arm-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/01/2014 05:49 AM, Ian Campbell wrote: > On Mon, 2014-03-31 at 10:26 -0700, Christoffer Dall wrote: >> However, that may be a pain to update > > Very much, and there would be nothing worse than having multiple > divergent copies of the spec. > >> so the preferred method could be to host it in either its current >> form (clear-text) or publish some versioned PDF somewhere and >> simply point to it from the compliant software pieces. > > I think that would be best. > > I'm at a loss to suggest a suitable neutral home though I'm > afraid. > I agree with formal PDF (or TeX/plain text) releases + versioning; something I can print out and hit people with always works great for spec compliance. On the topic of hosting, if Linaro itself isn't neutral enough, what about under the Linux Foundation? They already host a bunch of standards like the FHS. Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTOo2JAAoJEGKVRgSEnX1Qu+gH/ja+aqOqc04gbpFvuarHtzeM nLtJ1ie4JKOJTVqqQz+lgPhx+r3H9PrMFZnGvzs8H6GYSaU66i/SHKU150J1Ig5M 1w4DYqQj7DEClpoNmpPZVJJbevp70/wDH1wFSJZXJmxV9yOpMtrNZXwB60KANP2f MJDF+iDLIkv8vRPYQJEmuV4PMcJQs88X91eEb67jChX1ntMiiDAFSM6t2cRyfVG0 la4Ujk/p/u+Kr43wbhQITOKXZpWCtI8gjp7wTuZc+EDIhmufd5uiQ2VyTZaMkPkV xuX9871Y8VHGxCkAmhHPODbp3Wd4VUP2ewOYnTRYR2IIRpa4gNNLUa+MSdrL/sU= =2ub7 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-04-01 9:49 ` Ian Campbell @ 2014-04-01 9:57 ` Michael Casadevall -1 siblings, 0 replies; 111+ messages in thread From: Michael Casadevall @ 2014-04-01 9:57 UTC (permalink / raw) To: Ian Campbell, Christoffer Dall Cc: Olof Johansson, cross-distro, linux-arm-kernel, kvmarm, kvm, xen-devel, Peter Maydell, marc.zyngier, Rob Herring, Stefano Stabellini, Grant Likely -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/01/2014 05:49 AM, Ian Campbell wrote: > On Mon, 2014-03-31 at 10:26 -0700, Christoffer Dall wrote: >> However, that may be a pain to update > > Very much, and there would be nothing worse than having multiple > divergent copies of the spec. > >> so the preferred method could be to host it in either its current >> form (clear-text) or publish some versioned PDF somewhere and >> simply point to it from the compliant software pieces. > > I think that would be best. > > I'm at a loss to suggest a suitable neutral home though I'm > afraid. > I agree with formal PDF (or TeX/plain text) releases + versioning; something I can print out and hit people with always works great for spec compliance. On the topic of hosting, if Linaro itself isn't neutral enough, what about under the Linux Foundation? They already host a bunch of standards like the FHS. Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTOo2JAAoJEGKVRgSEnX1Qu+gH/ja+aqOqc04gbpFvuarHtzeM nLtJ1ie4JKOJTVqqQz+lgPhx+r3H9PrMFZnGvzs8H6GYSaU66i/SHKU150J1Ig5M 1w4DYqQj7DEClpoNmpPZVJJbevp70/wDH1wFSJZXJmxV9yOpMtrNZXwB60KANP2f MJDF+iDLIkv8vRPYQJEmuV4PMcJQs88X91eEb67jChX1ntMiiDAFSM6t2cRyfVG0 la4Ujk/p/u+Kr43wbhQITOKXZpWCtI8gjp7wTuZc+EDIhmufd5uiQ2VyTZaMkPkV xuX9871Y8VHGxCkAmhHPODbp3Wd4VUP2ewOYnTRYR2IIRpa4gNNLUa+MSdrL/sU= =2ub7 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-04-01 9:57 ` Michael Casadevall 0 siblings, 0 replies; 111+ messages in thread From: Michael Casadevall @ 2014-04-01 9:57 UTC (permalink / raw) To: linux-arm-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/01/2014 05:49 AM, Ian Campbell wrote: > On Mon, 2014-03-31 at 10:26 -0700, Christoffer Dall wrote: >> However, that may be a pain to update > > Very much, and there would be nothing worse than having multiple > divergent copies of the spec. > >> so the preferred method could be to host it in either its current >> form (clear-text) or publish some versioned PDF somewhere and >> simply point to it from the compliant software pieces. > > I think that would be best. > > I'm at a loss to suggest a suitable neutral home though I'm > afraid. > I agree with formal PDF (or TeX/plain text) releases + versioning; something I can print out and hit people with always works great for spec compliance. On the topic of hosting, if Linaro itself isn't neutral enough, what about under the Linux Foundation? They already host a bunch of standards like the FHS. Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTOo2JAAoJEGKVRgSEnX1Qu+gH/ja+aqOqc04gbpFvuarHtzeM nLtJ1ie4JKOJTVqqQz+lgPhx+r3H9PrMFZnGvzs8H6GYSaU66i/SHKU150J1Ig5M 1w4DYqQj7DEClpoNmpPZVJJbevp70/wDH1wFSJZXJmxV9yOpMtrNZXwB60KANP2f MJDF+iDLIkv8vRPYQJEmuV4PMcJQs88X91eEb67jChX1ntMiiDAFSM6t2cRyfVG0 la4Ujk/p/u+Kr43wbhQITOKXZpWCtI8gjp7wTuZc+EDIhmufd5uiQ2VyTZaMkPkV xuX9871Y8VHGxCkAmhHPODbp3Wd4VUP2ewOYnTRYR2IIRpa4gNNLUa+MSdrL/sU= =2ub7 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-04-01 9:57 ` Michael Casadevall @ 2014-04-01 10:16 ` Grant Likely -1 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-04-01 10:16 UTC (permalink / raw) To: Michael Casadevall Cc: Ian Campbell, Christoffer Dall, Olof Johansson, cross-distro, linux-arm-kernel, kvmarm, kvm, xen-devel, Peter Maydell, marc.zyngier, Rob Herring, Stefano Stabellini Start with Linaro publishing it. It can always be moved to another venue if someone dislikes Linaro having maintainership. g. On Tue, Apr 1, 2014 at 10:57 AM, Michael Casadevall <michael.casadevall@linaro.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > On 04/01/2014 05:49 AM, Ian Campbell wrote: >> On Mon, 2014-03-31 at 10:26 -0700, Christoffer Dall wrote: >>> However, that may be a pain to update >> >> Very much, and there would be nothing worse than having multiple >> divergent copies of the spec. >> >>> so the preferred method could be to host it in either its current >>> form (clear-text) or publish some versioned PDF somewhere and >>> simply point to it from the compliant software pieces. >> >> I think that would be best. >> >> I'm at a loss to suggest a suitable neutral home though I'm >> afraid. >> > > I agree with formal PDF (or TeX/plain text) releases + versioning; > something I can print out and hit people with always works great for > spec compliance. > > On the topic of hosting, if Linaro itself isn't neutral enough, what > about under the Linux Foundation? They already host a bunch of > standards like the FHS. > Michael > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.14 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJTOo2JAAoJEGKVRgSEnX1Qu+gH/ja+aqOqc04gbpFvuarHtzeM > nLtJ1ie4JKOJTVqqQz+lgPhx+r3H9PrMFZnGvzs8H6GYSaU66i/SHKU150J1Ig5M > 1w4DYqQj7DEClpoNmpPZVJJbevp70/wDH1wFSJZXJmxV9yOpMtrNZXwB60KANP2f > MJDF+iDLIkv8vRPYQJEmuV4PMcJQs88X91eEb67jChX1ntMiiDAFSM6t2cRyfVG0 > la4Ujk/p/u+Kr43wbhQITOKXZpWCtI8gjp7wTuZc+EDIhmufd5uiQ2VyTZaMkPkV > xuX9871Y8VHGxCkAmhHPODbp3Wd4VUP2ewOYnTRYR2IIRpa4gNNLUa+MSdrL/sU= > =2ub7 > -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-04-01 10:16 ` Grant Likely 0 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-04-01 10:16 UTC (permalink / raw) To: linux-arm-kernel Start with Linaro publishing it. It can always be moved to another venue if someone dislikes Linaro having maintainership. g. On Tue, Apr 1, 2014 at 10:57 AM, Michael Casadevall <michael.casadevall@linaro.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > On 04/01/2014 05:49 AM, Ian Campbell wrote: >> On Mon, 2014-03-31 at 10:26 -0700, Christoffer Dall wrote: >>> However, that may be a pain to update >> >> Very much, and there would be nothing worse than having multiple >> divergent copies of the spec. >> >>> so the preferred method could be to host it in either its current >>> form (clear-text) or publish some versioned PDF somewhere and >>> simply point to it from the compliant software pieces. >> >> I think that would be best. >> >> I'm at a loss to suggest a suitable neutral home though I'm >> afraid. >> > > I agree with formal PDF (or TeX/plain text) releases + versioning; > something I can print out and hit people with always works great for > spec compliance. > > On the topic of hosting, if Linaro itself isn't neutral enough, what > about under the Linux Foundation? They already host a bunch of > standards like the FHS. > Michael > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.14 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJTOo2JAAoJEGKVRgSEnX1Qu+gH/ja+aqOqc04gbpFvuarHtzeM > nLtJ1ie4JKOJTVqqQz+lgPhx+r3H9PrMFZnGvzs8H6GYSaU66i/SHKU150J1Ig5M > 1w4DYqQj7DEClpoNmpPZVJJbevp70/wDH1wFSJZXJmxV9yOpMtrNZXwB60KANP2f > MJDF+iDLIkv8vRPYQJEmuV4PMcJQs88X91eEb67jChX1ntMiiDAFSM6t2cRyfVG0 > la4Ujk/p/u+Kr43wbhQITOKXZpWCtI8gjp7wTuZc+EDIhmufd5uiQ2VyTZaMkPkV > xuX9871Y8VHGxCkAmhHPODbp3Wd4VUP2ewOYnTRYR2IIRpa4gNNLUa+MSdrL/sU= > =2ub7 > -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-04-01 9:57 ` Michael Casadevall (?) (?) @ 2014-04-01 10:16 ` Grant Likely -1 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-04-01 10:16 UTC (permalink / raw) To: Michael Casadevall Cc: cross-distro, Ian Campbell, kvm, Peter Maydell, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, linux-arm-kernel, Olof Johansson, kvmarm, Christoffer Dall Start with Linaro publishing it. It can always be moved to another venue if someone dislikes Linaro having maintainership. g. On Tue, Apr 1, 2014 at 10:57 AM, Michael Casadevall <michael.casadevall@linaro.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > On 04/01/2014 05:49 AM, Ian Campbell wrote: >> On Mon, 2014-03-31 at 10:26 -0700, Christoffer Dall wrote: >>> However, that may be a pain to update >> >> Very much, and there would be nothing worse than having multiple >> divergent copies of the spec. >> >>> so the preferred method could be to host it in either its current >>> form (clear-text) or publish some versioned PDF somewhere and >>> simply point to it from the compliant software pieces. >> >> I think that would be best. >> >> I'm at a loss to suggest a suitable neutral home though I'm >> afraid. >> > > I agree with formal PDF (or TeX/plain text) releases + versioning; > something I can print out and hit people with always works great for > spec compliance. > > On the topic of hosting, if Linaro itself isn't neutral enough, what > about under the Linux Foundation? They already host a bunch of > standards like the FHS. > Michael > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.14 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJTOo2JAAoJEGKVRgSEnX1Qu+gH/ja+aqOqc04gbpFvuarHtzeM > nLtJ1ie4JKOJTVqqQz+lgPhx+r3H9PrMFZnGvzs8H6GYSaU66i/SHKU150J1Ig5M > 1w4DYqQj7DEClpoNmpPZVJJbevp70/wDH1wFSJZXJmxV9yOpMtrNZXwB60KANP2f > MJDF+iDLIkv8vRPYQJEmuV4PMcJQs88X91eEb67jChX1ntMiiDAFSM6t2cRyfVG0 > la4Ujk/p/u+Kr43wbhQITOKXZpWCtI8gjp7wTuZc+EDIhmufd5uiQ2VyTZaMkPkV > xuX9871Y8VHGxCkAmhHPODbp3Wd4VUP2ewOYnTRYR2IIRpa4gNNLUa+MSdrL/sU= > =2ub7 > -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-03-28 18:45 ` Christoffer Dall ` (2 preceding siblings ...) (?) @ 2014-04-29 14:42 ` Christoffer Dall -1 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-04-29 14:42 UTC (permalink / raw) To: cross-distro, linux-arm-kernel, kvmarm, kvm, xen-devel Cc: Peter Maydell, Ian Campbell, Michael Casadevall, marc.zyngier, Rob Herring, Leif Lindholm, Robie Basak, Stefano Stabellini, Grant Likely On Fri, Mar 28, 2014 at 11:45:17AM -0700, Christoffer Dall wrote: > ARM VM System Specification > =========================== > I didn't receive a lot of comments on this one, I take this to mean that most people are happy with the content. If not, now is the time to speak up, otherwise we'll be taking steps to try and publish this slightly more formally. Thanks, -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-03-28 18:45 ` Christoffer Dall @ 2014-04-29 14:42 ` Christoffer Dall -1 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-04-29 14:42 UTC (permalink / raw) To: cross-distro, linux-arm-kernel, kvmarm, kvm, xen-devel Cc: Michael Casadevall, Rob Herring, Peter Maydell, marc.zyngier, Grant Likely, Leif Lindholm, Robie Basak, Stefano Stabellini, Ian Campbell On Fri, Mar 28, 2014 at 11:45:17AM -0700, Christoffer Dall wrote: > ARM VM System Specification > =========================== > I didn't receive a lot of comments on this one, I take this to mean that most people are happy with the content. If not, now is the time to speak up, otherwise we'll be taking steps to try and publish this slightly more formally. Thanks, -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-04-29 14:42 ` Christoffer Dall 0 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-04-29 14:42 UTC (permalink / raw) To: linux-arm-kernel On Fri, Mar 28, 2014 at 11:45:17AM -0700, Christoffer Dall wrote: > ARM VM System Specification > =========================== > I didn't receive a lot of comments on this one, I take this to mean that most people are happy with the content. If not, now is the time to speak up, otherwise we'll be taking steps to try and publish this slightly more formally. Thanks, -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-04-29 14:42 ` Christoffer Dall (?) @ 2014-04-30 8:14 ` Grant Likely -1 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-04-30 8:14 UTC (permalink / raw) To: Christoffer Dall, cross-distro, linux-arm-kernel, kvmarm, kvm, xen-devel Cc: Peter Maydell, Ian Campbell, Michael Casadevall, marc.zyngier, Rob Herring, Leif Lindholm, Robie Basak, Stefano Stabellini On Tue, 29 Apr 2014 07:42:06 -0700, Christoffer Dall <christoffer.dall@linaro.org> wrote: > On Fri, Mar 28, 2014 at 11:45:17AM -0700, Christoffer Dall wrote: > > ARM VM System Specification > > =========================== > > > > I didn't receive a lot of comments on this one, I take this to mean that > most people are happy with the content. If not, now is the time to > speak up, otherwise we'll be taking steps to try and publish this > slightly more formally. Yes, I'm happy with it. g. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-04-29 14:42 ` Christoffer Dall @ 2014-04-30 8:14 ` Grant Likely -1 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-04-30 8:14 UTC (permalink / raw) To: Christoffer Dall, cross-distro, linux-arm-kernel, kvmarm, kvm, xen-devel Cc: Michael Casadevall, Rob Herring, Peter Maydell, marc.zyngier, Leif Lindholm, Robie Basak, Stefano Stabellini, Ian Campbell On Tue, 29 Apr 2014 07:42:06 -0700, Christoffer Dall <christoffer.dall@linaro.org> wrote: > On Fri, Mar 28, 2014 at 11:45:17AM -0700, Christoffer Dall wrote: > > ARM VM System Specification > > =========================== > > > > I didn't receive a lot of comments on this one, I take this to mean that > most people are happy with the content. If not, now is the time to > speak up, otherwise we'll be taking steps to try and publish this > slightly more formally. Yes, I'm happy with it. g. ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-04-30 8:14 ` Grant Likely 0 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-04-30 8:14 UTC (permalink / raw) To: linux-arm-kernel On Tue, 29 Apr 2014 07:42:06 -0700, Christoffer Dall <christoffer.dall@linaro.org> wrote: > On Fri, Mar 28, 2014 at 11:45:17AM -0700, Christoffer Dall wrote: > > ARM VM System Specification > > =========================== > > > > I didn't receive a lot of comments on this one, I take this to mean that > most people are happy with the content. If not, now is the time to > speak up, otherwise we'll be taking steps to try and publish this > slightly more formally. Yes, I'm happy with it. g. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-03-28 18:45 ` Christoffer Dall ` (4 preceding siblings ...) (?) @ 2014-06-10 14:42 ` Peter Maydell -1 siblings, 0 replies; 111+ messages in thread From: Peter Maydell @ 2014-06-10 14:42 UTC (permalink / raw) To: Christoffer Dall Cc: cross-distro, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, Leif Lindholm, xen-devel, Robie Basak, Stefano Stabellini, Grant Likely, kvmarm, arm-mail-list On 28 March 2014 18:45, Christoffer Dall <christoffer.dall@linaro.org> wrote: > ARM VM System Specification > =========================== > > 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]. I just noticed that this doesn't mandate that the platform provides an RTC. As I understand it, the UEFI spec mandates that there's an RTC (could somebody more familiar with UEFI than me confirm/deny that?) so we should probably put one here. Suggested wording: RTC: The platform should provide a real time clock, based on an emulated pl031 or mc146818. and in the guest-support section later: The guest OS must include support for pl031 and mc146818 RTC. (QEMU is going to provide a PL031, because that's the standard ARM primecell device for this and it's what's in the vexpress. kvmtool looks like it's going to provide mc146818, because that's the standard x86 RTC and kvmtool happens to already emulate that.) thanks -- PMM ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-03-28 18:45 ` Christoffer Dall @ 2014-06-10 14:42 ` Peter Maydell -1 siblings, 0 replies; 111+ messages in thread From: Peter Maydell @ 2014-06-10 14:42 UTC (permalink / raw) To: Christoffer Dall Cc: cross-distro, arm-mail-list, kvmarm, kvm-devel, xen-devel, Michael Casadevall, Rob Herring, marc.zyngier, Grant Likely, Leif Lindholm, Robie Basak, Stefano Stabellini, Ian Campbell On 28 March 2014 18:45, Christoffer Dall <christoffer.dall@linaro.org> wrote: > ARM VM System Specification > =========================== > > 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]. I just noticed that this doesn't mandate that the platform provides an RTC. As I understand it, the UEFI spec mandates that there's an RTC (could somebody more familiar with UEFI than me confirm/deny that?) so we should probably put one here. Suggested wording: RTC: The platform should provide a real time clock, based on an emulated pl031 or mc146818. and in the guest-support section later: The guest OS must include support for pl031 and mc146818 RTC. (QEMU is going to provide a PL031, because that's the standard ARM primecell device for this and it's what's in the vexpress. kvmtool looks like it's going to provide mc146818, because that's the standard x86 RTC and kvmtool happens to already emulate that.) thanks -- PMM ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-10 14:42 ` Peter Maydell 0 siblings, 0 replies; 111+ messages in thread From: Peter Maydell @ 2014-06-10 14:42 UTC (permalink / raw) To: linux-arm-kernel On 28 March 2014 18:45, Christoffer Dall <christoffer.dall@linaro.org> wrote: > ARM VM System Specification > =========================== > > 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]. I just noticed that this doesn't mandate that the platform provides an RTC. As I understand it, the UEFI spec mandates that there's an RTC (could somebody more familiar with UEFI than me confirm/deny that?) so we should probably put one here. Suggested wording: RTC: The platform should provide a real time clock, based on an emulated pl031 or mc146818. and in the guest-support section later: The guest OS must include support for pl031 and mc146818 RTC. (QEMU is going to provide a PL031, because that's the standard ARM primecell device for this and it's what's in the vexpress. kvmtool looks like it's going to provide mc146818, because that's the standard x86 RTC and kvmtool happens to already emulate that.) thanks -- PMM ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 14:42 ` Peter Maydell @ 2014-06-10 15:03 ` Ian Campbell -1 siblings, 0 replies; 111+ messages in thread From: Ian Campbell @ 2014-06-10 15:03 UTC (permalink / raw) To: Peter Maydell Cc: Christoffer Dall, cross-distro, arm-mail-list, kvmarm, kvm-devel, xen-devel On Tue, 2014-06-10 at 15:42 +0100, Peter Maydell wrote: > On 28 March 2014 18:45, Christoffer Dall <christoffer.dall@linaro.org> wrote: > > ARM VM System Specification > > =========================== > > > > > 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]. > > I just noticed that this doesn't mandate that the platform > provides an RTC. As I understand it, the UEFI spec mandates > that there's an RTC (could somebody more familiar with UEFI > than me confirm/deny that?) so we should probably put one here. Isn't that already done transitively via the requirement to provide a UEFI environment? I thought the RTC was exposed via UEFI Runtime Service, in which case it's mostly a hypervisor internal issue how time is provided to the (hypervisor provided) UEFI implementation, the guest OS just uses the runtime services interfaces. Given that do we also need to standardise on a guest OS visible clock device too? I'm not sure if we do or not, but if yes then I have a couple of comments on the suggested wording (you can probably guess what they are going to be...): > Suggested wording: > > RTC: The platform should provide a real time clock, based > on an emulated pl031 or mc146818. We would need to include the Xen PV wallclock here too. > and in the guest-support section later: > > The guest OS must include support for pl031 and mc146818 RTC. and here. Ian. ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-10 15:03 ` Ian Campbell 0 siblings, 0 replies; 111+ messages in thread From: Ian Campbell @ 2014-06-10 15:03 UTC (permalink / raw) To: linux-arm-kernel On Tue, 2014-06-10 at 15:42 +0100, Peter Maydell wrote: > On 28 March 2014 18:45, Christoffer Dall <christoffer.dall@linaro.org> wrote: > > ARM VM System Specification > > =========================== > > > > > 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]. > > I just noticed that this doesn't mandate that the platform > provides an RTC. As I understand it, the UEFI spec mandates > that there's an RTC (could somebody more familiar with UEFI > than me confirm/deny that?) so we should probably put one here. Isn't that already done transitively via the requirement to provide a UEFI environment? I thought the RTC was exposed via UEFI Runtime Service, in which case it's mostly a hypervisor internal issue how time is provided to the (hypervisor provided) UEFI implementation, the guest OS just uses the runtime services interfaces. Given that do we also need to standardise on a guest OS visible clock device too? I'm not sure if we do or not, but if yes then I have a couple of comments on the suggested wording (you can probably guess what they are going to be...): > Suggested wording: > > RTC: The platform should provide a real time clock, based > on an emulated pl031 or mc146818. We would need to include the Xen PV wallclock here too. > and in the guest-support section later: > > The guest OS must include support for pl031 and mc146818 RTC. and here. Ian. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 14:42 ` Peter Maydell (?) (?) @ 2014-06-10 15:03 ` Ian Campbell -1 siblings, 0 replies; 111+ messages in thread From: Ian Campbell @ 2014-06-10 15:03 UTC (permalink / raw) To: Peter Maydell Cc: cross-distro, kvm-devel, xen-devel, Christoffer Dall, kvmarm, arm-mail-list On Tue, 2014-06-10 at 15:42 +0100, Peter Maydell wrote: > On 28 March 2014 18:45, Christoffer Dall <christoffer.dall@linaro.org> wrote: > > ARM VM System Specification > > =========================== > > > > > 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]. > > I just noticed that this doesn't mandate that the platform > provides an RTC. As I understand it, the UEFI spec mandates > that there's an RTC (could somebody more familiar with UEFI > than me confirm/deny that?) so we should probably put one here. Isn't that already done transitively via the requirement to provide a UEFI environment? I thought the RTC was exposed via UEFI Runtime Service, in which case it's mostly a hypervisor internal issue how time is provided to the (hypervisor provided) UEFI implementation, the guest OS just uses the runtime services interfaces. Given that do we also need to standardise on a guest OS visible clock device too? I'm not sure if we do or not, but if yes then I have a couple of comments on the suggested wording (you can probably guess what they are going to be...): > Suggested wording: > > RTC: The platform should provide a real time clock, based > on an emulated pl031 or mc146818. We would need to include the Xen PV wallclock here too. > and in the guest-support section later: > > The guest OS must include support for pl031 and mc146818 RTC. and here. Ian. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 14:42 ` Peter Maydell @ 2014-06-10 17:00 ` Paolo Bonzini -1 siblings, 0 replies; 111+ messages in thread From: Paolo Bonzini @ 2014-06-10 17:00 UTC (permalink / raw) To: Peter Maydell, Christoffer Dall Cc: cross-distro, arm-mail-list, kvmarm, kvm-devel, xen-devel, Michael Casadevall, Rob Herring, marc.zyngier, Grant Likely, Leif Lindholm, Robie Basak, Stefano Stabellini, Ian Campbell Il 10/06/2014 16:42, Peter Maydell ha scritto: > The guest OS must include support for pl031 and mc146818 RTC. > > (QEMU is going to provide a PL031, because that's the standard > ARM primecell device for this and it's what's in the vexpress. > kvmtool looks like it's going to provide mc146818, because > that's the standard x86 RTC and kvmtool happens to already > emulate that.) Why can't kvmtool add pl031 support? mc146818 is quite complicated to emulate efficiently (without waking up once a second or more). Paolo ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-10 17:00 ` Paolo Bonzini 0 siblings, 0 replies; 111+ messages in thread From: Paolo Bonzini @ 2014-06-10 17:00 UTC (permalink / raw) To: linux-arm-kernel Il 10/06/2014 16:42, Peter Maydell ha scritto: > The guest OS must include support for pl031 and mc146818 RTC. > > (QEMU is going to provide a PL031, because that's the standard > ARM primecell device for this and it's what's in the vexpress. > kvmtool looks like it's going to provide mc146818, because > that's the standard x86 RTC and kvmtool happens to already > emulate that.) Why can't kvmtool add pl031 support? mc146818 is quite complicated to emulate efficiently (without waking up once a second or more). Paolo ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 14:42 ` Peter Maydell ` (3 preceding siblings ...) (?) @ 2014-06-10 17:00 ` Paolo Bonzini -1 siblings, 0 replies; 111+ messages in thread From: Paolo Bonzini @ 2014-06-10 17:00 UTC (permalink / raw) To: Peter Maydell, Christoffer Dall Cc: cross-distro, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, Leif Lindholm, xen-devel, Robie Basak, Stefano Stabellini, Grant Likely, kvmarm, arm-mail-list Il 10/06/2014 16:42, Peter Maydell ha scritto: > The guest OS must include support for pl031 and mc146818 RTC. > > (QEMU is going to provide a PL031, because that's the standard > ARM primecell device for this and it's what's in the vexpress. > kvmtool looks like it's going to provide mc146818, because > that's the standard x86 RTC and kvmtool happens to already > emulate that.) Why can't kvmtool add pl031 support? mc146818 is quite complicated to emulate efficiently (without waking up once a second or more). Paolo ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 14:42 ` Peter Maydell ` (4 preceding siblings ...) (?) @ 2014-06-10 17:04 ` Christopher Covington -1 siblings, 0 replies; 111+ messages in thread From: Christopher Covington @ 2014-06-10 17:04 UTC (permalink / raw) To: Peter Maydell Cc: cross-distro, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, arm-mail-list, Grant Likely, kvmarm, Christoffer Dall Hi Peter, On 06/10/2014 10:42 AM, Peter Maydell wrote: > On 28 March 2014 18:45, Christoffer Dall <christoffer.dall@linaro.org> wrote: >> ARM VM System Specification >> =========================== >> > >> 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]. > > I just noticed that this doesn't mandate that the platform > provides an RTC. As I understand it, the UEFI spec mandates > that there's an RTC (could somebody more familiar with UEFI > than me confirm/deny that?) so we should probably put one here. Pardon my ignorance, but what exactly disqualifies Generic Timer implementations from being used as Real Time Clocks? Thanks, Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 14:42 ` Peter Maydell @ 2014-06-10 17:04 ` Christopher Covington -1 siblings, 0 replies; 111+ messages in thread From: Christopher Covington @ 2014-06-10 17:04 UTC (permalink / raw) To: Peter Maydell Cc: Christoffer Dall, cross-distro, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, Grant Likely, kvmarm, arm-mail-list Hi Peter, On 06/10/2014 10:42 AM, Peter Maydell wrote: > On 28 March 2014 18:45, Christoffer Dall <christoffer.dall@linaro.org> wrote: >> ARM VM System Specification >> =========================== >> > >> 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]. > > I just noticed that this doesn't mandate that the platform > provides an RTC. As I understand it, the UEFI spec mandates > that there's an RTC (could somebody more familiar with UEFI > than me confirm/deny that?) so we should probably put one here. Pardon my ignorance, but what exactly disqualifies Generic Timer implementations from being used as Real Time Clocks? Thanks, Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-10 17:04 ` Christopher Covington 0 siblings, 0 replies; 111+ messages in thread From: Christopher Covington @ 2014-06-10 17:04 UTC (permalink / raw) To: linux-arm-kernel Hi Peter, On 06/10/2014 10:42 AM, Peter Maydell wrote: > On 28 March 2014 18:45, Christoffer Dall <christoffer.dall@linaro.org> wrote: >> ARM VM System Specification >> =========================== >> > >> 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]. > > I just noticed that this doesn't mandate that the platform > provides an RTC. As I understand it, the UEFI spec mandates > that there's an RTC (could somebody more familiar with UEFI > than me confirm/deny that?) so we should probably put one here. Pardon my ignorance, but what exactly disqualifies Generic Timer implementations from being used as Real Time Clocks? Thanks, Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 17:04 ` Christopher Covington (?) @ 2014-06-10 18:08 ` Peter Maydell -1 siblings, 0 replies; 111+ messages in thread From: Peter Maydell @ 2014-06-10 18:08 UTC (permalink / raw) To: Christopher Covington Cc: cross-distro, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, arm-mail-list, Grant Likely, kvmarm, Christoffer Dall On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: > On 06/10/2014 10:42 AM, Peter Maydell wrote: >> I just noticed that this doesn't mandate that the platform >> provides an RTC. As I understand it, the UEFI spec mandates >> that there's an RTC (could somebody more familiar with UEFI >> than me confirm/deny that?) so we should probably put one here. > > Pardon my ignorance, but what exactly disqualifies Generic Timer > implementations from being used as Real Time Clocks? So my naive view was that an RTC actually had to have support for dealing with real (wall) clock time, ie knowing it's 2014 and not 1970. The generic timers are just timers. Or am I wrong and UEFI doesn't really require that? It's also handy if you're booting Linux directly without UEFI, since it means you can actually have a /dev/rtc0 (and QEMU's implementation at least will correctly give you the time based on the host's RTC). thanks -- PMM ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 17:04 ` Christopher Covington @ 2014-06-10 18:08 ` Peter Maydell -1 siblings, 0 replies; 111+ messages in thread From: Peter Maydell @ 2014-06-10 18:08 UTC (permalink / raw) To: Christopher Covington Cc: Christoffer Dall, cross-distro, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, Grant Likely, kvmarm, arm-mail-list On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: > On 06/10/2014 10:42 AM, Peter Maydell wrote: >> I just noticed that this doesn't mandate that the platform >> provides an RTC. As I understand it, the UEFI spec mandates >> that there's an RTC (could somebody more familiar with UEFI >> than me confirm/deny that?) so we should probably put one here. > > Pardon my ignorance, but what exactly disqualifies Generic Timer > implementations from being used as Real Time Clocks? So my naive view was that an RTC actually had to have support for dealing with real (wall) clock time, ie knowing it's 2014 and not 1970. The generic timers are just timers. Or am I wrong and UEFI doesn't really require that? It's also handy if you're booting Linux directly without UEFI, since it means you can actually have a /dev/rtc0 (and QEMU's implementation at least will correctly give you the time based on the host's RTC). thanks -- PMM ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-10 18:08 ` Peter Maydell 0 siblings, 0 replies; 111+ messages in thread From: Peter Maydell @ 2014-06-10 18:08 UTC (permalink / raw) To: linux-arm-kernel On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: > On 06/10/2014 10:42 AM, Peter Maydell wrote: >> I just noticed that this doesn't mandate that the platform >> provides an RTC. As I understand it, the UEFI spec mandates >> that there's an RTC (could somebody more familiar with UEFI >> than me confirm/deny that?) so we should probably put one here. > > Pardon my ignorance, but what exactly disqualifies Generic Timer > implementations from being used as Real Time Clocks? So my naive view was that an RTC actually had to have support for dealing with real (wall) clock time, ie knowing it's 2014 and not 1970. The generic timers are just timers. Or am I wrong and UEFI doesn't really require that? It's also handy if you're booting Linux directly without UEFI, since it means you can actually have a /dev/rtc0 (and QEMU's implementation at least will correctly give you the time based on the host's RTC). thanks -- PMM ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 18:08 ` Peter Maydell (?) @ 2014-06-10 18:56 ` Paolo Bonzini -1 siblings, 0 replies; 111+ messages in thread From: Paolo Bonzini @ 2014-06-10 18:56 UTC (permalink / raw) To: Peter Maydell, Christopher Covington Cc: cross-distro, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, arm-mail-list, Grant Likely, kvmarm, Christoffer Dall Il 10/06/2014 20:08, Peter Maydell ha scritto: > On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: >> On 06/10/2014 10:42 AM, Peter Maydell wrote: >>> I just noticed that this doesn't mandate that the platform >>> provides an RTC. As I understand it, the UEFI spec mandates >>> that there's an RTC (could somebody more familiar with UEFI >>> than me confirm/deny that?) so we should probably put one here. >> >> Pardon my ignorance, but what exactly disqualifies Generic Timer >> implementations from being used as Real Time Clocks? > > So my naive view was that an RTC actually had to have > support for dealing with real (wall) clock time, ie > knowing it's 2014 and not 1970. The generic timers are > just timers. Or am I wrong and UEFI doesn't really > require that? The real-time clock provides four UEFI runtime services (GetTime, SetTime, GetWakeupTime, SetWakeupTime). The spec says that you can return EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be retrieved/set due to a hardware error", but I don't think this is enough to make these two optional. By comparison, GetWakeupTime/SetWakeupTime can also return EFI_UNSUPPORTED. So I agree that the RTC is required in UEFI. Paolo ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 18:08 ` Peter Maydell @ 2014-06-10 18:56 ` Paolo Bonzini -1 siblings, 0 replies; 111+ messages in thread From: Paolo Bonzini @ 2014-06-10 18:56 UTC (permalink / raw) To: Peter Maydell, Christopher Covington Cc: Christoffer Dall, cross-distro, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, Grant Likely, kvmarm, arm-mail-list Il 10/06/2014 20:08, Peter Maydell ha scritto: > On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: >> On 06/10/2014 10:42 AM, Peter Maydell wrote: >>> I just noticed that this doesn't mandate that the platform >>> provides an RTC. As I understand it, the UEFI spec mandates >>> that there's an RTC (could somebody more familiar with UEFI >>> than me confirm/deny that?) so we should probably put one here. >> >> Pardon my ignorance, but what exactly disqualifies Generic Timer >> implementations from being used as Real Time Clocks? > > So my naive view was that an RTC actually had to have > support for dealing with real (wall) clock time, ie > knowing it's 2014 and not 1970. The generic timers are > just timers. Or am I wrong and UEFI doesn't really > require that? The real-time clock provides four UEFI runtime services (GetTime, SetTime, GetWakeupTime, SetWakeupTime). The spec says that you can return EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be retrieved/set due to a hardware error", but I don't think this is enough to make these two optional. By comparison, GetWakeupTime/SetWakeupTime can also return EFI_UNSUPPORTED. So I agree that the RTC is required in UEFI. Paolo ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-10 18:56 ` Paolo Bonzini 0 siblings, 0 replies; 111+ messages in thread From: Paolo Bonzini @ 2014-06-10 18:56 UTC (permalink / raw) To: linux-arm-kernel Il 10/06/2014 20:08, Peter Maydell ha scritto: > On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: >> On 06/10/2014 10:42 AM, Peter Maydell wrote: >>> I just noticed that this doesn't mandate that the platform >>> provides an RTC. As I understand it, the UEFI spec mandates >>> that there's an RTC (could somebody more familiar with UEFI >>> than me confirm/deny that?) so we should probably put one here. >> >> Pardon my ignorance, but what exactly disqualifies Generic Timer >> implementations from being used as Real Time Clocks? > > So my naive view was that an RTC actually had to have > support for dealing with real (wall) clock time, ie > knowing it's 2014 and not 1970. The generic timers are > just timers. Or am I wrong and UEFI doesn't really > require that? The real-time clock provides four UEFI runtime services (GetTime, SetTime, GetWakeupTime, SetWakeupTime). The spec says that you can return EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be retrieved/set due to a hardware error", but I don't think this is enough to make these two optional. By comparison, GetWakeupTime/SetWakeupTime can also return EFI_UNSUPPORTED. So I agree that the RTC is required in UEFI. Paolo ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 18:56 ` Paolo Bonzini @ 2014-06-10 19:18 ` Paolo Bonzini -1 siblings, 0 replies; 111+ messages in thread From: Paolo Bonzini @ 2014-06-10 19:18 UTC (permalink / raw) To: Peter Maydell, Christopher Covington Cc: Christoffer Dall, cross-distro, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, Grant Likely, kvmarm, arm-mail-list Il 10/06/2014 20:56, Paolo Bonzini ha scritto: > Il 10/06/2014 20:08, Peter Maydell ha scritto: >> On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: >>> On 06/10/2014 10:42 AM, Peter Maydell wrote: >>>> I just noticed that this doesn't mandate that the platform >>>> provides an RTC. As I understand it, the UEFI spec mandates >>>> that there's an RTC (could somebody more familiar with UEFI >>>> than me confirm/deny that?) so we should probably put one here. >>> >>> Pardon my ignorance, but what exactly disqualifies Generic Timer >>> implementations from being used as Real Time Clocks? >> >> So my naive view was that an RTC actually had to have >> support for dealing with real (wall) clock time, ie >> knowing it's 2014 and not 1970. The generic timers are >> just timers. Or am I wrong and UEFI doesn't really >> require that? > > The real-time clock provides four UEFI runtime services (GetTime, > SetTime, GetWakeupTime, SetWakeupTime). The spec says that you can > return EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be > retrieved/set due to a hardware error", but I don't think this is enough > to make these two optional. By comparison, GetWakeupTime/SetWakeupTime > can also return EFI_UNSUPPORTED. > > So I agree that the RTC is required in UEFI. ... that said, just like I thought was the case for the serial console, do we need to specify the exact hardware models? We can just say that the VM can expect UEFI boot and runtime services to work. This includes variable services, time services, the serial console protocols and more. It's up to the implementation to provide enough devices to support the firmware, and it's out of this spec's scope to specify the firmware's implementation. Paolo ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-10 19:18 ` Paolo Bonzini 0 siblings, 0 replies; 111+ messages in thread From: Paolo Bonzini @ 2014-06-10 19:18 UTC (permalink / raw) To: linux-arm-kernel Il 10/06/2014 20:56, Paolo Bonzini ha scritto: > Il 10/06/2014 20:08, Peter Maydell ha scritto: >> On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: >>> On 06/10/2014 10:42 AM, Peter Maydell wrote: >>>> I just noticed that this doesn't mandate that the platform >>>> provides an RTC. As I understand it, the UEFI spec mandates >>>> that there's an RTC (could somebody more familiar with UEFI >>>> than me confirm/deny that?) so we should probably put one here. >>> >>> Pardon my ignorance, but what exactly disqualifies Generic Timer >>> implementations from being used as Real Time Clocks? >> >> So my naive view was that an RTC actually had to have >> support for dealing with real (wall) clock time, ie >> knowing it's 2014 and not 1970. The generic timers are >> just timers. Or am I wrong and UEFI doesn't really >> require that? > > The real-time clock provides four UEFI runtime services (GetTime, > SetTime, GetWakeupTime, SetWakeupTime). The spec says that you can > return EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be > retrieved/set due to a hardware error", but I don't think this is enough > to make these two optional. By comparison, GetWakeupTime/SetWakeupTime > can also return EFI_UNSUPPORTED. > > So I agree that the RTC is required in UEFI. ... that said, just like I thought was the case for the serial console, do we need to specify the exact hardware models? We can just say that the VM can expect UEFI boot and runtime services to work. This includes variable services, time services, the serial console protocols and more. It's up to the implementation to provide enough devices to support the firmware, and it's out of this spec's scope to specify the firmware's implementation. Paolo ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 18:56 ` Paolo Bonzini (?) (?) @ 2014-06-10 19:18 ` Paolo Bonzini -1 siblings, 0 replies; 111+ messages in thread From: Paolo Bonzini @ 2014-06-10 19:18 UTC (permalink / raw) To: Peter Maydell, Christopher Covington Cc: cross-distro, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, arm-mail-list, Grant Likely, kvmarm, Christoffer Dall Il 10/06/2014 20:56, Paolo Bonzini ha scritto: > Il 10/06/2014 20:08, Peter Maydell ha scritto: >> On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: >>> On 06/10/2014 10:42 AM, Peter Maydell wrote: >>>> I just noticed that this doesn't mandate that the platform >>>> provides an RTC. As I understand it, the UEFI spec mandates >>>> that there's an RTC (could somebody more familiar with UEFI >>>> than me confirm/deny that?) so we should probably put one here. >>> >>> Pardon my ignorance, but what exactly disqualifies Generic Timer >>> implementations from being used as Real Time Clocks? >> >> So my naive view was that an RTC actually had to have >> support for dealing with real (wall) clock time, ie >> knowing it's 2014 and not 1970. The generic timers are >> just timers. Or am I wrong and UEFI doesn't really >> require that? > > The real-time clock provides four UEFI runtime services (GetTime, > SetTime, GetWakeupTime, SetWakeupTime). The spec says that you can > return EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be > retrieved/set due to a hardware error", but I don't think this is enough > to make these two optional. By comparison, GetWakeupTime/SetWakeupTime > can also return EFI_UNSUPPORTED. > > So I agree that the RTC is required in UEFI. ... that said, just like I thought was the case for the serial console, do we need to specify the exact hardware models? We can just say that the VM can expect UEFI boot and runtime services to work. This includes variable services, time services, the serial console protocols and more. It's up to the implementation to provide enough devices to support the firmware, and it's out of this spec's scope to specify the firmware's implementation. Paolo ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 18:56 ` Paolo Bonzini ` (2 preceding siblings ...) (?) @ 2014-06-10 19:18 ` Paolo Bonzini -1 siblings, 0 replies; 111+ messages in thread From: Paolo Bonzini @ 2014-06-10 19:18 UTC (permalink / raw) To: Peter Maydell, Christopher Covington Cc: cross-distro, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, arm-mail-list, Grant Likely, kvmarm, Christoffer Dall Il 10/06/2014 20:56, Paolo Bonzini ha scritto: > Il 10/06/2014 20:08, Peter Maydell ha scritto: >> On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: >>> On 06/10/2014 10:42 AM, Peter Maydell wrote: >>>> I just noticed that this doesn't mandate that the platform >>>> provides an RTC. As I understand it, the UEFI spec mandates >>>> that there's an RTC (could somebody more familiar with UEFI >>>> than me confirm/deny that?) so we should probably put one here. >>> >>> Pardon my ignorance, but what exactly disqualifies Generic Timer >>> implementations from being used as Real Time Clocks? >> >> So my naive view was that an RTC actually had to have >> support for dealing with real (wall) clock time, ie >> knowing it's 2014 and not 1970. The generic timers are >> just timers. Or am I wrong and UEFI doesn't really >> require that? > > The real-time clock provides four UEFI runtime services (GetTime, > SetTime, GetWakeupTime, SetWakeupTime). The spec says that you can > return EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be > retrieved/set due to a hardware error", but I don't think this is enough > to make these two optional. By comparison, GetWakeupTime/SetWakeupTime > can also return EFI_UNSUPPORTED. > > So I agree that the RTC is required in UEFI. ... that said, just like I thought was the case for the serial console, do we need to specify the exact hardware models? We can just say that the VM can expect UEFI boot and runtime services to work. This includes variable services, time services, the serial console protocols and more. It's up to the implementation to provide enough devices to support the firmware, and it's out of this spec's scope to specify the firmware's implementation. I think even the serial devices should be removed. Paolo ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 18:56 ` Paolo Bonzini @ 2014-06-10 19:18 ` Paolo Bonzini -1 siblings, 0 replies; 111+ messages in thread From: Paolo Bonzini @ 2014-06-10 19:18 UTC (permalink / raw) To: Peter Maydell, Christopher Covington Cc: Christoffer Dall, cross-distro, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, Grant Likely, kvmarm, arm-mail-list Il 10/06/2014 20:56, Paolo Bonzini ha scritto: > Il 10/06/2014 20:08, Peter Maydell ha scritto: >> On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: >>> On 06/10/2014 10:42 AM, Peter Maydell wrote: >>>> I just noticed that this doesn't mandate that the platform >>>> provides an RTC. As I understand it, the UEFI spec mandates >>>> that there's an RTC (could somebody more familiar with UEFI >>>> than me confirm/deny that?) so we should probably put one here. >>> >>> Pardon my ignorance, but what exactly disqualifies Generic Timer >>> implementations from being used as Real Time Clocks? >> >> So my naive view was that an RTC actually had to have >> support for dealing with real (wall) clock time, ie >> knowing it's 2014 and not 1970. The generic timers are >> just timers. Or am I wrong and UEFI doesn't really >> require that? > > The real-time clock provides four UEFI runtime services (GetTime, > SetTime, GetWakeupTime, SetWakeupTime). The spec says that you can > return EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be > retrieved/set due to a hardware error", but I don't think this is enough > to make these two optional. By comparison, GetWakeupTime/SetWakeupTime > can also return EFI_UNSUPPORTED. > > So I agree that the RTC is required in UEFI. ... that said, just like I thought was the case for the serial console, do we need to specify the exact hardware models? We can just say that the VM can expect UEFI boot and runtime services to work. This includes variable services, time services, the serial console protocols and more. It's up to the implementation to provide enough devices to support the firmware, and it's out of this spec's scope to specify the firmware's implementation. I think even the serial devices should be removed. Paolo ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-10 19:18 ` Paolo Bonzini 0 siblings, 0 replies; 111+ messages in thread From: Paolo Bonzini @ 2014-06-10 19:18 UTC (permalink / raw) To: linux-arm-kernel Il 10/06/2014 20:56, Paolo Bonzini ha scritto: > Il 10/06/2014 20:08, Peter Maydell ha scritto: >> On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: >>> On 06/10/2014 10:42 AM, Peter Maydell wrote: >>>> I just noticed that this doesn't mandate that the platform >>>> provides an RTC. As I understand it, the UEFI spec mandates >>>> that there's an RTC (could somebody more familiar with UEFI >>>> than me confirm/deny that?) so we should probably put one here. >>> >>> Pardon my ignorance, but what exactly disqualifies Generic Timer >>> implementations from being used as Real Time Clocks? >> >> So my naive view was that an RTC actually had to have >> support for dealing with real (wall) clock time, ie >> knowing it's 2014 and not 1970. The generic timers are >> just timers. Or am I wrong and UEFI doesn't really >> require that? > > The real-time clock provides four UEFI runtime services (GetTime, > SetTime, GetWakeupTime, SetWakeupTime). The spec says that you can > return EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be > retrieved/set due to a hardware error", but I don't think this is enough > to make these two optional. By comparison, GetWakeupTime/SetWakeupTime > can also return EFI_UNSUPPORTED. > > So I agree that the RTC is required in UEFI. ... that said, just like I thought was the case for the serial console, do we need to specify the exact hardware models? We can just say that the VM can expect UEFI boot and runtime services to work. This includes variable services, time services, the serial console protocols and more. It's up to the implementation to provide enough devices to support the firmware, and it's out of this spec's scope to specify the firmware's implementation. I think even the serial devices should be removed. Paolo ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 19:18 ` Paolo Bonzini (?) @ 2014-06-11 6:54 ` Christoffer Dall -1 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-06-11 6:54 UTC (permalink / raw) To: Paolo Bonzini Cc: Peter Maydell, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, cross-distro, xen-devel, Stefano Stabellini, Christopher Covington, Grant Likely, kvmarm, arm-mail-list On Tue, Jun 10, 2014 at 09:18:34PM +0200, Paolo Bonzini wrote: > Il 10/06/2014 20:56, Paolo Bonzini ha scritto: > >Il 10/06/2014 20:08, Peter Maydell ha scritto: > >>On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: > >>>On 06/10/2014 10:42 AM, Peter Maydell wrote: > >>>>I just noticed that this doesn't mandate that the platform > >>>>provides an RTC. As I understand it, the UEFI spec mandates > >>>>that there's an RTC (could somebody more familiar with UEFI > >>>>than me confirm/deny that?) so we should probably put one here. > >>> > >>>Pardon my ignorance, but what exactly disqualifies Generic Timer > >>>implementations from being used as Real Time Clocks? > >> > >>So my naive view was that an RTC actually had to have > >>support for dealing with real (wall) clock time, ie > >>knowing it's 2014 and not 1970. The generic timers are > >>just timers. Or am I wrong and UEFI doesn't really > >>require that? > > > >The real-time clock provides four UEFI runtime services (GetTime, > >SetTime, GetWakeupTime, SetWakeupTime). The spec says that you can > >return EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be > >retrieved/set due to a hardware error", but I don't think this is enough > >to make these two optional. By comparison, GetWakeupTime/SetWakeupTime > >can also return EFI_UNSUPPORTED. > > > >So I agree that the RTC is required in UEFI. > > ... that said, just like I thought was the case for the serial > console, do we need to specify the exact hardware models? > > We can just say that the VM can expect UEFI boot and runtime > services to work. This includes variable services, time services, > the serial console protocols and more. It's up to the > implementation to provide enough devices to support the firmware, > and it's out of this spec's scope to specify the firmware's > implementation. > > I think even the serial devices should be removed. > The problem is that the most common user problem with ARM VMs are that they boot the thing, and then get no output. So we wanted some way to make sure we know that the kernel should be able to print to a console. UEFI does provide DBG2 output, but that's only during boot time service (so I'm told), and we need to mandate something that will work when the kernel boots. If kernels actually do use the UEFI runtime services and have no need for direct access to an RTC when runing in a UEFI compliant system, then I agree with not specifying the hardware details. -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 19:18 ` Paolo Bonzini @ 2014-06-11 6:54 ` Christoffer Dall -1 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-06-11 6:54 UTC (permalink / raw) To: Paolo Bonzini Cc: Peter Maydell, Christopher Covington, cross-distro, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, Grant Likely, kvmarm, arm-mail-list On Tue, Jun 10, 2014 at 09:18:34PM +0200, Paolo Bonzini wrote: > Il 10/06/2014 20:56, Paolo Bonzini ha scritto: > >Il 10/06/2014 20:08, Peter Maydell ha scritto: > >>On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: > >>>On 06/10/2014 10:42 AM, Peter Maydell wrote: > >>>>I just noticed that this doesn't mandate that the platform > >>>>provides an RTC. As I understand it, the UEFI spec mandates > >>>>that there's an RTC (could somebody more familiar with UEFI > >>>>than me confirm/deny that?) so we should probably put one here. > >>> > >>>Pardon my ignorance, but what exactly disqualifies Generic Timer > >>>implementations from being used as Real Time Clocks? > >> > >>So my naive view was that an RTC actually had to have > >>support for dealing with real (wall) clock time, ie > >>knowing it's 2014 and not 1970. The generic timers are > >>just timers. Or am I wrong and UEFI doesn't really > >>require that? > > > >The real-time clock provides four UEFI runtime services (GetTime, > >SetTime, GetWakeupTime, SetWakeupTime). The spec says that you can > >return EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be > >retrieved/set due to a hardware error", but I don't think this is enough > >to make these two optional. By comparison, GetWakeupTime/SetWakeupTime > >can also return EFI_UNSUPPORTED. > > > >So I agree that the RTC is required in UEFI. > > ... that said, just like I thought was the case for the serial > console, do we need to specify the exact hardware models? > > We can just say that the VM can expect UEFI boot and runtime > services to work. This includes variable services, time services, > the serial console protocols and more. It's up to the > implementation to provide enough devices to support the firmware, > and it's out of this spec's scope to specify the firmware's > implementation. > > I think even the serial devices should be removed. > The problem is that the most common user problem with ARM VMs are that they boot the thing, and then get no output. So we wanted some way to make sure we know that the kernel should be able to print to a console. UEFI does provide DBG2 output, but that's only during boot time service (so I'm told), and we need to mandate something that will work when the kernel boots. If kernels actually do use the UEFI runtime services and have no need for direct access to an RTC when runing in a UEFI compliant system, then I agree with not specifying the hardware details. -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-11 6:54 ` Christoffer Dall 0 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-06-11 6:54 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jun 10, 2014 at 09:18:34PM +0200, Paolo Bonzini wrote: > Il 10/06/2014 20:56, Paolo Bonzini ha scritto: > >Il 10/06/2014 20:08, Peter Maydell ha scritto: > >>On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: > >>>On 06/10/2014 10:42 AM, Peter Maydell wrote: > >>>>I just noticed that this doesn't mandate that the platform > >>>>provides an RTC. As I understand it, the UEFI spec mandates > >>>>that there's an RTC (could somebody more familiar with UEFI > >>>>than me confirm/deny that?) so we should probably put one here. > >>> > >>>Pardon my ignorance, but what exactly disqualifies Generic Timer > >>>implementations from being used as Real Time Clocks? > >> > >>So my naive view was that an RTC actually had to have > >>support for dealing with real (wall) clock time, ie > >>knowing it's 2014 and not 1970. The generic timers are > >>just timers. Or am I wrong and UEFI doesn't really > >>require that? > > > >The real-time clock provides four UEFI runtime services (GetTime, > >SetTime, GetWakeupTime, SetWakeupTime). The spec says that you can > >return EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be > >retrieved/set due to a hardware error", but I don't think this is enough > >to make these two optional. By comparison, GetWakeupTime/SetWakeupTime > >can also return EFI_UNSUPPORTED. > > > >So I agree that the RTC is required in UEFI. > > ... that said, just like I thought was the case for the serial > console, do we need to specify the exact hardware models? > > We can just say that the VM can expect UEFI boot and runtime > services to work. This includes variable services, time services, > the serial console protocols and more. It's up to the > implementation to provide enough devices to support the firmware, > and it's out of this spec's scope to specify the firmware's > implementation. > > I think even the serial devices should be removed. > The problem is that the most common user problem with ARM VMs are that they boot the thing, and then get no output. So we wanted some way to make sure we know that the kernel should be able to print to a console. UEFI does provide DBG2 output, but that's only during boot time service (so I'm told), and we need to mandate something that will work when the kernel boots. If kernels actually do use the UEFI runtime services and have no need for direct access to an RTC when runing in a UEFI compliant system, then I agree with not specifying the hardware details. -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 6:54 ` Christoffer Dall (?) @ 2014-06-11 8:16 ` Paolo Bonzini -1 siblings, 0 replies; 111+ messages in thread From: Paolo Bonzini @ 2014-06-11 8:16 UTC (permalink / raw) To: Christoffer Dall Cc: Peter Maydell, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, cross-distro, xen-devel, Stefano Stabellini, Christopher Covington, Grant Likely, kvmarm, arm-mail-list Il 11/06/2014 08:54, Christoffer Dall ha scritto: > The problem is that the most common user problem with ARM VMs are that > they boot the thing, and then get no output. So we wanted some way to > make sure we know that the kernel should be able to print to a console. > > UEFI does provide DBG2 output, but that's only during boot time service > (so I'm told), and we need to mandate something that will work when > the kernel boots. Doh, indeed the console is not part of run-time services (so it's not even available for earlyprintk). > If kernels actually do use the UEFI runtime services and have no need > for direct access to an RTC when runing in a UEFI compliant system, then > I agree with not specifying the hardware details. The RTC is not needed for ordinary operation of the kernel and, in the current kernel, the EFI RTC driver is only used for IA64. However, it seems to be platform independent. I'll give it a shot (on x86, since that's the only architecture for which I know how to get UEFI firmware). Paolo ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 6:54 ` Christoffer Dall @ 2014-06-11 8:16 ` Paolo Bonzini -1 siblings, 0 replies; 111+ messages in thread From: Paolo Bonzini @ 2014-06-11 8:16 UTC (permalink / raw) To: Christoffer Dall Cc: Peter Maydell, Christopher Covington, cross-distro, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, Grant Likely, kvmarm, arm-mail-list Il 11/06/2014 08:54, Christoffer Dall ha scritto: > The problem is that the most common user problem with ARM VMs are that > they boot the thing, and then get no output. So we wanted some way to > make sure we know that the kernel should be able to print to a console. > > UEFI does provide DBG2 output, but that's only during boot time service > (so I'm told), and we need to mandate something that will work when > the kernel boots. Doh, indeed the console is not part of run-time services (so it's not even available for earlyprintk). > If kernels actually do use the UEFI runtime services and have no need > for direct access to an RTC when runing in a UEFI compliant system, then > I agree with not specifying the hardware details. The RTC is not needed for ordinary operation of the kernel and, in the current kernel, the EFI RTC driver is only used for IA64. However, it seems to be platform independent. I'll give it a shot (on x86, since that's the only architecture for which I know how to get UEFI firmware). Paolo ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-11 8:16 ` Paolo Bonzini 0 siblings, 0 replies; 111+ messages in thread From: Paolo Bonzini @ 2014-06-11 8:16 UTC (permalink / raw) To: linux-arm-kernel Il 11/06/2014 08:54, Christoffer Dall ha scritto: > The problem is that the most common user problem with ARM VMs are that > they boot the thing, and then get no output. So we wanted some way to > make sure we know that the kernel should be able to print to a console. > > UEFI does provide DBG2 output, but that's only during boot time service > (so I'm told), and we need to mandate something that will work when > the kernel boots. Doh, indeed the console is not part of run-time services (so it's not even available for earlyprintk). > If kernels actually do use the UEFI runtime services and have no need > for direct access to an RTC when runing in a UEFI compliant system, then > I agree with not specifying the hardware details. The RTC is not needed for ordinary operation of the kernel and, in the current kernel, the EFI RTC driver is only used for IA64. However, it seems to be platform independent. I'll give it a shot (on x86, since that's the only architecture for which I know how to get UEFI firmware). Paolo ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 8:16 ` Paolo Bonzini (?) @ 2014-06-11 9:06 ` Arnd Bergmann -1 siblings, 0 replies; 111+ messages in thread From: Arnd Bergmann @ 2014-06-11 9:06 UTC (permalink / raw) To: linux-arm-kernel Cc: Michael Casadevall, Ian Campbell, kvm-devel, Peter Maydell, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, cross-distro, Grant Likely, Paolo Bonzini, kvmarm, Christoffer Dall, Christopher Covington On Wednesday 11 June 2014 10:16:03 Paolo Bonzini wrote: > > > If kernels actually do use the UEFI runtime services and have no need > > for direct access to an RTC when runing in a UEFI compliant system, then > > I agree with not specifying the hardware details. > > The RTC is not needed for ordinary operation of the kernel and, in the > current kernel, the EFI RTC driver is only used for IA64. However, it > seems to be platform independent. I'll give it a shot (on x86, since > that's the only architecture for which I know how to get UEFI firmware). Using the EFI RTC seems appropriate for ARM, as it's a reasonable abstraction that should work with any hypervisor. I suspect the only reason we don't use it on x86 is that we know which RTC hardware we have and the kernel comes with a mandatory driver already. Arnd ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 8:16 ` Paolo Bonzini @ 2014-06-11 9:06 ` Arnd Bergmann -1 siblings, 0 replies; 111+ messages in thread From: Arnd Bergmann @ 2014-06-11 9:06 UTC (permalink / raw) To: linux-arm-kernel Cc: Paolo Bonzini, Christoffer Dall, Peter Maydell, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, cross-distro, xen-devel, Stefano Stabellini, Christopher Covington, Grant Likely, kvmarm On Wednesday 11 June 2014 10:16:03 Paolo Bonzini wrote: > > > If kernels actually do use the UEFI runtime services and have no need > > for direct access to an RTC when runing in a UEFI compliant system, then > > I agree with not specifying the hardware details. > > The RTC is not needed for ordinary operation of the kernel and, in the > current kernel, the EFI RTC driver is only used for IA64. However, it > seems to be platform independent. I'll give it a shot (on x86, since > that's the only architecture for which I know how to get UEFI firmware). Using the EFI RTC seems appropriate for ARM, as it's a reasonable abstraction that should work with any hypervisor. I suspect the only reason we don't use it on x86 is that we know which RTC hardware we have and the kernel comes with a mandatory driver already. Arnd ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-11 9:06 ` Arnd Bergmann 0 siblings, 0 replies; 111+ messages in thread From: Arnd Bergmann @ 2014-06-11 9:06 UTC (permalink / raw) To: linux-arm-kernel On Wednesday 11 June 2014 10:16:03 Paolo Bonzini wrote: > > > If kernels actually do use the UEFI runtime services and have no need > > for direct access to an RTC when runing in a UEFI compliant system, then > > I agree with not specifying the hardware details. > > The RTC is not needed for ordinary operation of the kernel and, in the > current kernel, the EFI RTC driver is only used for IA64. However, it > seems to be platform independent. I'll give it a shot (on x86, since > that's the only architecture for which I know how to get UEFI firmware). Using the EFI RTC seems appropriate for ARM, as it's a reasonable abstraction that should work with any hypervisor. I suspect the only reason we don't use it on x86 is that we know which RTC hardware we have and the kernel comes with a mandatory driver already. Arnd ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 9:06 ` Arnd Bergmann (?) @ 2014-06-30 16:19 ` Jon Masters -1 siblings, 0 replies; 111+ messages in thread From: Jon Masters @ 2014-06-30 16:19 UTC (permalink / raw) To: Arnd Bergmann, linux-arm-kernel Cc: Michael Casadevall, Ian Campbell, kvm-devel, Peter Maydell, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, cross-distro, Grant Likely, Paolo Bonzini, kvmarm, Christoffer Dall, Christopher Covington On 6/11/14, 5:06 AM, Arnd Bergmann wrote: > On Wednesday 11 June 2014 10:16:03 Paolo Bonzini wrote: >> >>> If kernels actually do use the UEFI runtime services and have no need >>> for direct access to an RTC when runing in a UEFI compliant system, then >>> I agree with not specifying the hardware details. >> >> The RTC is not needed for ordinary operation of the kernel and, in the >> current kernel, the EFI RTC driver is only used for IA64. However, it >> seems to be platform independent. I'll give it a shot (on x86, since >> that's the only architecture for which I know how to get UEFI firmware). > > Using the EFI RTC seems appropriate for ARM, as it's a reasonable > abstraction that should work with any hypervisor. I suspect the only > reason we don't use it on x86 is that we know which RTC hardware we > have and the kernel comes with a mandatory driver already. (sorry for delay in responding to this thread) Indeed. We should use the EFI RTC driver in general, rather than push for many individual RTC drivers on aarch64 systems that are EFI enabled. Within Red Hat, we currently have EFI Runtime Services live in many of our labs and are using the EFI RTC. This is the way forward. Jon. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 9:06 ` Arnd Bergmann @ 2014-06-30 16:19 ` Jon Masters -1 siblings, 0 replies; 111+ messages in thread From: Jon Masters @ 2014-06-30 16:19 UTC (permalink / raw) To: Arnd Bergmann, linux-arm-kernel Cc: Michael Casadevall, Ian Campbell, kvm-devel, Peter Maydell, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, cross-distro, Grant Likely, Paolo Bonzini, kvmarm, Christoffer Dall, Christopher Covington On 6/11/14, 5:06 AM, Arnd Bergmann wrote: > On Wednesday 11 June 2014 10:16:03 Paolo Bonzini wrote: >> >>> If kernels actually do use the UEFI runtime services and have no need >>> for direct access to an RTC when runing in a UEFI compliant system, then >>> I agree with not specifying the hardware details. >> >> The RTC is not needed for ordinary operation of the kernel and, in the >> current kernel, the EFI RTC driver is only used for IA64. However, it >> seems to be platform independent. I'll give it a shot (on x86, since >> that's the only architecture for which I know how to get UEFI firmware). > > Using the EFI RTC seems appropriate for ARM, as it's a reasonable > abstraction that should work with any hypervisor. I suspect the only > reason we don't use it on x86 is that we know which RTC hardware we > have and the kernel comes with a mandatory driver already. (sorry for delay in responding to this thread) Indeed. We should use the EFI RTC driver in general, rather than push for many individual RTC drivers on aarch64 systems that are EFI enabled. Within Red Hat, we currently have EFI Runtime Services live in many of our labs and are using the EFI RTC. This is the way forward. Jon. ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-30 16:19 ` Jon Masters 0 siblings, 0 replies; 111+ messages in thread From: Jon Masters @ 2014-06-30 16:19 UTC (permalink / raw) To: linux-arm-kernel On 6/11/14, 5:06 AM, Arnd Bergmann wrote: > On Wednesday 11 June 2014 10:16:03 Paolo Bonzini wrote: >> >>> If kernels actually do use the UEFI runtime services and have no need >>> for direct access to an RTC when runing in a UEFI compliant system, then >>> I agree with not specifying the hardware details. >> >> The RTC is not needed for ordinary operation of the kernel and, in the >> current kernel, the EFI RTC driver is only used for IA64. However, it >> seems to be platform independent. I'll give it a shot (on x86, since >> that's the only architecture for which I know how to get UEFI firmware). > > Using the EFI RTC seems appropriate for ARM, as it's a reasonable > abstraction that should work with any hypervisor. I suspect the only > reason we don't use it on x86 is that we know which RTC hardware we > have and the kernel comes with a mandatory driver already. (sorry for delay in responding to this thread) Indeed. We should use the EFI RTC driver in general, rather than push for many individual RTC drivers on aarch64 systems that are EFI enabled. Within Red Hat, we currently have EFI Runtime Services live in many of our labs and are using the EFI RTC. This is the way forward. Jon. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-30 16:19 ` Jon Masters @ 2014-06-30 20:46 ` Christoffer Dall -1 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-06-30 20:46 UTC (permalink / raw) To: Jon Masters Cc: Arnd Bergmann, linux-arm-kernel, Paolo Bonzini, Peter Maydell, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, cross-distro, xen-devel, Stefano Stabellini, Christopher Covington, Grant Likely, kvmarm On Mon, Jun 30, 2014 at 12:19:15PM -0400, Jon Masters wrote: > On 6/11/14, 5:06 AM, Arnd Bergmann wrote: > >On Wednesday 11 June 2014 10:16:03 Paolo Bonzini wrote: > >> > >>>If kernels actually do use the UEFI runtime services and have no need > >>>for direct access to an RTC when runing in a UEFI compliant system, then > >>>I agree with not specifying the hardware details. > >> > >>The RTC is not needed for ordinary operation of the kernel and, in the > >>current kernel, the EFI RTC driver is only used for IA64. However, it > >>seems to be platform independent. I'll give it a shot (on x86, since > >>that's the only architecture for which I know how to get UEFI firmware). > > > >Using the EFI RTC seems appropriate for ARM, as it's a reasonable > >abstraction that should work with any hypervisor. I suspect the only > >reason we don't use it on x86 is that we know which RTC hardware we > >have and the kernel comes with a mandatory driver already. > > (sorry for delay in responding to this thread) > > Indeed. We should use the EFI RTC driver in general, rather than > push for many individual RTC drivers on aarch64 systems that are EFI > enabled. Within Red Hat, we currently have EFI Runtime Services live > in many of our labs and are using the EFI RTC. This is the way > forward. > Seems like we should stick a note in there about being UEFI compatible requires an RTC. We went this far before Peter raised the issue with noone else realizing it, so it seems like a good idea to me. -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-30 20:46 ` Christoffer Dall 0 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-06-30 20:46 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jun 30, 2014 at 12:19:15PM -0400, Jon Masters wrote: > On 6/11/14, 5:06 AM, Arnd Bergmann wrote: > >On Wednesday 11 June 2014 10:16:03 Paolo Bonzini wrote: > >> > >>>If kernels actually do use the UEFI runtime services and have no need > >>>for direct access to an RTC when runing in a UEFI compliant system, then > >>>I agree with not specifying the hardware details. > >> > >>The RTC is not needed for ordinary operation of the kernel and, in the > >>current kernel, the EFI RTC driver is only used for IA64. However, it > >>seems to be platform independent. I'll give it a shot (on x86, since > >>that's the only architecture for which I know how to get UEFI firmware). > > > >Using the EFI RTC seems appropriate for ARM, as it's a reasonable > >abstraction that should work with any hypervisor. I suspect the only > >reason we don't use it on x86 is that we know which RTC hardware we > >have and the kernel comes with a mandatory driver already. > > (sorry for delay in responding to this thread) > > Indeed. We should use the EFI RTC driver in general, rather than > push for many individual RTC drivers on aarch64 systems that are EFI > enabled. Within Red Hat, we currently have EFI Runtime Services live > in many of our labs and are using the EFI RTC. This is the way > forward. > Seems like we should stick a note in there about being UEFI compatible requires an RTC. We went this far before Peter raised the issue with noone else realizing it, so it seems like a good idea to me. -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-30 20:46 ` Christoffer Dall (?) @ 2014-06-30 21:14 ` Peter Maydell -1 siblings, 0 replies; 111+ messages in thread From: Peter Maydell @ 2014-06-30 21:14 UTC (permalink / raw) To: Christoffer Dall Cc: Michael Casadevall, Arnd Bergmann, kvm-devel, Rob Herring, marc.zyngier, xen-devel, Grant Likely, Christopher Covington, Stefano Stabellini, cross-distro, Jon Masters, Paolo Bonzini, kvmarm, arm-mail-list, Ian Campbell On 30 June 2014 21:46, Christoffer Dall <christoffer.dall@linaro.org> wrote: > Seems like we should stick a note in there about being UEFI compatible > requires an RTC. We went this far before Peter raised the issue with > noone else realizing it, so it seems like a good idea to me. How about: ===== Guest OSes in the VM image should rely on the UEFI RTC API for real time clock services. (To provide that API, the VM system will likely need to implement some real time clock device, but the details of these are a private implementation issue between it and its associated UEFI implementation.) ===== ? thanks -- PMM ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-30 20:46 ` Christoffer Dall @ 2014-06-30 21:14 ` Peter Maydell -1 siblings, 0 replies; 111+ messages in thread From: Peter Maydell @ 2014-06-30 21:14 UTC (permalink / raw) To: Christoffer Dall Cc: Jon Masters, Arnd Bergmann, arm-mail-list, Paolo Bonzini, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, cross-distro, xen-devel, Stefano Stabellini, Christopher Covington, Grant Likely, kvmarm On 30 June 2014 21:46, Christoffer Dall <christoffer.dall@linaro.org> wrote: > Seems like we should stick a note in there about being UEFI compatible > requires an RTC. We went this far before Peter raised the issue with > noone else realizing it, so it seems like a good idea to me. How about: ===== Guest OSes in the VM image should rely on the UEFI RTC API for real time clock services. (To provide that API, the VM system will likely need to implement some real time clock device, but the details of these are a private implementation issue between it and its associated UEFI implementation.) ===== ? thanks -- PMM ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-30 21:14 ` Peter Maydell 0 siblings, 0 replies; 111+ messages in thread From: Peter Maydell @ 2014-06-30 21:14 UTC (permalink / raw) To: linux-arm-kernel On 30 June 2014 21:46, Christoffer Dall <christoffer.dall@linaro.org> wrote: > Seems like we should stick a note in there about being UEFI compatible > requires an RTC. We went this far before Peter raised the issue with > noone else realizing it, so it seems like a good idea to me. How about: ===== Guest OSes in the VM image should rely on the UEFI RTC API for real time clock services. (To provide that API, the VM system will likely need to implement some real time clock device, but the details of these are a private implementation issue between it and its associated UEFI implementation.) ===== ? thanks -- PMM ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-30 21:14 ` Peter Maydell @ 2014-07-01 17:03 ` Stefano Stabellini -1 siblings, 0 replies; 111+ messages in thread From: Stefano Stabellini @ 2014-07-01 17:03 UTC (permalink / raw) To: Peter Maydell Cc: Christoffer Dall, Jon Masters, Arnd Bergmann, arm-mail-list, Paolo Bonzini, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, cross-distro, xen-devel, Stefano Stabellini, Christopher Covington, Grant Likely, kvmarm On Mon, 30 Jun 2014, Peter Maydell wrote: > On 30 June 2014 21:46, Christoffer Dall <christoffer.dall@linaro.org> wrote: > > Seems like we should stick a note in there about being UEFI compatible > > requires an RTC. We went this far before Peter raised the issue with > > noone else realizing it, so it seems like a good idea to me. > > How about: > ===== > Guest OSes in the VM image should rely on the UEFI RTC API for > real time clock services. (To provide that API, the VM system will > likely need to implement some real time clock device, but the > details of these are a private implementation issue between it > and its associated UEFI implementation.) I don't see why we need to add the text within brackets: it is out of scope for this document. ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-07-01 17:03 ` Stefano Stabellini 0 siblings, 0 replies; 111+ messages in thread From: Stefano Stabellini @ 2014-07-01 17:03 UTC (permalink / raw) To: linux-arm-kernel On Mon, 30 Jun 2014, Peter Maydell wrote: > On 30 June 2014 21:46, Christoffer Dall <christoffer.dall@linaro.org> wrote: > > Seems like we should stick a note in there about being UEFI compatible > > requires an RTC. We went this far before Peter raised the issue with > > noone else realizing it, so it seems like a good idea to me. > > How about: > ===== > Guest OSes in the VM image should rely on the UEFI RTC API for > real time clock services. (To provide that API, the VM system will > likely need to implement some real time clock device, but the > details of these are a private implementation issue between it > and its associated UEFI implementation.) I don't see why we need to add the text within brackets: it is out of scope for this document. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-07-01 17:03 ` Stefano Stabellini (?) @ 2014-07-01 17:10 ` Peter Maydell -1 siblings, 0 replies; 111+ messages in thread From: Peter Maydell @ 2014-07-01 17:10 UTC (permalink / raw) To: Stefano Stabellini Cc: Michael Casadevall, Ian Campbell, Arnd Bergmann, Rob Herring, marc.zyngier, cross-distro, xen-devel, Grant Likely, Stefano Stabellini, arm-mail-list, kvm-devel, Jon Masters, Paolo Bonzini, kvmarm, Christoffer Dall, Christopher Covington On 1 July 2014 18:03, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote: > On Mon, 30 Jun 2014, Peter Maydell wrote: >> How about: >> ===== >> Guest OSes in the VM image should rely on the UEFI RTC API for >> real time clock services. (To provide that API, the VM system will >> likely need to implement some real time clock device, but the >> details of these are a private implementation issue between it >> and its associated UEFI implementation.) > > I don't see why we need to add the text within brackets: it is out of > scope for this document. The intention is to be an informative note, not normative text (I'm happy if we want to format the text to make that clearer, with some sort of NOTE: markup). I'd like VM implementors reading this spec to make the correct decisions even if they don't happen to know inside-out the details of the UEFI specification and what exactly UEFI demands of the hardware, and I think it's worth adding the occasional clarifying sentence even if it doesn't strictly speaking add any extra rules to the specification. thanks -- PMM ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-07-01 17:03 ` Stefano Stabellini @ 2014-07-01 17:10 ` Peter Maydell -1 siblings, 0 replies; 111+ messages in thread From: Peter Maydell @ 2014-07-01 17:10 UTC (permalink / raw) To: Stefano Stabellini Cc: Christoffer Dall, Jon Masters, Arnd Bergmann, arm-mail-list, Paolo Bonzini, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, cross-distro, xen-devel, Stefano Stabellini, Christopher Covington, Grant Likely, kvmarm On 1 July 2014 18:03, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote: > On Mon, 30 Jun 2014, Peter Maydell wrote: >> How about: >> ===== >> Guest OSes in the VM image should rely on the UEFI RTC API for >> real time clock services. (To provide that API, the VM system will >> likely need to implement some real time clock device, but the >> details of these are a private implementation issue between it >> and its associated UEFI implementation.) > > I don't see why we need to add the text within brackets: it is out of > scope for this document. The intention is to be an informative note, not normative text (I'm happy if we want to format the text to make that clearer, with some sort of NOTE: markup). I'd like VM implementors reading this spec to make the correct decisions even if they don't happen to know inside-out the details of the UEFI specification and what exactly UEFI demands of the hardware, and I think it's worth adding the occasional clarifying sentence even if it doesn't strictly speaking add any extra rules to the specification. thanks -- PMM ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-07-01 17:10 ` Peter Maydell 0 siblings, 0 replies; 111+ messages in thread From: Peter Maydell @ 2014-07-01 17:10 UTC (permalink / raw) To: linux-arm-kernel On 1 July 2014 18:03, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote: > On Mon, 30 Jun 2014, Peter Maydell wrote: >> How about: >> ===== >> Guest OSes in the VM image should rely on the UEFI RTC API for >> real time clock services. (To provide that API, the VM system will >> likely need to implement some real time clock device, but the >> details of these are a private implementation issue between it >> and its associated UEFI implementation.) > > I don't see why we need to add the text within brackets: it is out of > scope for this document. The intention is to be an informative note, not normative text (I'm happy if we want to format the text to make that clearer, with some sort of NOTE: markup). I'd like VM implementors reading this spec to make the correct decisions even if they don't happen to know inside-out the details of the UEFI specification and what exactly UEFI demands of the hardware, and I think it's worth adding the occasional clarifying sentence even if it doesn't strictly speaking add any extra rules to the specification. thanks -- PMM ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-07-01 17:10 ` Peter Maydell (?) @ 2014-07-02 10:13 ` Christoffer Dall -1 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-07-02 10:13 UTC (permalink / raw) To: Peter Maydell Cc: Michael Casadevall, Ian Campbell, Arnd Bergmann, Stefano Stabellini, marc.zyngier, Rob Herring, xen-devel, Grant Likely, Stefano Stabellini, cross-distro, kvm-devel, Jon Masters, Paolo Bonzini, kvmarm, arm-mail-list, Christopher Covington On Tue, Jul 01, 2014 at 06:10:19PM +0100, Peter Maydell wrote: > On 1 July 2014 18:03, Stefano Stabellini > <stefano.stabellini@eu.citrix.com> wrote: > > On Mon, 30 Jun 2014, Peter Maydell wrote: > >> How about: > >> ===== > >> Guest OSes in the VM image should rely on the UEFI RTC API for > >> real time clock services. (To provide that API, the VM system will > >> likely need to implement some real time clock device, but the > >> details of these are a private implementation issue between it > >> and its associated UEFI implementation.) > > > > I don't see why we need to add the text within brackets: it is out of > > scope for this document. > > The intention is to be an informative note, not normative text > (I'm happy if we want to format the text to make that clearer, > with some sort of NOTE: markup). I'd like VM implementors > reading this spec to make the correct decisions even if they > don't happen to know inside-out the details of the UEFI > specification and what exactly UEFI demands of the hardware, > and I think it's worth adding the occasional clarifying sentence > even if it doesn't strictly speaking add any extra rules to the > specification. > That's also the approach we've taken so far elsewhere in the document, so I think it's useful. -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-07-01 17:10 ` Peter Maydell @ 2014-07-02 10:13 ` Christoffer Dall -1 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-07-02 10:13 UTC (permalink / raw) To: Peter Maydell Cc: Stefano Stabellini, Jon Masters, Arnd Bergmann, arm-mail-list, Paolo Bonzini, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, cross-distro, xen-devel, Stefano Stabellini, Christopher Covington, Grant Likely, kvmarm On Tue, Jul 01, 2014 at 06:10:19PM +0100, Peter Maydell wrote: > On 1 July 2014 18:03, Stefano Stabellini > <stefano.stabellini@eu.citrix.com> wrote: > > On Mon, 30 Jun 2014, Peter Maydell wrote: > >> How about: > >> ===== > >> Guest OSes in the VM image should rely on the UEFI RTC API for > >> real time clock services. (To provide that API, the VM system will > >> likely need to implement some real time clock device, but the > >> details of these are a private implementation issue between it > >> and its associated UEFI implementation.) > > > > I don't see why we need to add the text within brackets: it is out of > > scope for this document. > > The intention is to be an informative note, not normative text > (I'm happy if we want to format the text to make that clearer, > with some sort of NOTE: markup). I'd like VM implementors > reading this spec to make the correct decisions even if they > don't happen to know inside-out the details of the UEFI > specification and what exactly UEFI demands of the hardware, > and I think it's worth adding the occasional clarifying sentence > even if it doesn't strictly speaking add any extra rules to the > specification. > That's also the approach we've taken so far elsewhere in the document, so I think it's useful. -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-07-02 10:13 ` Christoffer Dall 0 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-07-02 10:13 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jul 01, 2014 at 06:10:19PM +0100, Peter Maydell wrote: > On 1 July 2014 18:03, Stefano Stabellini > <stefano.stabellini@eu.citrix.com> wrote: > > On Mon, 30 Jun 2014, Peter Maydell wrote: > >> How about: > >> ===== > >> Guest OSes in the VM image should rely on the UEFI RTC API for > >> real time clock services. (To provide that API, the VM system will > >> likely need to implement some real time clock device, but the > >> details of these are a private implementation issue between it > >> and its associated UEFI implementation.) > > > > I don't see why we need to add the text within brackets: it is out of > > scope for this document. > > The intention is to be an informative note, not normative text > (I'm happy if we want to format the text to make that clearer, > with some sort of NOTE: markup). I'd like VM implementors > reading this spec to make the correct decisions even if they > don't happen to know inside-out the details of the UEFI > specification and what exactly UEFI demands of the hardware, > and I think it's worth adding the occasional clarifying sentence > even if it doesn't strictly speaking add any extra rules to the > specification. > That's also the approach we've taken so far elsewhere in the document, so I think it's useful. -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-30 21:14 ` Peter Maydell (?) (?) @ 2014-07-01 17:03 ` Stefano Stabellini -1 siblings, 0 replies; 111+ messages in thread From: Stefano Stabellini @ 2014-07-01 17:03 UTC (permalink / raw) To: Peter Maydell Cc: Michael Casadevall, Ian Campbell, Arnd Bergmann, Rob Herring, marc.zyngier, cross-distro, xen-devel, Grant Likely, Stefano Stabellini, arm-mail-list, kvm-devel, Jon Masters, Paolo Bonzini, kvmarm, Christoffer Dall, Christopher Covington On Mon, 30 Jun 2014, Peter Maydell wrote: > On 30 June 2014 21:46, Christoffer Dall <christoffer.dall@linaro.org> wrote: > > Seems like we should stick a note in there about being UEFI compatible > > requires an RTC. We went this far before Peter raised the issue with > > noone else realizing it, so it seems like a good idea to me. > > How about: > ===== > Guest OSes in the VM image should rely on the UEFI RTC API for > real time clock services. (To provide that API, the VM system will > likely need to implement some real time clock device, but the > details of these are a private implementation issue between it > and its associated UEFI implementation.) I don't see why we need to add the text within brackets: it is out of scope for this document. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-30 16:19 ` Jon Masters (?) (?) @ 2014-06-30 20:46 ` Christoffer Dall -1 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-06-30 20:46 UTC (permalink / raw) To: Jon Masters Cc: Peter Maydell, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, xen-devel, Arnd Bergmann, cross-distro, Stefano Stabellini, Grant Likely, Paolo Bonzini, kvmarm, linux-arm-kernel, Christopher Covington On Mon, Jun 30, 2014 at 12:19:15PM -0400, Jon Masters wrote: > On 6/11/14, 5:06 AM, Arnd Bergmann wrote: > >On Wednesday 11 June 2014 10:16:03 Paolo Bonzini wrote: > >> > >>>If kernels actually do use the UEFI runtime services and have no need > >>>for direct access to an RTC when runing in a UEFI compliant system, then > >>>I agree with not specifying the hardware details. > >> > >>The RTC is not needed for ordinary operation of the kernel and, in the > >>current kernel, the EFI RTC driver is only used for IA64. However, it > >>seems to be platform independent. I'll give it a shot (on x86, since > >>that's the only architecture for which I know how to get UEFI firmware). > > > >Using the EFI RTC seems appropriate for ARM, as it's a reasonable > >abstraction that should work with any hypervisor. I suspect the only > >reason we don't use it on x86 is that we know which RTC hardware we > >have and the kernel comes with a mandatory driver already. > > (sorry for delay in responding to this thread) > > Indeed. We should use the EFI RTC driver in general, rather than > push for many individual RTC drivers on aarch64 systems that are EFI > enabled. Within Red Hat, we currently have EFI Runtime Services live > in many of our labs and are using the EFI RTC. This is the way > forward. > Seems like we should stick a note in there about being UEFI compatible requires an RTC. We went this far before Peter raised the issue with noone else realizing it, so it seems like a good idea to me. -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 18:56 ` Paolo Bonzini @ 2014-06-11 11:33 ` Grant Likely -1 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-06-11 11:33 UTC (permalink / raw) To: Paolo Bonzini Cc: Peter Maydell, Christopher Covington, Christoffer Dall, cross-distro, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, kvmarm, arm-mail-list On Tue, Jun 10, 2014 at 7:56 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: > Il 10/06/2014 20:08, Peter Maydell ha scritto: > >> On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: >>> >>> On 06/10/2014 10:42 AM, Peter Maydell wrote: >>>> >>>> I just noticed that this doesn't mandate that the platform >>>> provides an RTC. As I understand it, the UEFI spec mandates >>>> that there's an RTC (could somebody more familiar with UEFI >>>> than me confirm/deny that?) so we should probably put one here. >>> >>> >>> Pardon my ignorance, but what exactly disqualifies Generic Timer >>> implementations from being used as Real Time Clocks? >> >> >> So my naive view was that an RTC actually had to have >> support for dealing with real (wall) clock time, ie >> knowing it's 2014 and not 1970. The generic timers are >> just timers. Or am I wrong and UEFI doesn't really >> require that? > > > The real-time clock provides four UEFI runtime services (GetTime, SetTime, > GetWakeupTime, SetWakeupTime). The spec says that you can return > EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be > retrieved/set due to a hardware error", but I don't think this is enough to > make these two optional. By comparison, GetWakeupTime/SetWakeupTime can > also return EFI_UNSUPPORTED. In practical terms, yes the VM needs to provide an RTC interface, but I don't think it needs to appear in this spec, even if the kernel accesses it directly. Portable images should use the UEFI service. g. ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-11 11:33 ` Grant Likely 0 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-06-11 11:33 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jun 10, 2014 at 7:56 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: > Il 10/06/2014 20:08, Peter Maydell ha scritto: > >> On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: >>> >>> On 06/10/2014 10:42 AM, Peter Maydell wrote: >>>> >>>> I just noticed that this doesn't mandate that the platform >>>> provides an RTC. As I understand it, the UEFI spec mandates >>>> that there's an RTC (could somebody more familiar with UEFI >>>> than me confirm/deny that?) so we should probably put one here. >>> >>> >>> Pardon my ignorance, but what exactly disqualifies Generic Timer >>> implementations from being used as Real Time Clocks? >> >> >> So my naive view was that an RTC actually had to have >> support for dealing with real (wall) clock time, ie >> knowing it's 2014 and not 1970. The generic timers are >> just timers. Or am I wrong and UEFI doesn't really >> require that? > > > The real-time clock provides four UEFI runtime services (GetTime, SetTime, > GetWakeupTime, SetWakeupTime). The spec says that you can return > EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be > retrieved/set due to a hardware error", but I don't think this is enough to > make these two optional. By comparison, GetWakeupTime/SetWakeupTime can > also return EFI_UNSUPPORTED. In practical terms, yes the VM needs to provide an RTC interface, but I don't think it needs to appear in this spec, even if the kernel accesses it directly. Portable images should use the UEFI service. g. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 11:33 ` Grant Likely (?) @ 2014-06-11 11:58 ` Arnd Bergmann -1 siblings, 0 replies; 111+ messages in thread From: Arnd Bergmann @ 2014-06-11 11:58 UTC (permalink / raw) To: linux-arm-kernel Cc: cross-distro, Ian Campbell, kvm-devel, Peter Maydell, marc.zyngier, Michael Casadevall, Rob Herring, xen-devel, Stefano Stabellini, Christopher Covington, Grant Likely, Paolo Bonzini, kvmarm, Christoffer Dall On Wednesday 11 June 2014 12:33:30 Grant Likely wrote: > On Tue, Jun 10, 2014 at 7:56 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: > > Il 10/06/2014 20:08, Peter Maydell ha scritto: > > > >> On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: > >>> > >>> On 06/10/2014 10:42 AM, Peter Maydell wrote: > >>>> > >>>> I just noticed that this doesn't mandate that the platform > >>>> provides an RTC. As I understand it, the UEFI spec mandates > >>>> that there's an RTC (could somebody more familiar with UEFI > >>>> than me confirm/deny that?) so we should probably put one here. > >>> > >>> > >>> Pardon my ignorance, but what exactly disqualifies Generic Timer > >>> implementations from being used as Real Time Clocks? > >> > >> > >> So my naive view was that an RTC actually had to have > >> support for dealing with real (wall) clock time, ie > >> knowing it's 2014 and not 1970. The generic timers are > >> just timers. Or am I wrong and UEFI doesn't really > >> require that? > > > > > > The real-time clock provides four UEFI runtime services (GetTime, SetTime, > > GetWakeupTime, SetWakeupTime). The spec says that you can return > > EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be > > retrieved/set due to a hardware error", but I don't think this is enough to > > make these two optional. By comparison, GetWakeupTime/SetWakeupTime can > > also return EFI_UNSUPPORTED. > > In practical terms, yes the VM needs to provide an RTC interface, but > I don't think it needs to appear in this spec, even if the kernel > accesses it directly. Portable images should use the UEFI service. It sounds like it should be in the spec then, if we want people building portable images to include the efi-rtc driver. Arnd ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 11:33 ` Grant Likely @ 2014-06-11 11:58 ` Arnd Bergmann -1 siblings, 0 replies; 111+ messages in thread From: Arnd Bergmann @ 2014-06-11 11:58 UTC (permalink / raw) To: linux-arm-kernel Cc: Grant Likely, Paolo Bonzini, Peter Maydell, Ian Campbell, kvm-devel, cross-distro, marc.zyngier, Michael Casadevall, Rob Herring, xen-devel, Stefano Stabellini, Christopher Covington, kvmarm, Christoffer Dall On Wednesday 11 June 2014 12:33:30 Grant Likely wrote: > On Tue, Jun 10, 2014 at 7:56 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: > > Il 10/06/2014 20:08, Peter Maydell ha scritto: > > > >> On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: > >>> > >>> On 06/10/2014 10:42 AM, Peter Maydell wrote: > >>>> > >>>> I just noticed that this doesn't mandate that the platform > >>>> provides an RTC. As I understand it, the UEFI spec mandates > >>>> that there's an RTC (could somebody more familiar with UEFI > >>>> than me confirm/deny that?) so we should probably put one here. > >>> > >>> > >>> Pardon my ignorance, but what exactly disqualifies Generic Timer > >>> implementations from being used as Real Time Clocks? > >> > >> > >> So my naive view was that an RTC actually had to have > >> support for dealing with real (wall) clock time, ie > >> knowing it's 2014 and not 1970. The generic timers are > >> just timers. Or am I wrong and UEFI doesn't really > >> require that? > > > > > > The real-time clock provides four UEFI runtime services (GetTime, SetTime, > > GetWakeupTime, SetWakeupTime). The spec says that you can return > > EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be > > retrieved/set due to a hardware error", but I don't think this is enough to > > make these two optional. By comparison, GetWakeupTime/SetWakeupTime can > > also return EFI_UNSUPPORTED. > > In practical terms, yes the VM needs to provide an RTC interface, but > I don't think it needs to appear in this spec, even if the kernel > accesses it directly. Portable images should use the UEFI service. It sounds like it should be in the spec then, if we want people building portable images to include the efi-rtc driver. Arnd ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-11 11:58 ` Arnd Bergmann 0 siblings, 0 replies; 111+ messages in thread From: Arnd Bergmann @ 2014-06-11 11:58 UTC (permalink / raw) To: linux-arm-kernel On Wednesday 11 June 2014 12:33:30 Grant Likely wrote: > On Tue, Jun 10, 2014 at 7:56 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: > > Il 10/06/2014 20:08, Peter Maydell ha scritto: > > > >> On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: > >>> > >>> On 06/10/2014 10:42 AM, Peter Maydell wrote: > >>>> > >>>> I just noticed that this doesn't mandate that the platform > >>>> provides an RTC. As I understand it, the UEFI spec mandates > >>>> that there's an RTC (could somebody more familiar with UEFI > >>>> than me confirm/deny that?) so we should probably put one here. > >>> > >>> > >>> Pardon my ignorance, but what exactly disqualifies Generic Timer > >>> implementations from being used as Real Time Clocks? > >> > >> > >> So my naive view was that an RTC actually had to have > >> support for dealing with real (wall) clock time, ie > >> knowing it's 2014 and not 1970. The generic timers are > >> just timers. Or am I wrong and UEFI doesn't really > >> require that? > > > > > > The real-time clock provides four UEFI runtime services (GetTime, SetTime, > > GetWakeupTime, SetWakeupTime). The spec says that you can return > > EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be > > retrieved/set due to a hardware error", but I don't think this is enough to > > make these two optional. By comparison, GetWakeupTime/SetWakeupTime can > > also return EFI_UNSUPPORTED. > > In practical terms, yes the VM needs to provide an RTC interface, but > I don't think it needs to appear in this spec, even if the kernel > accesses it directly. Portable images should use the UEFI service. It sounds like it should be in the spec then, if we want people building portable images to include the efi-rtc driver. Arnd ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 11:58 ` Arnd Bergmann (?) @ 2014-06-11 12:02 ` Grant Likely -1 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-06-11 12:02 UTC (permalink / raw) To: Arnd Bergmann Cc: Peter Maydell, Ian Campbell, kvm-devel, cross-distro, marc.zyngier, Michael Casadevall, Rob Herring, xen-devel, Stefano Stabellini, Paolo Bonzini, kvmarm, linux-arm-kernel On Wed, Jun 11, 2014 at 12:58 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Wednesday 11 June 2014 12:33:30 Grant Likely wrote: >> On Tue, Jun 10, 2014 at 7:56 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: >> > Il 10/06/2014 20:08, Peter Maydell ha scritto: >> > >> >> On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: >> >>> >> >>> On 06/10/2014 10:42 AM, Peter Maydell wrote: >> >>>> >> >>>> I just noticed that this doesn't mandate that the platform >> >>>> provides an RTC. As I understand it, the UEFI spec mandates >> >>>> that there's an RTC (could somebody more familiar with UEFI >> >>>> than me confirm/deny that?) so we should probably put one here. >> >>> >> >>> >> >>> Pardon my ignorance, but what exactly disqualifies Generic Timer >> >>> implementations from being used as Real Time Clocks? >> >> >> >> >> >> So my naive view was that an RTC actually had to have >> >> support for dealing with real (wall) clock time, ie >> >> knowing it's 2014 and not 1970. The generic timers are >> >> just timers. Or am I wrong and UEFI doesn't really >> >> require that? >> > >> > >> > The real-time clock provides four UEFI runtime services (GetTime, SetTime, >> > GetWakeupTime, SetWakeupTime). The spec says that you can return >> > EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be >> > retrieved/set due to a hardware error", but I don't think this is enough to >> > make these two optional. By comparison, GetWakeupTime/SetWakeupTime can >> > also return EFI_UNSUPPORTED. >> >> In practical terms, yes the VM needs to provide an RTC interface, but >> I don't think it needs to appear in this spec, even if the kernel >> accesses it directly. Portable images should use the UEFI service. > > It sounds like it should be in the spec then, if we want people building > portable images to include the efi-rtc driver. Fair enough. g. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 11:58 ` Arnd Bergmann @ 2014-06-11 12:02 ` Grant Likely -1 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-06-11 12:02 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel, cross-distro, Ian Campbell, kvm-devel, Peter Maydell, marc.zyngier, Michael Casadevall, Rob Herring, xen-devel, Stefano Stabellini, Paolo Bonzini, kvmarm On Wed, Jun 11, 2014 at 12:58 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Wednesday 11 June 2014 12:33:30 Grant Likely wrote: >> On Tue, Jun 10, 2014 at 7:56 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: >> > Il 10/06/2014 20:08, Peter Maydell ha scritto: >> > >> >> On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: >> >>> >> >>> On 06/10/2014 10:42 AM, Peter Maydell wrote: >> >>>> >> >>>> I just noticed that this doesn't mandate that the platform >> >>>> provides an RTC. As I understand it, the UEFI spec mandates >> >>>> that there's an RTC (could somebody more familiar with UEFI >> >>>> than me confirm/deny that?) so we should probably put one here. >> >>> >> >>> >> >>> Pardon my ignorance, but what exactly disqualifies Generic Timer >> >>> implementations from being used as Real Time Clocks? >> >> >> >> >> >> So my naive view was that an RTC actually had to have >> >> support for dealing with real (wall) clock time, ie >> >> knowing it's 2014 and not 1970. The generic timers are >> >> just timers. Or am I wrong and UEFI doesn't really >> >> require that? >> > >> > >> > The real-time clock provides four UEFI runtime services (GetTime, SetTime, >> > GetWakeupTime, SetWakeupTime). The spec says that you can return >> > EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be >> > retrieved/set due to a hardware error", but I don't think this is enough to >> > make these two optional. By comparison, GetWakeupTime/SetWakeupTime can >> > also return EFI_UNSUPPORTED. >> >> In practical terms, yes the VM needs to provide an RTC interface, but >> I don't think it needs to appear in this spec, even if the kernel >> accesses it directly. Portable images should use the UEFI service. > > It sounds like it should be in the spec then, if we want people building > portable images to include the efi-rtc driver. Fair enough. g. ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-11 12:02 ` Grant Likely 0 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-06-11 12:02 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jun 11, 2014 at 12:58 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Wednesday 11 June 2014 12:33:30 Grant Likely wrote: >> On Tue, Jun 10, 2014 at 7:56 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: >> > Il 10/06/2014 20:08, Peter Maydell ha scritto: >> > >> >> On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: >> >>> >> >>> On 06/10/2014 10:42 AM, Peter Maydell wrote: >> >>>> >> >>>> I just noticed that this doesn't mandate that the platform >> >>>> provides an RTC. As I understand it, the UEFI spec mandates >> >>>> that there's an RTC (could somebody more familiar with UEFI >> >>>> than me confirm/deny that?) so we should probably put one here. >> >>> >> >>> >> >>> Pardon my ignorance, but what exactly disqualifies Generic Timer >> >>> implementations from being used as Real Time Clocks? >> >> >> >> >> >> So my naive view was that an RTC actually had to have >> >> support for dealing with real (wall) clock time, ie >> >> knowing it's 2014 and not 1970. The generic timers are >> >> just timers. Or am I wrong and UEFI doesn't really >> >> require that? >> > >> > >> > The real-time clock provides four UEFI runtime services (GetTime, SetTime, >> > GetWakeupTime, SetWakeupTime). The spec says that you can return >> > EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be >> > retrieved/set due to a hardware error", but I don't think this is enough to >> > make these two optional. By comparison, GetWakeupTime/SetWakeupTime can >> > also return EFI_UNSUPPORTED. >> >> In practical terms, yes the VM needs to provide an RTC interface, but >> I don't think it needs to appear in this spec, even if the kernel >> accesses it directly. Portable images should use the UEFI service. > > It sounds like it should be in the spec then, if we want people building > portable images to include the efi-rtc driver. Fair enough. g. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 11:33 ` Grant Likely ` (2 preceding siblings ...) (?) @ 2014-06-11 14:14 ` Peter Maydell -1 siblings, 0 replies; 111+ messages in thread From: Peter Maydell @ 2014-06-11 14:14 UTC (permalink / raw) To: Grant Likely Cc: arm-mail-list, cross-distro, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, Christopher Covington, Paolo Bonzini, kvmarm, Christoffer Dall On 11 June 2014 12:33, Grant Likely <grant.likely@linaro.org> wrote: > In practical terms, yes the VM needs to provide an RTC interface, but > I don't think it needs to appear in this spec, even if the kernel > accesses it directly. Portable images should use the UEFI service. I think it might helpful to include some implementation notes to the effect that the VM needs to provide certain things to the associated UEFI implementation but that these aren't part of the specification and the guest OS is expected to use the UEFI interfaces, just for the sake of clarity for people who aren't too familiar with what UEFI requires or provides. thanks -- PMM ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 11:33 ` Grant Likely @ 2014-06-11 14:14 ` Peter Maydell -1 siblings, 0 replies; 111+ messages in thread From: Peter Maydell @ 2014-06-11 14:14 UTC (permalink / raw) To: Grant Likely Cc: Paolo Bonzini, Christopher Covington, Christoffer Dall, cross-distro, Ian Campbell, kvm-devel, Michael Casadevall, marc.zyngier, Rob Herring, xen-devel, Stefano Stabellini, kvmarm, arm-mail-list On 11 June 2014 12:33, Grant Likely <grant.likely@linaro.org> wrote: > In practical terms, yes the VM needs to provide an RTC interface, but > I don't think it needs to appear in this spec, even if the kernel > accesses it directly. Portable images should use the UEFI service. I think it might helpful to include some implementation notes to the effect that the VM needs to provide certain things to the associated UEFI implementation but that these aren't part of the specification and the guest OS is expected to use the UEFI interfaces, just for the sake of clarity for people who aren't too familiar with what UEFI requires or provides. thanks -- PMM ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-11 14:14 ` Peter Maydell 0 siblings, 0 replies; 111+ messages in thread From: Peter Maydell @ 2014-06-11 14:14 UTC (permalink / raw) To: linux-arm-kernel On 11 June 2014 12:33, Grant Likely <grant.likely@linaro.org> wrote: > In practical terms, yes the VM needs to provide an RTC interface, but > I don't think it needs to appear in this spec, even if the kernel > accesses it directly. Portable images should use the UEFI service. I think it might helpful to include some implementation notes to the effect that the VM needs to provide certain things to the associated UEFI implementation but that these aren't part of the specification and the guest OS is expected to use the UEFI interfaces, just for the sake of clarity for people who aren't too familiar with what UEFI requires or provides. thanks -- PMM ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 18:56 ` Paolo Bonzini ` (5 preceding siblings ...) (?) @ 2014-06-11 11:33 ` Grant Likely -1 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-06-11 11:33 UTC (permalink / raw) To: Paolo Bonzini Cc: arm-mail-list, Peter Maydell, Ian Campbell, kvm-devel, cross-distro, marc.zyngier, Michael Casadevall, Rob Herring, xen-devel, Stefano Stabellini, Christopher Covington, kvmarm, Christoffer Dall On Tue, Jun 10, 2014 at 7:56 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: > Il 10/06/2014 20:08, Peter Maydell ha scritto: > >> On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote: >>> >>> On 06/10/2014 10:42 AM, Peter Maydell wrote: >>>> >>>> I just noticed that this doesn't mandate that the platform >>>> provides an RTC. As I understand it, the UEFI spec mandates >>>> that there's an RTC (could somebody more familiar with UEFI >>>> than me confirm/deny that?) so we should probably put one here. >>> >>> >>> Pardon my ignorance, but what exactly disqualifies Generic Timer >>> implementations from being used as Real Time Clocks? >> >> >> So my naive view was that an RTC actually had to have >> support for dealing with real (wall) clock time, ie >> knowing it's 2014 and not 1970. The generic timers are >> just timers. Or am I wrong and UEFI doesn't really >> require that? > > > The real-time clock provides four UEFI runtime services (GetTime, SetTime, > GetWakeupTime, SetWakeupTime). The spec says that you can return > EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be > retrieved/set due to a hardware error", but I don't think this is enough to > make these two optional. By comparison, GetWakeupTime/SetWakeupTime can > also return EFI_UNSUPPORTED. In practical terms, yes the VM needs to provide an RTC interface, but I don't think it needs to appear in this spec, even if the kernel accesses it directly. Portable images should use the UEFI service. g. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-03-28 18:45 ` Christoffer Dall ` (6 preceding siblings ...) (?) @ 2014-06-10 16:44 ` Claudio Fontana -1 siblings, 0 replies; 111+ messages in thread From: Claudio Fontana @ 2014-06-10 16:44 UTC (permalink / raw) To: Christoffer Dall, cross-distro, linux-arm-kernel, kvmarm, kvm, xen-devel Cc: Michael Casadevall, Ian Campbell, Rob Herring, Leif Lindholm, Robie Basak, Stefano Stabellini, Grant Likely Hello all, I just wanted to share with you guys how we are using virtualization on ARM64 over here for the OSv project. I don't know if that's something that could be useful for your specification effort. In OSv, creating and starting a VM to some level means starting an application. That is, OSv should be a very thin bare bones guest server OS, which also acts as a kind of run-time library for an application to run. All the devices are assumed to be virtualized and heavily relying on virtio. Therefore we see a higher need for quick VM launch than it might be for other use cases. One aspect of this is that we currently start executing the image directly (no UEFI involved on the guest), and in some cases we might not need a full fledged file system at all, as the communication can happen via virtio channels. We do have a need for ACPI for discovery of information like gic addresses, timers, interrupts... (no interest on device trees, really), and of PCI-E. By skipping steps like UEFI, grub, firmware load, etc we strive to keep our application launch time low. Is this going to create problems for us in the future if you start requiring every VM to boot using those instead? Thank you for your comments, Claudio On 28.03.2014 19:45, 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, 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 as specified in Section 3.3 (3.3 (Boot Option Variables Default Boot > Behavior) and 3.4.1.1 (Removable Media Boot Behavior) in [6]. > > 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 UEFI compliant in order to 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. > > This document strongly recommends that VM implementations implement > persistent variable storage for their UEFI implementation. Persistent > variable storage shall be a property of a VM instance, but shall not be > stored as part of a portable disk image. Portable disk images shall > conform to the UEFI removable disk requirements from the UEFI spec and > cannot rely on on a pre-configured UEFI environment. > > The binary UEFI firmware implementation should not be distributed as > part of the VM image, but is specific to the VM implementation. > > > Hardware Description > -------------------- > The VM system must be UEFI compliant and therefore the UEFI system table > will provide a means to access hardware description data. > > The VM implementation must provide through its UEFI implementation: > > a complete FDT which describes the entire VM system and will boot > mainline kernels driven by device tree alone > > 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 booting, see [4] and [5]. > > > 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) or a bus-specific > mechanism such as PCI. > > If aarch64 physical CPUs implement support for the aarch32 execution > state in EL1 and EL0 execution, it is recommended that the VM > implementation supports booting the VM at EL1 in both aarch32 and > aarch64 execution states. > > 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]. > > It is strongly recommended that the VM implementation provides 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. > > For the VM image to be compliant with this spec, the following applies > for the guest OS in the VM image: > > The guest OS must include support for pl011 UART, virtio-console, and > the Xen PV console. > > The guest OS must include support for GICv2 and any available newer > version of the GIC architecture to maintain compatibility with older > VM implementations. > > It is strongly recommended to include support for all available > (block, network, console, balloon) virtio-pci, virtio-mmio, and Xen PV > drivers in the guest OS kernel or initial ramdisk. > > > Other common peripherals for block devices, networking, and more can > (and typically will) be provided, but OS software written and compiled > to run on ARM VMs cannot make any assumptions about which variations > of these should exist or which implementation they use (e.g. VirtIO or > Xen PV). See "Hardware Description" above. > > > Changes from previous versions of this RFC > ------------------------------------------ > Changes v1-v2: > - Clearly specify that the guest must support the pl011, > virtio-console, and Xen PV console. (Note that it was discussed to > mandate a pl011 during Linaro Connect Asia 2014, but that was under the > impression that the SBSA specification was an output-only no-irq > serial port, which is not the case. The only two benefits from > mandating a specific serial type was to handle "console=ttyAMA0" > kernel command line parameters and earlyprintk; Grant Likely has > submitted patches to avoid the need for "console=" parameters, and > Rob Herring has submitted patches for paravirtualized earlyprintk > consoles.) > - Reference EFI specification for bootable paths. > - Remove discussion on ACPI boot methods and do not suggest ACPI > support in VMs. > - Add specification about UEFI persistent variable storage and > portability. > > > References > ---------- > [1]: The ARM Architecture Reference Manual, ARMv8, Issue A.b > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > [2]: ARM Server Base System Architecture > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029/index.html > > [3]: The ARM Generic Interrupt Controller Architecture Specifications v2.0 > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > [4]: http://www.secretlab.ca/archives/27 > > [5]: https://git.linaro.org/people/leif.lindholm/linux.git/blob/refs/heads/uefi-for-upstream:/Documentation/arm/uefi.txt > > [6]: UEFI Specification 2.4 Revision A > http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > -- Claudio Fontana Server Virtualization Architect Huawei Technologies Duesseldorf GmbH Riesstraße 25 - 80992 München office: +49 89 158834 4135 mobile: +49 15253060158 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-03-28 18:45 ` Christoffer Dall @ 2014-06-10 16:44 ` Claudio Fontana -1 siblings, 0 replies; 111+ messages in thread From: Claudio Fontana @ 2014-06-10 16:44 UTC (permalink / raw) To: Christoffer Dall, cross-distro, linux-arm-kernel, kvmarm, kvm, xen-devel Cc: Michael Casadevall, Ian Campbell, Rob Herring, Leif Lindholm, Robie Basak, Stefano Stabellini, Grant Likely Hello all, I just wanted to share with you guys how we are using virtualization on ARM64 over here for the OSv project. I don't know if that's something that could be useful for your specification effort. In OSv, creating and starting a VM to some level means starting an application. That is, OSv should be a very thin bare bones guest server OS, which also acts as a kind of run-time library for an application to run. All the devices are assumed to be virtualized and heavily relying on virtio. Therefore we see a higher need for quick VM launch than it might be for other use cases. One aspect of this is that we currently start executing the image directly (no UEFI involved on the guest), and in some cases we might not need a full fledged file system at all, as the communication can happen via virtio channels. We do have a need for ACPI for discovery of information like gic addresses, timers, interrupts... (no interest on device trees, really), and of PCI-E. By skipping steps like UEFI, grub, firmware load, etc we strive to keep our application launch time low. Is this going to create problems for us in the future if you start requiring every VM to boot using those instead? Thank you for your comments, Claudio On 28.03.2014 19:45, 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, 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 as specified in Section 3.3 (3.3 (Boot Option Variables Default Boot > Behavior) and 3.4.1.1 (Removable Media Boot Behavior) in [6]. > > 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 UEFI compliant in order to 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. > > This document strongly recommends that VM implementations implement > persistent variable storage for their UEFI implementation. Persistent > variable storage shall be a property of a VM instance, but shall not be > stored as part of a portable disk image. Portable disk images shall > conform to the UEFI removable disk requirements from the UEFI spec and > cannot rely on on a pre-configured UEFI environment. > > The binary UEFI firmware implementation should not be distributed as > part of the VM image, but is specific to the VM implementation. > > > Hardware Description > -------------------- > The VM system must be UEFI compliant and therefore the UEFI system table > will provide a means to access hardware description data. > > The VM implementation must provide through its UEFI implementation: > > a complete FDT which describes the entire VM system and will boot > mainline kernels driven by device tree alone > > 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 booting, see [4] and [5]. > > > 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) or a bus-specific > mechanism such as PCI. > > If aarch64 physical CPUs implement support for the aarch32 execution > state in EL1 and EL0 execution, it is recommended that the VM > implementation supports booting the VM at EL1 in both aarch32 and > aarch64 execution states. > > 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]. > > It is strongly recommended that the VM implementation provides 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. > > For the VM image to be compliant with this spec, the following applies > for the guest OS in the VM image: > > The guest OS must include support for pl011 UART, virtio-console, and > the Xen PV console. > > The guest OS must include support for GICv2 and any available newer > version of the GIC architecture to maintain compatibility with older > VM implementations. > > It is strongly recommended to include support for all available > (block, network, console, balloon) virtio-pci, virtio-mmio, and Xen PV > drivers in the guest OS kernel or initial ramdisk. > > > Other common peripherals for block devices, networking, and more can > (and typically will) be provided, but OS software written and compiled > to run on ARM VMs cannot make any assumptions about which variations > of these should exist or which implementation they use (e.g. VirtIO or > Xen PV). See "Hardware Description" above. > > > Changes from previous versions of this RFC > ------------------------------------------ > Changes v1-v2: > - Clearly specify that the guest must support the pl011, > virtio-console, and Xen PV console. (Note that it was discussed to > mandate a pl011 during Linaro Connect Asia 2014, but that was under the > impression that the SBSA specification was an output-only no-irq > serial port, which is not the case. The only two benefits from > mandating a specific serial type was to handle "console=ttyAMA0" > kernel command line parameters and earlyprintk; Grant Likely has > submitted patches to avoid the need for "console=" parameters, and > Rob Herring has submitted patches for paravirtualized earlyprintk > consoles.) > - Reference EFI specification for bootable paths. > - Remove discussion on ACPI boot methods and do not suggest ACPI > support in VMs. > - Add specification about UEFI persistent variable storage and > portability. > > > References > ---------- > [1]: The ARM Architecture Reference Manual, ARMv8, Issue A.b > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > [2]: ARM Server Base System Architecture > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029/index.html > > [3]: The ARM Generic Interrupt Controller Architecture Specifications v2.0 > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > [4]: http://www.secretlab.ca/archives/27 > > [5]: https://git.linaro.org/people/leif.lindholm/linux.git/blob/refs/heads/uefi-for-upstream:/Documentation/arm/uefi.txt > > [6]: UEFI Specification 2.4 Revision A > http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > -- Claudio Fontana Server Virtualization Architect Huawei Technologies Duesseldorf GmbH Riesstraße 25 - 80992 München office: +49 89 158834 4135 mobile: +49 15253060158 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-10 16:44 ` Claudio Fontana 0 siblings, 0 replies; 111+ messages in thread From: Claudio Fontana @ 2014-06-10 16:44 UTC (permalink / raw) To: linux-arm-kernel Hello all, I just wanted to share with you guys how we are using virtualization on ARM64 over here for the OSv project. I don't know if that's something that could be useful for your specification effort. In OSv, creating and starting a VM to some level means starting an application. That is, OSv should be a very thin bare bones guest server OS, which also acts as a kind of run-time library for an application to run. All the devices are assumed to be virtualized and heavily relying on virtio. Therefore we see a higher need for quick VM launch than it might be for other use cases. One aspect of this is that we currently start executing the image directly (no UEFI involved on the guest), and in some cases we might not need a full fledged file system at all, as the communication can happen via virtio channels. We do have a need for ACPI for discovery of information like gic addresses, timers, interrupts... (no interest on device trees, really), and of PCI-E. By skipping steps like UEFI, grub, firmware load, etc we strive to keep our application launch time low. Is this going to create problems for us in the future if you start requiring every VM to boot using those instead? Thank you for your comments, Claudio On 28.03.2014 19:45, 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, 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 as specified in Section 3.3 (3.3 (Boot Option Variables Default Boot > Behavior) and 3.4.1.1 (Removable Media Boot Behavior) in [6]. > > 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 UEFI compliant in order to 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. > > This document strongly recommends that VM implementations implement > persistent variable storage for their UEFI implementation. Persistent > variable storage shall be a property of a VM instance, but shall not be > stored as part of a portable disk image. Portable disk images shall > conform to the UEFI removable disk requirements from the UEFI spec and > cannot rely on on a pre-configured UEFI environment. > > The binary UEFI firmware implementation should not be distributed as > part of the VM image, but is specific to the VM implementation. > > > Hardware Description > -------------------- > The VM system must be UEFI compliant and therefore the UEFI system table > will provide a means to access hardware description data. > > The VM implementation must provide through its UEFI implementation: > > a complete FDT which describes the entire VM system and will boot > mainline kernels driven by device tree alone > > 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 booting, see [4] and [5]. > > > 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) or a bus-specific > mechanism such as PCI. > > If aarch64 physical CPUs implement support for the aarch32 execution > state in EL1 and EL0 execution, it is recommended that the VM > implementation supports booting the VM at EL1 in both aarch32 and > aarch64 execution states. > > 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]. > > It is strongly recommended that the VM implementation provides 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. > > For the VM image to be compliant with this spec, the following applies > for the guest OS in the VM image: > > The guest OS must include support for pl011 UART, virtio-console, and > the Xen PV console. > > The guest OS must include support for GICv2 and any available newer > version of the GIC architecture to maintain compatibility with older > VM implementations. > > It is strongly recommended to include support for all available > (block, network, console, balloon) virtio-pci, virtio-mmio, and Xen PV > drivers in the guest OS kernel or initial ramdisk. > > > Other common peripherals for block devices, networking, and more can > (and typically will) be provided, but OS software written and compiled > to run on ARM VMs cannot make any assumptions about which variations > of these should exist or which implementation they use (e.g. VirtIO or > Xen PV). See "Hardware Description" above. > > > Changes from previous versions of this RFC > ------------------------------------------ > Changes v1-v2: > - Clearly specify that the guest must support the pl011, > virtio-console, and Xen PV console. (Note that it was discussed to > mandate a pl011 during Linaro Connect Asia 2014, but that was under the > impression that the SBSA specification was an output-only no-irq > serial port, which is not the case. The only two benefits from > mandating a specific serial type was to handle "console=ttyAMA0" > kernel command line parameters and earlyprintk; Grant Likely has > submitted patches to avoid the need for "console=" parameters, and > Rob Herring has submitted patches for paravirtualized earlyprintk > consoles.) > - Reference EFI specification for bootable paths. > - Remove discussion on ACPI boot methods and do not suggest ACPI > support in VMs. > - Add specification about UEFI persistent variable storage and > portability. > > > References > ---------- > [1]: The ARM Architecture Reference Manual, ARMv8, Issue A.b > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > [2]: ARM Server Base System Architecture > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029/index.html > > [3]: The ARM Generic Interrupt Controller Architecture Specifications v2.0 > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > [4]: http://www.secretlab.ca/archives/27 > > [5]: https://git.linaro.org/people/leif.lindholm/linux.git/blob/refs/heads/uefi-for-upstream:/Documentation/arm/uefi.txt > > [6]: UEFI Specification 2.4 Revision A > http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf > _______________________________________________ > kvmarm mailing list > kvmarm at lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > -- Claudio Fontana Server Virtualization Architect Huawei Technologies Duesseldorf GmbH Riesstra?e 25 - 80992 M?nchen office: +49 89 158834 4135 mobile: +49 15253060158 ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 16:44 ` Claudio Fontana @ 2014-06-10 19:21 ` Arnd Bergmann -1 siblings, 0 replies; 111+ messages in thread From: Arnd Bergmann @ 2014-06-10 19:21 UTC (permalink / raw) To: linux-arm-kernel Cc: Claudio Fontana, Christoffer Dall, cross-distro, kvmarm, kvm, xen-devel, Michael Casadevall, Ian Campbell, Rob Herring, Leif Lindholm, Robie Basak, Stefano Stabellini, Grant Likely On Tuesday 10 June 2014 18:44:59 Claudio Fontana wrote: > I just wanted to share with you guys how we are using virtualization > on ARM64 over here for the OSv project. > By skipping steps like UEFI, grub, firmware load, etc we strive to > keep our application launch time low. > Is this going to create problems for us in the future if you start > requiring every VM to boot using those instead? My feeling is that it's out of scope for this specification. What you are doing is great, and you should keep doing it that way. It does mean that your applications are aware of which hypervisor they are running on, and you have to manage them using OSv specific tools on the host. The VM System Specification however is meant to provide a way to distribute a file system image for a virtual machine that can run on any compliant hypervisor using any compliant management tools. The reason it goes through all the boot loader steps is to make it much closer to a real system, so distros don't have to special-case this. If you don't care about that, you can just install the tools on the host to manage your OSv application without a boot loader. In particular, you can support multiple targets on OSv: e.g. native Xen, native KVM, and portable standard hypervisor following the ARM VM System Spec. Arnd ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-10 19:21 ` Arnd Bergmann 0 siblings, 0 replies; 111+ messages in thread From: Arnd Bergmann @ 2014-06-10 19:21 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 10 June 2014 18:44:59 Claudio Fontana wrote: > I just wanted to share with you guys how we are using virtualization > on ARM64 over here for the OSv project. > By skipping steps like UEFI, grub, firmware load, etc we strive to > keep our application launch time low. > Is this going to create problems for us in the future if you start > requiring every VM to boot using those instead? My feeling is that it's out of scope for this specification. What you are doing is great, and you should keep doing it that way. It does mean that your applications are aware of which hypervisor they are running on, and you have to manage them using OSv specific tools on the host. The VM System Specification however is meant to provide a way to distribute a file system image for a virtual machine that can run on any compliant hypervisor using any compliant management tools. The reason it goes through all the boot loader steps is to make it much closer to a real system, so distros don't have to special-case this. If you don't care about that, you can just install the tools on the host to manage your OSv application without a boot loader. In particular, you can support multiple targets on OSv: e.g. native Xen, native KVM, and portable standard hypervisor following the ARM VM System Spec. Arnd ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 16:44 ` Claudio Fontana (?) (?) @ 2014-06-10 19:21 ` Arnd Bergmann -1 siblings, 0 replies; 111+ messages in thread From: Arnd Bergmann @ 2014-06-10 19:21 UTC (permalink / raw) To: linux-arm-kernel Cc: cross-distro, Ian Campbell, kvm, Michael Casadevall, Claudio Fontana, Rob Herring, Leif Lindholm, xen-devel, Robie Basak, Stefano Stabellini, Grant Likely, kvmarm, Christoffer Dall On Tuesday 10 June 2014 18:44:59 Claudio Fontana wrote: > I just wanted to share with you guys how we are using virtualization > on ARM64 over here for the OSv project. > By skipping steps like UEFI, grub, firmware load, etc we strive to > keep our application launch time low. > Is this going to create problems for us in the future if you start > requiring every VM to boot using those instead? My feeling is that it's out of scope for this specification. What you are doing is great, and you should keep doing it that way. It does mean that your applications are aware of which hypervisor they are running on, and you have to manage them using OSv specific tools on the host. The VM System Specification however is meant to provide a way to distribute a file system image for a virtual machine that can run on any compliant hypervisor using any compliant management tools. The reason it goes through all the boot loader steps is to make it much closer to a real system, so distros don't have to special-case this. If you don't care about that, you can just install the tools on the host to manage your OSv application without a boot loader. In particular, you can support multiple targets on OSv: e.g. native Xen, native KVM, and portable standard hypervisor following the ARM VM System Spec. Arnd ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 16:44 ` Claudio Fontana ` (2 preceding siblings ...) (?) @ 2014-06-11 9:50 ` Stefano Stabellini -1 siblings, 0 replies; 111+ messages in thread From: Stefano Stabellini @ 2014-06-11 9:50 UTC (permalink / raw) To: Claudio Fontana Cc: cross-distro, Ian Campbell, kvm, Michael Casadevall, Rob Herring, Leif Lindholm, xen-devel, Robie Basak, Stefano Stabellini, Christoffer Dall, Grant Likely, kvmarm, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 10501 bytes --] Although not in the ARM VM System Specification, Xen is certainly going to support a fast boot path without UEFI firmware. I guess KVM will too. You'll have to rely on hypervisor specific mechanisms to achieve it. In fact I wouldn't worry about UEFI when you need ACPI, that is not in this specification. Moreover the only hypervisor supporting virtio on ARM is KVM as far as I know. So it looks like you are already tying yourself to one hypervisor (KVM) and an out-of-spec standard (ACPI). The ARM VM System Specification is for people that intend to produce cross-hypervisor images. On Tue, 10 Jun 2014, Claudio Fontana wrote: > Hello all, > > I just wanted to share with you guys how we are using virtualization on ARM64 over here for the OSv project. > I don't know if that's something that could be useful for your specification effort. > > In OSv, creating and starting a VM to some level means starting an application. > That is, OSv should be a very thin bare bones guest server OS, which also acts as a kind of run-time library for an application to run. > All the devices are assumed to be virtualized and heavily relying on virtio. > > Therefore we see a higher need for quick VM launch than it might be for other use cases. > > One aspect of this is that we currently start executing the image directly (no UEFI involved on the guest), > and in some cases we might not need a full fledged file system at all, > as the communication can happen via virtio channels. > > We do have a need for ACPI for discovery of information like gic addresses, timers, interrupts... (no interest on device trees, really), and of PCI-E. > > By skipping steps like UEFI, grub, firmware load, etc we strive to keep our application launch time low. > Is this going to create problems for us in the future if you start requiring every VM to boot using those instead? > > Thank you for your comments, > > Claudio > > > On 28.03.2014 19:45, 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, 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 as specified in Section 3.3 (3.3 (Boot Option Variables Default Boot > > Behavior) and 3.4.1.1 (Removable Media Boot Behavior) in [6]. > > > > 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 UEFI compliant in order to 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. > > > > This document strongly recommends that VM implementations implement > > persistent variable storage for their UEFI implementation. Persistent > > variable storage shall be a property of a VM instance, but shall not be > > stored as part of a portable disk image. Portable disk images shall > > conform to the UEFI removable disk requirements from the UEFI spec and > > cannot rely on on a pre-configured UEFI environment. > > > > The binary UEFI firmware implementation should not be distributed as > > part of the VM image, but is specific to the VM implementation. > > > > > > Hardware Description > > -------------------- > > The VM system must be UEFI compliant and therefore the UEFI system table > > will provide a means to access hardware description data. > > > > The VM implementation must provide through its UEFI implementation: > > > > a complete FDT which describes the entire VM system and will boot > > mainline kernels driven by device tree alone > > > > 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 booting, see [4] and [5]. > > > > > > 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) or a bus-specific > > mechanism such as PCI. > > > > If aarch64 physical CPUs implement support for the aarch32 execution > > state in EL1 and EL0 execution, it is recommended that the VM > > implementation supports booting the VM at EL1 in both aarch32 and > > aarch64 execution states. > > > > 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]. > > > > It is strongly recommended that the VM implementation provides 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. > > > > For the VM image to be compliant with this spec, the following applies > > for the guest OS in the VM image: > > > > The guest OS must include support for pl011 UART, virtio-console, and > > the Xen PV console. > > > > The guest OS must include support for GICv2 and any available newer > > version of the GIC architecture to maintain compatibility with older > > VM implementations. > > > > It is strongly recommended to include support for all available > > (block, network, console, balloon) virtio-pci, virtio-mmio, and Xen PV > > drivers in the guest OS kernel or initial ramdisk. > > > > > > Other common peripherals for block devices, networking, and more can > > (and typically will) be provided, but OS software written and compiled > > to run on ARM VMs cannot make any assumptions about which variations > > of these should exist or which implementation they use (e.g. VirtIO or > > Xen PV). See "Hardware Description" above. > > > > > > Changes from previous versions of this RFC > > ------------------------------------------ > > Changes v1-v2: > > - Clearly specify that the guest must support the pl011, > > virtio-console, and Xen PV console. (Note that it was discussed to > > mandate a pl011 during Linaro Connect Asia 2014, but that was under the > > impression that the SBSA specification was an output-only no-irq > > serial port, which is not the case. The only two benefits from > > mandating a specific serial type was to handle "console=ttyAMA0" > > kernel command line parameters and earlyprintk; Grant Likely has > > submitted patches to avoid the need for "console=" parameters, and > > Rob Herring has submitted patches for paravirtualized earlyprintk > > consoles.) > > - Reference EFI specification for bootable paths. > > - Remove discussion on ACPI boot methods and do not suggest ACPI > > support in VMs. > > - Add specification about UEFI persistent variable storage and > > portability. > > > > > > References > > ---------- > > [1]: The ARM Architecture Reference Manual, ARMv8, Issue A.b > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > > > [2]: ARM Server Base System Architecture > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029/index.html > > > > [3]: The ARM Generic Interrupt Controller Architecture Specifications v2.0 > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > > > [4]: http://www.secretlab.ca/archives/27 > > > > [5]: https://git.linaro.org/people/leif.lindholm/linux.git/blob/refs/heads/uefi-for-upstream:/Documentation/arm/uefi.txt > > > > [6]: UEFI Specification 2.4 Revision A > > http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf > > _______________________________________________ > > kvmarm mailing list > > kvmarm@lists.cs.columbia.edu > > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > > > > > -- > Claudio Fontana > Server Virtualization Architect > Huawei Technologies Duesseldorf GmbH > Riesstraße 25 - 80992 München > > office: +49 89 158834 4135 > mobile: +49 15253060158 > [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 16:44 ` Claudio Fontana @ 2014-06-11 9:50 ` Stefano Stabellini -1 siblings, 0 replies; 111+ messages in thread From: Stefano Stabellini @ 2014-06-11 9:50 UTC (permalink / raw) To: Claudio Fontana Cc: Christoffer Dall, cross-distro, linux-arm-kernel, kvmarm, kvm, xen-devel, Ian Campbell, Michael Casadevall, Rob Herring, Leif Lindholm, Robie Basak, Stefano Stabellini, Grant Likely [-- Attachment #1: Type: text/plain, Size: 10501 bytes --] Although not in the ARM VM System Specification, Xen is certainly going to support a fast boot path without UEFI firmware. I guess KVM will too. You'll have to rely on hypervisor specific mechanisms to achieve it. In fact I wouldn't worry about UEFI when you need ACPI, that is not in this specification. Moreover the only hypervisor supporting virtio on ARM is KVM as far as I know. So it looks like you are already tying yourself to one hypervisor (KVM) and an out-of-spec standard (ACPI). The ARM VM System Specification is for people that intend to produce cross-hypervisor images. On Tue, 10 Jun 2014, Claudio Fontana wrote: > Hello all, > > I just wanted to share with you guys how we are using virtualization on ARM64 over here for the OSv project. > I don't know if that's something that could be useful for your specification effort. > > In OSv, creating and starting a VM to some level means starting an application. > That is, OSv should be a very thin bare bones guest server OS, which also acts as a kind of run-time library for an application to run. > All the devices are assumed to be virtualized and heavily relying on virtio. > > Therefore we see a higher need for quick VM launch than it might be for other use cases. > > One aspect of this is that we currently start executing the image directly (no UEFI involved on the guest), > and in some cases we might not need a full fledged file system at all, > as the communication can happen via virtio channels. > > We do have a need for ACPI for discovery of information like gic addresses, timers, interrupts... (no interest on device trees, really), and of PCI-E. > > By skipping steps like UEFI, grub, firmware load, etc we strive to keep our application launch time low. > Is this going to create problems for us in the future if you start requiring every VM to boot using those instead? > > Thank you for your comments, > > Claudio > > > On 28.03.2014 19:45, 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, 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 as specified in Section 3.3 (3.3 (Boot Option Variables Default Boot > > Behavior) and 3.4.1.1 (Removable Media Boot Behavior) in [6]. > > > > 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 UEFI compliant in order to 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. > > > > This document strongly recommends that VM implementations implement > > persistent variable storage for their UEFI implementation. Persistent > > variable storage shall be a property of a VM instance, but shall not be > > stored as part of a portable disk image. Portable disk images shall > > conform to the UEFI removable disk requirements from the UEFI spec and > > cannot rely on on a pre-configured UEFI environment. > > > > The binary UEFI firmware implementation should not be distributed as > > part of the VM image, but is specific to the VM implementation. > > > > > > Hardware Description > > -------------------- > > The VM system must be UEFI compliant and therefore the UEFI system table > > will provide a means to access hardware description data. > > > > The VM implementation must provide through its UEFI implementation: > > > > a complete FDT which describes the entire VM system and will boot > > mainline kernels driven by device tree alone > > > > 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 booting, see [4] and [5]. > > > > > > 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) or a bus-specific > > mechanism such as PCI. > > > > If aarch64 physical CPUs implement support for the aarch32 execution > > state in EL1 and EL0 execution, it is recommended that the VM > > implementation supports booting the VM at EL1 in both aarch32 and > > aarch64 execution states. > > > > 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]. > > > > It is strongly recommended that the VM implementation provides 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. > > > > For the VM image to be compliant with this spec, the following applies > > for the guest OS in the VM image: > > > > The guest OS must include support for pl011 UART, virtio-console, and > > the Xen PV console. > > > > The guest OS must include support for GICv2 and any available newer > > version of the GIC architecture to maintain compatibility with older > > VM implementations. > > > > It is strongly recommended to include support for all available > > (block, network, console, balloon) virtio-pci, virtio-mmio, and Xen PV > > drivers in the guest OS kernel or initial ramdisk. > > > > > > Other common peripherals for block devices, networking, and more can > > (and typically will) be provided, but OS software written and compiled > > to run on ARM VMs cannot make any assumptions about which variations > > of these should exist or which implementation they use (e.g. VirtIO or > > Xen PV). See "Hardware Description" above. > > > > > > Changes from previous versions of this RFC > > ------------------------------------------ > > Changes v1-v2: > > - Clearly specify that the guest must support the pl011, > > virtio-console, and Xen PV console. (Note that it was discussed to > > mandate a pl011 during Linaro Connect Asia 2014, but that was under the > > impression that the SBSA specification was an output-only no-irq > > serial port, which is not the case. The only two benefits from > > mandating a specific serial type was to handle "console=ttyAMA0" > > kernel command line parameters and earlyprintk; Grant Likely has > > submitted patches to avoid the need for "console=" parameters, and > > Rob Herring has submitted patches for paravirtualized earlyprintk > > consoles.) > > - Reference EFI specification for bootable paths. > > - Remove discussion on ACPI boot methods and do not suggest ACPI > > support in VMs. > > - Add specification about UEFI persistent variable storage and > > portability. > > > > > > References > > ---------- > > [1]: The ARM Architecture Reference Manual, ARMv8, Issue A.b > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > > > [2]: ARM Server Base System Architecture > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029/index.html > > > > [3]: The ARM Generic Interrupt Controller Architecture Specifications v2.0 > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > > > [4]: http://www.secretlab.ca/archives/27 > > > > [5]: https://git.linaro.org/people/leif.lindholm/linux.git/blob/refs/heads/uefi-for-upstream:/Documentation/arm/uefi.txt > > > > [6]: UEFI Specification 2.4 Revision A > > http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf > > _______________________________________________ > > kvmarm mailing list > > kvmarm@lists.cs.columbia.edu > > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > > > > > -- > Claudio Fontana > Server Virtualization Architect > Huawei Technologies Duesseldorf GmbH > Riesstraße 25 - 80992 München > > office: +49 89 158834 4135 > mobile: +49 15253060158 > ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-11 9:50 ` Stefano Stabellini 0 siblings, 0 replies; 111+ messages in thread From: Stefano Stabellini @ 2014-06-11 9:50 UTC (permalink / raw) To: linux-arm-kernel Although not in the ARM VM System Specification, Xen is certainly going to support a fast boot path without UEFI firmware. I guess KVM will too. You'll have to rely on hypervisor specific mechanisms to achieve it. In fact I wouldn't worry about UEFI when you need ACPI, that is not in this specification. Moreover the only hypervisor supporting virtio on ARM is KVM as far as I know. So it looks like you are already tying yourself to one hypervisor (KVM) and an out-of-spec standard (ACPI). The ARM VM System Specification is for people that intend to produce cross-hypervisor images. On Tue, 10 Jun 2014, Claudio Fontana wrote: > Hello all, > > I just wanted to share with you guys how we are using virtualization on ARM64 over here for the OSv project. > I don't know if that's something that could be useful for your specification effort. > > In OSv, creating and starting a VM to some level means starting an application. > That is, OSv should be a very thin bare bones guest server OS, which also acts as a kind of run-time library for an application to run. > All the devices are assumed to be virtualized and heavily relying on virtio. > > Therefore we see a higher need for quick VM launch than it might be for other use cases. > > One aspect of this is that we currently start executing the image directly (no UEFI involved on the guest), > and in some cases we might not need a full fledged file system at all, > as the communication can happen via virtio channels. > > We do have a need for ACPI for discovery of information like gic addresses, timers, interrupts... (no interest on device trees, really), and of PCI-E. > > By skipping steps like UEFI, grub, firmware load, etc we strive to keep our application launch time low. > Is this going to create problems for us in the future if you start requiring every VM to boot using those instead? > > Thank you for your comments, > > Claudio > > > On 28.03.2014 19:45, 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, 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 as specified in Section 3.3 (3.3 (Boot Option Variables Default Boot > > Behavior) and 3.4.1.1 (Removable Media Boot Behavior) in [6]. > > > > 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 UEFI compliant in order to 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. > > > > This document strongly recommends that VM implementations implement > > persistent variable storage for their UEFI implementation. Persistent > > variable storage shall be a property of a VM instance, but shall not be > > stored as part of a portable disk image. Portable disk images shall > > conform to the UEFI removable disk requirements from the UEFI spec and > > cannot rely on on a pre-configured UEFI environment. > > > > The binary UEFI firmware implementation should not be distributed as > > part of the VM image, but is specific to the VM implementation. > > > > > > Hardware Description > > -------------------- > > The VM system must be UEFI compliant and therefore the UEFI system table > > will provide a means to access hardware description data. > > > > The VM implementation must provide through its UEFI implementation: > > > > a complete FDT which describes the entire VM system and will boot > > mainline kernels driven by device tree alone > > > > 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 booting, see [4] and [5]. > > > > > > 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) or a bus-specific > > mechanism such as PCI. > > > > If aarch64 physical CPUs implement support for the aarch32 execution > > state in EL1 and EL0 execution, it is recommended that the VM > > implementation supports booting the VM at EL1 in both aarch32 and > > aarch64 execution states. > > > > 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]. > > > > It is strongly recommended that the VM implementation provides 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. > > > > For the VM image to be compliant with this spec, the following applies > > for the guest OS in the VM image: > > > > The guest OS must include support for pl011 UART, virtio-console, and > > the Xen PV console. > > > > The guest OS must include support for GICv2 and any available newer > > version of the GIC architecture to maintain compatibility with older > > VM implementations. > > > > It is strongly recommended to include support for all available > > (block, network, console, balloon) virtio-pci, virtio-mmio, and Xen PV > > drivers in the guest OS kernel or initial ramdisk. > > > > > > Other common peripherals for block devices, networking, and more can > > (and typically will) be provided, but OS software written and compiled > > to run on ARM VMs cannot make any assumptions about which variations > > of these should exist or which implementation they use (e.g. VirtIO or > > Xen PV). See "Hardware Description" above. > > > > > > Changes from previous versions of this RFC > > ------------------------------------------ > > Changes v1-v2: > > - Clearly specify that the guest must support the pl011, > > virtio-console, and Xen PV console. (Note that it was discussed to > > mandate a pl011 during Linaro Connect Asia 2014, but that was under the > > impression that the SBSA specification was an output-only no-irq > > serial port, which is not the case. The only two benefits from > > mandating a specific serial type was to handle "console=ttyAMA0" > > kernel command line parameters and earlyprintk; Grant Likely has > > submitted patches to avoid the need for "console=" parameters, and > > Rob Herring has submitted patches for paravirtualized earlyprintk > > consoles.) > > - Reference EFI specification for bootable paths. > > - Remove discussion on ACPI boot methods and do not suggest ACPI > > support in VMs. > > - Add specification about UEFI persistent variable storage and > > portability. > > > > > > References > > ---------- > > [1]: The ARM Architecture Reference Manual, ARMv8, Issue A.b > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > > > [2]: ARM Server Base System Architecture > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029/index.html > > > > [3]: The ARM Generic Interrupt Controller Architecture Specifications v2.0 > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > > > [4]: http://www.secretlab.ca/archives/27 > > > > [5]: https://git.linaro.org/people/leif.lindholm/linux.git/blob/refs/heads/uefi-for-upstream:/Documentation/arm/uefi.txt > > > > [6]: UEFI Specification 2.4 Revision A > > http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf > > _______________________________________________ > > kvmarm mailing list > > kvmarm at lists.cs.columbia.edu > > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > > > > > -- > Claudio Fontana > Server Virtualization Architect > Huawei Technologies Duesseldorf GmbH > Riesstra?e 25 - 80992 M?nchen > > office: +49 89 158834 4135 > mobile: +49 15253060158 > ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 9:50 ` Stefano Stabellini @ 2014-06-11 9:55 ` Christoffer Dall -1 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-06-11 9:55 UTC (permalink / raw) To: Stefano Stabellini Cc: Claudio Fontana, cross-distro, linux-arm-kernel, kvmarm, kvm, xen-devel, Ian Campbell, Michael Casadevall, Rob Herring, Leif Lindholm, Robie Basak, Stefano Stabellini, Grant Likely Agree with what Stefano says, and I strongly recommend you reconsider your position on FDT vs. ACPI for ARM VMs, but it's completely up to you of course :) -Christoffer On Wed, Jun 11, 2014 at 10:50:04AM +0100, Stefano Stabellini wrote: > Although not in the ARM VM System Specification, Xen is certainly going > to support a fast boot path without UEFI firmware. I guess KVM will too. > You'll have to rely on hypervisor specific mechanisms to achieve it. > > In fact I wouldn't worry about UEFI when you need ACPI, that is not in > this specification. Moreover the only hypervisor supporting virtio on > ARM is KVM as far as I know. > > So it looks like you are already tying yourself to one hypervisor (KVM) > and an out-of-spec standard (ACPI). The ARM VM System Specification is > for people that intend to produce cross-hypervisor images. > > > On Tue, 10 Jun 2014, Claudio Fontana wrote: > > Hello all, > > > > I just wanted to share with you guys how we are using virtualization on ARM64 over here for the OSv project. > > I don't know if that's something that could be useful for your specification effort. > > > > In OSv, creating and starting a VM to some level means starting an application. > > That is, OSv should be a very thin bare bones guest server OS, which also acts as a kind of run-time library for an application to run. > > All the devices are assumed to be virtualized and heavily relying on virtio. > > > > Therefore we see a higher need for quick VM launch than it might be for other use cases. > > > > One aspect of this is that we currently start executing the image directly (no UEFI involved on the guest), > > and in some cases we might not need a full fledged file system at all, > > as the communication can happen via virtio channels. > > > > We do have a need for ACPI for discovery of information like gic addresses, timers, interrupts... (no interest on device trees, really), and of PCI-E. > > > > By skipping steps like UEFI, grub, firmware load, etc we strive to keep our application launch time low. > > Is this going to create problems for us in the future if you start requiring every VM to boot using those instead? > > > > Thank you for your comments, > > > > Claudio > > > > > > On 28.03.2014 19:45, 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, 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 as specified in Section 3.3 (3.3 (Boot Option Variables Default Boot > > > Behavior) and 3.4.1.1 (Removable Media Boot Behavior) in [6]. > > > > > > 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 UEFI compliant in order to 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. > > > > > > This document strongly recommends that VM implementations implement > > > persistent variable storage for their UEFI implementation. Persistent > > > variable storage shall be a property of a VM instance, but shall not be > > > stored as part of a portable disk image. Portable disk images shall > > > conform to the UEFI removable disk requirements from the UEFI spec and > > > cannot rely on on a pre-configured UEFI environment. > > > > > > The binary UEFI firmware implementation should not be distributed as > > > part of the VM image, but is specific to the VM implementation. > > > > > > > > > Hardware Description > > > -------------------- > > > The VM system must be UEFI compliant and therefore the UEFI system table > > > will provide a means to access hardware description data. > > > > > > The VM implementation must provide through its UEFI implementation: > > > > > > a complete FDT which describes the entire VM system and will boot > > > mainline kernels driven by device tree alone > > > > > > 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 booting, see [4] and [5]. > > > > > > > > > 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) or a bus-specific > > > mechanism such as PCI. > > > > > > If aarch64 physical CPUs implement support for the aarch32 execution > > > state in EL1 and EL0 execution, it is recommended that the VM > > > implementation supports booting the VM at EL1 in both aarch32 and > > > aarch64 execution states. > > > > > > 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]. > > > > > > It is strongly recommended that the VM implementation provides 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. > > > > > > For the VM image to be compliant with this spec, the following applies > > > for the guest OS in the VM image: > > > > > > The guest OS must include support for pl011 UART, virtio-console, and > > > the Xen PV console. > > > > > > The guest OS must include support for GICv2 and any available newer > > > version of the GIC architecture to maintain compatibility with older > > > VM implementations. > > > > > > It is strongly recommended to include support for all available > > > (block, network, console, balloon) virtio-pci, virtio-mmio, and Xen PV > > > drivers in the guest OS kernel or initial ramdisk. > > > > > > > > > Other common peripherals for block devices, networking, and more can > > > (and typically will) be provided, but OS software written and compiled > > > to run on ARM VMs cannot make any assumptions about which variations > > > of these should exist or which implementation they use (e.g. VirtIO or > > > Xen PV). See "Hardware Description" above. > > > > > > > > > Changes from previous versions of this RFC > > > ------------------------------------------ > > > Changes v1-v2: > > > - Clearly specify that the guest must support the pl011, > > > virtio-console, and Xen PV console. (Note that it was discussed to > > > mandate a pl011 during Linaro Connect Asia 2014, but that was under the > > > impression that the SBSA specification was an output-only no-irq > > > serial port, which is not the case. The only two benefits from > > > mandating a specific serial type was to handle "console=ttyAMA0" > > > kernel command line parameters and earlyprintk; Grant Likely has > > > submitted patches to avoid the need for "console=" parameters, and > > > Rob Herring has submitted patches for paravirtualized earlyprintk > > > consoles.) > > > - Reference EFI specification for bootable paths. > > > - Remove discussion on ACPI boot methods and do not suggest ACPI > > > support in VMs. > > > - Add specification about UEFI persistent variable storage and > > > portability. > > > > > > > > > References > > > ---------- > > > [1]: The ARM Architecture Reference Manual, ARMv8, Issue A.b > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > > > > > [2]: ARM Server Base System Architecture > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029/index.html > > > > > > [3]: The ARM Generic Interrupt Controller Architecture Specifications v2.0 > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > > > > > [4]: http://www.secretlab.ca/archives/27 > > > > > > [5]: https://git.linaro.org/people/leif.lindholm/linux.git/blob/refs/heads/uefi-for-upstream:/Documentation/arm/uefi.txt > > > > > > [6]: UEFI Specification 2.4 Revision A > > > http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf > > > _______________________________________________ > > > kvmarm mailing list > > > kvmarm@lists.cs.columbia.edu > > > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > > > > > > > > > -- > > Claudio Fontana > > Server Virtualization Architect > > Huawei Technologies Duesseldorf GmbH > > Riesstraße 25 - 80992 München > > > > office: +49 89 158834 4135 > > mobile: +49 15253060158 > > ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-11 9:55 ` Christoffer Dall 0 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-06-11 9:55 UTC (permalink / raw) To: linux-arm-kernel Agree with what Stefano says, and I strongly recommend you reconsider your position on FDT vs. ACPI for ARM VMs, but it's completely up to you of course :) -Christoffer On Wed, Jun 11, 2014 at 10:50:04AM +0100, Stefano Stabellini wrote: > Although not in the ARM VM System Specification, Xen is certainly going > to support a fast boot path without UEFI firmware. I guess KVM will too. > You'll have to rely on hypervisor specific mechanisms to achieve it. > > In fact I wouldn't worry about UEFI when you need ACPI, that is not in > this specification. Moreover the only hypervisor supporting virtio on > ARM is KVM as far as I know. > > So it looks like you are already tying yourself to one hypervisor (KVM) > and an out-of-spec standard (ACPI). The ARM VM System Specification is > for people that intend to produce cross-hypervisor images. > > > On Tue, 10 Jun 2014, Claudio Fontana wrote: > > Hello all, > > > > I just wanted to share with you guys how we are using virtualization on ARM64 over here for the OSv project. > > I don't know if that's something that could be useful for your specification effort. > > > > In OSv, creating and starting a VM to some level means starting an application. > > That is, OSv should be a very thin bare bones guest server OS, which also acts as a kind of run-time library for an application to run. > > All the devices are assumed to be virtualized and heavily relying on virtio. > > > > Therefore we see a higher need for quick VM launch than it might be for other use cases. > > > > One aspect of this is that we currently start executing the image directly (no UEFI involved on the guest), > > and in some cases we might not need a full fledged file system at all, > > as the communication can happen via virtio channels. > > > > We do have a need for ACPI for discovery of information like gic addresses, timers, interrupts... (no interest on device trees, really), and of PCI-E. > > > > By skipping steps like UEFI, grub, firmware load, etc we strive to keep our application launch time low. > > Is this going to create problems for us in the future if you start requiring every VM to boot using those instead? > > > > Thank you for your comments, > > > > Claudio > > > > > > On 28.03.2014 19:45, 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, 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 as specified in Section 3.3 (3.3 (Boot Option Variables Default Boot > > > Behavior) and 3.4.1.1 (Removable Media Boot Behavior) in [6]. > > > > > > 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 UEFI compliant in order to 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. > > > > > > This document strongly recommends that VM implementations implement > > > persistent variable storage for their UEFI implementation. Persistent > > > variable storage shall be a property of a VM instance, but shall not be > > > stored as part of a portable disk image. Portable disk images shall > > > conform to the UEFI removable disk requirements from the UEFI spec and > > > cannot rely on on a pre-configured UEFI environment. > > > > > > The binary UEFI firmware implementation should not be distributed as > > > part of the VM image, but is specific to the VM implementation. > > > > > > > > > Hardware Description > > > -------------------- > > > The VM system must be UEFI compliant and therefore the UEFI system table > > > will provide a means to access hardware description data. > > > > > > The VM implementation must provide through its UEFI implementation: > > > > > > a complete FDT which describes the entire VM system and will boot > > > mainline kernels driven by device tree alone > > > > > > 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 booting, see [4] and [5]. > > > > > > > > > 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) or a bus-specific > > > mechanism such as PCI. > > > > > > If aarch64 physical CPUs implement support for the aarch32 execution > > > state in EL1 and EL0 execution, it is recommended that the VM > > > implementation supports booting the VM at EL1 in both aarch32 and > > > aarch64 execution states. > > > > > > 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]. > > > > > > It is strongly recommended that the VM implementation provides 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. > > > > > > For the VM image to be compliant with this spec, the following applies > > > for the guest OS in the VM image: > > > > > > The guest OS must include support for pl011 UART, virtio-console, and > > > the Xen PV console. > > > > > > The guest OS must include support for GICv2 and any available newer > > > version of the GIC architecture to maintain compatibility with older > > > VM implementations. > > > > > > It is strongly recommended to include support for all available > > > (block, network, console, balloon) virtio-pci, virtio-mmio, and Xen PV > > > drivers in the guest OS kernel or initial ramdisk. > > > > > > > > > Other common peripherals for block devices, networking, and more can > > > (and typically will) be provided, but OS software written and compiled > > > to run on ARM VMs cannot make any assumptions about which variations > > > of these should exist or which implementation they use (e.g. VirtIO or > > > Xen PV). See "Hardware Description" above. > > > > > > > > > Changes from previous versions of this RFC > > > ------------------------------------------ > > > Changes v1-v2: > > > - Clearly specify that the guest must support the pl011, > > > virtio-console, and Xen PV console. (Note that it was discussed to > > > mandate a pl011 during Linaro Connect Asia 2014, but that was under the > > > impression that the SBSA specification was an output-only no-irq > > > serial port, which is not the case. The only two benefits from > > > mandating a specific serial type was to handle "console=ttyAMA0" > > > kernel command line parameters and earlyprintk; Grant Likely has > > > submitted patches to avoid the need for "console=" parameters, and > > > Rob Herring has submitted patches for paravirtualized earlyprintk > > > consoles.) > > > - Reference EFI specification for bootable paths. > > > - Remove discussion on ACPI boot methods and do not suggest ACPI > > > support in VMs. > > > - Add specification about UEFI persistent variable storage and > > > portability. > > > > > > > > > References > > > ---------- > > > [1]: The ARM Architecture Reference Manual, ARMv8, Issue A.b > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > > > > > [2]: ARM Server Base System Architecture > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029/index.html > > > > > > [3]: The ARM Generic Interrupt Controller Architecture Specifications v2.0 > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > > > > > [4]: http://www.secretlab.ca/archives/27 > > > > > > [5]: https://git.linaro.org/people/leif.lindholm/linux.git/blob/refs/heads/uefi-for-upstream:/Documentation/arm/uefi.txt > > > > > > [6]: UEFI Specification 2.4 Revision A > > > http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf > > > _______________________________________________ > > > kvmarm mailing list > > > kvmarm at lists.cs.columbia.edu > > > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > > > > > > > > > -- > > Claudio Fontana > > Server Virtualization Architect > > Huawei Technologies Duesseldorf GmbH > > Riesstra?e 25 - 80992 M?nchen > > > > office: +49 89 158834 4135 > > mobile: +49 15253060158 > > ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 9:55 ` Christoffer Dall (?) @ 2014-06-11 11:28 ` Grant Likely -1 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-06-11 11:28 UTC (permalink / raw) To: Christoffer Dall Cc: cross-distro, Ian Campbell, kvm, Stefano Stabellini, Robie Basak, Claudio Fontana, Rob Herring, Leif Lindholm, xen-devel, Michael Casadevall, Stefano Stabellini, kvmarm, linux-arm-kernel On Wed, Jun 11, 2014 at 10:55 AM, Christoffer Dall <christoffer.dall@linaro.org> wrote: > Agree with what Stefano says, and I strongly recommend you reconsider > your position on FDT vs. ACPI for ARM VMs, but it's completely up to > you of course :) Not entirely. The plan right now is to only support ACPI when booting with UEFI. If they don't use UEFI, then ACPI will not be available. If OSv only supports ACPI, then it is forced to use the UEFI boot path. g. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 9:55 ` Christoffer Dall @ 2014-06-11 11:28 ` Grant Likely -1 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-06-11 11:28 UTC (permalink / raw) To: Christoffer Dall Cc: Stefano Stabellini, Claudio Fontana, cross-distro, linux-arm-kernel, kvmarm, kvm, xen-devel, Ian Campbell, Michael Casadevall, Rob Herring, Leif Lindholm, Robie Basak, Stefano Stabellini On Wed, Jun 11, 2014 at 10:55 AM, Christoffer Dall <christoffer.dall@linaro.org> wrote: > Agree with what Stefano says, and I strongly recommend you reconsider > your position on FDT vs. ACPI for ARM VMs, but it's completely up to > you of course :) Not entirely. The plan right now is to only support ACPI when booting with UEFI. If they don't use UEFI, then ACPI will not be available. If OSv only supports ACPI, then it is forced to use the UEFI boot path. g. ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-11 11:28 ` Grant Likely 0 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-06-11 11:28 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jun 11, 2014 at 10:55 AM, Christoffer Dall <christoffer.dall@linaro.org> wrote: > Agree with what Stefano says, and I strongly recommend you reconsider > your position on FDT vs. ACPI for ARM VMs, but it's completely up to > you of course :) Not entirely. The plan right now is to only support ACPI when booting with UEFI. If they don't use UEFI, then ACPI will not be available. If OSv only supports ACPI, then it is forced to use the UEFI boot path. g. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 11:28 ` Grant Likely (?) @ 2014-06-11 12:04 ` Christoffer Dall -1 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-06-11 12:04 UTC (permalink / raw) To: Grant Likely Cc: cross-distro, Ian Campbell, kvm, Stefano Stabellini, Robie Basak, Claudio Fontana, Rob Herring, Leif Lindholm, xen-devel, Michael Casadevall, Stefano Stabellini, kvmarm, linux-arm-kernel On Wed, Jun 11, 2014 at 12:28:40PM +0100, Grant Likely wrote: > On Wed, Jun 11, 2014 at 10:55 AM, Christoffer Dall > <christoffer.dall@linaro.org> wrote: > > Agree with what Stefano says, and I strongly recommend you reconsider > > your position on FDT vs. ACPI for ARM VMs, but it's completely up to > > you of course :) > > Not entirely. of course it's up to them what they want to do. > The plan right now is to only support ACPI when booting > with UEFI. If they don't use UEFI, then ACPI will not be available. If > OSv only supports ACPI, then it is forced to use the UEFI boot path. > The plan right now is to not support ACPI in VMs at all, as per the last discussion at LCA14. If an when someone wants to add that, fine, but the spec mandates FDT describing the full system. If OSv wants to hack a KVM implementation or provide a static ACPI blob coupled to OSv that happens to describe the KVM/ARM/QEMU system model, then they can do that. Crazy, it sounds to me, but as I said, up to the OSv guys. -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 11:28 ` Grant Likely @ 2014-06-11 12:04 ` Christoffer Dall -1 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-06-11 12:04 UTC (permalink / raw) To: Grant Likely Cc: Stefano Stabellini, Claudio Fontana, cross-distro, linux-arm-kernel, kvmarm, kvm, xen-devel, Ian Campbell, Michael Casadevall, Rob Herring, Leif Lindholm, Robie Basak, Stefano Stabellini On Wed, Jun 11, 2014 at 12:28:40PM +0100, Grant Likely wrote: > On Wed, Jun 11, 2014 at 10:55 AM, Christoffer Dall > <christoffer.dall@linaro.org> wrote: > > Agree with what Stefano says, and I strongly recommend you reconsider > > your position on FDT vs. ACPI for ARM VMs, but it's completely up to > > you of course :) > > Not entirely. of course it's up to them what they want to do. > The plan right now is to only support ACPI when booting > with UEFI. If they don't use UEFI, then ACPI will not be available. If > OSv only supports ACPI, then it is forced to use the UEFI boot path. > The plan right now is to not support ACPI in VMs at all, as per the last discussion at LCA14. If an when someone wants to add that, fine, but the spec mandates FDT describing the full system. If OSv wants to hack a KVM implementation or provide a static ACPI blob coupled to OSv that happens to describe the KVM/ARM/QEMU system model, then they can do that. Crazy, it sounds to me, but as I said, up to the OSv guys. -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-11 12:04 ` Christoffer Dall 0 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-06-11 12:04 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jun 11, 2014 at 12:28:40PM +0100, Grant Likely wrote: > On Wed, Jun 11, 2014 at 10:55 AM, Christoffer Dall > <christoffer.dall@linaro.org> wrote: > > Agree with what Stefano says, and I strongly recommend you reconsider > > your position on FDT vs. ACPI for ARM VMs, but it's completely up to > > you of course :) > > Not entirely. of course it's up to them what they want to do. > The plan right now is to only support ACPI when booting > with UEFI. If they don't use UEFI, then ACPI will not be available. If > OSv only supports ACPI, then it is forced to use the UEFI boot path. > The plan right now is to not support ACPI in VMs at all, as per the last discussion at LCA14. If an when someone wants to add that, fine, but the spec mandates FDT describing the full system. If OSv wants to hack a KVM implementation or provide a static ACPI blob coupled to OSv that happens to describe the KVM/ARM/QEMU system model, then they can do that. Crazy, it sounds to me, but as I said, up to the OSv guys. -Christoffer ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 9:50 ` Stefano Stabellini (?) (?) @ 2014-06-11 9:55 ` Christoffer Dall -1 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-06-11 9:55 UTC (permalink / raw) To: Stefano Stabellini Cc: cross-distro, Ian Campbell, kvm, Michael Casadevall, Claudio Fontana, Rob Herring, Leif Lindholm, xen-devel, Robie Basak, Stefano Stabellini, Grant Likely, kvmarm, linux-arm-kernel Agree with what Stefano says, and I strongly recommend you reconsider your position on FDT vs. ACPI for ARM VMs, but it's completely up to you of course :) -Christoffer On Wed, Jun 11, 2014 at 10:50:04AM +0100, Stefano Stabellini wrote: > Although not in the ARM VM System Specification, Xen is certainly going > to support a fast boot path without UEFI firmware. I guess KVM will too. > You'll have to rely on hypervisor specific mechanisms to achieve it. > > In fact I wouldn't worry about UEFI when you need ACPI, that is not in > this specification. Moreover the only hypervisor supporting virtio on > ARM is KVM as far as I know. > > So it looks like you are already tying yourself to one hypervisor (KVM) > and an out-of-spec standard (ACPI). The ARM VM System Specification is > for people that intend to produce cross-hypervisor images. > > > On Tue, 10 Jun 2014, Claudio Fontana wrote: > > Hello all, > > > > I just wanted to share with you guys how we are using virtualization on ARM64 over here for the OSv project. > > I don't know if that's something that could be useful for your specification effort. > > > > In OSv, creating and starting a VM to some level means starting an application. > > That is, OSv should be a very thin bare bones guest server OS, which also acts as a kind of run-time library for an application to run. > > All the devices are assumed to be virtualized and heavily relying on virtio. > > > > Therefore we see a higher need for quick VM launch than it might be for other use cases. > > > > One aspect of this is that we currently start executing the image directly (no UEFI involved on the guest), > > and in some cases we might not need a full fledged file system at all, > > as the communication can happen via virtio channels. > > > > We do have a need for ACPI for discovery of information like gic addresses, timers, interrupts... (no interest on device trees, really), and of PCI-E. > > > > By skipping steps like UEFI, grub, firmware load, etc we strive to keep our application launch time low. > > Is this going to create problems for us in the future if you start requiring every VM to boot using those instead? > > > > Thank you for your comments, > > > > Claudio > > > > > > On 28.03.2014 19:45, 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, 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 as specified in Section 3.3 (3.3 (Boot Option Variables Default Boot > > > Behavior) and 3.4.1.1 (Removable Media Boot Behavior) in [6]. > > > > > > 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 UEFI compliant in order to 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. > > > > > > This document strongly recommends that VM implementations implement > > > persistent variable storage for their UEFI implementation. Persistent > > > variable storage shall be a property of a VM instance, but shall not be > > > stored as part of a portable disk image. Portable disk images shall > > > conform to the UEFI removable disk requirements from the UEFI spec and > > > cannot rely on on a pre-configured UEFI environment. > > > > > > The binary UEFI firmware implementation should not be distributed as > > > part of the VM image, but is specific to the VM implementation. > > > > > > > > > Hardware Description > > > -------------------- > > > The VM system must be UEFI compliant and therefore the UEFI system table > > > will provide a means to access hardware description data. > > > > > > The VM implementation must provide through its UEFI implementation: > > > > > > a complete FDT which describes the entire VM system and will boot > > > mainline kernels driven by device tree alone > > > > > > 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 booting, see [4] and [5]. > > > > > > > > > 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) or a bus-specific > > > mechanism such as PCI. > > > > > > If aarch64 physical CPUs implement support for the aarch32 execution > > > state in EL1 and EL0 execution, it is recommended that the VM > > > implementation supports booting the VM at EL1 in both aarch32 and > > > aarch64 execution states. > > > > > > 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]. > > > > > > It is strongly recommended that the VM implementation provides 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. > > > > > > For the VM image to be compliant with this spec, the following applies > > > for the guest OS in the VM image: > > > > > > The guest OS must include support for pl011 UART, virtio-console, and > > > the Xen PV console. > > > > > > The guest OS must include support for GICv2 and any available newer > > > version of the GIC architecture to maintain compatibility with older > > > VM implementations. > > > > > > It is strongly recommended to include support for all available > > > (block, network, console, balloon) virtio-pci, virtio-mmio, and Xen PV > > > drivers in the guest OS kernel or initial ramdisk. > > > > > > > > > Other common peripherals for block devices, networking, and more can > > > (and typically will) be provided, but OS software written and compiled > > > to run on ARM VMs cannot make any assumptions about which variations > > > of these should exist or which implementation they use (e.g. VirtIO or > > > Xen PV). See "Hardware Description" above. > > > > > > > > > Changes from previous versions of this RFC > > > ------------------------------------------ > > > Changes v1-v2: > > > - Clearly specify that the guest must support the pl011, > > > virtio-console, and Xen PV console. (Note that it was discussed to > > > mandate a pl011 during Linaro Connect Asia 2014, but that was under the > > > impression that the SBSA specification was an output-only no-irq > > > serial port, which is not the case. The only two benefits from > > > mandating a specific serial type was to handle "console=ttyAMA0" > > > kernel command line parameters and earlyprintk; Grant Likely has > > > submitted patches to avoid the need for "console=" parameters, and > > > Rob Herring has submitted patches for paravirtualized earlyprintk > > > consoles.) > > > - Reference EFI specification for bootable paths. > > > - Remove discussion on ACPI boot methods and do not suggest ACPI > > > support in VMs. > > > - Add specification about UEFI persistent variable storage and > > > portability. > > > > > > > > > References > > > ---------- > > > [1]: The ARM Architecture Reference Manual, ARMv8, Issue A.b > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > > > > > [2]: ARM Server Base System Architecture > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029/index.html > > > > > > [3]: The ARM Generic Interrupt Controller Architecture Specifications v2.0 > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html > > > > > > [4]: http://www.secretlab.ca/archives/27 > > > > > > [5]: https://git.linaro.org/people/leif.lindholm/linux.git/blob/refs/heads/uefi-for-upstream:/Documentation/arm/uefi.txt > > > > > > [6]: UEFI Specification 2.4 Revision A > > > http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf > > > _______________________________________________ > > > kvmarm mailing list > > > kvmarm@lists.cs.columbia.edu > > > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > > > > > > > > > -- > > Claudio Fontana > > Server Virtualization Architect > > Huawei Technologies Duesseldorf GmbH > > Riesstraße 25 - 80992 München > > > > office: +49 89 158834 4135 > > mobile: +49 15253060158 > > ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 9:50 ` Stefano Stabellini @ 2014-06-11 10:27 ` Arnd Bergmann -1 siblings, 0 replies; 111+ messages in thread From: Arnd Bergmann @ 2014-06-11 10:27 UTC (permalink / raw) To: linux-arm-kernel Cc: Stefano Stabellini, Claudio Fontana, cross-distro, Ian Campbell, kvm, Michael Casadevall, Rob Herring, Leif Lindholm, xen-devel, Robie Basak, Stefano Stabellini, Christoffer Dall, Grant Likely, kvmarm On Wednesday 11 June 2014 10:50:04 Stefano Stabellini wrote: > Although not in the ARM VM System Specification, Xen is certainly going > to support a fast boot path without UEFI firmware. I guess KVM will too. > You'll have to rely on hypervisor specific mechanisms to achieve it. > > In fact I wouldn't worry about UEFI when you need ACPI, that is not in > this specification. Moreover the only hypervisor supporting virtio on > ARM is KVM as far as I know. Ah right, I missed the part about ACPI. > > One aspect of this is that we currently start executing the image directly (no UEFI involved on the guest), > > and in some cases we might not need a full fledged file system at all, > > as the communication can happen via virtio channels. > > > > We do have a need for ACPI for discovery of information like gic addresses, > > timers, interrupts... (no interest on device trees, really), and of PCI-E. I wonder how you'd expect to find the ACPI data when there is no UEFI. It's not likely that any hypervisor would ship with an ACPI implementation that is independent of UEFI, because Linux (or any other full OS for that matter) would support that scenario. You could of course link OSv with an ACPI binary that is specific to KVM, but then I don't know why you wouldn't just hardcode the data in OSv directly. Arnd ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-11 10:27 ` Arnd Bergmann 0 siblings, 0 replies; 111+ messages in thread From: Arnd Bergmann @ 2014-06-11 10:27 UTC (permalink / raw) To: linux-arm-kernel On Wednesday 11 June 2014 10:50:04 Stefano Stabellini wrote: > Although not in the ARM VM System Specification, Xen is certainly going > to support a fast boot path without UEFI firmware. I guess KVM will too. > You'll have to rely on hypervisor specific mechanisms to achieve it. > > In fact I wouldn't worry about UEFI when you need ACPI, that is not in > this specification. Moreover the only hypervisor supporting virtio on > ARM is KVM as far as I know. Ah right, I missed the part about ACPI. > > One aspect of this is that we currently start executing the image directly (no UEFI involved on the guest), > > and in some cases we might not need a full fledged file system at all, > > as the communication can happen via virtio channels. > > > > We do have a need for ACPI for discovery of information like gic addresses, > > timers, interrupts... (no interest on device trees, really), and of PCI-E. I wonder how you'd expect to find the ACPI data when there is no UEFI. It's not likely that any hypervisor would ship with an ACPI implementation that is independent of UEFI, because Linux (or any other full OS for that matter) would support that scenario. You could of course link OSv with an ACPI binary that is specific to KVM, but then I don't know why you wouldn't just hardcode the data in OSv directly. Arnd ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-11 9:50 ` Stefano Stabellini ` (3 preceding siblings ...) (?) @ 2014-06-11 10:27 ` Arnd Bergmann -1 siblings, 0 replies; 111+ messages in thread From: Arnd Bergmann @ 2014-06-11 10:27 UTC (permalink / raw) To: linux-arm-kernel Cc: cross-distro, Ian Campbell, kvm, Michael Casadevall, Stefano Stabellini, Claudio Fontana, Rob Herring, Leif Lindholm, xen-devel, Robie Basak, Stefano Stabellini, Grant Likely, kvmarm, Christoffer Dall On Wednesday 11 June 2014 10:50:04 Stefano Stabellini wrote: > Although not in the ARM VM System Specification, Xen is certainly going > to support a fast boot path without UEFI firmware. I guess KVM will too. > You'll have to rely on hypervisor specific mechanisms to achieve it. > > In fact I wouldn't worry about UEFI when you need ACPI, that is not in > this specification. Moreover the only hypervisor supporting virtio on > ARM is KVM as far as I know. Ah right, I missed the part about ACPI. > > One aspect of this is that we currently start executing the image directly (no UEFI involved on the guest), > > and in some cases we might not need a full fledged file system at all, > > as the communication can happen via virtio channels. > > > > We do have a need for ACPI for discovery of information like gic addresses, > > timers, interrupts... (no interest on device trees, really), and of PCI-E. I wonder how you'd expect to find the ACPI data when there is no UEFI. It's not likely that any hypervisor would ship with an ACPI implementation that is independent of UEFI, because Linux (or any other full OS for that matter) would support that scenario. You could of course link OSv with an ACPI binary that is specific to KVM, but then I don't know why you wouldn't just hardcode the data in OSv directly. Arnd ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 16:44 ` Claudio Fontana ` (4 preceding siblings ...) (?) @ 2014-06-11 11:22 ` Grant Likely -1 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-06-11 11:22 UTC (permalink / raw) To: Claudio Fontana Cc: Michael Casadevall, Ian Campbell, kvm, cross-distro, Rob Herring, Leif Lindholm, xen-devel, Robie Basak, Stefano Stabellini, Christoffer Dall, kvmarm, linux-arm-kernel On 10 Jun 2014 17:45, "Claudio Fontana" <claudio.fontana@huawei.com> wrote: > > Hello all, > > I just wanted to share with you guys how we are using virtualization on ARM64 over here for the OSv project. > I don't know if that's something that could be useful for your specification effort. > > In OSv, creating and starting a VM to some level means starting an application. > That is, OSv should be a very thin bare bones guest server OS, which also acts as a kind of run-time library for an application to run. > All the devices are assumed to be virtualized and heavily relying on virtio. > > Therefore we see a higher need for quick VM launch than it might be for other use cases. > > One aspect of this is that we currently start executing the image directly (no UEFI involved on the guest), > and in some cases we might not need a full fledged file system at all, > as the communication can happen via virtio channels. The purpose of this spec is for creating portable disk images. It is intended to support the virtual-machine-looks-just-like-a-real-machine model, and is intended to provide exactly the same interface to installers as to real machines. It isn't really interesting for use cases like OSv or anyone who wants to start the kernel directly. You don't need UEFI in that case because the host has pre-knowledge of which kernel binary to load. In that regard this spec doesn't affect you. > > We do have a need for ACPI for discovery of information like gic addresses, timers, interrupts... (no interest on device trees, really), and of PCI-E. This may be a problem for you then. The only time we're planning to support ACPI in a VM is when UEFI is used for booting. Even the first version of this spec specifies FDT, not ACPI. FDT support is there now in Xen and KVM, but there is nothing for ACPI on ARM VMs. What is the objection to obtaining discovery information from FDT? > By skipping steps like UEFI, grub, firmware load, etc we strive to keep our application launch time low. > Is this going to create problems for us in the future if you start requiring every VM to boot using those instead? No, we're not requiring a full firmware stack to boot. As described above, this is only for booting disk images. g. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [RFC v2] ARM VM System Specification 2014-06-10 16:44 ` Claudio Fontana @ 2014-06-11 11:22 ` Grant Likely -1 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-06-11 11:22 UTC (permalink / raw) To: Claudio Fontana Cc: Michael Casadevall, Robie Basak, Stefano Stabellini, xen-devel, kvm, kvmarm, cross-distro, Rob Herring, linux-arm-kernel, Christoffer Dall, Leif Lindholm, Ian Campbell On 10 Jun 2014 17:45, "Claudio Fontana" <claudio.fontana@huawei.com> wrote: > > Hello all, > > I just wanted to share with you guys how we are using virtualization on ARM64 over here for the OSv project. > I don't know if that's something that could be useful for your specification effort. > > In OSv, creating and starting a VM to some level means starting an application. > That is, OSv should be a very thin bare bones guest server OS, which also acts as a kind of run-time library for an application to run. > All the devices are assumed to be virtualized and heavily relying on virtio. > > Therefore we see a higher need for quick VM launch than it might be for other use cases. > > One aspect of this is that we currently start executing the image directly (no UEFI involved on the guest), > and in some cases we might not need a full fledged file system at all, > as the communication can happen via virtio channels. The purpose of this spec is for creating portable disk images. It is intended to support the virtual-machine-looks-just-like-a-real-machine model, and is intended to provide exactly the same interface to installers as to real machines. It isn't really interesting for use cases like OSv or anyone who wants to start the kernel directly. You don't need UEFI in that case because the host has pre-knowledge of which kernel binary to load. In that regard this spec doesn't affect you. > > We do have a need for ACPI for discovery of information like gic addresses, timers, interrupts... (no interest on device trees, really), and of PCI-E. This may be a problem for you then. The only time we're planning to support ACPI in a VM is when UEFI is used for booting. Even the first version of this spec specifies FDT, not ACPI. FDT support is there now in Xen and KVM, but there is nothing for ACPI on ARM VMs. What is the objection to obtaining discovery information from FDT? > By skipping steps like UEFI, grub, firmware load, etc we strive to keep our application launch time low. > Is this going to create problems for us in the future if you start requiring every VM to boot using those instead? No, we're not requiring a full firmware stack to boot. As described above, this is only for booting disk images. g. ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-06-11 11:22 ` Grant Likely 0 siblings, 0 replies; 111+ messages in thread From: Grant Likely @ 2014-06-11 11:22 UTC (permalink / raw) To: linux-arm-kernel On 10 Jun 2014 17:45, "Claudio Fontana" <claudio.fontana@huawei.com> wrote: > > Hello all, > > I just wanted to share with you guys how we are using virtualization on ARM64 over here for the OSv project. > I don't know if that's something that could be useful for your specification effort. > > In OSv, creating and starting a VM to some level means starting an application. > That is, OSv should be a very thin bare bones guest server OS, which also acts as a kind of run-time library for an application to run. > All the devices are assumed to be virtualized and heavily relying on virtio. > > Therefore we see a higher need for quick VM launch than it might be for other use cases. > > One aspect of this is that we currently start executing the image directly (no UEFI involved on the guest), > and in some cases we might not need a full fledged file system at all, > as the communication can happen via virtio channels. The purpose of this spec is for creating portable disk images. It is intended to support the virtual-machine-looks-just-like-a-real-machine model, and is intended to provide exactly the same interface to installers as to real machines. It isn't really interesting for use cases like OSv or anyone who wants to start the kernel directly. You don't need UEFI in that case because the host has pre-knowledge of which kernel binary to load. In that regard this spec doesn't affect you. > > We do have a need for ACPI for discovery of information like gic addresses, timers, interrupts... (no interest on device trees, really), and of PCI-E. This may be a problem for you then. The only time we're planning to support ACPI in a VM is when UEFI is used for booting. Even the first version of this spec specifies FDT, not ACPI. FDT support is there now in Xen and KVM, but there is nothing for ACPI on ARM VMs. What is the objection to obtaining discovery information from FDT? > By skipping steps like UEFI, grub, firmware load, etc we strive to keep our application launch time low. > Is this going to create problems for us in the future if you start requiring every VM to boot using those instead? No, we're not requiring a full firmware stack to boot. As described above, this is only for booting disk images. g. ^ permalink raw reply [flat|nested] 111+ messages in thread
* [RFC v2] ARM VM System Specification @ 2014-03-28 18:45 Christoffer Dall 0 siblings, 0 replies; 111+ messages in thread From: Christoffer Dall @ 2014-03-28 18:45 UTC (permalink / raw) To: cross-distro, linux-arm-kernel, kvmarm, kvm, xen-devel Cc: Peter Maydell, Ian Campbell, Michael Casadevall, marc.zyngier, Rob Herring, Leif Lindholm, Robie Basak, Stefano Stabellini, Grant Likely 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, 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 as specified in Section 3.3 (3.3 (Boot Option Variables Default Boot Behavior) and 3.4.1.1 (Removable Media Boot Behavior) in [6]. 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 UEFI compliant in order to 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. This document strongly recommends that VM implementations implement persistent variable storage for their UEFI implementation. Persistent variable storage shall be a property of a VM instance, but shall not be stored as part of a portable disk image. Portable disk images shall conform to the UEFI removable disk requirements from the UEFI spec and cannot rely on on a pre-configured UEFI environment. The binary UEFI firmware implementation should not be distributed as part of the VM image, but is specific to the VM implementation. Hardware Description -------------------- The VM system must be UEFI compliant and therefore the UEFI system table will provide a means to access hardware description data. The VM implementation must provide through its UEFI implementation: a complete FDT which describes the entire VM system and will boot mainline kernels driven by device tree alone 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 booting, see [4] and [5]. 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) or a bus-specific mechanism such as PCI. If aarch64 physical CPUs implement support for the aarch32 execution state in EL1 and EL0 execution, it is recommended that the VM implementation supports booting the VM at EL1 in both aarch32 and aarch64 execution states. 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]. It is strongly recommended that the VM implementation provides 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. For the VM image to be compliant with this spec, the following applies for the guest OS in the VM image: The guest OS must include support for pl011 UART, virtio-console, and the Xen PV console. The guest OS must include support for GICv2 and any available newer version of the GIC architecture to maintain compatibility with older VM implementations. It is strongly recommended to include support for all available (block, network, console, balloon) virtio-pci, virtio-mmio, and Xen PV drivers in the guest OS kernel or initial ramdisk. Other common peripherals for block devices, networking, and more can (and typically will) be provided, but OS software written and compiled to run on ARM VMs cannot make any assumptions about which variations of these should exist or which implementation they use (e.g. VirtIO or Xen PV). See "Hardware Description" above. Changes from previous versions of this RFC ------------------------------------------ Changes v1-v2: - Clearly specify that the guest must support the pl011, virtio-console, and Xen PV console. (Note that it was discussed to mandate a pl011 during Linaro Connect Asia 2014, but that was under the impression that the SBSA specification was an output-only no-irq serial port, which is not the case. The only two benefits from mandating a specific serial type was to handle "console=ttyAMA0" kernel command line parameters and earlyprintk; Grant Likely has submitted patches to avoid the need for "console=" parameters, and Rob Herring has submitted patches for paravirtualized earlyprintk consoles.) - Reference EFI specification for bootable paths. - Remove discussion on ACPI boot methods and do not suggest ACPI support in VMs. - Add specification about UEFI persistent variable storage and portability. References ---------- [1]: The ARM Architecture Reference Manual, ARMv8, Issue A.b http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html [2]: ARM Server Base System Architecture http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029/index.html [3]: The ARM Generic Interrupt Controller Architecture Specifications v2.0 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.b/index.html [4]: http://www.secretlab.ca/archives/27 [5]: https://git.linaro.org/people/leif.lindholm/linux.git/blob/refs/heads/uefi-for-upstream:/Documentation/arm/uefi.txt [6]: UEFI Specification 2.4 Revision A http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf ^ permalink raw reply [flat|nested] 111+ messages in thread
end of thread, other threads:[~2014-07-02 10:13 UTC | newest] Thread overview: 111+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-03-28 18:45 [RFC v2] ARM VM System Specification Christoffer Dall 2014-03-28 18:45 ` Christoffer Dall 2014-03-30 22:10 ` Olof Johansson 2014-03-30 22:10 ` Olof Johansson 2014-03-30 22:10 ` Olof Johansson 2014-03-31 17:26 ` Christoffer Dall 2014-03-31 17:26 ` Christoffer Dall 2014-03-31 17:26 ` Christoffer Dall 2014-04-01 9:49 ` Ian Campbell 2014-04-01 9:49 ` Ian Campbell 2014-04-01 9:49 ` Ian Campbell 2014-04-01 9:57 ` Michael Casadevall 2014-04-01 9:57 ` Michael Casadevall 2014-04-01 9:57 ` Michael Casadevall 2014-04-01 10:16 ` Grant Likely 2014-04-01 10:16 ` Grant Likely 2014-04-01 10:16 ` Grant Likely 2014-04-29 14:42 ` Christoffer Dall 2014-04-29 14:42 ` Christoffer Dall 2014-04-29 14:42 ` Christoffer Dall 2014-04-30 8:14 ` Grant Likely 2014-04-30 8:14 ` Grant Likely 2014-04-30 8:14 ` Grant Likely 2014-06-10 14:42 ` Peter Maydell 2014-06-10 14:42 ` Peter Maydell 2014-06-10 14:42 ` Peter Maydell 2014-06-10 15:03 ` Ian Campbell 2014-06-10 15:03 ` Ian Campbell 2014-06-10 15:03 ` Ian Campbell 2014-06-10 17:00 ` Paolo Bonzini 2014-06-10 17:00 ` Paolo Bonzini 2014-06-10 17:00 ` Paolo Bonzini 2014-06-10 17:04 ` Christopher Covington 2014-06-10 17:04 ` Christopher Covington 2014-06-10 17:04 ` Christopher Covington 2014-06-10 18:08 ` Peter Maydell 2014-06-10 18:08 ` Peter Maydell 2014-06-10 18:08 ` Peter Maydell 2014-06-10 18:56 ` Paolo Bonzini 2014-06-10 18:56 ` Paolo Bonzini 2014-06-10 18:56 ` Paolo Bonzini 2014-06-10 19:18 ` Paolo Bonzini 2014-06-10 19:18 ` Paolo Bonzini 2014-06-10 19:18 ` Paolo Bonzini 2014-06-10 19:18 ` Paolo Bonzini 2014-06-10 19:18 ` Paolo Bonzini 2014-06-10 19:18 ` Paolo Bonzini 2014-06-11 6:54 ` Christoffer Dall 2014-06-11 6:54 ` Christoffer Dall 2014-06-11 6:54 ` Christoffer Dall 2014-06-11 8:16 ` Paolo Bonzini 2014-06-11 8:16 ` Paolo Bonzini 2014-06-11 8:16 ` Paolo Bonzini 2014-06-11 9:06 ` Arnd Bergmann 2014-06-11 9:06 ` Arnd Bergmann 2014-06-11 9:06 ` Arnd Bergmann 2014-06-30 16:19 ` Jon Masters 2014-06-30 16:19 ` Jon Masters 2014-06-30 16:19 ` Jon Masters 2014-06-30 20:46 ` Christoffer Dall 2014-06-30 20:46 ` Christoffer Dall 2014-06-30 21:14 ` Peter Maydell 2014-06-30 21:14 ` Peter Maydell 2014-06-30 21:14 ` Peter Maydell 2014-07-01 17:03 ` Stefano Stabellini 2014-07-01 17:03 ` Stefano Stabellini 2014-07-01 17:10 ` Peter Maydell 2014-07-01 17:10 ` Peter Maydell 2014-07-01 17:10 ` Peter Maydell 2014-07-02 10:13 ` Christoffer Dall 2014-07-02 10:13 ` Christoffer Dall 2014-07-02 10:13 ` Christoffer Dall 2014-07-01 17:03 ` Stefano Stabellini 2014-06-30 20:46 ` Christoffer Dall 2014-06-11 11:33 ` Grant Likely 2014-06-11 11:33 ` Grant Likely 2014-06-11 11:58 ` Arnd Bergmann 2014-06-11 11:58 ` Arnd Bergmann 2014-06-11 11:58 ` Arnd Bergmann 2014-06-11 12:02 ` Grant Likely 2014-06-11 12:02 ` Grant Likely 2014-06-11 12:02 ` Grant Likely 2014-06-11 14:14 ` Peter Maydell 2014-06-11 14:14 ` Peter Maydell 2014-06-11 14:14 ` Peter Maydell 2014-06-11 11:33 ` Grant Likely 2014-06-10 16:44 ` Claudio Fontana 2014-06-10 16:44 ` Claudio Fontana 2014-06-10 16:44 ` Claudio Fontana 2014-06-10 19:21 ` Arnd Bergmann 2014-06-10 19:21 ` Arnd Bergmann 2014-06-10 19:21 ` Arnd Bergmann 2014-06-11 9:50 ` Stefano Stabellini 2014-06-11 9:50 ` Stefano Stabellini 2014-06-11 9:50 ` Stefano Stabellini 2014-06-11 9:55 ` Christoffer Dall 2014-06-11 9:55 ` Christoffer Dall 2014-06-11 11:28 ` Grant Likely 2014-06-11 11:28 ` Grant Likely 2014-06-11 11:28 ` Grant Likely 2014-06-11 12:04 ` Christoffer Dall 2014-06-11 12:04 ` Christoffer Dall 2014-06-11 12:04 ` Christoffer Dall 2014-06-11 9:55 ` Christoffer Dall 2014-06-11 10:27 ` Arnd Bergmann 2014-06-11 10:27 ` Arnd Bergmann 2014-06-11 10:27 ` Arnd Bergmann 2014-06-11 11:22 ` Grant Likely 2014-06-11 11:22 ` Grant Likely 2014-06-11 11:22 ` Grant Likely 2014-03-28 18:45 Christoffer Dall
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.