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; Fri, 28 Jun 2019 06:12:28 -0700 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6CE5830C5836; Fri, 28 Jun 2019 13:12:19 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-139.ams2.redhat.com [10.36.116.139]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6CD9E5D705; Fri, 28 Jun 2019 13:12:16 +0000 (UTC) Subject: Re: [PATCH v3 4/4] OvmfPkg: don't assign PCI BARs above 4GiB when CSM enabled To: David Woodhouse , Alexander Graf Cc: devel@edk2.groups.io, Ard Biesheuvel References: <91d912c9-533a-22a3-4aa3-0fe114e1149f@amazon.com> <20006502-76ad-864a-97cb-0187cc44cf2a@redhat.com> From: "Laszlo Ersek" Message-ID: <7811dd9d-1d86-8a2b-f36d-19c0ea3e455a@redhat.com> Date: Fri, 28 Jun 2019 15:12:15 +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.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Fri, 28 Jun 2019 13:12:26 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/27/19 21:16, David Woodhouse wrote: > On Thu, 2019-06-27 at 21:01 +0200, Laszlo Ersek wrote: >> >> 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. > > Choosing is easy if you're running qemu on your desktop box. > > If the owner of the guest doesn't also own the host, then you're into > "configurability", which means guests either having to *explicitly* > manage which firmware they get which is a pain for the customer, Depends on the customer. They are capable of choosing the OS they want. At least some of them are able to (and/or prefer to) choose the firmware under their OS too. In the opposite direction, the "libosinfo" project already tracks minute details of guest OSes (for example, what version of the virtio spec the OS's drivers support), so that users can get "optimized defaults", when they create domains. Adding "preferred firmware" shouldn't be infeasible IMO, if it were necessary. > or some kind of half-arsed guessing about which firmware to use, based > on poking around in the image that's being booted. Which doesn't > generally go well either. > > There's a reason Intel went for the one-size-fits-all on real > hardware, and it applies just as well to (some, but not all) virtual > hosting too. Quoting an earlier message from the list: http://mid.mail-archive.com/4dfb6a1f-da8f-4141-8687-be968ff261a9@hpe.com On 01/25/19 21:28, Brian J. Johnson wrote: > In fall of 2017, Intel declared their intention to end legacy BIOS > support on their platforms by 2020. > > http://www.uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf > > > I believe they have stuck to this story at subsequent UEFI plugfests. Anyway: CSM_ENABLE works again, thanks to you, so people can build it usefully again. I'd just like to keep it default-off up-stream. Thanks Laszlo