From: "Laszlo Ersek" <lersek@redhat.com>
To: devel@edk2.groups.io, sean.brogan@microsoft.com,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
"Leif Lindholm (Linaro address)" <leif.lindholm@linaro.org>
Subject: Re: [edk2-devel] Adding Bhyve support into upstream EDK2
Date: Tue, 10 Mar 2020 00:17:39 +0100 [thread overview]
Message-ID: <620e6fb0-45ab-c8ed-8881-a907dc4cc030@redhat.com> (raw)
In-Reply-To: <11d7bea8-ee02-c6a0-e5e2-6a0abaa5e35f@redhat.com>
On 03/09/20 23:54, Laszlo Ersek wrote:
> On 03/09/20 07:08, Sean via Groups.Io wrote:
>> From someone who has developed and maintained platforms with edk2 for
>> the last decade +, I can tell you that having OVMF in edk2 hasn't kept
>> the tree free from regressions.
>
> Of course. Changes to core packages (even spec changes) are always
> motivated by platform goals. And regressions are unavoidable, as much as
> we try to prevent them (even *spec* regressions). I hope you're not
> claiming that OVMF has been a major source of regressions in the core
> packages.
>
> And, you have the advantage of *plausibly* claiming that OVMF-oriented
> changes have caused regressions in the core -- plausibly because those
> contributions, and the dependent OVMF changes, are upstream. Whereas I
> can't classify any other regressions as associated by Microsoft platform
> needs, simply because those platform needs have hardly ever been public.
> (One of my never-ending crusades has been "better commit messages",
> i.e., with use case spelled out.)
I think I misread your point.
IIUC, you weren't blaming OVMF for regressions, instead, you were
questioning the usefulness of OVMF in catching regressions in the core.
Putting aside your rhetorical expression "keep the tree free from
regressions" -- because how could any single platform keep the whole
tree free of regressions? --, OVMF *has* caught regressions. In fact,
running OVMF on QEMU/KVM has been one of the best ways for rooting out
multiprocessing / synchronization bugs in UefiCpuPkg, due to the VCPU
jitter that KVM tends to introduce. This is why I asked (years ago) to
be CC'd on all UefiCpuPkg patches, so I could regression-test them
before they are pushed. (Hence my "R:" role in UefiCpuPkg.)
$ git log \
--oneline \
--reverse \
--grep='Regression-tested-by: Laszlo Ersek <lersek@redhat.com>' \
master -- \
':!OvmfPkg' \
':!ArmVirtPkg' \
':!ArmPlatformPkg/ArmVirtualizationPkg' \
| wc -l
(83 patches)
This is also (part of) why I wrote:
https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt
Two semi-recent commits that fixed regressions (exposed by OVMF) have been:
- 4d05a4b709ce ("MdeModulePkg/BdsDxe: Fix calling
PlatformBootManagerWaitCallback on 0", 2019-10-15)
- a52355624440 ("UefiCpuPkg/PiSmmCpuDxeSmm: fix 2M->4K page splitting
regression for PDEs", 2020-01-17)
Thanks
Laszlo
next prev parent reply other threads:[~2020-03-09 23:17 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-06 16:09 Adding Bhyve support into upstream EDK2 Rebecca Cran
2020-03-06 19:54 ` Laszlo Ersek
2020-03-06 20:04 ` [edk2-devel] " Laszlo Ersek
2020-03-07 1:29 ` Yao, Jiewen
2020-03-24 1:34 ` Rebecca Cran
2020-03-25 0:04 ` Laszlo Ersek
2020-03-25 18:18 ` [EXTERNAL] " Bret Barkelew
2020-03-27 12:56 ` Laszlo Ersek
2020-03-25 18:50 ` Rebecca Cran
[not found] ` <15F9E16A0219E7B7.19404@groups.io>
2020-03-07 1:43 ` Yao, Jiewen
2020-03-07 7:39 ` Laszlo Ersek
2020-03-07 7:52 ` Ard Biesheuvel
2020-03-08 2:40 ` Rebecca Cran
2020-03-09 6:08 ` Sean
2020-03-09 22:54 ` Laszlo Ersek
2020-03-09 23:17 ` Laszlo Ersek [this message]
2020-03-10 1:50 ` Sean
2020-03-10 9:05 ` Laszlo Ersek
2020-03-10 17:25 ` Sean
2020-03-10 17:54 ` Ard Biesheuvel
2020-03-10 19:10 ` Sean
2020-03-10 19:23 ` Michael D Kinney
2020-03-10 19:44 ` Sean
2020-03-10 20:04 ` Rebecca Cran
2020-03-11 0:05 ` Laszlo Ersek
2020-03-11 0:30 ` Sean
2020-03-11 3:21 ` Liming Gao
2020-03-10 23:34 ` Laszlo Ersek
2020-03-11 0:43 ` Leif Lindholm
2020-03-07 7:53 ` Laszlo Ersek
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=620e6fb0-45ab-c8ed-8881-a907dc4cc030@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