From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web10.1343.1583524486000422725 for ; Fri, 06 Mar 2020 11:54:46 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SzN5dpOh; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583524485; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=03CUzmQuEwNHMoaXHC+LJ3jdlYeoHqrAnGNwOX25TPk=; b=SzN5dpOhNDsgbxhmmtMY2ZKxyKMPXVr8ZFwYNQ+r3+R7lbnV+Q9dBChLfwB0qwmOuAT2/h Ejrpivq2AMtR8jWfioMDU4oKBHRajHp60bjB2ukUW1aiLrxlhKOE0bJQT+LvG4YnEGO8Y2 VMFXYzl//K1seaWHwsIhTT/ebnLFo7k= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-410-vbdt9WBcOpSeMbwXVY1ScA-1; Fri, 06 Mar 2020 14:54:39 -0500 X-MC-Unique: vbdt9WBcOpSeMbwXVY1ScA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8D25618C8C01; Fri, 6 Mar 2020 19:54:37 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-130.ams2.redhat.com [10.36.117.130]) by smtp.corp.redhat.com (Postfix) with ESMTP id 193288AC39; Fri, 6 Mar 2020 19:54:35 +0000 (UTC) Subject: Re: Adding Bhyve support into upstream EDK2 To: Rebecca Cran References: From: "Laszlo Ersek" Cc: devel@edk2.groups.io, Jordan Justen , Ard Biesheuvel , Anthony Perard Message-ID: Date: Fri, 6 Mar 2020 20:54:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/06/20 17:09, Rebecca Cran wrote: > 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. It depends: - on the amount of patches you have, - on the complexity the patches introduce. For example, ArmVirtPkg platforms use a large number (large proportion) of OvmfPkg modules. I still very much like ArmVirtPkg to stay a separate package. For another example, IA32/X64 Xen support is presently "mixed into" OvmfPkg code that otherwise targets QEMU. This mixture can be witnessed at two levels: - Xen-specific modules pulled into OvmfPkg{Ia32,Ia32X64,X64}.{dsc,fdf}, - dynamically enabled/disabled Xen-guest code that's part of the same source files (or same modules) that otherwise target QEMU. There is no general recipe for keeping things shared by default, and coding up the exceptions one by one, versus keeping things duplicated by default, and extracting the common parts one by one. Again, it depends on code size and complexity. As I mentioned, I strongly prefer ArmVirtPkg to stay separate from OvmfPkg. Leif disagreed with that, IIRC. I don't remember how Ard feels about it. Regarding Xen, I seem to recall that both Ard and myself prefer to keep Xen as a separate *platform* (DSC, FDF) in both ArmVirtPkg and OvmfPkg. ArmVirtPkg has always been like that (Ard did the Xen enablement that way, up-front -- see commit 22455087dc37). In OvmfPkg, we had started from the opposite direction, and it's quite recent that Anthony has proposed to isolate Xen support to a dedicated platform -- see . (Which is a very welcome proposal, as far as I'm concerned.) So... if you have a small number of trivial patches (or at least well-separable drivers, libraries etc) for supporting bhyve, those could be added to OvmfPkg, perhaps. If you needed to hook a bunch of complex / deep "if"s into existent code, then I would very much *NOT* like that, on the other hand. Because the latter kind of code: - makes human reasoning difficult, - is virtually a recipe for regressions. Regressions because: imagine there is a patch (motivated by a QEMU feature) that rearranges some code that's also used, in a *slightly* customized manner, on bhyve. If we mess up the code for bhyve, we don't notice, because we don't *test* on bhyve. So in such cases, code duplication / separation is actually beneficial, because it prevents users / developers of platform X from regressing platform Y. As you see such separation is mostly driven by what contributors run on, and test on. Quick request: please do not ask me to look at the current bhyve patches, off-list. Feel free to post them as an RFC series, instead. Another reason I'd likely prefer bhyve to be reasonably separate is maintenance responsibility. We have a pathname pattern based Maintainers.txt now -- I would want to be able to assign BZs, and patch reviews, immediately to you, for anything bhyve-related. (I mean... it's not like I am some special "arbitrator" or whatever; instead, the Maintainers.txt patterns should tell *anyone* asking, that you would be responsible for bhyve patch review.) In that sense, BhyvePkg would surely be my preference. I don't use bhyve, so I want none of that responsibility, and also no increased chance of regressions (in either direction: I don't want bhyve patches to break OVMF on QEMU, and I don't want to break bhyve support with QEMU-oriented patches). FWIW, I do agree that bhyve support would be nice to have up-stream, and specifically in "edk2", not "edk2-platforms". Virtual platforms are very useful for testing core code updates, and therefore they get a pass into "edk2". (I specifically remember an on-list discussion about the edk2 vs. edk2-platforms split, and virtual platforms and emulators were *generally* permitted in edk2.) Thanks Laszlo