Making distributions Just Work on ARM servers

Masters started by noting that the server and embedded markets are, in many ways, stark opposites of each other. In the embedded area, products are developed under tight deadlines, and the operating-system software is typically modified to suit the hardware. In the server market, instead, the operating system that will be installed on next year's systems was made last year. In this realm, he said, changing the hardware is seen as being easier than changing the software. Thus, there is a strong desire for a set of standards that will allow vendors to make servers that can run last year's enterprise distribution releases.

To that end, two documents have been written. The first of these, the Server Base System Architecture (SBSA) [PDF], describes the minimal features that a compliant system must provide. These include architectural specifications (a minimum of the ARM v8.0 architecture, for example) and the system-on-chip (SoC) features (interrupts, clocks, watchdogs, etc.) that must be provided. The other document, the Server Base Boot Requirements (SBBR) [PDF], provides the requirements to be able to boot a compliant distribution. It represents, Masters said, the "ACPI takeover of the world". Along with ACPI, it mandates the UEFI firmware standard and the set of expected boot protocols.

The result is a minimal specification for a set of standard hardware that can boot into a standard bootloader and discover the hardware that is available. There is, at this point, a lot that is not covered. The operation of caches is not discussed, for example, and there is no standard memory map. Emerging technologies are necessarily not a part of this document.

At this point, SUSE developer Alexander Graf noted that the goals behind these standards are good, but there is a missing piece: a way to inject drivers into the system during the installation process. New servers will certainly include hardware that was unknown at the time that a given distribution release was made, so there needs to be a way to add drivers at a later date. Masters agreed that this was a problem that should be worked on, but questioned whether it is appropriate to address it in the SBSA standard; Grant Likely added that it might be better handled at the UEFI level.

Another question had to do with how the standard had been defined; it was acknowledge that, so far, it has been a "who you know" process. Red Hat wanted to have something in place and there wasn't much time to get it done, so things just went forward with as much input from distributors and hardware vendors as could be arranged. There is a desire to open up and formalize the process in the near future, though. Masters noted that many of the core x86 standards were created in a closed manner early on; that is just how things have to be done at that stage, he suggested. An effort will be made to make the process more democratic going forward.

Dong Wei then took over, noting that, while ACPI started as an x86-dominated standard, most of the contributions to ACPI are coming from the ARM community now. The ACPI process has been opened up as this happened, and the actual specifications can now be found online and downloaded without even a click-through license step.

Work is being done on a set of compliance tests, he said. The SBSA test suite checks for the necessary system components and looks at the integration of PCIe peripherals. There have been a lot of "very creative" PCIe implementations shipped, he said, requiring thorough testing. The SBBR test suite tests the firmware interfaces provided by the subject system. The UEFI tests are based on the UEFI self-certification tests (SCT), while the ACPI tests use the Firmware Test Suite from Canonical. The intent is to provide all of these tests under open-source licenses. Unfortunately, at the moment, the UEFI SCT is only available to members. The development of this suite has been moved to a private GitHub repository as a preparatory step toward opening it entirely. There is a unified test suite release coming together in this GitHub repository.

An audience member asked why these tests are being done in the ARM community, rather than existing as a set of cross-architecture tests. Users want their systems to look the same, after all, regardless of their underlying architecture. The answer was that these are low-level tests that are aimed at just that goal, but that getting there requires this layer of architecture-specific test suites.

There was some discussion of a certification process for hardware. Users want their distributions to just work, and a certification sticker would give them confidence that a given product would, indeed, work properly. Masters answered that the tests being discussed here are an input to the certification process, rather than the certification itself. Once the hardware passes the compliance tests, distributors will start doing their own certification testing. There is, though, interest in adding distribution boot testing to the test suites as a way of improving the testing overall.

The final question had to do with cross-platform drivers. There is an interpreted executable format known as EFI Byte Code (EBC); drivers compiled to that format can run on multiple architectures. There is an EBC interpreter for ARM in the Tianocore UEFI reference implementation now. Shipping EBC drivers would allow vendors to support multiple architectures with a single binary, simplifying their lives.

It was noted, though, that this benefit vanishes if x86 drivers continue to be shipped as native executables. Adding ARM drivers requires supporting a second binary format; whether it's EBC or ARM native doesn't make a whole lot of difference. Only if a third major architecture arises will there be value in using EBC. There are also problems with EBC compilers being proprietary, a lack of support for the existing x86 EBC interpreter, and the fact that Microsoft, the only company doing secure-boot signing for drivers, will not sign EBC drivers.

Graf asked whether drivers could, instead, be shipped as a multiple-architecture binary. Progress is being made in this direction, and EFI supports multiple binary formats. Regardless of what form the solution might take, it was asserted that this is a critical blocker for the ARM server market. Without a way to simplify the driver-support problem, it is going to be hard to get card vendors to support ARM servers in general. As the session wound down, this situation was described as the highest-priority problem needing solution for distributors wanting to support ARM servers.

[Thanks to Linaro and the Linux Foundation for funding your editor's travel to Connect.]