Re: [edk2-devel] Where to put the bhyve code in the edk2 repo: BhyvePkg, or under OvmfPkg?

["Laszlo Ersek" <lersek@redhat.com>]

On 05/11/20 23:58, Rebecca Cran wrote:
> On May 11, 2020, at 3:22 PM, Michael D Kinney
> <michael.d.kinney@intel.com> wrote:
>>
>> Hi Laszlo,
>>
>> Is there an option for Bhyve to live in an edk2-platforms branch
>> or in edk2-staging branch until it meets the quality criteria for
>> OvmfPkg in the edk2 repo?

I'd like to have Bhyve in edk2 in order for it to share the git history
with the other edk2 modules (OvmfPkg, core, etc).

edk2-platforms being separate is already causing massive amounts of
pain. It's now common that we can't merge an otherwise self-contained
edk2 patch series, implemented, posted, and reviewed as a unit of work
with well defined boundaries, because it would break edk2-platforms, and
there is no way to cover two distinct repositories in a single patch
set.

There have been three separate instances of that concern just in the
last ~5 days:

- https://edk2.groups.io/g/devel/message/58872
  (May 8th)

- https://edk2.groups.io/g/devel/message/58874
  (May 8th)

- https://edk2.groups.io/g/devel/message/59204
  (May 11th)

> Also, what is the quality criteria? I'd be interested in working to
> improve any problems it currently has. I'm also planning to work on
> the Azure agent for FreeBSD and get a set of CI tests running for it.

Hm. Maybe I made a mistake. I segued from Ard's words to the Linux
"staging" definition; that may have been wrong. Ard's words were:

> However, I don't think every platforms in core EDK2 can be a first
> class citizen. There is simply no way we can expect contributors to
> make sure that their changes don't break under Bhyve, and the same
> will be true once (if) we merge kvmtool guest support, which is under
> development as well (given that it supports virtualization only, and
> so unlike QEMU, which supports emulation as well, it requires a native
> host)
>
> So I agree that it makes sense to incorporate Bhyve into core EDK2,
> but we have to decide on some rules regarding 'second class'
> platforms: how/when to test them, and how urgently we treat
> regressions found during such testing. We can treat ArmVirtXen the
> same way, imo, as well as KvmTool when it lands.

So maybe the question is how large the user base of a given
virtualization platform is, how wide-spread and easy-to-use the
virtualization platform is. How much time and presence can be dedicated
to maintaining its firmware.

If it's a niche virt platform, then keeping its firmware-side
counterparts regression-free is more difficult for the community (due to
the disproportionate amount of resources that its testing would
require), and so the quality of *that* firmware code is expected to be
lower.

Importantly, I do think "manpower dedicated" outweighs "platform is
niche". There was a time when UefiCpuPkg changes would break OVMF every
two weeks. We didn't solve that by making QEMU/KVM "less of a niche" for
the UefiCpuPkg owners -- we solved it by me asking (first informally) to
be CC'd on all UefiCpuPkg patches, and then formally to be marked as a
designated reviewer for UefiCpuPkg. And I'd review and regression-test a
whole bunch of UefiCpuPkg patches, just so I could catch regressions
before they made it into the tree.

If the bhyve community can *permanently* provide reviews /
regression-testing for such OVMF contributors that never use bhyve, that
would significantly increase the stability of bhyve firmware code, and
it would outweigh bhyve's user base (likely) being smaller. Xen
regressions were also reduced when the Xen community finally delegated
designated reviewers to edk2.

Reviewing and testing patches you don't really care for, but see as
possibly regressive for the platform you do care about, is a *lot* of
work. So I guess it could boil down to how much work your platform's
user base can contribute to the edk2 project.

Thanks
Laszlo