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.133.124]) by mx.groups.io with SMTP id smtpd.web11.8116.1672987228408259253 for ; Thu, 05 Jan 2023 22:40:29 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TfHvsakM; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1672987227; 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: in-reply-to:in-reply-to:references:references; bh=+8aTInpoltnJootbpZt1nmr/b9Cg1YX33POqs4agioM=; b=TfHvsakMI/Han2ajOlfTwdm1HRkC5GjUm6OVvvagZuveYwYDCRjKv9qgVPs/8KekGUnD+J 4O4+hVVgt6b9LLVvFM6ZWV0ERdJCeHr+da3SjEj1wZ0n6MjzzPYf6wSHlD5Fsrj+6AmuDP 0UNSP9XhOfGmV6uY8kxiuUilBvBgzrk= 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-614-YUcTnP6HMmSewpOn1KtKvQ-1; Fri, 06 Jan 2023 01:40:21 -0500 X-MC-Unique: YUcTnP6HMmSewpOn1KtKvQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id AA3D6811E6E; Fri, 6 Jan 2023 06:40:20 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.238]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 569FF1121314; Fri, 6 Jan 2023 06:40:20 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 069291800081; Fri, 6 Jan 2023 07:40:19 +0100 (CET) Date: Fri, 6 Jan 2023 07:40:19 +0100 From: "Gerd Hoffmann" To: Laszlo Ersek Cc: Min Xu , 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 Subject: Re: [PATCH V1 1/1] OvmfPkg/IntelTdxX64: Raise DXEFV size to 13MB Message-ID: <20230106064019.fzzadlwjs676hv4g@sirius.home.kraxel.org> References: <20230105072105.144-1-min.m.xu@intel.com> <20230105113158.lq5r5zxuyrgapqjy@sirius.home.kraxel.org> <136b74e1-7966-0748-6bcc-c49c80a25082@redhat.com> MIME-Version: 1.0 In-Reply-To: <136b74e1-7966-0748-6bcc-c49c80a25082@redhat.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > > 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? > > 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. Sure, we have to check where sharing makes sense and where not on a case-by-case base. Some truely generic bits (like the list of usb drivers, or crypto/network support) might make sense to share across all platforms. Platform-specific bits are a different story. They would probably be restricted to the three kvm variants we have (i.e. OvmfPkgIa32, OvmfPkgIa32X64, OvmfPkgX64). Possibly AmdSev and IntelTdx too (again depending on the kind if change). > 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. I think with PlatformInitLib is a nice solution for that. It allows to share code instead of cut+pasting stuff. But the different platforms still have their own setup code. They can use all, some or none of the helper functions from the library and we also don't have a single code path which must detect and handle all possible cases at runtime. take care, Gerd