From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id ABAC4211AF9E8 for ; Wed, 23 Jan 2019 01:47:06 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 117DF1E2E3; Wed, 23 Jan 2019 09:47:06 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-61.rdu2.redhat.com [10.10.120.61]) by smtp.corp.redhat.com (Postfix) with ESMTP id B31241001F54; Wed, 23 Jan 2019 09:47:00 +0000 (UTC) To: "Ni, Ray" , 'David Woodhouse' , Gerd Hoffmann , "Richardson, Brian" Cc: "Justen, Jordan L" , "edk2-devel@lists.01.org" , Kevin O'Connor , Anthony Perard 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> From: Laszlo Ersek Message-ID: <04736175-5976-8aff-ded1-e3bbbbaac679@redhat.com> Date: Wed, 23 Jan 2019 10:46:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5BFCF8F8@SHSMSX103.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 23 Jan 2019 09:47:06 +0000 (UTC) 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 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 X-List-Received-Date: Wed, 23 Jan 2019 09:47:06 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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. Thanks, Laszlo