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

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

Andrew,

OvmfPkg README already has a broad definition.


=== OVMF OVERVIEW ===

The Open Virtual Machine Firmware (OVMF) project aims
to support firmware for Virtual Machines using the edk2
code base.  More information can be found at:


Mike

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On
> Behalf Of Andrew Fish via groups.io
> Sent: Monday, May 11, 2020 9:39 AM
> To: Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>; Laszlo
> Ersek <lersek@redhat.com>; Rebecca Cran
> <rebecca@bsdio.com>; edk2-devel-groups-io
> <devel@edk2.groups.io>; Leif Lindholm
> <leif@nuviainc.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>
> Subject: Re: [edk2-devel] Where to put the bhyve code
> in the edk2 repo: BhyvePkg, or under OvmfPkg?
> 
> 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.
> >>
> >
> 
> 
>