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

["Michael D Kinney" <michael.d.kinney@intel.com>]

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?

Mike

> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Monday, May 11, 2020 2:12 PM
> To: Kinney, Michael D <michael.d.kinney@intel.com>; Ard
> Biesheuvel <ard.biesheuvel@arm.com>; Rebecca Cran
> <rebecca@bsdio.com>; edk2-devel-groups-io
> <devel@edk2.groups.io>
> Cc: 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 05/11/20 18:36, Kinney, Michael D wrote:
> > I agree that ArmVirtPkg contents should be added to
> OvmfPkg.
> 
> I guess "OvmfPkg/Secondary/Bhyve" would be a
> compromise.
> 
> (I would actually prefer "Staging" to "Secondary",
> according to the following definition:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvald
> s/linux.git/tree/drivers/staging/Kconfig
> 
> menuconfig STAGING
> 	bool "Staging drivers"
> 	---help---
> 	  This option allows you to select a number of
> drivers that are
> 	  not of the "normal" Linux kernel quality level.
> These drivers
> 	  are placed here in order to get a wider audience
> to make use of
> 	  them.  Please note that these drivers are under
> heavy
> 	  development, may or may not work, and may contain
> userspace
> 	  interfaces that most likely will be changed in the
> near
> 	  future.
> 
> 	  Using any of these drivers will taint your kernel
> which might
> 	  affect support options from both the community,
> and various
> 	  commercial support organizations.
> 
> 	  If you wish to work on these drivers, to help
> improve them, or
> 	  to report problems you have with them, please see
> the
> 	  drivers/staging/<driver_name>/TODO file to see
> what needs to be
> 	  worked on, and who to contact.
> 
> 	  If in doubt, say N here.
> 
> However, edk2 already uses a separate "staging" repo in
> (nearly) the same sense, so I figure the "staging" term
> is already taken. Hence "Secondary", or even
> "SecondClass".)
> 
> Thanks
> Laszlo
> 
> >> -----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.
> >>
> >