From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by mx.groups.io with SMTP id smtpd.web11.1497.1583525067096300060 for ; Fri, 06 Mar 2020 12:04:27 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Ug34Gne9; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583525066; h=from:from:reply-to: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=5Ui+d93UGZMElE8JGKsCtt4JkwoPCvj/bLVsMcQzycg=; b=Ug34Gne9sO9asmk4AGSdTQKR+V/dvXy0fBLF+UowCeBqvaIoeri5QYL3rvbEkbf4TAMmVm R15YhYNDkAWHLi+NBBxHanHbZtP3Hpeg4FAUykSzpjP+5dP8SLLm70erjCkumQ31ttRycC 9EfIyTm6OD8VEQtiyLe4iGfcBGeCXWc= 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-471-cAHFJ-76O4O98Phr8L7Z1w-1; Fri, 06 Mar 2020 15:04:21 -0500 X-MC-Unique: cAHFJ-76O4O98Phr8L7Z1w-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 32C5E13F8; Fri, 6 Mar 2020 20:04:20 +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 BA65153793; Fri, 6 Mar 2020 20:04:17 +0000 (UTC) Subject: Re: [edk2-devel] Adding Bhyve support into upstream EDK2 From: "Laszlo Ersek" To: Rebecca Cran Cc: devel@edk2.groups.io, Jordan Justen , Ard Biesheuvel , Anthony Perard Reply-To: devel@edk2.groups.io, lersek@redhat.com References: Message-ID: <60e18c4a-aa74-3a48-ce1d-cbd22dd92005@redhat.com> Date: Fri, 6 Mar 2020 21:04:16 +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.15 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 20:54, Laszlo Ersek wrote: > 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.) A further question is code size -- if we were to introduce bhyve support as additional drivers, I would want to permit downstreams to easily disable those, without downstream patches for the DSC/FDF files, i.e., with a simple -D flag. Thanks Laszlo