svn commit: r49571 - head/en_US.ISO8859-1/htdocs/news/status

Tue Oct 25 03:19:51 UTC 2016

Author: bjk
Date: Tue Oct 25 03:19:49 2016
New Revision: 49571
URL: https://svnweb.freebsd.org/changeset/doc/49571

Log:
  Add entry on EFI Runtime Services from kib

Modified:
  head/en_US.ISO8859-1/htdocs/news/status/report-2016-07-2016-09.xml

Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2016-07-2016-09.xml
==============================================================================

--- head/en_US.ISO8859-1/htdocs/news/status/report-2016-07-2016-09.xml	Mon Oct 24 20:22:54 2016	(r49570)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2016-07-2016-09.xml	Tue Oct 25 03:19:49 2016	(r49571)
@@ -1424,4 +1424,105 @@
       The FreeBSD Foundation
     </sponsor>
   </project>
+
+  <project cat='arch'>
+    <title>UEFI Runtime Services</title>
+
+    <contact>
+      <person>
+	<name>
+	  <given>Konstantin</given>
+	  <common>Belousov</common>
+	</name>
+	<email>kib at FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>UEFI (Unified Extensible Firmware Interface) specifies two
+	kinds of services for use by operating systems.  Boot Services are
+	designed for OS loaders to be able to load and initialize kernels,
+	while Runtime Services are supposed to be used by the kernels
+	during regular system operations.  The boot and runtime phases are
+	explicitely separated.  During boot, when loaders are executed,
+	the machine configuration is owned by UEFI.  During runtime, the
+	kernel manages the configuration, but needs to inform the firmware
+	about any changes that are made.</p>
+
+      <p>The model of split boot/runtime configuration makes assumptions
+	about the OS architecture that do not quite apply to the existing
+	&os; codebase.  For instance, the firmware notification of the
+	future runtime configuration must be done while the loader is
+	effectively still in control.  In technical terms, the
+	SetVirtualAddressMap() call must be made with the 1:1
+	physical:virtual mapping on amd64 systems, which for &os; means
+	that the call can be only issued by the loader.  But the loader
+	needs to know intimate details of the kernel address map to
+	provide the requested information.  This creates a new,
+	unfortunate, coupling between loader and kernel.</p>
+
+      <p>Reading the publicly available information about the MS
+	Windows boot process explained the UEFI control transfer
+	model.  The Windows loader constructs the address map for the
+	kernel, and with such a division of work the UEFI model is
+	reasonable.  The &os; kernel constructs its own address
+	space, only relying on a minimal map constructed by the
+	loader, which is enough for the pmap subsystem to bootstrap
+	itself and then to perform machine initialization in common
+	code.</p>
+
+      <p>Initial experiments with enabling runtime services were
+	centered around utilizing the direct address map (DMAP) on
+	amd64, which currently always exists and linearly maps at
+	least the lower 4G of physical addresses at some KVA location.
+	It was supposed that kernel would export the DMAP details like
+	linear base and guaranteed size for loader from its ELF image,
+	and provide the needed overflow map if the DMAP cannot
+	completely serve.  Unfortunately, two show-stopper bugs were
+	discovered with this approach.</p>
+
+      <p>First, EDK-based firmwares apparently require that the
+	runtime mapping exists simultaneously with the physical
+	mapping for the SetVirtualAddressMap() call.  Second, there
+	were references from other open-source projects mentioning
+	that some firmwares required the presence of the physical
+	mapping during runtime call.  Effectively, this forces both
+	kernel and loader to provide both mappings for all runtime
+	calls.</p>
+
+      <p>With such restrictions, informing the firmware about the
+	details of the kernel address space only adds useless work.
+	We could just as easily establish the 1:1 physical mapping
+	during runtime and get rid of SetVirtualAddressMap() entirely.
+	This approach was coded and the kernel interface to access
+	runtime services is based on it.</p>
+
+      <p>During the development, in particular, when trying to make
+	the loader modifications, it was quickly realized that there
+	were no fault-reporting facilities in loader.efi.  Machine
+	exceptions resulted in a silent hang.  Curiosly, in such a
+	situation the Intel firmware outputs the error code over the
+	serial port on 115200/8/1 settings, regardless of UEFI console
+	configuration, which was discovered by accident.
+	Unfortunately, the error code alone is not enough to diagnose
+	most problems.</p>
+
+      <p>A primitive fault reporter was written for loader.efi on
+	amd64, which intercepts exceptions from the firmware IDT and
+	dumps the machine state to the loader console.  Due to
+	complexity of the interception and possible bugs which might
+	do more harm than good there, the dumper is only activated by
+	explicit administrator action.</p>
+
+      <p>Note that the described work only provides the kernel
+	interfaces to make calling the EFI runtime services as easy as
+	calling a regular C function.  User-visible feature
+	development making use of the new interfaces is being
+	performed right now. </p>
+    </body>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+  </project>
 </report>
