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.web11.10158.1583566789224781924 for ; Fri, 06 Mar 2020 23:39:49 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=N8lUa+DV; 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=1583566788; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ep2efM0liZmR255eYSjuQn/ptWEZDvLP+qwn9GhUlv0=; b=N8lUa+DVBMZ4bnvaa70WAlxnZwOW146RVGy2w12x/9JGkCiETSiy7GA8wVVjj4fe8OUAhY PJvskjvGVFR06201Ce1Z5yFlWYatqMxIpc7kkZANU0W26ws9QvOy373nKlb0ICJ1XTyPCq 3tpKT9zTOSr3NeT2La00hqXWpYTjWlQ= 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-269-VSqXLXjYMXKr9ZOIRv6JkA-1; Sat, 07 Mar 2020 02:39:41 -0500 X-MC-Unique: VSqXLXjYMXKr9ZOIRv6JkA-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 CCBB013EA; Sat, 7 Mar 2020 07:39:39 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-30.ams2.redhat.com [10.36.116.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5EA975D9CD; Sat, 7 Mar 2020 07:39:38 +0000 (UTC) Subject: Re: [edk2-devel] Adding Bhyve support into upstream EDK2 To: "Yao, Jiewen" , "devel@edk2.groups.io" , "rebecca@bsdio.com" , "Justen, Jordan L" , Ard Biesheuvel References: <15F9E16A0219E7B7.19404@groups.io> <74D8A39837DF1E4DA445A8C0B3885C503F972D92@shsmsx102.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: Date: Sat, 7 Mar 2020 08:39:37 +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: <74D8A39837DF1E4DA445A8C0B3885C503F972D92@shsmsx102.ccr.corp.intel.com> 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 Hi Jiewen, On 03/07/20 02:43, Yao, Jiewen wrote: > Just saw Laszlo's email. Similar feedback. Especially, I like the regression test part. Thanks. > I am not sure how many virtual platforms we will have eventually. > If there are more and more, maybe we can create a new edk2-virt-platform repo, and put them together there. (Similar to edk2-platform repo for the physical platform) Regarding the last part ("move them together here") -- I'm 100% opposed to removing OvmfPkg and ArmVirtPkg from edk2. They *must* remain in the exact same git repository where the core (MdePkg, MdeModulePkg, CryptoPkg, SecurityPkg, UefiCpuPkg, ...) lives too, and share a common git history. ArmVirtPkg and OvmfPkg move very closely together with the core, most significant ArmVirtPkg and OvmfPkg contributions need changes (and therefore introduce new dependencies) on the core. Managing such dependencies is a nightmare evein with git submodules; it only works if the git history is shared. This problem is not theoretical, it already has a bad effect on edk2-platforms. For a recent example, my latest OvmfPkg patch series: https://bugzilla.tianocore.org/show_bug.cgi?id=1512#c18 merged as commit range 61d3b2d4279e..1158fc8e2c7b, started by improving the logging in MdeModulePkg/PiSmmCore (a1ddad95933e), and fixing a bug in UefiCpuPkg/PiSmmCpuDxeSmm (90e11edd16c7). I don't necessarily mind if *new* virtual platforms are outside of the edk2 tree, but if I'm completely honest about "why", it's because I don't use those new platforms. And that's a *selfish* reason -- if I want ArmVirtPkg and OvmfPkg to benefit from sharing and interleaving their histories with the core, then other virtual platforms deserve the same, even if I don't use them. (In fact, I think that even edk2-platforms should never have been split out of edk2 -- but that ship has sailed. I believe I argued against separating edk2-platforms, but my reasons weren't strong or convincing enough.) Thanks, Laszlo >> -----Original Message----- >> From: devel@edk2.groups.io On Behalf Of Yao, Jiewen >> Sent: Saturday, March 7, 2020 9:30 AM >> To: devel@edk2.groups.io; rebecca@bsdio.com; Laszlo Ersek >> ; Justen, Jordan L ; Ard >> Biesheuvel >> Subject: Re: [edk2-devel] Adding Bhyve support into upstream EDK2 >> >> I can share some of my experience, for your information only. >> >> 0) If the patch is generic, not specific to Bhyve, but benefit to current EDKII pkg, >> you can submit them directly. No need to wait for Bhyve. >> >> 1) If the patch is very simple, you can merge into current PKG with current DSC. >> If there is something special to the Bhyve that can be detected at runtime, then >> detect at runtime. >> If there is something special to the Byhve that need to be determine at build >> time, then you can introduce a PCD (such as PcdBhyveXXX) and configurate at >> build time. >> >> 2) If the patch is big, you can introduce a standalone driver and put to current >> PKG and introduce a new DSC file (such as OvmfBhyve.dsc). You can control and >> build Byhve with the new DSC file. >> >> 3) If the patch is extremely big and has architecture difference, you can >> introduce a new pkg (BhyvePkg) and put all new drivers there. You can still refer >> to some drivers in OvmfPkg, which introduce a dependency (BhyvePkg => >> OvmfPkg). The OvmfPkg change may impact BhyvePkg build or running. >> >> X) Last but not least important, if the Bhyve has a different *security >> requirement* or *threat model* with current Pkg, then you had better introduce >> a new pkg or update the current Pkg with same threat model. Before that, you >> had better not use any driver in other package and keep them separate. It is easy >> for future audit purpose. >> >> Above is the generic rule. I think OvmfPkg maintainer can provide more >> comment on that. >> >> Can you post the patch? :-) >> >> Thank you >> Yao Jiewen >> >>> -----Original Message----- >>> From: devel@edk2.groups.io On Behalf Of Rebecca >>> Cran >>> Sent: Saturday, March 7, 2020 12:10 AM >>> To: devel@edk2.groups.io; Laszlo Ersek ; Justen, Jordan >> L >>> ; Ard Biesheuvel >>> Subject: [edk2-devel] Adding Bhyve support into upstream EDK2 >>> >>> 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. >>> >>> >>> -- >>> Rebecca Cran >>> >>> >>> >>> >> >> >> >