Re: [edk2-devel] Adding Bhyve support into upstream EDK2

["Yao, Jiewen" <jiewen.yao@intel.com>]

Just saw Laszlo's email. Similar feedback. Especially, I like the regression test part.

I am not sure how many virtual platforms we will have eventually.
If there are more and more, maybe we can create a new edk2-virt-platform repo, and put them together there. (Similar to edk2-platform repo for the physical platform)


> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Yao, Jiewen
> Sent: Saturday, March 7, 2020 9:30 AM
> To: devel@edk2.groups.io; rebecca@bsdio.com; Laszlo Ersek
> <lersek@redhat.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Ard
> Biesheuvel <ard.biesheuvel@linaro.org>
> Subject: Re: [edk2-devel] Adding Bhyve support into upstream EDK2
> 
> I can share some of my experience, for your information only.
> 
> 0) If the patch is generic, not specific to Bhyve, but benefit to current EDKII pkg,
> you can submit them directly. No need to wait for Bhyve.
> 
> 1) If the patch is very simple, you can merge into current PKG with current DSC.
> If there is something special to the Bhyve that can be detected at runtime, then
> detect at runtime.
> If there is something special to the Byhve that need to be determine at build
> time, then you can introduce a PCD (such as PcdBhyveXXX) and configurate at
> build time.
> 
> 2) If the patch is big, you can introduce a standalone driver and put to current
> PKG and introduce a new DSC file (such as OvmfBhyve.dsc). You can control and
> build Byhve with the new DSC file.
> 
> 3) If the patch is extremely big and has architecture difference, you can
> introduce a new pkg (BhyvePkg) and put all new drivers there. You can still refer
> to some drivers in OvmfPkg, which introduce a dependency (BhyvePkg =>
> OvmfPkg). The OvmfPkg change may impact BhyvePkg build or running.
> 
> X) Last but not least important, if the Bhyve has a different *security
> requirement* or *threat model* with current Pkg, then you had better introduce
> a new pkg or update the current Pkg with same threat model. Before that, you
> had better not use any driver in other package and keep them separate. It is easy
> for future audit purpose.
> 
> Above is the generic rule. I think OvmfPkg maintainer can provide more
> comment on that.
> 
> Can you post the patch? :-)
> 
> Thank you
> Yao Jiewen
> 
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca
> > Cran
> > Sent: Saturday, March 7, 2020 12:10 AM
> > To: devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>; Justen, Jordan
> L
> > <jordan.l.justen@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > Subject: [edk2-devel] Adding Bhyve support into upstream EDK2
> >
> > I'm currently working on updating EDK2 support for Bhyve
> > (https://bhyve.org/) from the edk2-stable201903 tag to
> > edk2-stable202002. It's currently kept in a separate repo
> > (https://github.com/freebsd/uefi-edk2), but I'd like to discuss pushing
> > support upstream into the main edk2 repo (I guess into edk2-staging as a
> > first step?).
> >
> >
> > Would that be something people would be open to considering, or should
> > it remain separate? Should it be a new top-level package (e.g. BhyvePkg)
> > or could it be just a configuration option when building OVMF? It's
> > currently maintained as a set of patches against OvmfPkg, which seems to
> > work quite well.
> >
> >
> > --
> > Rebecca Cran
> >
> >
> >
> >
> 
> 
>