From mboxrd@z Thu Jan  1 00:00:00 1970
Authentication-Results: mx.groups.io;
 dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 by groups.io with SMTP; Wed, 12 Jun 2019 09:28:24 -0700
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.redhat.com (Postfix) with ESMTPS id 43F32D4015;
	Wed, 12 Jun 2019 16:28:19 +0000 (UTC)
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-191.ams2.redhat.com [10.36.117.191])
	by smtp.corp.redhat.com (Postfix) with ESMTP id BCC445DD7E;
	Wed, 12 Jun 2019 16:28:17 +0000 (UTC)
Subject: Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency
To: David Woodhouse <dwmw2@infradead.org>, "Wu, Hao A" <hao.a.wu@intel.com>,
 "Ni, Ray" <ray.ni@intel.com>, "Justen, Jordan L"
 <jordan.l.justen@intel.com>, "devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
 "Phillips, D Scott" <d.scott.phillips@intel.com>
References: <20190611014313.12160-1-hao.a.wu@intel.com>
 <156023851748.468.9950138266923344967@jljusten-skl>
 <453b7e3c48014bd651717ccf9d9380356530bc82.camel@infradead.org>
 <B80AF82E9BFB8E4FBD8C89DA810C6A093C8E4FAF@SHSMSX104.ccr.corp.intel.com>
 <abc1db5b19a72e79fb481c381d06d7af3057515d.camel@infradead.org>
 <B80AF82E9BFB8E4FBD8C89DA810C6A093C8EC920@SHSMSX104.ccr.corp.intel.com>
 <734D49CCEBEEF84792F5B80ED585239D5C1B3908@SHSMSX104.ccr.corp.intel.com>
 <B80AF82E9BFB8E4FBD8C89DA810C6A093C8EC967@SHSMSX104.ccr.corp.intel.com>
 <862b419a-0715-7430-1f68-bbf54143f7b7@redhat.com>
 <038f0a993eba5d25eb5e499fa4be95fa6717ad3e.camel@infradead.org>
 <4bc1c867-31e8-53cc-429c-c68b2085f34a@redhat.com>
 <4e29cf1987459443f2bc3c99ba51bd770f5343b1.camel@infradead.org>
From: "Laszlo Ersek" <lersek@redhat.com>
Message-ID: <c2ddf54d-7072-f4c7-6619-d7c6da04126d@redhat.com>
Date: Wed, 12 Jun 2019 18:28:16 +0200
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: <4e29cf1987459443f2bc3c99ba51bd770f5343b1.camel@infradead.org>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 12 Jun 2019 16:28:24 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 06/12/19 17:15, David Woodhouse wrote:
> On Wed, 2019-06-12 at 13:52 +0200, Laszlo Ersek wrote:
>> (2c) SeaBIOS is built *twice*, once for the CSM, and another time for
>> the Cirrus VGABIOS.
>=20
> We shouldn't need to rebuild the VGA BIOS, should we? Any Legacy VGA
> BIOS should work =E2=80=94 and indeed UEFI should be able to use the Le=
gacy VGA
> BIOS even if it doesn't have native support for the video hardware.
>=20
> ISTR Windows 2008 even called legacy INT10 as part of the boot process
> and was part of my testing at the time?

Agreed on both counts. But, given that both the CSM binary and the
vgabios come from the same project (SeaBIOS), and that all software has
bugs :) , I thought it prudent to build all SeaBIOS artifacts in sync,
at any given SeaBIOS commit. I was preparing for a SeaBIOS bisection too
(expecting a regression), and I wanted to cover all SeaBIOS code with
that bisection.

Thanks
Laszlo