From: "Laszlo Ersek" <lersek@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>, Alexander Graf <graf@amazon.com>
Cc: devel@edk2.groups.io, Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH v3 4/4] OvmfPkg: don't assign PCI BARs above 4GiB when CSM enabled
Date: Fri, 28 Jun 2019 15:12:15 +0200 [thread overview]
Message-ID: <7811dd9d-1d86-8a2b-f36d-19c0ea3e455a@redhat.com> (raw)
In-Reply-To: <f4892bedfd4d3ee73c3c35e5a7150357633a7907.camel@infradead.org>
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
next prev parent reply other threads:[~2019-06-28 13:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-27 16:36 [PATCH v3 4/4] OvmfPkg: don't assign PCI BARs above 4GiB when CSM enabled graf
2019-06-27 18:43 ` Laszlo Ersek
2019-06-27 19:01 ` Laszlo Ersek
2019-06-27 19:16 ` David Woodhouse
2019-06-28 13:12 ` Laszlo Ersek [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-06-26 11:37 [PATCH v3 0/4] OvmfPkg: CSM boot fixes David Woodhouse
2019-06-26 11:37 ` [PATCH v3 4/4] OvmfPkg: don't assign PCI BARs above 4GiB when CSM enabled David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7811dd9d-1d86-8a2b-f36d-19c0ea3e455a@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox