From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:400d:c0d::22c; helo=mail-qt0-x22c.google.com; envelope-from=gsomlo@gmail.com; receiver=edk2-devel@lists.01.org Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id BA06D209603ED for ; Tue, 15 May 2018 07:49:47 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id m5-v6so609051qti.1 for ; Tue, 15 May 2018 07:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=hWkE1NGCrnoRAQd8tfBMiBuNmQycidizxqxXeVuDXkg=; b=jfSKq9GF4ScfxrPFcMD/MxyONUPiDGD0Yd8KhDvSiz1lASd/FqaO46pHnwpvF3XieZ 3qFUxMEDL6dan2YRHqAlbK9FkRi+UODk2zmpnS7n0MM6KGR//8AHd92yMTgaacOUph/K lZ2a3PujRnnK+HF18ToDPG1PEnhftXbwi/wwpV159b0vnDPYMGBL1PlMSjPvJP/GFBaL ngvbzZhID6m9Lqd63naNNxwSI0IJAN5P5RYtWoeE39XtDsSQKpffSCfUxdAHuiB9DyxL q6z9g78QluW+Ctn0HIjAM8jzVUKDQUNK7AXWh9fLHRlVLrc42wk2+3eU3ZUTeyohm6pa qzfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=hWkE1NGCrnoRAQd8tfBMiBuNmQycidizxqxXeVuDXkg=; b=o2A3YPydNsrwDKhVywJ/WVZDKj3+R9iltcQUOp7R2dKJyRo6JMF8l9R0fkdQHOjbqU cWnQb6+6Y4W3fAo1g0rzMx+N+47Vcd2i8PF4s+Bnv+mIErKLwsCCj1aeRIYo6sdJDW6H y72a+7oSWNow6Un/quqalslnEfHqZNvCzl/qSIc2JoDfiIpTYDwbPYDicYZmcNemTycH m9yyW7Uy77xeJ6En0b/2XxnKPAVIq/Y0bR4ZtCzzWcU4PHpVhCkMKwrHcMfxhf6suYfU LNHIrmj+Mjz4xkPX96DEZdvMyvGzlqqW/qJpCeUJB/LdzMjnLyWI7ft9Xs8evsGb2bZi LhaQ== X-Gm-Message-State: ALKqPwcMDplHXXS+TbEIh64FASkiIM1yLRI6W+H9GmitslOftkRi2oWs L3Qg0nNEGkSiUC7MC0o1GlQ= X-Google-Smtp-Source: AB8JxZpkOgbgNOlYk4ZhV9tFdRxopmystzPNxBqZ/JEjYaA04uyEAhCP04ZOUDZJaitp0VGlJiQBzQ== X-Received: by 2002:aed:3224:: with SMTP id y33-v6mr14351682qtd.179.1526395786416; Tue, 15 May 2018 07:49:46 -0700 (PDT) Received: from hedwig.ini.cmu.edu (HEDWIG.INI.CMU.EDU. [128.2.16.51]) by smtp.gmail.com with ESMTPSA id g67-v6sm164203qkb.51.2018.05.15.07.49.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 15 May 2018 07:49:45 -0700 (PDT) Date: Tue, 15 May 2018 10:49:43 -0400 From: "Gabriel L. Somlo" To: Laszlo Ersek Cc: Marvin =?iso-8859-1?Q?H=E4user?= , "edk2-devel@lists.01.org" , "eric.dong@intel.com" , "star.zeng@intel.com" , "jordan.l.justen@intel.com" , "ard.biesheuvel@linaro.org" , "ruiyu.ni@intel.com" , Gerd Hoffmann Message-ID: <20180515144941.GI2284@hedwig.ini.cmu.edu> References: <12b0e557-4f3b-3766-1e52-c069c02b692e@redhat.com> <9d7aa3e0-d342-ab5a-f54b-2a853a5fcf57@redhat.com> MIME-Version: 1.0 In-Reply-To: <9d7aa3e0-d342-ab5a-f54b-2a853a5fcf57@redhat.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.1 (2017-09-22) Subject: Re: Proposition of a BmEnumerateBootOptions() hook. X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 14:49:48 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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.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