From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61])
 by mx.groups.io with SMTP id smtpd.web12.5194.1573743069822528674
 for <devel@edk2.groups.io>;
 Thu, 14 Nov 2019 06:51:10 -0800
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fPHhRhtY;
 spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1573743068;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=S4WyNrdIyRDQ+42jVKylEggqq0dmrwyPtunvSHJKRU8=;
	b=fPHhRhtYO2UBeldY+DjJw84+pcRVyWbijkgX1QqFlTz3aeFivne24FREWuKZgtAO2Tk4XI
	tMIjYKhbsmNPEAwfdfBzY2VEaYufNfWma3la/Ua/vcQqynsHrFFAAaghD4uUeJykmZ7hu6
	kUr2s/0oBMqdPCt7hfMWEFJN2uJQkMQ=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-280-xFD_mnRyMfOjwCiJ07G3Bw-1; Thu, 14 Nov 2019 09:51:07 -0500
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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id CCEED1005502;
	Thu, 14 Nov 2019 14:51:05 +0000 (UTC)
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-80.ams2.redhat.com [10.36.117.80])
	by smtp.corp.redhat.com (Postfix) with ESMTP id 698451001B05;
	Thu, 14 Nov 2019 14:51:04 +0000 (UTC)
Subject: Re: [edk2-devel] [PATCH 08/11] OvmfPkg: specify RngLib instances in dsc files
To: "Wang, Jian J" <jian.j.wang@intel.com>,
 "devel@edk2.groups.io" <devel@edk2.groups.io>,
 Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "Justen, Jordan L" <jordan.l.justen@intel.com>,
 "Gao, Liming" <liming.gao@intel.com>, "Ni, Ray" <ray.ni@intel.com>
References: <20191114021743.3876-1-jian.j.wang@intel.com>
 <20191114021743.3876-9-jian.j.wang@intel.com>
 <492770b6-9010-0513-618e-a525d0c63064@redhat.com>
 <D827630B58408649ACB04F44C5100036259AFF13@SHSMSX107.ccr.corp.intel.com>
From: "Laszlo Ersek" <lersek@redhat.com>
Message-ID: <adf55523-1f65-d0f4-cfe3-cfdea8bd2bc4@redhat.com>
Date: Thu, 14 Nov 2019 15:51:03 +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: <D827630B58408649ACB04F44C5100036259AFF13@SHSMSX107.ccr.corp.intel.com>
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22
X-MC-Unique: xFD_mnRyMfOjwCiJ07G3Bw-1
X-Mimecast-Spam-Score: 0
Content-Language: en-US
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

On 11/14/19 15:40, Wang, Jian J wrote:

> I'm curious that you want to do the "degrade" dynamically at boot time no=
t
> build time, right?

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.

(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.)

Thanks
Laszlo