From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.120, mailfrom: jordan.l.justen@intel.com) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by groups.io with SMTP; Wed, 10 Apr 2019 11:37:11 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2019 11:37:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,334,1549958400"; d="scan'208";a="222309304" Received: from askirtik-mobl1.amr.corp.intel.com (HELO localhost) ([10.254.188.249]) by orsmga001.jf.intel.com with ESMTP; 10 Apr 2019 11:37:10 -0700 MIME-Version: 1.0 In-Reply-To: References: <20190409110844.14746-1-anthony.perard@citrix.com> <20190409110844.14746-3-anthony.perard@citrix.com> <155488970861.20447.12525571872411959890@jljusten-skl> To: Anthony PERARD , Laszlo Ersek , devel@edk2.groups.io From: "Jordan Justen" Cc: Ard Biesheuvel , Julien Grall , xen-devel@lists.xenproject.org Subject: Re: [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf Message-ID: <155492143006.23894.8253130602441997952@jljusten-skl> User-Agent: alot/0.8 Date: Wed, 10 Apr 2019 11:37:10 -0700 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2019-04-10 07:27:15, Laszlo Ersek wrote: > On 04/10/19 11:48, Jordan Justen wrote: > > On 2019-04-09 04:08:15, Anthony PERARD wrote: > >> This is a copy of OvmfX64, removing VirtIO and some SMM. > >> > >> This new platform will be changed to make it works on two types of Xen > >> guest: HVM and PVH. > >> > >> Compare to OvmfX64, this patch: > >> > >> - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION > >> - removed: VirtioLib class resolution > >> - removed: all UEFI_DRIVER modules for virtio devices > >> - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions > >> - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules > >> - removed: Everything related to SMM_REQUIRE=3D=3Dtrue > >> - removed: Everything related to SECURE_BOOT_ENABLE=3D=3Dtrue > >> - removed: Everything related to TPM2_ENABLE=3D=3Dtrue > >> - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE > >> - changed: default FD_SIZE_IN_KB to 2M. > >> > >> Contributed-under: TianoCore Contribution Agreement 1.1 > >> Signed-off-by: Anthony PERARD > >> --- > >> OvmfPkg/{OvmfPkgX64.dsc =3D> XenOvmf.dsc} | 202 +----------------= --- > >=20 > > I guess we all want our name to be first :), but OvmfXen seems more > > like the pattern that edk2 uses when making sub-platforms. For example: ArmVirtPkg/ArmVirtXen.dsc > >=20 > > Also, in some cases we've used !ifdef type things to keep dsc and fdf > > files common. Would that not be workable here? Maybe it would get too > > ugly. :\ >=20 > I've been happy with a similar Xen<->QEMU split under ArmVirtPkg. > Duplications in updates are usually not a huge burden, and keeping the > files separate has proved very helpful for determining > maintainer/reviewer/tester responsibility. >=20 > > It could help to prevent having to sync dsc changes across, and > > prevent changes from being omitted for Xen on accident. >=20 > True, but in my experience that's been the smaller problem. The larger > problem has been modifying Xen stuff in unintended ways (=3D regressing > Xen), because we can't test (or don't even notice) the Xen-side > implications of changes made to common source. Does that mean you avoid changing ArmVirtXen.dsc entirely, or you try to update it when it seems likely to not cause trouble? I could see unintended breakage either way. Anyway, it sounds like it's generally working out okay with ArmVirtXen, so it seems okay to follow that under OvmfPkg. -Jordan