From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.136; helo=mga12.intel.com; envelope-from=ruiyu.ni@intel.com; receiver=edk2-devel@lists.01.org Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) (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 39FE2211982C2 for ; Mon, 17 Dec 2018 02:44:34 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2018 02:44:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,365,1539673200"; d="scan'208";a="107985965" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga007.fm.intel.com with ESMTP; 17 Dec 2018 02:44:33 -0800 Received: from fmsmsx115.amr.corp.intel.com (10.18.116.19) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 17 Dec 2018 02:44:33 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx115.amr.corp.intel.com (10.18.116.19) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 17 Dec 2018 02:44:33 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.203]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.210]) with mapi id 14.03.0415.000; Mon, 17 Dec 2018 18:44:31 +0800 From: "Ni, Ruiyu" To: Laszlo Ersek , "Justen, Jordan L" , Ard Biesheuvel , Anthony Perard , Julien Grall CC: "edk2-devel@lists.01.org" , Kevin O'Connor , Gerd Hoffmann , David Woodhouse Thread-Topic: Drop CSM support in OvmfPkg? Thread-Index: AdSVrlbHq3cEbVXKTw64xdd45eGHWv//+jKA//92RaA= Date: Mon, 17 Dec 2018 10:44:30 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5BF61929@SHSMSX104.ccr.corp.intel.com> References: <734D49CCEBEEF84792F5B80ED585239D5BF6035C@SHSMSX104.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 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: Mon, 17 Dec 2018 10:44:34 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Laszlo Ersek > Sent: Monday, December 17, 2018 5:54 PM > To: Ni, Ruiyu ; Justen, Jordan L > ; Ard Biesheuvel ; > Anthony Perard ; Julien Grall > > Cc: edk2-devel@lists.01.org; Kevin O'Connor ; Gerd > Hoffmann ; David Woodhouse > > Subject: Re: Drop CSM support in OvmfPkg? >=20 > (Adding Kevin, Gerd, David) >=20 > On 12/17/18 03:23, Ni, Ruiyu wrote: > > Hi OvmfPkg maintainers and reviewers, > > I am working on removing IntelFrameworkModulePkg and > IntelFrameworkPkg. The biggest dependency now I see is the CSM > components that OVMF depends on. > > So I'd like to know your opinion about how to handle this. I see two op= tions > here: > > > > 1. Drop CSM support in OvmfPkg. > > 2. Create a OvmfPkg/Csm folder to duplicate all CSM components there= . > > > > What's your opinion about this? >=20 > (1) Personally I never use CSM builds of OVMF. The OVMF builds in RHEL an= d > Fedora also don't enable the CSM (mainly because I had found debugging & > supporting the CSM *extremely* difficult). For virtualization, we general= ly > recommend "use SeaBIOS directly if you need a traditional BIOS guest". Yes that was my original thought. >=20 > (2) I'd be definitely unhappy about having to maintain the platform- > independent CSM components under OvmfPkg (such as > LegacyBootManagerLib, LegacyBootMaintUiLib, LegacyBiosDxe, VideoDxe). You are very correct about the scope of CSM components. >=20 > (3) However, David and Kevin had put a *lot* of work into enabling SeaBIO= S > to function as a CSM in combination with OVMF. Today, the CSM target is a > dedicated / separate "build mode" of SeaBIOS. I will wait for David and Kevin's comments. >=20 > (4) I also think an open source CSM implementation should exist, just so > people can study it and experiment with it. The CSM specification (from > Intel) is a public document, and the edk2 code is the reference > implementation for it. Killing the reference implementation makes the spe= c > mostly useless. Are Intel withdrawing the spec too? (Or has that happened > already?) CSM implementation follows the CSM specification. I am not sure if there is a public spec, an accordingly implementation should exist. For example, there is a framework HII spec which defines EFI_FORM_BROWSER_PROTOCOL. But there is no implementation of such protocol now in edk2 repo, only implementation of EFI_FORM_BROWSER2_PROTOCOL. >=20 > In short, I think the community would benefit if someone continued to > maintain the CSM infrastructure in edk2, but personally I won't volunteer= . I > also understand if Intel has no more resources for it. > Removing CSM from edk2 altogether (including OVMF) might be the natural > (albeit regrettable) result. I just see not much benefit of maintaining CSM in edk2 since now major OSVs don't support CSM boot anymore. Correct me if I am wrong. >=20 > Thanks > Laszlo