Re: Proposition of a BmEnumerateBootOptions() hook.

["Gabriel L. Somlo" <gsomlo@gmail.com>]

On Tue, May 15, 2018 at 03:52:34PM +0200, Laszlo Ersek wrote:
>
> [...]
>
> > APPLE BLESS
> >
> > This might be interesting for the OVMF maintainers.
> > I did not want to mention this concept at first, because I don't think
> > there is a terrible huge demand or interest, however I would like to
> > be able to implement Apple bless support for OVMF without having to
> > fork and modify edk2 drivers.
> > I did not check about a concrete way of implementation, however I will
> > shortly describe what needs to be involved.
> >
> > Secondary partitions: Supporting this will be easy when accepting the
> > hook proposed above and considering my comments regarding NV vs
> > volatile variables. No boot options are proactively added for those
> > installs and they are scanned on demand, which can be done entirely in
> > the proposed hook function.
> 
> I think it could also be done in AfterConsole(). I realize it might
> incur more pflash traffic -- like any other Boot#### option generation
> -- than what you might consider optimal, but functionally that shouldn't
> be a barrier.
> 
> > Primary partition: The so-called "Startup Volume" unfortunately is a
> > bit trickier. For it, a practically invalid Boot Option is added,
> > which is an expanded device path to the volume to be booted, however
> > without having a File Device Path Node appended.
> 
> This doesn't immediately seem invalid -- if memory serves, you can have
> \EFI\BOOT\BOOT<arch>.efi on fixed media as well, and if a boot option
> only names the HD() in question, that default boot path will be launched
> off of it.
> 
> > I had hoped to be able to use EFI_LOAD_FILE_PROTOCOL, however
> > obviously EFI_SIMPLE_FILE_SYSTEM_PROTOCOL will attach to the mentioned
> > DevicePath, which means LoadFile will not be called. Support for this
> > would need to be done via a platform-specific error handler for when
> > the DevicePath is determined to be invalid, which can then either fix
> > it up and return success or fail as well. I have not looked into this
> > in detail and I can understand if you are not interested in supporting
> > such a scenario. However if you do, I will look into it as soon as
> > possible and probably perform a few tests in OVMF.
> 
> I have a more general comment in the end: I doubt I could legally test
> an OSX guest on non-Apple hardware, so I won't try (and I'll most likely
> not buy or otherwise procure OSX, let alone Apple hardware, just for
> this). That means, if you post patches, my main focus will be on keeping
> the current behavior regression-free, and (secondarily) the
> implementation preferably simple & separated.
> 
> I've added Gabriel and Gerd to the CC list because I believe they might
> be interested in OSX guests (I seem to remember that a sizeable
> out-of-tree patchset is necessary for OSX guests anyway).

For whatever it's worth:

The size of the out-of-tree patchset (available at github.com/gsomlo/edk2,
branches gls-hfsplus -> gls-macboot -> gls-miscopt, with the latter
containing everything, cumulatively) is mainly due to the HFS+ driver
needed to access OSX disk images. The 'macboot' bits are from a GSoC
project by Reza Jelveh, and I haven't had a chance to really understand
how they work yet, since I think HFS+ support in a form acceptable to EDK2
are the bigger priority (and "gls-hfsplus" is not in a form acceptable
to EDK2 at the moment :)

Anyhow, the patched OVMF can boot Sierra right now, there's an
only-slightly-outdated writeup about it at
www.contrib.andrew.cmu.edu/~somlo/OSXKVM/

My long-term wish is to get everything cleaned up and palatable for
upstream inclusion, but haven't found time to really get into it over
the last couple of years.

Cheers,
--Gabriel