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

["Andrew Fish" <afish@apple.com>]

Crazy question. Should we add a VirtualizationPkg and move everything under that? I'm not sure the disruption to OVMF is worth, but figured I'd ask.

Thanks,

Andrew Fish

> On May 11, 2020, at 9:36 AM, Kinney, Michael D <michael.d.kinney@intel.com> wrote:
> 
> I agree that ArmVirtPkg contents should be added to OvmfPkg.
> 
> Mike
> 
>> -----Original Message-----
>> From: Ard Biesheuvel <ard.biesheuvel@arm.com>
>> Sent: Monday, May 11, 2020 9:21 AM
>> To: Laszlo Ersek <lersek@redhat.com>; Rebecca Cran
>> <rebecca@bsdio.com>; edk2-devel-groups-io
>> <devel@edk2.groups.io>
>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>;
>> Andrew Fish <afish@apple.com>; Leif Lindholm
>> <leif@nuviainc.com>; Justen, Jordan L
>> <jordan.l.justen@intel.com>
>> Subject: Re: Where to put the bhyve code in the edk2
>> repo: BhyvePkg, or under OvmfPkg?
>> 
>> On 5/11/20 5:55 PM, Laszlo Ersek wrote:
>>> (CC'ing Ard and Jordan.)
>>> 
>>> On 05/08/20 17:44, Rebecca Cran wrote:
>>>> During the Community Meeting last night, I was asked
>> to send this email
>>>> starting a discussion about where to put the bhyve
>> code in the edk2
>>>> tree: whether it should be in a new BhyvePkg, or
>> added under OvmfPkg.
>>> 
>>> I prefer a top-level BhyvePkg.
>>> 
>>> If most edk2 consumers wouldn't like to see a top-
>> level BhyvePkg
>>> directory, I can certainly live with OvmfPkg/Bhyve.
>>> 
>>> I can also live with OvmfPkg/Bhyve*,
>> OvmfPkg/Library/Bhyve*, etc, modules.
>>> 
>>> So I guess these would be my choices in decreasing
>> order of preference.
>>> (To be clear, I consider my option#3 still a lot
>> better than not having
>>> bhyve support in upstream edk2 at all.)
>>> 
>>> In either case, "Maintainers.txt" should get a new
>> section listing the
>>> bhyve-specific modules as being under your and Peter
>> Grehan's
>>> reviewership ("R").
>>> 
>>>> It
>>>> appears it's already been decided it should be in
>> edk2 along with the
>>>> other virtual platforms and not edk2-platforms,
>> where code for physical
>>>> platforms will reside.
>>> 
>>> I haven't been aware that this is a done deal, but if
>> it is, it makes me
>>> glad! I've always wanted bhyve stuff to be in edk2
>> and not in
>>> edk2-platforms.
>>> 
>> 
>> I think it is a good thing to have support for virtual
>> platforms in core
>> EDK2, given that such a platform is only a download
>> away for anyone who
>> wants to try it. I am strongly opposed to the idea that
>> core EDK2 should
>> just be a repository of bits and pieces that platforms
>> can incorporate,
>> especially because it can make regressions unsolveable
>> once we get
>> ourselves into a state where reverting some patch fixes
>> a problem on one
>> platform and creates one on another.
>> 
>> 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.
>> 
>> Whether we create a BhyvePkg depends on our future
>> intent wrt merging
>> OVMF with other virtual platforms. I think it would
>> make sense for the
>> ArmVirtPkg and OvmfPkg to be merged at some point, at
>> which time it will
>> probably make little sense to have a separate BhyvePkg.
>> But I'm not sure
>> what Laszlo's take is on this.
>> 
>> In summary, I can live with any of these options, as
>> long as the
>> underlying rules and assumptions are clarified.
>> 
>