From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [63.128.21.74]) by mx.groups.io with SMTP id smtpd.web10.1687.1585094724211387416 for ; Tue, 24 Mar 2020 17:05:24 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gndrd8xo; spf=pass (domain: redhat.com, ip: 63.128.21.74, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585094723; 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=4U23h7fOny4FT32ZOqT3D+TzyX+Rojjd2lvpufezy9E=; b=gndrd8xoTr//ZiwbTyN6G1m98Mj5dmfGUDr9K5R0UT2xy9B1F/4ShiM+bUEyQUkkPZKJ2e hdOUI0qz6MgYhtW68nB7xRkSNmMNduFa3bG8TAXl1zbswgZy3h8fz+vLSZzQGlstermZti xM25qMiZ9GP9yXo9zlzfyhMgspeRtJU= 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-248-43zw2es3NvCVrHyxwoP3wg-1; Tue, 24 Mar 2020 20:05:03 -0400 X-MC-Unique: 43zw2es3NvCVrHyxwoP3wg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E0125800D48; Wed, 25 Mar 2020 00:05:01 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-139.ams2.redhat.com [10.36.115.139]) by smtp.corp.redhat.com (Postfix) with ESMTP id 89BE85C1B2; Wed, 25 Mar 2020 00:05:00 +0000 (UTC) Subject: Re: [edk2-devel] Adding Bhyve support into upstream EDK2 To: Rebecca Cran , devel@edk2.groups.io, jiewen.yao@intel.com, "Justen, Jordan L" , Ard Biesheuvel References: <74D8A39837DF1E4DA445A8C0B3885C503F972D18@shsmsx102.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: Date: Wed, 25 Mar 2020 01:04:59 +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: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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 03/24/20 02:34, Rebecca Cran wrote: > On 3/6/20 6:29 PM, Yao, Jiewen wrote: >> Can you post the patch? :-) > > Thanks, It's just about ready for review I think. There's perhaps a bit > more deduplication between BhyvePkg and OvmfPkg to be done. > > Since the patch is 1.7MB, I've uploaded it to > https://bex.dev/bhyve-edk2-stable202002.diff . Umm... :) This is way too large, I think. Just because I indeed recommend creating a separate BhyvePkg, it's really not advisable to create a complete copy of OvmfPkg, as first step. I assume most modules can be reused from under OvmfPkg; can't they? Consider for example ArmVirtPkg. The ArmVirtQemu DSC and FDF files refer to a bunch of content that resides under OvmfPkg. That's what BhyvePkg should do too: - introduce its own DEC, DSC and FDF files, - reuse everything possible verbatim from under OvmfPkg, - if changes are necessary: - tweak existent OvmfPkg PCDs in the BhyvePkg DSC file, - introduce new library instances for library classes, and link those into OvmfPkg modules (and any other edk2 modules) via the BhyvePkg DSC file, - in the worst case, copy a *small* subset of OvmfPkg modules, and tweak the source under BhyvePkg. - add totally BHYVE specific modules (drivers) under BhyvePkg. Basically any given platform (DSC / FDF) is supposed to cherry-pick whatever it can reuse from edk2 -- that's why edk2 is a "kit". And virtual platforms are most welcome to depend on (consume modules from) OvmfPkg. Again, it's impossible to tell in advance, but in some cases, the tweaks might be minimal enough to upstream them into OvmfPkg (conditionally on a PCD, or conditionally on some small / easy runtime detection of BHYVE). Then BhyvePkg only has to activate said PCD (or just rely on the runtme detection). Again, there's no general rule; it depends on how much the bhyve specifics would complicate the OvmfPkg code. Thanks, Laszlo