From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) by mx.groups.io with SMTP id smtpd.web10.811.1581488504990347186 for ; Tue, 11 Feb 2020 22:21:45 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=LXKZgd8Q; spf=pass (domain: apple.com, ip: 17.171.2.68, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id 01C6HAA2016301; Tue, 11 Feb 2020 22:21:43 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : content-transfer-encoding : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=4LGS9Y0AXF/qWRRQF6net/ZL+iG0chdFDLwqLCajlko=; b=LXKZgd8QgxJuQUMUoao+W92MTMsaWUM6Qh4XH8D5ASl13i+Jc+SdhcwlZNDyoEbXryk9 sszjLM3VrzsCXMzpKu+FnE03TvEk8oVDrloZvFV+j4Ra+BFk4hjxp6D/x/sXj1HHOXBO urCRttkKeQ/xvD+N2gWeeNsgMpqj1JncOxjr9RYkCbAEu7MsCvm09Nr1liRKmuHsSI3A KBjbb9eKHwpO/x1fk8G3DRFUg4zOBsgAxMSaxSNZz/Q+AU9MKTg8INDS05kiVXnKqFE8 t6XOq3SfGhEdPtdCeXlFcXSoSg4ZlfTv8YG05iEMZJZRFEzMB98hMYEwl9fmSOvB5N7B yg== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2y1thy56rv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 11 Feb 2020 22:21:43 -0800 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPS id <0Q5K00IW3SC6XEA0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Tue, 11 Feb 2020 22:21:42 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) id <0Q5K00300SA1EC00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Tue, 11 Feb 2020 22:21:42 -0800 (PST) X-Va-A: X-Va-T-CD: 7daa14ab80d2839c17f099a8fda5373c X-Va-E-CD: be3ad1bb8586f868aa9351093d44c94a X-Va-R-CD: 6c4affdca55139a43dfc2299838b0723 X-Va-CD: 0 X-Va-ID: 56676119-7fb2-4981-b66e-70603adc7570 X-V-A: X-V-T-CD: 7daa14ab80d2839c17f099a8fda5373c X-V-E-CD: be3ad1bb8586f868aa9351093d44c94a X-V-R-CD: 6c4affdca55139a43dfc2299838b0723 X-V-CD: 0 X-V-ID: c686a51b-a8ee-4045-81f1-7611aaf9556d X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.572 definitions=2020-02-11_07:2020-02-11,2020-02-11 signatures=0 Received: from [17.234.8.219] by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPSA id <0Q5K00BDQSC52N50@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Tue, 11 Feb 2020 22:21:42 -0800 (PST) Sender: afish@apple.com From: "Andrew Fish" MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Subject: Re: [edk2-devel] PCD Migration issue Date: Tue, 11 Feb 2020 22:21:40 -0800 References: <6D19BFCB-B1F3-415E-9DDA-23992E98B637@apple.com> <882c2df7f2c74859ba2d96031a9faf8c@intel.com> To: devel@edk2.groups.io, Liming Gao In-reply-to: <882c2df7f2c74859ba2d96031a9faf8c@intel.com> Message-id: <212C86E2-A4B9-4B23-8280-0A3F871E206C@apple.com> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-02-11_07:,, signatures=0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Liming, I agree I don't think this has been thought about.=20 Does the edk2 still support booting a split PEI from ROM and DXE from caps= ule for update? If yes that seems to imply the assumption is that platform = would not change any Dynamic PCD layout, or update the PCD database version= s. If you have a platform in a common core base, and update the EDK2 code t= o pick up security fixes it seems the PCD data base implies you have to fre= eze Dynamic PCD usage in your common core?=20 Thanks, Andrew Fish > On Feb 11, 2020, at 7:54 PM, Liming Gao wrote: >=20 > Andrew: > Current implementation requires PEI PcdDB and DXE PcdDB match. This is = like a new request for PCD DataBase. It requests PCD DB binary format and D= ynamic PCD token assignment be compatible in the different version. >=20 > Thanks > Liming >> -----Original Message----- >> From: devel@edk2.groups.io On Behalf Of Andrew F= ish via Groups.Io >> Sent: Tuesday, February 11, 2020 1:39 AM >> To: devel@edk2.groups.io >> Subject: [edk2-devel] PCD Migration issue >>=20 >> We recently hit an issue when updating our UDK version in our common co= de base. Our recovery update path started failing for older >> platforms since the PEI was the old UDK version and the DXE from the Ca= psule was the new UDK version. Basically the version of the PCD >> changed. It looks like there are some checks, but the seem to be more a= bout making sure the build systems matches the code vs. dealing >> with an update case like we hit. >>=20 >> It does not look like the PCD database is designed to deal with this. W= e are fixing this by extracting the PEI PCD database from the >> capsule and then having some platform specific code to patch any PCD en= tries that got set in PEI that are needed by DXE. >>=20 >> In the future it would be helpful if the PCD database would change in s= ome what of a backward compatible way, and have the headers >> needed to parse the old and new version. >>=20 >> It also seems like adding a Dynamic PCD could potentially change the to= ken layout and thus break compatibility? Is there any scheme to >> keep a previous token layout? >>=20 >> Thanks, >>=20 >> Andrew Fish >>=20 >=20 >=20 >=20 >=20