From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) by mx.groups.io with SMTP id smtpd.web12.528.1589215146774753065 for ; Mon, 11 May 2020 09:39:07 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=YyCidDda; spf=pass (domain: apple.com, ip: 17.151.62.66, mailfrom: afish@apple.com) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 04BGXFrA035649; Mon, 11 May 2020 09:38:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=1MhqZwSx1zP3r8XkGhWyD+VFR/mn4JeqyKz0Sa3MTVU=; b=YyCidDda7Z1i4AsQfxiIjX/PRQitioUvLsVDexG09AwJPUza4PEpgMEjvBVjJfymDDs2 mJOdIY+hHAbCUqThbpDqUWkomthkRDh2vYypMrwDO81PZX4zFp3/BCVGPTpdYue8AoFq 8YIdrW84QBN0D6Sv/uET+6OSpA0yvv5S0NH21Q88zZSzXh3+C3mUGiMaeuW4O0e9YPiv fNj6YYIJKNZZN2RB0hn6zPl5YwnBTiCxkNNO0YDOw9KJXvovU2XW3U9G0gs6SDc2abMz 8GW3YUZ2fM3u1edarGYWPavUHYQAAtLk9KExK2fxR5J7zMfmcXV/su8/jR4xASlXQfG9 UQ== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by nwk-aaemail-lapp01.apple.com with ESMTP id 30wuexthx7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 11 May 2020 09:38:45 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QA600ZJAE8L3Y10@rn-mailsvcp-mta-lapp03.rno.apple.com>; Mon, 11 May 2020 09:38:45 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QA600Q00DVBW400@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Mon, 11 May 2020 09:38:45 -0700 (PDT) X-Va-A: X-Va-T-CD: d83e0f5ae76e2c6a77545e7e22b49ca9 X-Va-E-CD: 5de36a1bd7d22c5b3313d066ca75aa53 X-Va-R-CD: ed759bc094dc03099cbcb995db3c0aac X-Va-CD: 0 X-Va-ID: 1dc8391a-02b1-41cb-bda1-b13f0d2da0c2 X-V-A: X-V-T-CD: d83e0f5ae76e2c6a77545e7e22b49ca9 X-V-E-CD: 5de36a1bd7d22c5b3313d066ca75aa53 X-V-R-CD: ed759bc094dc03099cbcb995db3c0aac X-V-CD: 0 X-V-ID: 60f56015-0aa6-408a-bba0-e9ed957cc15a X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.676 definitions=2020-05-11_08:2020-05-11,2020-05-11 signatures=0 Received: from [17.235.21.247] (unknown [17.235.21.247]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QA60035LE8KM500@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Mon, 11 May 2020 09:38:45 -0700 (PDT) MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Subject: Re: Where to put the bhyve code in the edk2 repo: BhyvePkg, or under OvmfPkg? From: "Andrew Fish" In-reply-to: Date: Mon, 11 May 2020 09:38:44 -0700 Cc: Ard Biesheuvel , Laszlo Ersek , Rebecca Cran , edk2-devel-groups-io , Leif Lindholm , Jordan Justen Message-id: <3FAF5FCD-9755-42A6-A736-C110E6813718@apple.com> References: <30320333-7ea6-084c-4b6c-569bc2a8b1aa@arm.com> To: Mike Kinney X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.676 definitions=2020-05-11_08:2020-05-11,2020-05-11 signatures=0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable 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 = wrote: >=20 > I agree that ArmVirtPkg contents should be added to OvmfPkg. >=20 > Mike >=20 >> -----Original Message----- >> From: Ard Biesheuvel >> Sent: Monday, May 11, 2020 9:21 AM >> To: Laszlo Ersek ; Rebecca Cran >> ; edk2-devel-groups-io >> >> Cc: Kinney, Michael D ; >> Andrew Fish ; Leif Lindholm >> ; Justen, Jordan L >> >> Subject: Re: Where to put the bhyve code in the edk2 >> repo: BhyvePkg, or under OvmfPkg? >>=20 >> On 5/11/20 5:55 PM, Laszlo Ersek wrote: >>> (CC'ing Ard and Jordan.) >>>=20 >>> 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. >>>=20 >>> I prefer a top-level BhyvePkg. >>>=20 >>> If most edk2 consumers wouldn't like to see a top- >> level BhyvePkg >>> directory, I can certainly live with OvmfPkg/Bhyve. >>>=20 >>> I can also live with OvmfPkg/Bhyve*, >> OvmfPkg/Library/Bhyve*, etc, modules. >>>=20 >>> 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.) >>>=20 >>> 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"). >>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>=20 >> 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. >>=20 >> 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) >>=20 >> 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. >>=20 >> 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. >>=20 >> In summary, I can live with any of these options, as >> long as the >> underlying rules and assumptions are clarified. >>=20 >=20