From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [63.128.21.74]) by mx.groups.io with SMTP id smtpd.web10.13091.1585319995847326113 for ; Fri, 27 Mar 2020 07:39:56 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=EFKbGNyh; spf=pass (domain: redhat.com, ip: 63.128.21.74, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585319995; 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=JMsgefZVE1FR7OL+CHwnB/O5Mkp8fjh9/C4AJN6ujRY=; b=EFKbGNyhtiD+lCktVmkMhsAp/SoTj537jGECmHBVQBLsdAQnibaooBuCIU0R4kL3rJSAna N5TXqMzpAE9rpqKQ53RJbNh0VBeke7GgI01T6QF+naeNqGLETrLuY1upavB3uz/UWUd5Jl WwVbagX+KrpIwvR4WGAeYfb2xKxEgOY= 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-394-u0b7uDyNPR29Pn8FWzucsw-1; Fri, 27 Mar 2020 10:39:53 -0400 X-MC-Unique: u0b7uDyNPR29Pn8FWzucsw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 30E81107ACCD; Fri, 27 Mar 2020 14:39:52 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-36.ams2.redhat.com [10.36.114.36]) by smtp.corp.redhat.com (Postfix) with ESMTP id 20AF996F9A; Fri, 27 Mar 2020 14:39:49 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] .azurepipelines: Enable CI for OvmfPkg and EmulatorPkg From: "Laszlo Ersek" To: devel@edk2.groups.io, ard.biesheuvel@linaro.org, "Zhang, Shenglei" Cc: Sean Brogan , Bret Barkelew , Michael D Kinney , Liming Gao , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , Anthony Perard References: <20200326070418.25824-1-shenglei.zhang@intel.com> <896ef5b0-8487-3cba-8472-5a210b00fe8d@redhat.com> Message-ID: Date: Fri, 27 Mar 2020 15:39:49 +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: <896ef5b0-8487-3cba-8472-5a210b00fe8d@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/27/20 15:36, Laszlo Ersek wrote: > (+Phil, +Anthony) > > On 03/26/20 09:43, Ard Biesheuvel wrote: >> (+ Laszlo) >> >> On Thu, 26 Mar 2020 at 08:04, Zhang, Shenglei wrote: >>> >>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2570 >>> OvmfPkg and EmulatorPkg are mostly used by the developers, so add >>> them to target list. >>> >>> Cc: Sean Brogan >>> Cc: Bret Barkelew >>> Cc: Michael D Kinney >>> Cc: Liming Gao >>> Signed-off-by: Shenglei Zhang >> >> Could we add ArmVirtPkg as well please? Also, which .DSCs are built >> inside OvmfPkg/ with this change? > > Thanks for the CC. > > (1) Having learned that Sean and probably others do not benefit from > OvmfPkg, I do not wish to slow down PR gating for them, by making OVMF > builds a mandatory part of CI -- as long as the PR does not have a patch > that modifies OvmfPkg itself. > > (I'm unsure if the above behavior is already ensured by the CI system -- > if it is, then I'm sorry about the noise.) > > Same applies (from my perspective) to ArmVirtPkg. > > Obviously, I would definitely *like* if ArmVirtPkg / OvmfPkg builds were > a constant, mandatory part of CI, but I totally realize it would put an > unjustified burden on contributors that do not care about those > platforms at all -- especially given that the core package(s) being > patched -- such as NetworkPkg -- *are* test-built by CI in isolation anyway. > > > (2) In case the PR does modify OvmfPkg, and so the platform builds are > required, I would like the builds to cover more ground: > > (2a) DEBUG, RELEASE and NOOPT should all be covered, > > (2b) Ia32, Ia32X64, and X64 should all be covered. > > (I've CC'd Anthony so he can speak to the "OvmfXen.dsc" build configs.) > > (2c) For each of the three platforms I mention in (2b), there should be > a "bare bones" (default) build, but also a reasonably "full-blown" build. > > - Bare-bones build: > > -D FD_SIZE_2MB > > (This is so that the default (bare-bones) configuration continue to fit > in the (arguably legacy) 2MB FD.) > > - Full-blown build: > > -D SECURE_BOOT_ENABLE \ > -D SMM_REQUIRE \ > -D TPM_ENABLE \ > -D TPM_CONFIG_ENABLE \ > -D NETWORK_TLS_ENABLE \ > -D NETWORK_IP6_ENABLE \ > -D NETWORK_HTTP_BOOT_ENABLE > > Note that this will require the OpenSSL submodule to be initialized. > > This means 3 * 3 * 2 = 18 builds thus far. > > > (3) ArmVirtPkg platforms should be built if either OvmfPkg or ArmVirtPkg > is modified. > > Personally I'd like the ArmVirtQemu platform to be built, but Ard and > Anthony will likely ask for more. > > For ArmVirtQemu, because we have no (i) different FD sizes, nor (b) an > SMM stack that makes some drivers strictly exclusive with other drivers, > I think we should simply aim at the most comprehensive build: > > (3a) DEBUG, RELEASE and NOOPT, > > (3b) Options: > > -D SECURE_BOOT_ENABLE \ > -D TPM2_ENABLE \ > -D TPM2_CONFIG_ENABLE \ > -D NETWORK_IP6_ENABLE \ > -D NETWORK_HTTP_BOOT_ENABLE \ > -D NETWORK_TLS_ENABLE > > This means +3 builds (21 builds in total) from my perspective. ... to be clear: the above is my "wish list". If, at the moment, we can enable OvmfPkg and ArmVirtPkg builds in any shape or form whatsoever, that's already an improvement! So my comments are not to be taken as disagreement with the currently proposed patch. I'm just describing how I believe we should do these builds eventually. Thanks Laszlo