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=kraxel@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 D4FEF211B6C1A for ; Tue, 22 Jan 2019 22:12:22 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9ABB55C9; Wed, 23 Jan 2019 06:12:21 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-116-38.ams2.redhat.com [10.36.116.38]) by smtp.corp.redhat.com (Postfix) with ESMTP id 26E5F5E1B0; Wed, 23 Jan 2019 06:12:20 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 3353931F63; Wed, 23 Jan 2019 07:12:20 +0100 (CET) Date: Wed, 23 Jan 2019 07:12:20 +0100 From: Gerd Hoffmann To: David Woodhouse Cc: "Ni, Ray" , Laszlo Ersek , "Richardson, Brian" , "Justen, Jordan L" , "edk2-devel@lists.01.org" , Kevin O'Connor , Anthony Perard Message-ID: <20190123061220.f4dr2bpmp6udfyeu@sirius.home.kraxel.org> 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> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 23 Jan 2019 06:12:21 +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 06:12:23 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 22, 2019 at 04:23:06PM +0000, David Woodhouse wrote: > 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. The idea never really took off though. > 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. It's not mandated by libvirt, you can easily create a VM configuration which uses a OVMF build with CSM support. But, yes, it is rarely seen in practice. Microsoft is doing the same btw: hyper-v has gen1 (bios) and gen2 (uefi) guest types. > 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. Seems people try to address this by building cloud images which support both BIOS and UEFI. > A one-size-fits-all BIOS using OVMF+CSM is very much > preferable. Building a one-size-fits-all BIOS is pretty much impossible due to CSM being incompatible with secure boot. cheers, Gerd