What does the ideal open source runtime BIOS interface look like?
Turtle (Mill bee) | Thu 18 Apr 1:30 p.m.–2:15 p.m.
Presented by
-
Nicholas is an open source hacker at IBM's Linux Technology Center (LTC). He mostly works on Power architecture specific code, particularly in Linux and QEMU.
Abstract
One of the components of a firmware stack is a BIOS. The runtime BIOS provides abstraction for services and controls to low level hardware, to the operating system. The runtime BIOS component of OpenPOWER systems is called OPAL.
Although IBM OpenPOWER systems have an entirely open-source firmware stack and OPAL is an open specification, it resembles a traditional runtime BIOS interface where a BIOS call is a big-hammer operation that causes the operating system to lose control of the CPU while it runs rather opaque code in a special mode, before returning control to the OS.
ACPI addresses some of the limitations of such interfaces by providing bytecode that can be run by the operating system, however this approach seems to be designed for proprietary firmware and binary blobs. Can we do better with a ground-up design for open-source firmware and operating systems? Can eBPF save the day? In this talk I will present some findings of my investigations into answering these questions.
One of the components of a firmware stack is a BIOS. The runtime BIOS provides abstraction for services and controls to low level hardware, to the operating system. The runtime BIOS component of OpenPOWER systems is called OPAL. Although IBM OpenPOWER systems have an entirely open-source firmware stack and OPAL is an open specification, it resembles a traditional runtime BIOS interface where a BIOS call is a big-hammer operation that causes the operating system to lose control of the CPU while it runs rather opaque code in a special mode, before returning control to the OS. ACPI addresses some of the limitations of such interfaces by providing bytecode that can be run by the operating system, however this approach seems to be designed for proprietary firmware and binary blobs. Can we do better with a ground-up design for open-source firmware and operating systems? Can eBPF save the day? In this talk I will present some findings of my investigations into answering these questions.