(my mail client doesn't ident, sorry for the mess) On Thu, 9 Feb 2023 at 10:48, ff <f...@shokubai.tech <mailto:f...@shokubai.tech>> wrote: > > Hi > > Anyone knows what is the status of standardizing firmware handoff (when > starting BL33) ? > Here is a reference to the topic: > https://github.com/FirmwareHandoff/firmware_handoff > <https://github.com/FirmwareHandoff/firmware_handoff> > > I would be interested in both standard text and standard implementation in > TFA. > > The context is portability of type-1 hypervisors that need to be fully in > control of security and thus execute BL33 in an ad hoc "VM". > The rationale is to isolate everything that deals with devices or IO (at its > core, a hypervisor deals only with CPU, RAM, MMU, SMMU, GIC). > > Cheers > > FF > > PS: To explore how easy it is to boot a hypervisor with either booti, bootefi > or BL33 I published a Rust tool (barekit) that can do precisely that (and > much more as it can be used to create BL32 or even a Rust based FF-A > implementation): > https://www.linkedin.com/posts/fozog_github-fozogbarekit-rust-base-code-to-activity-7026199056116822017-7_l8?utm_source=share&utm_medium=member_desktop > > <https://www.linkedin.com/posts/fozog_github-fozogbarekit-rust-base-code-to-activity-7026199056116822017-7_l8?utm_source=share&utm_medium=member_desktop> > https://github.com/fozog/barekit <https://github.com/fozog/barekit> >
Interesting! I implemented something similar last year for QEM/mach-virt https://github.com/ardbiesheuvel/efilite <https://github.com/ardbiesheuvel/efilite> Doing EFI boot like this in a VM is actually faster than without any firmware whatsoever, given that there is no need to play with the MMU and caches or clean the entire kernel image to the PoC. (In my testing, EFI boot takes 3.5ms whereas bare metal boot takes 4.5 ms from vCPU reset to reaching start_kernel() in Linux) The main reason is precisely the one you mention: hypervisor folks ask for 'direct kernel boot' because it is faster but still want to pretend while in the kernel that we did EFI boot, for ACPI tables, SMBIOS, TPM support etc, but all this mucking about with uncached memory with the MMU off is both slow and unsafe, especially on recent micro-architectures. <ff_response> That's fantastic. Efilite is the perfect companion: - U-Boot is needed for special hardware initialization (Serdes...) at boot time - Efilite is really for VM startup. BTW, as you are associated with gnuefi: dealing with relocs has been a challenge __ I now understand the .bss issue with GNUEFI: it is a "virtual" section hidden in .data. The problem is the Rust linker (may be others) do not updated some headers that would help know it's size. And I discovered that .bss has to be initialized to 0... more details in coff_stager.rs. </ff_response> _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
