Re: [PATCH V1 1/1] OvmfPkg/IntelTdxX64: Raise DXEFV size to 13MB

["Laszlo Ersek" <lersek@redhat.com>]

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 <min.m.xu@intel.com>
>>
>> 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