From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web11.118.1589214043652906463 for ; Mon, 11 May 2020 09:20:43 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: ard.biesheuvel@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6C6EF30E; Mon, 11 May 2020 09:20:42 -0700 (PDT) Received: from [192.168.1.81] (unknown [10.37.8.255]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9BF173F305; Mon, 11 May 2020 09:20:40 -0700 (PDT) Subject: Re: Where to put the bhyve code in the edk2 repo: BhyvePkg, or under OvmfPkg? To: Laszlo Ersek , Rebecca Cran , edk2-devel-groups-io Cc: "Kinney, Michael D" , Andrew Fish , Leif Lindholm , "Jordan Justen (Intel address)" References: From: "Ard Biesheuvel" Message-ID: <30320333-7ea6-084c-4b6c-569bc2a8b1aa@arm.com> Date: Mon, 11 May 2020 18:20:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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.