From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web11.17301.1672936125184775816 for ; Thu, 05 Jan 2023 08:28:45 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Ts3ChOpB; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1672936124; 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=6+Shc2cxaPOUU9bdp2V5RmtRx1BezOv5bEilhNhyHEw=; b=Ts3ChOpBw/Rx9/kS/DLnAMbQ4ZSTe5xh9dsiCwMC2Cgf2oGYDCiUy/h00zJek8zlzQps94 pe6tidB4UrMyvrK5zGwsZztsIsDYLiEJ+rzYeW8MycfvY7FIGBJF5j22ieydAuyGMycQL+ HG+iXFgaqrc9n67HAVUPeaSZ7jYnW38= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-347-cNONyKMaNiKt_ZTyvB1H2A-1; Thu, 05 Jan 2023 11:28:41 -0500 X-MC-Unique: cNONyKMaNiKt_ZTyvB1H2A-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E9780106D1B9; Thu, 5 Jan 2023 16:28:22 +0000 (UTC) Received: from [10.39.192.44] (unknown [10.39.192.44]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7095A2026D68; Thu, 5 Jan 2023 16:28:20 +0000 (UTC) Message-ID: <136b74e1-7966-0748-6bcc-c49c80a25082@redhat.com> Date: Thu, 5 Jan 2023 17:28:19 +0100 MIME-Version: 1.0 Subject: Re: [PATCH V1 1/1] OvmfPkg/IntelTdxX64: Raise DXEFV size to 13MB To: Gerd Hoffmann , Min Xu Cc: devel@edk2.groups.io, Anthony Perard , Ard Biesheuvel , Brijesh Singh , Erdem Aktas , James Bottomley , Jiewen Yao , Jordan Justen , Julien Grall , Peter Grehan , Rebecca Cran , Sebastien Boeuf , Tom Lendacky References: <20230105072105.144-1-min.m.xu@intel.com> <20230105113158.lq5r5zxuyrgapqjy@sirius.home.kraxel.org> From: "Laszlo Ersek" In-Reply-To: <20230105113158.lq5r5zxuyrgapqjy@sirius.home.kraxel.org> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 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 1/5/23 12:31, Gerd Hoffmann wrote: > On Thu, Jan 05, 2023 at 03:21:05PM +0800, Min Xu wrote: >> From: Min M Xu >> >> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4236 >> >> Similarly to the "cadence" mentioned in commit d272449 ("OvmfPkg: >> raise DXEFV size to 11 MB", 2018-05-29), it's been ~1.75 years since >> commit 5e75c4d ("OvmfPkg: raise DXEFV size to 12 MB", 2020-03-11), >> and we've outgrown DXEFV again (with NOOPT builds). Increase the DXEFV >> size of IntelTdxX64 to 13MB now. > > Not sure this makes sense given that you want split DXEFV into two > smaller volumes for IntelTdx (patch series sent in december IIRC). > > Also we maybe should move the MEMFD section to a Include/Fdf snippet > to reduce code duplication and make it easier to keep things in sync? sigh, I followed up on this, but mistakenly, I only sent it to Gerd. Reposting to the list as well: ... the only comment I have here is for this lasst paragraph. The problem with centralized code is the same as the advantage of centralized code. You modify it once and it affects everything. But for example I cannot *test* everything. Code duplication in edk2 has helped in the past with separating responsibilities. One example has been Xen. Originally, in OvmfPkg, Xen support was integrated into a bunch of other modules, and there was no dedicated Xen platform. When Xen got introduced to ArmVirtPkg, it got its own dedicated platform, and it showed us how much easier maintenance would be that way. Xen-based developers and QEMU/KVM-based developers virtually never cross-tested (nobody has the "other" setup, or the time to test it). So Xen-oriented patches in OvmfPkg kept breaking QEMU/KVM functionality, and of course vice versa; whereas in ArmVirtPkg, no such cross-interference was seen. After a while we separated Xen to a new platform under OvmfPkg too (TianoCore#1689, TianoCore#2122), and there was much consequent rejoicing. Jordan slightly disagreed with the split, and I agreed with him from a purity sense, but from a practical maintenance POV, the joint Xen<->QEMU/KVM codebase had been a nightmare. This was one of my main driving principles during the initial discussions about TDX. I think extracting further commonalities between the TDX platform(s) and the traditional platforms works against that. It creates an area where modifications must be tested at the same (for the same patches) by multiple disparate teams. I know I couldn't do that. Cloning BZs and posting ported patches helps. At the same time: if regular maintainers *can* and *are willing* to test such central changes in *all* affected platforms, then yes, centralization is absolutely vital, because then it *saves* work. So I guess it must reflect the community's structure. Laszlo