This is a patch set to support booting Hurd on a Qemu virtual machine configured with UEFI firmware. Now that multiboot2 is supported there was surprisingly little that needed to be done to achieve this. A serial console only is supported at this stage. My next focus will be to support a graphical console.
I hope that patches 1, 2, 3 and 5 will be acceptable, subject to review. It's patch 4, I think, that might not be. This patch adds a new gnumach device called "efi" whose only purpose is to make the physical address of the EFI System Table available to privileged processes. I modelled this on when we added support for 'PIC mode' status to an "irq" device. It seems a lot of effort for basically accessing a single integral value. I considered adding a mach message for the purpose but couldn't see a message set in which it made sense. One could add a Mach 'registry' feature which gave privileged read access to key (string) value (binary) pairs, perhaps. Anyway, I've put this solution forward as a default implementation that is functional at least. Patches 1-3 could be merged without 4 and 5. I exposed the EFI system root rather than the ACPI-RSDP for 2 reasons: 1) It is more useful in the sense that you can reach the RSDP from the EFI root and other servers might want to access other parts of the EFI data. 2) libacpica requires the physical address of the RSDP for its API. One cannot use the copy of the RSDP (supplied by the bootloader in MULTIBOOT2_TAG_TYPE_ACPI_NEW, for example) because the physical address of the copy is in 'available' RAM and the interested party (acpi) cannot map that address. It can map addresses that are 'reserved' (by ACPI) though and so it was necessary to search for the actual firmware RSDP address via the EFI tables. I didn't want to make a big patch to libacpica to use a virtual address instead. I've made the assumption that there is no inclination to support hurd-i386 using 32 bit UEFI. Thanks, Mike.
