From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::12d; helo=mail-it1-x12d.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 743AB2096DCEF for ; Wed, 23 Jan 2019 04:26:34 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id h193so2598605ita.5 for ; Wed, 23 Jan 2019 04:26:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xfjk30Ryr7CFd9cScfImJOgzIUoSjyT24GnH9+19PAM=; b=BXO1OOiIgMUzjKY2nk3sQZaTgcYdRLeliSYIBy7d3Y8Qh4oNLfBkzp+JIpOsUvDL1t Uym1/nSLZe1tJh0HUo6IJs3iFbKFMKzliGaoPsgtA2FyhGIUT3kfNBD+8AOgkTIKpePX QIYTRJtArp5NCOUH8uenIx5tqjolEh0q7UH5s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xfjk30Ryr7CFd9cScfImJOgzIUoSjyT24GnH9+19PAM=; b=G1zvZz3pV7WyFGiCctq0u5dYkxSFx6DrtqspozT/O3xV/CKl+6eMqB27E3/rFLrt5k +SsYvMq+xLu6aPkd7iC/0S/yJoOtKOrOat7FCXeoSRnkomYqlMFqo161d+4bs9BFAKFU cObeE+kVxzeeXJn6QgR0jbej86Yu2J/oRa7PxSxBDelyuvMFmlJ0mhya1terqena4PZ0 UoBs8aJhFg4psFvVRYiLwQcrbGFcS5pyQZsMHRd/esyyu++1WxWYmZ1EqS+4Ql20F81j e4muopaooELm30wF4LhYYtmcCb7ta4y3FVmRL8HedxzC32YV+Yo7hV7wPQyro3A/zfre LJGw== X-Gm-Message-State: AJcUukdJiMJNLBuYu3v/xtudd/pBBme1I3U5L4AaErsXlH/Nyh6mC8Lv 4PJMOOH3sVyZeitXJXEJ2NDofuu2DSpvBXC34ooZRw== X-Google-Smtp-Source: ALg8bN7OIKN5jaIzZfTsJuNkzcRf5kVnaneSlMtICFfVg1GH+WoyJuZESvteIRpRoHe9jqIIyr9acL1B+KABpaeykFc= X-Received: by 2002:a02:734b:: with SMTP id a11mr768652jae.62.1548246393383; Wed, 23 Jan 2019 04:26:33 -0800 (PST) MIME-Version: 1.0 References: <734D49CCEBEEF84792F5B80ED585239D5BF6035C@SHSMSX104.ccr.corp.intel.com> <20181220064447.7eflwhm3t5upj7ds@sirius.home.kraxel.org> <734D49CCEBEEF84792F5B80ED585239D5BF6895F@SHSMSX104.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5BFCEBF2@SHSMSX103.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5BFCF8F8@SHSMSX103.ccr.corp.intel.com> <04736175-5976-8aff-ded1-e3bbbbaac679@redhat.com> In-Reply-To: <04736175-5976-8aff-ded1-e3bbbbaac679@redhat.com> From: Ard Biesheuvel Date: Wed, 23 Jan 2019 13:26:20 +0100 Message-ID: To: Laszlo Ersek Cc: "Ni, Ray" , David Woodhouse , Gerd Hoffmann , "Richardson, Brian" , Anthony Perard , "Justen, Jordan L" , "edk2-devel@lists.01.org" , "Kevin O'Connor" Subject: Re: Drop CSM support in OvmfPkg? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 12:26:34 -0000 Content-Type: text/plain; charset="UTF-8" On Wed, 23 Jan 2019 at 10:55, Laszlo Er > > That's going to be a hard thing to keep from happening over time, as > > this is valid C :(sek wrote: > > Hi All, > > On 01/23/19 04:43, Ni, Ray wrote: > >> -----Original Message----- > >> From: David Woodhouse > >> Sent: Wednesday, January 23, 2019 12:23 AM > >> To: Ni, Ray ; Gerd Hoffmann ; > >> Laszlo Ersek ; Richardson, Brian > >> > >> Cc: Justen, Jordan L ; edk2-devel@lists.01.org; > >> Kevin O'Connor ; Anthony Perard > >> > >> Subject: Re: Drop CSM support in OvmfPkg? > >> > >> On Tue, 2019-01-22 at 16:13 +0000, Ni, Ray wrote: > >>> David, > >>> I'd like to re-start the discussion. > >>> Could you please kindly explain the background/reason of adding CSM > >>> support in OVMF? > >>> Maybe knowing the reason can help to make further decisions of > >>> whether to > >>> A. keep it outside OvmfPkg > >>> B. keep it inside OvmfPkg > >>> C. maybe have a chance to just remove the CSM support after > >>> revisiting > >> > >> > >> The idea was to make it simple to have a single firmware image for > >> virtual machines which would support both UEFI and Legacy boot for > >> guests simultaneously. > >> > >> In libvirt there has been an alternative approach, where the BIOS image > >> is switched between OVMF and SeaBIOS according to the configuration of > >> the guest VM. > >> > >> That's fine for libvirt, but in situations where VM hosting is provided > >> as a service, it becomes quite painful to manage the 'UEFI' vs. > >> 'Legacy' flags on guest images and then switch firmware images > >> accordingly. A one-size-fits-all BIOS using OVMF+CSM is very much > >> preferable. > > > > David, > > Thanks for sharing. I now understand that you do have a need of > > CSM + UEFI OVMF image. > > A very straightforward idea is to move all COM components you needed > > into OvmfPkg. But Laszlo as the OvmfPkg owner may disagree with this. > > So maybe you could set up another (github) repo and clone all the CSM components > > there. > > EDKII build tool supports to build firmware from multiple repos. > > That's how we can have edk2-platforms and to-be-created edk2-app. > > In practical, you could create a new csm repo. > > Laszlo/Gerd who don't care about CSM can just build OVMF image from edk2 repo. > > You can build the OVMF image from edk2 and csm repo. > > > > We can have a call if you are ok. I can explain how that can work in details. > > I'm fine if we move the generic CSM components into OvmfPkg, however I'm > going to ask David to assume reviewer responsibilities for them. > > Given the current format of "Maintainers.txt", we couldn't spell out the > exact pathnames of the CSM components, so we'd add a line like > > R: David Woodhouse > > under OvmfPkg. There is "prior art" for this pattern, see: > > R: Anthony Perard > R: Julien Grall > > Because Anthony and Julien are the authority on Xen-related code under > OvmfPkg. (See commit 337fe6a06eda, "Maintainers.txt: add Xen reviewers > to OvmfPkg", 2017-09-26.) > > > If we keep CSM support in OvmfPkg in any form at all, then I would > prefer holding all the related stuff in the core edk2 repository (with > the above Reviewership), over requiring people to deal with multiple > repositories. I agree (from experience) that PACKAGES_PATH / multiple > workspaces work fine, but in this case I think keeping one shared > history is an advantage. > I don't have an opinion on whether we should keep CSM or not in OvmfPkg. But if we do, I agree we should just move all the pieces we rely on and that are getting dropped into OvmfPkg/ proper, rather than keeping them on the side somewhere.