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; Thu, 27 Jun 2019 12:01:24 -0700 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D3D0E81E0D; Thu, 27 Jun 2019 19:01:17 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-118.ams2.redhat.com [10.36.116.118]) by smtp.corp.redhat.com (Postfix) with ESMTP id BC6915C1B4; Thu, 27 Jun 2019 19:01:15 +0000 (UTC) Subject: Re: [PATCH v3 4/4] OvmfPkg: don't assign PCI BARs above 4GiB when CSM enabled From: "Laszlo Ersek" To: Alexander Graf Cc: devel@edk2.groups.io, David Woodhouse , Ard Biesheuvel References: <91d912c9-533a-22a3-4aa3-0fe114e1149f@amazon.com> Message-ID: <20006502-76ad-864a-97cb-0187cc44cf2a@redhat.com> Date: Thu, 27 Jun 2019 21:01:14 +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: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 27 Jun 2019 19:01:20 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/27/19 20:43, Laszlo Ersek wrote: > On 06/27/19 18:36, Alexander Graf wrote: >> That way we could have CSM enabled OVMF for everyone ;) > > Well, as long as we're discussing "everyone": we should forget about the > CSM altogether, in the long term. The CSM is a concession towards OSes > that are stuck in the past; a concession that is hugely complex and > difficult to debug & maintain. It is also incompatible with Secure Boot. > Over time, we should spend less and less time & energy on the CSM. Just > my opinion, of course. :) To clarify -- this is by no means to say that *SeaBIOS* is a relic. I absolutely don't imply that. Users should use the firmware they need, especially in the virtual world, where choosing is really easy. But the *CSM* is just an elaborate workaround for the user, to circumvent a decision that a platform vendor made for him/her unsolicitedly. In the virtual world in particular, I don't think such workarounds should be necessary; the platform vendor should *please* the user, and give them SeaBIOS directly, if they want that. (Again, just my opinion -- I just wanted to clarify that I wasn't taking a stab at SeaBIOS. That would be *foolish*.) Thanks Laszlo