From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mx.groups.io with SMTP id smtpd.web11.5196.1573743343590842849 for ; Thu, 14 Nov 2019 06:55:44 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.136, mailfrom: jian.j.wang@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2019 06:55:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,304,1569308400"; d="scan'208";a="208143585" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga006.jf.intel.com with ESMTP; 14 Nov 2019 06:55:35 -0800 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 14 Nov 2019 06:55:34 -0800 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 14 Nov 2019 06:55:34 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Thu, 14 Nov 2019 06:55:34 -0800 Received: from shsmsx107.ccr.corp.intel.com ([169.254.9.63]) by shsmsx102.ccr.corp.intel.com ([169.254.2.108]) with mapi id 14.03.0439.000; Thu, 14 Nov 2019 22:55:32 +0800 From: "Wang, Jian J" To: "devel@edk2.groups.io" , "lersek@redhat.com" , Ard Biesheuvel CC: "Justen, Jordan L" , "Gao, Liming" , "Ni, Ray" Subject: Re: [edk2-devel] [PATCH 08/11] OvmfPkg: specify RngLib instances in dsc files Thread-Topic: [edk2-devel] [PATCH 08/11] OvmfPkg: specify RngLib instances in dsc files Thread-Index: AQHVmtvBOKYP5K/O4kyUc+QpdU2PZaeKueaQ//+AJYCAAIbngA== Date: Thu, 14 Nov 2019 14:55:32 +0000 Message-ID: References: <20191114021743.3876-1-jian.j.wang@intel.com> <20191114021743.3876-9-jian.j.wang@intel.com> <492770b6-9010-0513-618e-a525d0c63064@redhat.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOGQxMzExNDctNmJhZi00ZGU3LWI0MzEtNzdiOWJhNjAwOGRkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiRWZ0QUJSR21UNDFnSm1hSnFicHQ5RnpNcmJJV0FDVFJwbVcwWFc5UGRyZHh4T0QwbmpcL09IY3l6T1liNXJzdnYifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: jian.j.wang@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Laszlo, That makes sense for virtual platforms. Thanks for the explanation. Regards, Jian > -----Original Message----- > From: devel@edk2.groups.io On Behalf Of Laszlo Er= sek > Sent: Thursday, November 14, 2019 10:51 PM > To: Wang, Jian J ; devel@edk2.groups.io; Ard > Biesheuvel > Cc: Justen, Jordan L ; Gao, Liming > ; Ni, Ray > Subject: Re: [edk2-devel] [PATCH 08/11] OvmfPkg: specify RngLib instance= s in > dsc files >=20 > On 11/14/19 15:40, Wang, Jian J wrote: >=20 > > I'm curious that you want to do the "degrade" dynamically at boot time= not > > build time, right? >=20 > Indeed, that's the whole point. When running on QEMU (considering all of > arm/aarch64/i386/x86_64), the firmware can assume quite little of the > underlying platform hardware; a single firmware binary is expected to > support multiple (virtual) hardware configurations. Therefore several > decisions have to be made dynamically at boot time, in the firmware, > that physical firmware platforms can hard-wire at build time. >=20 > (Of course this approach has its limits -- the most visible "platform > split" that we do implement at build time is "QEMU vs. Xen". ArmVirtPkg > implements this switch only at build time, and OvmfPkg will also fully > adopt that approach in the future.) >=20 > Thanks > Laszlo >=20 >=20 >=20