From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.81]) by mx.groups.io with SMTP id smtpd.web12.2020.1589231547704887464 for ; Mon, 11 May 2020 14:12:27 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Qkq6xwxh; spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589231546; 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=/bvlla5iJg3m9eL6WgM3jLhH6BwQsJvPkwpb2qVjH3c=; b=Qkq6xwxh6Mre7lvzi/snyTUmYoatLFah3Rf3DXHbgAvW62gefrrHzZMUi+XnzFjvbpi6ZR +VI9IBQTzd1Gs7PPx+UswAU6/bfgJpLyqcfW96VELCk6EdvUZ1mkuBzNtzYh3q9yRulSX3 GDdV99pSd55rlJsghH7mmIh+ePD1jUE= 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-499-GQNL2fL3MRWrrU_rGBqUGQ-1; Mon, 11 May 2020 17:12:17 -0400 X-MC-Unique: GQNL2fL3MRWrrU_rGBqUGQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9FADA8005AD; Mon, 11 May 2020 21:12:15 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-11.ams2.redhat.com [10.36.113.11]) by smtp.corp.redhat.com (Postfix) with ESMTP id D38655D9DC; Mon, 11 May 2020 21:12:13 +0000 (UTC) Subject: Re: Where to put the bhyve code in the edk2 repo: BhyvePkg, or under OvmfPkg? To: "Kinney, Michael D" , Ard Biesheuvel , Rebecca Cran , edk2-devel-groups-io Cc: Andrew Fish , Leif Lindholm , "Justen, Jordan L" References: <30320333-7ea6-084c-4b6c-569bc2a8b1aa@arm.com> From: "Laszlo Ersek" Message-ID: <29ea808a-f3de-ba07-1f8c-73b6b610cf67@redhat.com> Date: Mon, 11 May 2020 23:12:12 +0200 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.14 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 05/11/20 18:36, Kinney, Michael D wrote: > I agree that ArmVirtPkg contents should be added to OvmfPkg. I guess "OvmfPkg/Secondary/Bhyve" would be a compromise. (I would actually prefer "Staging" to "Secondary", according to the following definition: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/Kconfig menuconfig STAGING bool "Staging drivers" ---help--- This option allows you to select a number of drivers that are not of the "normal" Linux kernel quality level. These drivers are placed here in order to get a wider audience to make use of them. Please note that these drivers are under heavy development, may or may not work, and may contain userspace interfaces that most likely will be changed in the near future. Using any of these drivers will taint your kernel which might affect support options from both the community, and various commercial support organizations. If you wish to work on these drivers, to help improve them, or to report problems you have with them, please see the drivers/staging//TODO file to see what needs to be worked on, and who to contact. If in doubt, say N here. However, edk2 already uses a separate "staging" repo in (nearly) the same sense, so I figure the "staging" term is already taken. Hence "Secondary", or even "SecondClass".) Thanks Laszlo >> -----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? >> >> 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. >> >