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.web12.2488.1589275710745187588 for ; Tue, 12 May 2020 02:28:31 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SL2BwWyE; 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=1589275709; 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=m/fgGYnLcbj1SZBHgwqPdgTeymGGIEc6GLYQGYBhUCQ=; b=SL2BwWyEreDk+PhSJgm8S9+H5h8fkLL65aHyPWnrz+mRj0kQ6Nl1s/JlnbQHi/fMkI573X BQi76nvcEfKxa/Bwv3EaDSwZO+JKkfE2fU7hDqQcN3m+9HXMlC3aYeM1LhrLS2Y8JqBjel BPjVIhaKqS2rW/7crnxG9OiPsu4lPpo= 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-291-VfGkB6hKOLGAJSvIxvlrGA-1; Tue, 12 May 2020 05:28:23 -0400 X-MC-Unique: VfGkB6hKOLGAJSvIxvlrGA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EA3B819067E3; Tue, 12 May 2020 09:28:21 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-120.ams2.redhat.com [10.36.114.120]) by smtp.corp.redhat.com (Postfix) with ESMTP id EFA9810001B3; Tue, 12 May 2020 09:28:19 +0000 (UTC) Subject: Re: [edk2-devel] Where to put the bhyve code in the edk2 repo: BhyvePkg, or under OvmfPkg? To: Rebecca Cran , devel@edk2.groups.io, michael.d.kinney@intel.com Cc: Ard Biesheuvel , Andrew Fish , Leif Lindholm , "Justen, Jordan L" References: <20CE2FEE-3844-422E-8DB2-2784C9B56CE9@bsdio.com> From: "Laszlo Ersek" Message-ID: <2de7aa2e-a024-3c2b-14c0-161e68c31121@redhat.com> Date: Tue, 12 May 2020 11:28:19 +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: <20CE2FEE-3844-422E-8DB2-2784C9B56CE9@bsdio.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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 23:58, Rebecca Cran wrote: > On May 11, 2020, at 3:22 PM, Michael D Kinney > wrote: >> >> Hi Laszlo, >> >> Is there an option for Bhyve to live in an edk2-platforms branch >> or in edk2-staging branch until it meets the quality criteria for >> OvmfPkg in the edk2 repo? I'd like to have Bhyve in edk2 in order for it to share the git history with the other edk2 modules (OvmfPkg, core, etc). edk2-platforms being separate is already causing massive amounts of pain. It's now common that we can't merge an otherwise self-contained edk2 patch series, implemented, posted, and reviewed as a unit of work with well defined boundaries, because it would break edk2-platforms, and there is no way to cover two distinct repositories in a single patch set. There have been three separate instances of that concern just in the last ~5 days: - https://edk2.groups.io/g/devel/message/58872 (May 8th) - https://edk2.groups.io/g/devel/message/58874 (May 8th) - https://edk2.groups.io/g/devel/message/59204 (May 11th) > Also, what is the quality criteria? I'd be interested in working to > improve any problems it currently has. I'm also planning to work on > the Azure agent for FreeBSD and get a set of CI tests running for it. Hm. Maybe I made a mistake. I segued from Ard's words to the Linux "staging" definition; that may have been wrong. Ard's words were: > 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. So maybe the question is how large the user base of a given virtualization platform is, how wide-spread and easy-to-use the virtualization platform is. How much time and presence can be dedicated to maintaining its firmware. If it's a niche virt platform, then keeping its firmware-side counterparts regression-free is more difficult for the community (due to the disproportionate amount of resources that its testing would require), and so the quality of *that* firmware code is expected to be lower. Importantly, I do think "manpower dedicated" outweighs "platform is niche". There was a time when UefiCpuPkg changes would break OVMF every two weeks. We didn't solve that by making QEMU/KVM "less of a niche" for the UefiCpuPkg owners -- we solved it by me asking (first informally) to be CC'd on all UefiCpuPkg patches, and then formally to be marked as a designated reviewer for UefiCpuPkg. And I'd review and regression-test a whole bunch of UefiCpuPkg patches, just so I could catch regressions before they made it into the tree. If the bhyve community can *permanently* provide reviews / regression-testing for such OVMF contributors that never use bhyve, that would significantly increase the stability of bhyve firmware code, and it would outweigh bhyve's user base (likely) being smaller. Xen regressions were also reduced when the Xen community finally delegated designated reviewers to edk2. Reviewing and testing patches you don't really care for, but see as possibly regressive for the platform you do care about, is a *lot* of work. So I guess it could boil down to how much work your platform's user base can contribute to the edk2 project. Thanks Laszlo