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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
