Re: [edk2-devel] [edk2-platforms][PATCH V1 0/7] Fix ACPI Low Power Idle states for RD platforms
Hi Pierre,
Thanks for reviewing this patch series. Please find my reply inline.
Regards,
Pranav
> -Original Message-
> From: Pierre Gondois
> Sent: Tuesday, June 21, 2022 2:15 PM
> To: devel@edk2.groups.io; Pranav Madhu ;
> Thomas Abraham
> Cc: Sami Mujawar ; Ard Biesheuvel
> ; nd
> Subject: Re: [edk2-devel] [edk2-platforms][PATCH V1 0/7] Fix ACPI Low
> Power Idle states for RD platforms
>
> Hello Pranav,
> Would it be possible to extend this change to the Juno aswell as the platform
> has a Null Residency Counter and doesn't support OS Initiated LPI ?
It can be changed for Juno as well, but I do not have access to any Juno boards
and this patch series is focusing on RD platforms. The Juno board update can be
posted as a separate patch.
>
> Another remark is that for RdV1MC, RdN2, RdV1 and RdN2Cfg1 platforms,
> CPUs don't need to be encapsulated anymore in cluster objects
> Cf:
> Device (CL00) { // Cluster 0
>Name (_HID, "ACPI0010")
>Name (_UID, 0)
>...
> }
> since Clusters don't have any additional information. But keeping them is
> correct aswell.
These platforms have a minimal cluster logic but does not support low power
states. But the cluster encapsulation represents the platform topology
accurately. So it would be better to keep the cluster encapsulation.
>
> Regards,
> Pierre
>
> On 6/20/22 18:53, Pranav Madhu via groups.io wrote:
> > Hi All,
> >
> > Could you please let me know if any updates required for this series of
> patch?
> >
> > Regards,
> > Pranav
> >
> > *From:* Thomas Abraham
> > *Sent:* Sunday, June 12, 2022 2:16 AM
> > *To:* Pranav Madhu ; devel@edk2.groups.io
> > *Subject:* Re: [edk2-devel] [edk2-platforms][PATCH V1 0/7] Fix ACPI
> > Low Power Idle states for RD platforms
> >
> > On Thu, Jun 9, 2022 at 11:20 AM, Pranav Madhu wrote:
> >
> > The DSDT ACPI table used for Neoverse reference design platforms
> include
> > the _LPI control method for the kernel to enter idle states. This patch
> > series fixes bugs in the existing _LPI control method due to which
> > certain high level OS failed to boot on the supported Neoverse reference
> > design platforms. For each platform, the fixes include - clearing level
> > ID value as the platform supports only platform co-ordinated _LPI and
> > removing residency counter frequency as the platform does not
> implement
> > residency counter.
> >
> > In addition to this, the RD-N2 and RD-N2-Cfg1 platforms are direct
> > connect platforms and so the _LPI control method for cluster is removed.
> >
> > Link to github branch with the patches in this series -
> > https://github.com/Pranav-Madhu/edk2-
> platforms/tree/topics/lpi_fix_for_rd= Madhu/edk2-platforms/tree/topics/lpi_fix_for_rd=>
> > _platforms
> >
> > Pranav Madhu (7):
> > Platform/Sgi: Fix ACPI Low Power Idle states for SGI575
> > Platform/Sgi: Fix ACPI Low Power Idle states for RD-N1-Edge
> > Platform/Sgi: Fix ACPI Low Power Idle states for RD-N1-Edge-X2
> > Platform/Sgi: Fix ACPI Low Power Idle states for RD-V1
> > Platform/Sgi: Fix ACPI Low Power Idle states for RD-V1-MC
> > Platform/Sgi: Fix ACPI Low Power Idle states for RD-N2
> > Platform/Sgi: Fix ACPI Low Power Idle states for RD-N2-Cfg1
> >
> > Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl | 8 +-
> > Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2/Dsdt.asl | 8 +-
> > Platform/ARM/SgiPkg/AcpiTables/RdN2/Dsdt.asl | 78 +---=
> >
> > Platform/ARM/SgiPkg/AcpiTables/RdN2Cfg1/Dsdt.asl | 54 +-
> > Platform/ARM/SgiPkg/AcpiTables/RdV1/Dsdt.asl | 8 +-
> > Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Dsdt.asl | 8 +-
> > Platform/ARM/SgiPkg/AcpiTables/Sgi575/Dsdt.asl | 8 +-
> > 7 files changed, 28 insertions(+), 144 deletions(-)
> >
> >
> > For this series -
> > Reviewed-by: Thomas Abraham > >
> >
> >
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90670): https://edk2.groups.io/g/devel/message/90670
Mute This Topic: https://groups.io/mt/91652410/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-platforms][PATCH V2 0/9] Upadate the ACPI tables for RD platforms
Hi Pierre, Thanks for reviewing the patch series. IORT table has separate specification document and not included as a part of ACPI 6.4. That was the reason for excluding IORT from this series. If required, it will be updated in a separate patch. I've posted V3 of this patch, no major changes, I request you to have a look at that: https://edk2.groups.io/g/devel/message/90399. Regards, Pranav > On 6/22/22 10:57, Pranav Madhu via groups.io wrote:> > Hello Pranav, > > The definitions for the IORT table are still at 6_0, (IORT revision=0): > MdePkg/Include/IndustryStandard/IoRemappingTable.h > and the definitions are used at: > Platform/ARM/SgiPkg/AcpiTables/Iort.aslc > > The IORT spec is now at the version E.d (revision=5). > Does the IORT need to be updated aswell ? > > Regards, > Pierre > > On 6/20/22 18:52, Pranav Madhu via groups.io wrote: > > Hi All, > > > > Could you please let me know if any updates are required for this series of > patch? > > > > Regards, > > Pranav > > > >> -Original Message- > >> From: Thomas Abraham > >> Sent: Tuesday, April 19, 2022 1:40 AM > >> To: devel@edk2.groups.io; Pranav Madhu > >> Cc: Ard Biesheuvel ; Sami Mujawar > >> > >> Subject: Re: [edk2-devel] [edk2-platforms][PATCH V2 0/9] Upadate the > >> ACPI tables for RD platforms > >> > >> > >> On 4/18/22 12:54, Pranav Madhu via groups.io wrote: > >>> Changes since V1: > >>> - Rebased on top of latest master branch. > >>> - Rebased on top of patch to remove SLC cache entries from PPTT (link > >>> for the same in edk2.groups.io is provided below) > >>> > >>> Arm infrastructure reference design platforms uses ACPI tables to > >>> provide the hardware information to the operating system. Currently > >>> the ACPI tables are aligned with ACPI v6.2 and v6.3 specification. > >>> This patch series update the tables to ACPI v6.4 specificaion. > >>> > >>> The first patch in this series update the generic tables which are > >>> common for all platfoms. The subsequent patches in this series > >>> update platform specific ACPI tables to v6.4 for the respective platform. > >>> > >>> This patch series also update the headers in the .aslc files to > >>> match the coding style as per edk2 coding guidelines. > >>> > >>> This patch series should be applied on top of the patch series > >>> https://edk2.groups.io/g/devel/message/88996 > >>> > >>> Link to github branch with the patches in this series - > >>> https://github.com/Pranav-Madhu/edk2- > >> platforms/tree/topics/acpi64_for_ > >>> rd_platforms > >>> > >>> > >>> Pranav Madhu (9): > >>> Platform/Sgi: Update ACPI version to v6.4 > >>> Platform/Sgi: Update ACPI version to v6.4 for SGI-575 platform > >>> Platform/Sgi: Update ACPI version to v6.4 for Rd-N1-Edge platform > >>> Platform/Sgi: Update ACPI version to v6.4 for Rd-N1-Edge-X2 platform > >>> Platform/Sgi: Update ACPI version to v6.4 for Rd-E1-Edge platform > >>> Platform/Sgi: Update ACPI version to v6.4 for Rd-V1 platform > >>> Platform/Sgi: Update ACPI version to v6.4 for Rd-V1-MC platform > >>> Platform/Sgi: Update ACPI version to v6.4 for Rd-N2 platform > >>> Platform/Sgi: Update ACPI version to v6.4 for Rd-N2-Cfg1 > >>> platform > >> > >> For this series - > >> Reviewed-by: Thomas Abraham > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, > please notify the sender immediately and do not disclose the contents to any > other person, use it for any purpose, or store or copy the information in any > medium. Thank you. > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#90669): https://edk2.groups.io/g/devel/message/90669 Mute This Topic: https://groups.io/mt/90537675/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 3/3] OvmfPkg: Initialize NvVarStore with Configuration FV in Td guest
On June 20, 2022 7:01 PM, Gerd Hoffman wrote:
>
> > + UINT8 *CfvBase;
> > + UINT32CfvSize;
> >
> >DEBUG ((DEBUG_INFO, "EMU Variable FVB Started\n"));
> >
> > @@ -774,6 +776,23 @@ FvbInitialize (
> >
> >mEmuVarsFvb.BufferPtr = Ptr;
> >
> > + //
> > + // In Tdx guest the VarNvStore content should be initialized by the
> Configuration FV (CFV).
> > + // Integrity of the CFV has been validated by TdxValidateCfv
> > + (@PlatformInitLib) // if (TdIsEnabled ()) {
> > +CfvBase = (UINT8 *)(UINTN)PcdGet32 (PcdCfvBase);
> > +CfvSize = (UINT32)PcdGet32 (PcdCfvRawDataSize);
> > +
> > +if (CfvSize > mEmuVarsFvb.Size) {
> > + DEBUG ((DEBUG_ERROR, "Size of CFV is larger than the EMU Variable
> FVB.\n"));
> > + ASSERT (FALSE);
> > +} else {
> > + CopyMem (Ptr, CfvBase, CfvSize);
> > + Initialize = FALSE;
> > +}
> > + }
>
> There is PcdEmuVariableNvStoreReserved for that. How about just copying
> the store to ram, then set PcdEmuVariableNvStoreReserved to the location
> and let the existing logic handle it?
There is ReserveEmuVariableNvStore in PlatformPei/Platform.c. This function is
called to allocate storage for NV Variables. PcdEmuVariableNvStoreReserved is
set in that function too. So we can copy the content to that reserved storage
if it is tdx guest. Then we let the exiting logic to handle it. So I would like
to extract ReserveEmuVariableNvStore to PlatformReserveEmuVariableNvStore (in
PlatformInitLib) and call it in both PlatformPei/Platform.c and
PeilesssStartup.c.
What's your thought?
>
> Also why limit this to tdx?
Because I am not sure if other platforms need such operation. So in current
stage it is limit to tdx.
Thanks
Min
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90668): https://edk2.groups.io/g/devel/message/90668
Mute This Topic: https://groups.io/mt/91835110/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] UefiPayloadPkg: UniversalPayloadBuild.py to support --pcd feature
++ James
-Original Message-
From: Guo, Gua
Sent: Monday, June 20, 2022 9:56 AM
To: devel@edk2.groups.io
Cc: Guo, Gua ; Dong, Guo ; Ni, Ray
Subject: [PATCH] UefiPayloadPkg: UniversalPayloadBuild.py to support --pcd
feature
From: Gua Guo
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3955
Currently, UPL freezed all PCD and only known UPL hob can hook DXE Drivers
behavior, add optional feature on UniversalPayloadBuild.py to have another way
to hook PCD value.
Cc: Guo Dong
Cc: Ray Ni
Signed-off-by: Gua Guo
---
UefiPayloadPkg/UniversalPayloadBuild.py | 8
1 file changed, 8 insertions(+)
diff --git a/UefiPayloadPkg/UniversalPayloadBuild.py
b/UefiPayloadPkg/UniversalPayloadBuild.py
index 089d631b51..c71526e0a6 100644
--- a/UefiPayloadPkg/UniversalPayloadBuild.py
+++ b/UefiPayloadPkg/UniversalPayloadBuild.py
@@ -82,6 +82,11 @@ def BuildUniversalPayload(Args, MacroList):
print("- Failed - Please check if LLVM is installed or if CLANG_BIN is
set correctly") sys.exit(1) +Pcds = ""+if (Args.pcd != None):+
for PcdItem in Args.pcd:+Pcds += " --pcd {}".format
(PcdItem)+ Defines = "" for key in MacroList: Defines +=" -D
{0}={1}".format(key, MacroList[key])@@ -90,12 +95,14 @@ def
BuildUniversalPayload(Args, MacroList):
# Building DXE core and DXE drivers as DXEFV. # BuildPayload =
f"build -p {DscPath} -b {BuildTarget} -a X64 -t {ToolChain} -y
{PayloadReportPath} {Quiet}"+BuildPayload += Pcds BuildPayload +=
Defines RunCommand(BuildPayload) # # Building Universal Payload
entry. # BuildModule = f"build -p {DscPath} -b {BuildTarget} -a
{BuildArch} -m {EntryModuleInf} -t {ElfToolChain} -y {ModuleReportPath}
{Quiet}"+BuildModule += Pcds BuildModule += Defines
RunCommand(BuildModule) @@ -128,6 +135,7 @@ def main():
parser.add_argument("-D", "--Macro", action="append",
default=["UNIVERSAL_PAYLOAD=TRUE"]) parser.add_argument('-i', '--ImageId',
type=str, help='Specify payload ID (16 bytes maximal).', default ='UEFI')
parser.add_argument('-q', '--Quiet', action='store_true', help='Disable all
build messages except FATAL ERRORS.')+parser.add_argument("-p", "--pcd",
action="append") MacroList = {} args = parser.parse_args() if
args.Macro is not None:--
2.31.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90666): https://edk2.groups.io/g/devel/message/90666
Mute This Topic: https://groups.io/mt/91892604/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Windows 10 build failing
I'm facing the same issue with latest EDK2 repo pull, using VS2019, NASM 2.15. Somehow, got EmulatorPkg build working, but MdeModulePkg build fails with same above error. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#90664): https://edk2.groups.io/g/devel/message/90664 Mute This Topic: https://groups.io/mt/91805662/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH] UefiPayloadPkg: UniversalPayloadBuild.py to support --pcd feature
From: Gua Guo
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3955
Currently, UPL freezed all PCD and only known UPL hob can hook DXE
Drivers behavior, add optional feature on UniversalPayloadBuild.py to
have another way to hook PCD value.
Cc: Guo Dong
Cc: Ray Ni
Signed-off-by: Gua Guo
---
UefiPayloadPkg/UniversalPayloadBuild.py | 8
1 file changed, 8 insertions(+)
diff --git a/UefiPayloadPkg/UniversalPayloadBuild.py
b/UefiPayloadPkg/UniversalPayloadBuild.py
index 089d631b51..c71526e0a6 100644
--- a/UefiPayloadPkg/UniversalPayloadBuild.py
+++ b/UefiPayloadPkg/UniversalPayloadBuild.py
@@ -82,6 +82,11 @@ def BuildUniversalPayload(Args, MacroList):
print("- Failed - Please check if LLVM is installed or if CLANG_BIN is
set correctly")
sys.exit(1)
+Pcds = ""
+if (Args.pcd != None):
+for PcdItem in Args.pcd:
+Pcds += " --pcd {}".format (PcdItem)
+
Defines = ""
for key in MacroList:
Defines +=" -D {0}={1}".format(key, MacroList[key])
@@ -90,12 +95,14 @@ def BuildUniversalPayload(Args, MacroList):
# Building DXE core and DXE drivers as DXEFV.
#
BuildPayload = f"build -p {DscPath} -b {BuildTarget} -a X64 -t {ToolChain}
-y {PayloadReportPath} {Quiet}"
+BuildPayload += Pcds
BuildPayload += Defines
RunCommand(BuildPayload)
#
# Building Universal Payload entry.
#
BuildModule = f"build -p {DscPath} -b {BuildTarget} -a {BuildArch} -m
{EntryModuleInf} -t {ElfToolChain} -y {ModuleReportPath} {Quiet}"
+BuildModule += Pcds
BuildModule += Defines
RunCommand(BuildModule)
@@ -128,6 +135,7 @@ def main():
parser.add_argument("-D", "--Macro", action="append",
default=["UNIVERSAL_PAYLOAD=TRUE"])
parser.add_argument('-i', '--ImageId', type=str, help='Specify payload ID
(16 bytes maximal).', default ='UEFI')
parser.add_argument('-q', '--Quiet', action='store_true', help='Disable
all build messages except FATAL ERRORS.')
+parser.add_argument("-p", "--pcd", action="append")
MacroList = {}
args = parser.parse_args()
if args.Macro is not None:
--
2.31.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90665): https://edk2.groups.io/g/devel/message/90665
Mute This Topic: https://groups.io/mt/91892604/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [Patch V2] XhcCreateUsbHc: Check return value of XHC_PAGESIZE_OFFSET
Patch merged via:
PR - https://github.com/tianocore/edk2/pull/2997
Commit -
https://github.com/tianocore/edk2/commit/b97243dea3c95ad923fa4ca190940158209e8384
Best Regards,
Hao Wu
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Wu, Hao
> A
> Sent: Monday, June 20, 2022 3:40 PM
> To: Luo, Heng ; devel@edk2.groups.io
> Cc: Ni, Ray ; Chan, Amy
> Subject: Re: [edk2-devel] [Patch V2] XhcCreateUsbHc: Check return value of
> XHC_PAGESIZE_OFFSET
>
> Reviewed-by: Hao A Wu
>
> Will wait some time to see if comments from other reviewers.
>
> Also, Will change the title a little bit to:
> MdeModulePkg/XhciDxe: Check return value of XHC_PAGESIZE_OFFSET
>
> Best Regards,
> Hao Wu
>
> > -Original Message-
> > From: Luo, Heng
> > Sent: Monday, June 20, 2022 3:08 PM
> > To: devel@edk2.groups.io
> > Cc: Ni, Ray ; Wu, Hao A
> > Subject: [Patch V2] XhcCreateUsbHc: Check return value of
> > XHC_PAGESIZE_OFFSET
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3954
> >
> > Report error if reserved bits are not 0 for PageSize
> >
> > Cc: Ray Ni
> > Cc: Hao Wu
> > Signed-off-by: Heng Luo
> > ---
> > MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 10 --
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> > b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> > index b79499e225..381d7a9536 100644
> > --- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> > +++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> > @@ -1,7 +1,7 @@
> > /** @file
> >
> >The XHCI controller driver.
> >
> >
> >
> > -Copyright (c) 2011 - 2018, Intel Corporation. All rights
> > reserved.
> >
> > +Copyright (c) 2011 - 2022, Intel Corporation. All rights
> > +reserved.
> >
> > SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >
> >
> > **/
> >
> > @@ -1813,7 +1813,13 @@ XhcCreateUsbHc (
> >// This xHC supports a page size of 2^(n+12) if bit n is Set. For
> > example,
> >
> >// if bit 0 is Set, the xHC supports 4k byte page sizes.
> >
> >//
> >
> > - PageSize = XhcReadOpReg (Xhc, XHC_PAGESIZE_OFFSET) &
> > XHC_PAGESIZE_MASK;
> >
> > + PageSize = XhcReadOpReg (Xhc, XHC_PAGESIZE_OFFSET);
> >
> > + if ((PageSize & (~XHC_PAGESIZE_MASK)) != 0) {
> >
> > +DEBUG ((DEBUG_ERROR, "XhcCreateUsb3Hc: Reserved bits are not 0
> > + for
> > PageSize\n"));
> >
> > +goto ON_ERROR;
> >
> > + }
> >
> > +
> >
> > + PageSize &= XHC_PAGESIZE_MASK;
> >
> >Xhc->PageSize = 1 << (HighBitSet32 (PageSize) + 12);
> >
> >
> >
> >ExtCapReg = (UINT16)(Xhc->HcCParams.Data.ExtCapReg);
> >
> > --
> > 2.31.1.windows.1
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90663): https://edk2.groups.io/g/devel/message/90663
Mute This Topic: https://groups.io/mt/91872204/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - 06/21/2022 #cal-reminder
*Reminder: TianoCore Bug Triage - APAC / NAMO* *When:* 06/21/2022 6:30pm to 7:30pm (UTC-07:00) America/Los Angeles *Where:* https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTk1YzJhN2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d *Organizer:* Liming Gao gaolim...@byosoft.com.cn ( gaolim...@byosoft.com.cn?subject=Re:%20Event:%20TianoCore%20Bug%20Triage%20-%20APAC%20%2F%20NAMO ) View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=1262370 ) *Description:* TianoCore Bug Triage - APAC / NAMO Hosted by Liming Gao Microsoft Teams meeting *Join on your computer or mobile app* Click here to join the meeting ( https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d ) *Join with a video conferencing device* te...@conf.intel.com Video Conference ID: 116 062 094 0 Alternate VTC dialing instructions ( https://conf.intel.com/teams/?conf=1160620940=teams=conf.intel.com=test_call ) *Or call in (audio only)* +1 916-245-6934,,77463821# ( tel:+19162456934,,77463821# ) United States, Sacramento Phone Conference ID: 774 638 21# Find a local number ( https://dialin.teams.microsoft.com/d195d438-2daa-420e-b9ea-da26f9d1d6d5?id=77463821 ) | Reset PIN ( https://mysettings.lync.com/pstnconferencing ) Learn More ( https://aka.ms/JoinTeamsMeeting ) | Meeting options ( https://teams.microsoft.com/meetingOptions/?organizerId=b286b53a-1218-4db3-bfc9-3d4c5aa7669e=46c98d88-e344-4ed4-8496-4ed7712e255d=19_meeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh@thread.v2=0=en-US ) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#90662): https://edk2.groups.io/g/devel/message/90662 Mute This Topic: https://groups.io/mt/91891522/21656 Mute #cal-reminder:https://edk2.groups.io/g/devel/mutehashtag/cal-reminder Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v6 5/5] OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with spec
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the hypervisor for each
Host Bridge to create the RootBridge elements.
In Ovmf platforms, the host can provide the specification of
non-discoverable hardware resources like PCI host bridges. If the
proper fw-cfg file is found, parse the contents provided by the
host into a linked list by using the Hardware Info library. Then,
using the list of PCI host bridges' descriptions, populate the
PCI_ROOT_BRIDGES array with the resources and attributes specified
by the host. If the file is not provided or no Host Bridge is found
in it, fold back to the legacy method based on pre-defined
apertures and rules.
In some use cases, the host requires additional control over the
hardware resources' configurations in the guest for performance and
discoverability reasons. For instance, to disclose information about
the PCI hierarchy to the guest so that this can profit from
optimized accesses. In this case, the host can decide to describe
multiple PCI Host Bridges and provide a specific set of resources
(e.g. MMIO apertures) so that the guest uses the values provided.
Using the provided values may entitle the guest to added performance,
for example by using specific MMIO mappings that can enable peer-to-peer
communication across the PCI hierarchy or by allocating memory closer
to a device for faster DMA transactions.
Cc: Alexander Graf
Cc: Gerd Hoffmann
Acked-by: Gerd Hoffmann
Signed-off-by: Nicolas Ojeda Leon
---
Notes:
v6:
Preparation for merge:
- Verify the status output of HardwareInfoPciHostBridgeGet and abort
the host-provided PCI root bridges parsing if an error happened.
- Verify the validity of bus number range (start - end) extracted
from host-provided info to avoid creating root bridges that have
an invalid range. Abort parsing if error detected.
- Cast bus number values down to UINT8 after having verified values
are in range.
v5:
- Added "Acked-by" tag
---
.../PciHostBridgeUtilityLib.c | 332 +-
.../PciHostBridgeUtilityLib.inf | 1 +
2 files changed, 328 insertions(+), 5 deletions(-)
diff --git a/OvmfPkg/Library/PciHostBridgeUtilityLib/PciHostBridgeUtilityLib.c
b/OvmfPkg/Library/PciHostBridgeUtilityLib/PciHostBridgeUtilityLib.c
index 92e1ea812f..cad2bd6c96 100644
--- a/OvmfPkg/Library/PciHostBridgeUtilityLib/PciHostBridgeUtilityLib.c
+++ b/OvmfPkg/Library/PciHostBridgeUtilityLib/PciHostBridgeUtilityLib.c
@@ -12,13 +12,16 @@
#include
#include
+#include
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#pragma pack(1)
typedef struct {
@@ -189,7 +192,9 @@ PciHostBridgeUtilityUninitRootBridge (
}
/**
- Utility function to return all the root bridge instances in an array.
+ Utility function to scan PCI root bridges and create instances for those
+ that are found not empty. Populate their resources from the default
+ provided parameters and return all the root bridge instances in an array.
@param[out] Count The number of root bridge instances.
@@ -217,9 +222,9 @@ PciHostBridgeUtilityUninitRootBridge (
@returnAll the root bridge instances in an array.
**/
+STATIC
PCI_ROOT_BRIDGE *
-EFIAPI
-PciHostBridgeUtilityGetRootBridges (
+PciHostBridgeUtilityGetRootBridgesBusScan (
OUT UINTN *Count,
IN UINT64Attributes,
IN UINT64AllocationAttributes,
@@ -243,8 +248,6 @@ PciHostBridgeUtilityGetRootBridges (
UINTN LastRootBridgeNumber;
UINTN RootBridgeNumber;
- *Count = 0;
-
if ((BusMin > BusMax) || (BusMax > PCI_MAX_BUS)) {
DEBUG ((
DEBUG_ERROR,
@@ -403,6 +406,325 @@ FreeBridges:
return NULL;
}
+/**
+ Utility function to read root bridges information from host-provided fw-cfg
+ file and return them in an array.
+
+ @param[out] Count The number of root bridge instances.
+
+ @return All the root bridge instances in an array parsed from
+ host-provided fw-cfg file (hardware-info).
+**/
+STATIC
+PCI_ROOT_BRIDGE *
+PciHostBridgeUtilityGetRootBridgesHostProvided (
+ OUT UINTN *Count
+ )
+{
+ EFI_STATUSStatus;
+ FIRMWARE_CONFIG_ITEM FwCfgItem;
+ UINTN FwCfgSize;
+ PCI_ROOT_BRIDGE *Bridges;
+ UINTN Initialized;
+ UINTN LastRootBridgeNumber;
+ UINTN RootBridgeNumber;
+ UINTN PciHostBridgeCount;
+ UINT8 *HardwareInfoBlob;
+ LIST_ENTRYHwInfoList;
+ LIST_ENTRY*HwLink;
+ HARDWARE_INFO
[edk2-devel] [PATCH v6 4/5] Ovmf/PlatformPei: Use host-provided GPA end if available
Read the "hardware-info" item from fw-cfg to extract specifications
of PCI host bridges and analyze the 64-bit apertures of them to
find out the highest 64-bit MMIO address required which determines
the address space required by the guest, and, consequently, the
FirstNonAddress used to calculate size of physical addresses.
Using the static PeiHardwareInfoLib, read the fw-cfg file of
hardware information to extract, one by one, all the host
bridges. Find the last 64-bit MMIO address of each host bridge,
using the HardwareInfoPciHostBridgeLib API, and compare it to an
accumulate value to discover the highest address used, which
corresponds to the highest value that must be included in the
guest's physical address space.
Given that platforms with multiple host bridges may provide the PCI
apertures' addresses, the memory detection logic must take into
account that, if the host provided the MMIO windows that can and must
be used, the guest needs to take those values. Therefore, if the
MMIO windows are found in the host-provided fw-cfg file, skip all the
logic calculating the physical address size and just use the value
provided. Since each PCI host bridge corresponds to an element in
the information provided by the host, each of these must be analyzed
looking for the highest address used.
Cc: Alexander Graf
Cc: Gerd Hoffmann
Acked-by: Gerd Hoffmann
Signed-off-by: Nicolas Ojeda Leon
---
Notes:
v6:
Preparation for merge:
v5:
- Moved all changes from MemDetect.c into recently created
PlatformInitLib/MemDetect.c effectively re-basing this patch
onto latest master
- Adapted function name to use Platform convention without
any changes in the logic
---
OvmfPkg/Library/PlatformInitLib/MemDetect.c | 148 +-
.../PlatformInitLib/PlatformInitLib.inf | 1 +
2 files changed, 142 insertions(+), 7 deletions(-)
diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
index c28d7601f8..942eaf89cf 100644
--- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
+++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
@@ -27,6 +27,7 @@ Module Name:
#include
#include
#include
+#include
#include
#include
#include
@@ -527,6 +528,126 @@ PlatformAddressWidthFromCpuid (
));
}
+/**
+ Iterate over the PCI host bridges resources information optionally provided
+ in fw-cfg and find the highest address contained in the PCI MMIO windows. If
+ the information is found, return the exclusive end; one past the last usable
+ address.
+
+ @param[out] PciMmioAddressEnd Pointer to one-after End Address updated with
+information extracted from host-provided data
+or zero if no information available or an
+error happened
+
+ @retval EFI_SUCCESS PCI information was read and the output
+parameter updated with the last valid
+address in the 64-bit MMIO range.
+ @retval EFI_INVALID_PARAMETER Pointer parameter is invalid
+ @retval EFI_INCOMPATIBLE_VERSION Hardware information found in fw-cfg
+has an incompatible format
+ @retval EFI_UNSUPPORTED Fw-cfg is not supported, thus host
+provided information, if any, cannot be
+read
+ @retval EFI_NOT_FOUND No PCI host bridge information provided
+by the host.
+**/
+STATIC
+EFI_STATUS
+PlatformScanHostProvided64BitPciMmioEnd (
+ OUT UINT64 *PciMmioAddressEnd
+ )
+{
+ EFI_STATUSStatus;
+ HOST_BRIDGE_INFO HostBridge;
+ FIRMWARE_CONFIG_ITEM FwCfgItem;
+ UINTN FwCfgSize;
+ UINTN FwCfgReadIndex;
+ UINTN ReadDataSize;
+ UINT64Above4GMmioEnd;
+
+ if (PciMmioAddressEnd == NULL) {
+return EFI_INVALID_PARAMETER;
+ }
+
+ *PciMmioAddressEnd = 0;
+ Above4GMmioEnd = 0;
+
+ Status = QemuFwCfgFindFile ("etc/hardware-info", , );
+ if (EFI_ERROR (Status)) {
+return Status;
+ }
+
+ QemuFwCfgSelectItem (FwCfgItem);
+
+ FwCfgReadIndex = 0;
+ while (FwCfgReadIndex < FwCfgSize) {
+Status = QemuFwCfgReadNextHardwareInfoByType (
+ HardwareInfoTypeHostBridge,
+ sizeof (HostBridge),
+ FwCfgSize,
+ ,
+ ,
+
+ );
+
+if (Status != EFI_SUCCESS) {
+ //
+ // No more data available to read in the file, break
+ // loop and finish process
+ //
+ break;
+}
+
+Status = HardwareInfoPciHostBridgeLastMmioAddress (
+ ,
+ ReadDataSize,
+ TRUE,
+
+ );
+
+if (Status != EFI_SUCCESS) {
+ //
+ // Error parsing MMIO apertures and extracting last MMIO
+ //
[edk2-devel] [PATCH v6 2/5] Ovmf/HardwareInfoLib: Create Pei lib to parse directly from fw-cfg
Define the HardwareInfoLib API and create the PeiHardwareInfoLib which implements it, specifically for Pei usage, supporting only static accesses to parse data directly from a fw-cfg file. All list-like APIs are implemented as unsupported and only a fw-cfg wrapper to read hardware info elements is provided. The Hardware Info library is intended to describe non-discoverable hardware information and share that from the host to the guest in Ovmf platforms. The QEMU fw-cfg extension for this library provides a first variation to parse hardware info by reading it directly from a fw-cfg file. This library offers a wrapper function to the plain QmeuFwCfgReadBytes which, specifically, parses header-data pairs out of the binary values in the file. For this purpose, the approach is incremental, reading the file block by block and outputting the values only for a specific known hardware type (e.g. PCI host bridges). One element is returned in each call until the end of the file is reached. Considering fw-cfg as the first means to transport hardware info from the host to the guest, this wrapping library offers the possibility to statically, and in steps, read a specific type of hardware info elements out of the file. This method reads one hardware element of a specific type at a time, without the need to pre-allocate memory and read the whole file or dynamically allocate memory for each new element found. As a usage example, the static approach followed by this library enables early UEFI stages to use and read hardware information supplied by the host. For instance, in early times of the PEI stage, hardware information can be parsed out from a fw-cfg file prescinding from memory services, that may not yet be available, and avoiding dynamic memory allocations. Cc: Alexander Graf Cc: Gerd Hoffmann Acked-by: Gerd Hoffmann Signed-off-by: Nicolas Ojeda Leon --- Notes: v6: Preparation for merge: - Updated files' copyright to follow EDK2 format - Explicitly cast header size to UINTN when reading hardware information from a fw-cfg file. - Before casting verify validity of values to avoid overflows as well as check ReadIndex is inside bounds. - Add HardwareInfoLib library class definition of to OvmfPkg.dec - Include PeiHardwareInfoLib as part of library classes needed by several platforms which indirectly depend on it (fix CI build for all platforms). --- ArmVirtPkg/ArmVirtQemu.dsc| 1 + OvmfPkg/AmdSev/AmdSevX64.dsc | 1 + OvmfPkg/Bhyve/BhyveX64.dsc| 1 + OvmfPkg/CloudHv/CloudHvX64.dsc| 1 + OvmfPkg/Include/Library/HardwareInfoLib.h | 159 ++ .../Library/HardwareInfoLib/HardwareInfoPei.c | 79 + .../HardwareInfoLib/PeiHardwareInfoLib.inf| 39 + .../QemuFwCfgHardwareInfoLib.c| 88 ++ OvmfPkg/Microvm/MicrovmX64.dsc| 1 + OvmfPkg/OvmfPkg.dec | 4 + OvmfPkg/OvmfPkgIa32.dsc | 1 + OvmfPkg/OvmfPkgIa32X64.dsc| 1 + OvmfPkg/OvmfPkgX64.dsc| 1 + OvmfPkg/OvmfXen.dsc | 1 + 14 files changed, 378 insertions(+) create mode 100644 OvmfPkg/Include/Library/HardwareInfoLib.h create mode 100644 OvmfPkg/Library/HardwareInfoLib/HardwareInfoPei.c create mode 100644 OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf create mode 100644 OvmfPkg/Library/HardwareInfoLib/QemuFwCfgHardwareInfoLib.c diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc index aa0ce61630..9369a88858 100644 --- a/ArmVirtPkg/ArmVirtQemu.dsc +++ b/ArmVirtPkg/ArmVirtQemu.dsc @@ -81,6 +81,7 @@ PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf PciHostBridgeLib|OvmfPkg/Fdt/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf PciHostBridgeUtilityLib|OvmfPkg/Library/PciHostBridgeUtilityLib/PciHostBridgeUtilityLib.inf + PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf !if $(TPM2_ENABLE) == TRUE Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc index 6b3827f7f6..72cbf710df 100644 --- a/OvmfPkg/AmdSev/AmdSevX64.dsc +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc @@ -168,6 +168,7 @@ FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf BlobVerifierLib|OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierLibSevHashes.inf MemEncryptTdxLib|OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf + PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf !if $(SOURCE_DEBUG_ENABLE) == TRUE PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLibDebug.inf diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc index f0166e136c..ada904464e 100644 --- a/OvmfPkg/Bhyve/BhyveX64.dsc +++
[edk2-devel] [PATCH v6 0/5] Handling of multiple PCI
Increased control is provided in Ovmf platforms to define and configure the specifications of multiple PCI host bridges in the hypervisor. The host propagates this information to the guest, initially through fw-cfg interface. In some AWS EC2 platforms, we expose a PCI topology including several root bridges portraying information about physical distribution that enables the guest to optimize accesses. Current PCI driver for Ovmf enables the explicit definition of multiple root bridges and contains the logic to fix their resources based on platform-specific PCD entries. However, we need a way to control, from the hypervisor, how many and which resources each PCI root bridge can use. For this reason, this patch series introduces a mechanism to provide PCI host bridges information like bus number range, attributes, allocation attributes, PIO aperture as well as 32 and 64- bit prefetchable and non-prefetchable MMIO ranges through a fw-cfg item created by the hypervisor and consumed by the guest firmware. In order to offer a generic and extensible way to disclose non-discoverable hardware information from the host to the guest, a new library called HardwareInfoLib is created in the OvmfPkg. In essence, this library offers the functionality to parse a generic BLOB into a list as well as the methods to iterate over such list, including filtering options. The library is conceived in a generic way so that further hardware elements can also be described using it. For such purpose the length of the BLOB is not restricted but instead regarded as a sequence of header-info elements that allow the parsing during runtime. Furthermore, specific functionality is provided wrapping QemuFwCfgReadBytes to extract hardware descriptions, in the aforementioned format, in a static way so that early in the Pei stage the library can be used to identify address space requirements. The core of the library offers enough flexibility to process as many elements, even from different hardware types (heterogenous), as needed in a single run. This library is extended for the particular use case already exposed, PCI host bridges, and this same code offers an example of how to tailor it for further hardware components. After acknowledgement from Gerd Hoffmann and fixing all warnings and errors found by the CI pipeline (via draft pull request), here I send a new revision of the patches for merging. --- Notes: v6: Prepearation for upstream merge: - No functional change at all. - Small changes to fix all builds excercised by CI (https://github.com/tianocore/edk2/pull/2938) - Added libraries to furhter platforms as per dependencies requirements - Explicit casting of some values as required by build and verification of values when demoting values. - Arranged added files copyright to the format required. - Changed HOST_BRIDGE_INFO bitfield member to UINT32 to follow EDK2 guidelines motivated on build in 32-bit windows systems. - Added verification of Bus Number range when values provided by host to make sure Root Bridge is initialized with valid values v5: - Removed last 3 patches dealing with pre-populated resources to encapsulate related changes in more manageable chunks and while pre-populated changes are finalized. - Added Acked-by to all commits - Re-based on top of latest master and refactored changes in MemDetect.c to adapt to recently created PlatformInitLib/MemDetect.c v4: - Minor modification to use MAX_UINT64 as global invalid base address when reading PCI host bridge information provided by the host (Patch 1) - Refactor PciHostBridgeUtilityGetRootBridges into a thin wrapper that calls 2 new function: one (BusScan) that performs the legacy bus scan population process and a new one (HostProvided) that populates Root Bridges with host provided values. (Patch 5) - Move code that sets value of PcdPciPreservePopulatedMappings token based on host-provided fw-cfg file into the function that populates root bridges with host provided data (Patch 6) - Restructured base address retrieval to leave PCI Resource Allocation protocol untouched and instead augment the existing services to enable base address retrieval before allocation. (Patch 7) - Use new method to retrieve Root Bridge base addresses before allocation and use that to handle pre-populated BARs (Patch 8) Nicolas Ojeda Leon (5): OvmfPkg/Library: Create base HardwareInfoLib for PCI Host Bridges Ovmf/HardwareInfoLib: Create Pei lib to parse directly from fw-cfg Ovmf/HardwareInfoLib: Add Dxe lib to dynamically parse heterogenous data Ovmf/PlatformPei: Use host-provided GPA end if available OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with spec ArmVirtPkg/ArmVirtQemu.dsc| 2 + OvmfPkg/AmdSev/AmdSevX64.dsc | 2 + OvmfPkg/Bhyve/BhyveX64.dsc| 2 + OvmfPkg/CloudHv/CloudHvX64.dsc
Re: [edk2-devel] [PATCH v3] UefiPayloadPkg: Add support for logging to CBMEM console
Reviewed-by: Guo Dong
-Original Message-
From: Benjamin Doron
Sent: Sunday, June 5, 2022 5:55 PM
To: devel@edk2.groups.io
Cc: Dong, Guo ; Ni, Ray ; Maurice Ma
; You, Benjamin ; Rhodes, Sean
Subject: [PATCH v3] UefiPayloadPkg: Add support for logging to CBMEM console
Writes TianoCore debug logs into the CBMEM console ringbuffer, from where the
user can retrieve them with the `cbmem` userspace utility.
The intention is to aid in debugging non-fatal issues even in release builds,
or simply make TianoCore's logs available to those interested.
Consequently, MDEPKG_NDEBUG must be masked. As an in-memory debug logging
library, ASSERTs must be non-fatal to be seen, so they neither dead-loop nor
create a breakpoint. It is assumed that ASSERT() neither enforces fatal
conditions nor security integrity, as release builds do not call DebugAssert()
from the ASSERT macro.
More detailed debug logs are produced with the DEBUG_CODE macro, but this
guards other debug-related code throughout the codebase. To avoid changing
behaviour on release builds, this is only set for debug builds.
Tested on QEMU, dumping the appropriate memory region in the UEFI shell shows
the TianoCore log. An improved revision of the debug library used in several
coreboot-related EDK2 forks, including MrChromebox's.
Previous revisions also tested on an Acer Aspire VN7-572G laptop.
Cc: Guo Dong
Cc: Ray Ni
Cc: Maurice Ma
Cc: Benjamin You
Cc: Sean Rhodes
Signed-off-by: Benjamin Doron
---
UefiPayloadPkg/Include/Coreboot.h | 13 +
UefiPayloadPkg/Library/CbSerialPortLib/CbSerialPortLib.c | 264
UefiPayloadPkg/Library/CbSerialPortLib/CbSerialPortLib.inf | 30 +++
UefiPayloadPkg/UefiPayloadPkg.dsc | 25 +-
4 files changed, 327 insertions(+), 5 deletions(-)
diff --git a/UefiPayloadPkg/Include/Coreboot.h
b/UefiPayloadPkg/Include/Coreboot.h
index a3e1109fe84e..5892fae7682b 100644
--- a/UefiPayloadPkg/Include/Coreboot.h
+++ b/UefiPayloadPkg/Include/Coreboot.h
@@ -199,6 +199,13 @@ struct cb_forward {
UINT64forward; }; +struct cb_cbmem_ref {+ UINT32tag;+ // Field
contains size of this struct = 0x0010+ UINT32size;+ UINT64
cbmem_addr;+};+ #define CB_TAG_FRAMEBUFFER 0x0012 struct cb_framebuffer {
UINT32tag;@@ -229,6 +236,12 @@ struct cb_vdat {
#define CB_TAG_TIMESTAMPS 0x0016 #define CB_TAG_CBMEM_CONSOLE
0x0017+struct cbmem_console {+ UINT32 size;+ UINT32 cursor;+ UINT8
body[0];+} __attribute__((packed));+ #define CB_TAG_MRC_CACHE 0x0018
struct cb_cbmem_tab { UINT32tag;diff --git
a/UefiPayloadPkg/Library/CbSerialPortLib/CbSerialPortLib.c
b/UefiPayloadPkg/Library/CbSerialPortLib/CbSerialPortLib.c
new file mode 100644
index ..863fbcfef2f0
--- /dev/null
+++ b/UefiPayloadPkg/Library/CbSerialPortLib/CbSerialPortLib.c
@@ -0,0 +1,264 @@
+/** @file+ CBMEM console SerialPortLib instance++ Copyright (c) 2022, Baruch
Binyamin Doron+ SPDX-License-Identifier: BSD-2-Clause-Patent++**/++#include
+#include ++#include +#include
+#include ++// Upper nibble
contains flags+#define CBMC_CURSOR_MASK ((1 << 28) - 1)+#define CBMC_OVERFLOW
(1 << 31)++STATIC struct cbmem_console *mCbConsole = NULL;++/**+ Find
coreboot record with given Tag.+ NOTE: This coreboot-specific function
definition is absent+ from the common BlParseLib header.++ @param Tag
The tag id to be found++ @retval NULL The Tag is
not found.+ @retval OthersThe pointer to the record
found.++**/+VOID *+FindCbTag (+ IN UINT32 Tag+ );++/**+ Initialize
the serial device hardware.++ If no initialization is required, then return
RETURN_SUCCESS.+ If the serial device was successfully initialized, then
return RETURN_SUCCESS.+ If the serial device could not be initialized, then
return RETURN_DEVICE_ERROR.++ @retval RETURN_SUCCESSThe serial device
was initialized.+ @retval RETURN_DEVICE_ERROR The serial device could not be
initialized.++**/+RETURN_STATUS+EFIAPI+SerialPortInitialize (+ VOID+ )+{+ //
The coreboot table contains large structures as references+ struct
cb_cbmem_ref *cbref = FindCbTag(CB_TAG_CBMEM_CONSOLE);+ if (!cbref) {+
return RETURN_DEVICE_ERROR;+ }++ mCbConsole = (VOID
*)(UINTN)cbref->cbmem_addr; // Support PEI and DXE+ if (mCbConsole == NULL)
{+return RETURN_DEVICE_ERROR;+ }++ return RETURN_SUCCESS;+}++/**+ Write
data from buffer to serial device.++ Writes NumberOfBytes data bytes from
Buffer to the serial device.+ The number of bytes actually written to the
serial device is returned.+ If the return value is less than NumberOfBytes,
then the write operation failed.+ If Buffer is NULL, then ASSERT().+ If
NumberOfBytes is zero, then return 0.++ @param Buffer Pointer to
the data buffer to be written.+ @param NumberOfBytesNumber of bytes to
written to the serial device.++ @retval 0
Re: [edk2-devel] [edk2-platforms][PATCH V2 0/9] Upadate the ACPI tables for RD platforms
Hello Pranav, The definitions for the IORT table are still at 6_0, (IORT revision=0): MdePkg/Include/IndustryStandard/IoRemappingTable.h and the definitions are used at: Platform/ARM/SgiPkg/AcpiTables/Iort.aslc The IORT spec is now at the version E.d (revision=5). Does the IORT need to be updated aswell ? Regards, Pierre On 6/20/22 18:52, Pranav Madhu via groups.io wrote: Hi All, Could you please let me know if any updates are required for this series of patch? Regards, Pranav -Original Message- From: Thomas Abraham Sent: Tuesday, April 19, 2022 1:40 AM To: devel@edk2.groups.io; Pranav Madhu Cc: Ard Biesheuvel ; Sami Mujawar Subject: Re: [edk2-devel] [edk2-platforms][PATCH V2 0/9] Upadate the ACPI tables for RD platforms On 4/18/22 12:54, Pranav Madhu via groups.io wrote: Changes since V1: - Rebased on top of latest master branch. - Rebased on top of patch to remove SLC cache entries from PPTT (link for the same in edk2.groups.io is provided below) Arm infrastructure reference design platforms uses ACPI tables to provide the hardware information to the operating system. Currently the ACPI tables are aligned with ACPI v6.2 and v6.3 specification. This patch series update the tables to ACPI v6.4 specificaion. The first patch in this series update the generic tables which are common for all platfoms. The subsequent patches in this series update platform specific ACPI tables to v6.4 for the respective platform. This patch series also update the headers in the .aslc files to match the coding style as per edk2 coding guidelines. This patch series should be applied on top of the patch series https://edk2.groups.io/g/devel/message/88996 Link to github branch with the patches in this series - https://github.com/Pranav-Madhu/edk2- platforms/tree/topics/acpi64_for_ rd_platforms Pranav Madhu (9): Platform/Sgi: Update ACPI version to v6.4 Platform/Sgi: Update ACPI version to v6.4 for SGI-575 platform Platform/Sgi: Update ACPI version to v6.4 for Rd-N1-Edge platform Platform/Sgi: Update ACPI version to v6.4 for Rd-N1-Edge-X2 platform Platform/Sgi: Update ACPI version to v6.4 for Rd-E1-Edge platform Platform/Sgi: Update ACPI version to v6.4 for Rd-V1 platform Platform/Sgi: Update ACPI version to v6.4 for Rd-V1-MC platform Platform/Sgi: Update ACPI version to v6.4 for Rd-N2 platform Platform/Sgi: Update ACPI version to v6.4 for Rd-N2-Cfg1 platform For this series - Reviewed-by: Thomas Abraham IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#90654): https://edk2.groups.io/g/devel/message/90654 Mute This Topic: https://groups.io/mt/90537675/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] Validity of Function pointers to Global Boot Services functions
Hello everyone, The UEFI specification states that Global Boot Services functions are available on all platforms. Does that mean that we can assume that the pointer to the functions of "global" boot services functions will be valid if the SystemTable pointer and the BootServices pointer are valid? According to the Spec, Global Boot Services functions are divided into the following categories: - Event, Timer, and Task Priority Services (Section 7.1) - Memory Allocation Services (Section 7.2) - Protocol Handler Services (Section 7.3) - Image Services (Section 7.4) - Miscellaneous Services (Section 7.5) Yours Sincerely, Ayush Singh -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#90653): https://edk2.groups.io/g/devel/message/90653 Mute This Topic: https://groups.io/mt/91898972/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-platforms][PATCH V1 0/7] Fix ACPI Low Power Idle states for RD platforms
Hello Pranav,
Would it be possible to extend this change to the Juno aswell as the
platform has a Null Residency Counter and doesn't support OS Initiated LPI ?
Another remark is that for RdV1MC, RdN2, RdV1 and RdN2Cfg1 platforms,
CPUs don't need to be encapsulated anymore in cluster objects
Cf:
Device (CL00) { // Cluster 0
Name (_HID, "ACPI0010")
Name (_UID, 0)
...
}
since Clusters don't have any additional information. But keeping them
is correct aswell.
Regards,
Pierre
On 6/20/22 18:53, Pranav Madhu via groups.io wrote:
Hi All,
Could you please let me know if any updates required for this series of patch?
Regards,
Pranav
*From:* Thomas Abraham
*Sent:* Sunday, June 12, 2022 2:16 AM
*To:* Pranav Madhu ; devel@edk2.groups.io
*Subject:* Re: [edk2-devel] [edk2-platforms][PATCH V1 0/7] Fix ACPI Low Power
Idle states for RD platforms
On Thu, Jun 9, 2022 at 11:20 AM, Pranav Madhu wrote:
The DSDT ACPI table used for Neoverse reference design platforms include
the _LPI control method for the kernel to enter idle states. This patch
series fixes bugs in the existing _LPI control method due to which
certain high level OS failed to boot on the supported Neoverse reference
design platforms. For each platform, the fixes include - clearing level
ID value as the platform supports only platform co-ordinated _LPI and
removing residency counter frequency as the platform does not implement
residency counter.
In addition to this, the RD-N2 and RD-N2-Cfg1 platforms are direct
connect platforms and so the _LPI control method for cluster is removed.
Link to github branch with the patches in this series -
https://github.com/Pranav-Madhu/edk2-platforms/tree/topics/lpi_fix_for_rd=
_platforms
Pranav Madhu (7):
Platform/Sgi: Fix ACPI Low Power Idle states for SGI575
Platform/Sgi: Fix ACPI Low Power Idle states for RD-N1-Edge
Platform/Sgi: Fix ACPI Low Power Idle states for RD-N1-Edge-X2
Platform/Sgi: Fix ACPI Low Power Idle states for RD-V1
Platform/Sgi: Fix ACPI Low Power Idle states for RD-V1-MC
Platform/Sgi: Fix ACPI Low Power Idle states for RD-N2
Platform/Sgi: Fix ACPI Low Power Idle states for RD-N2-Cfg1
Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl | 8 +-
Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2/Dsdt.asl | 8 +-
Platform/ARM/SgiPkg/AcpiTables/RdN2/Dsdt.asl | 78 +---=
Platform/ARM/SgiPkg/AcpiTables/RdN2Cfg1/Dsdt.asl | 54 +-
Platform/ARM/SgiPkg/AcpiTables/RdV1/Dsdt.asl | 8 +-
Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Dsdt.asl | 8 +-
Platform/ARM/SgiPkg/AcpiTables/Sgi575/Dsdt.asl | 8 +-
7 files changed, 28 insertions(+), 144 deletions(-)
For this series -
Reviewed-by: Thomas Abraham mailto:thomas.abra...@arm.com>>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90652): https://edk2.groups.io/g/devel/message/90652
Mute This Topic: https://groups.io/mt/91652410/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Discussing how SystemTable and its Pointers should be treated in Rust
On 21/06/2022 07:04, Ayush Singh wrote: 1. Initialize the pointers needed for a module to work early on and keep them local to the module. This will mean that the allocator module will store the `allocate_pool` and `free_pool` pointers in a static private to the module which will be initialized by the std before the Rust main is run. 2. Only have one global pointer to the SystemTable and pass that to the functions (like allocate and deallocate) when needed. I am leaning more towards the first approach right now since it would mean that we will only need to assert that the local pointer is valid. However, the 1st approach is a NOGO if it is possible that the pointers in SysteTable can be changed by UEFI. By change, I mean that for example the `allocate_pool` pointer in SystemTable is replaced with a different pointer midway through the program. In that case, the pointer in the allocator module will become invalid but the SystemTable will contain the pointer to the new location of `allocate_pool` and stay valid. The UEFI shim will modify the LoadImage, StartImage, Exit, and ExitBootServices pointers in SystemTable->BootServices: https://github.com/rhboot/shim/blob/main/replacements.c#L154-L183 In certain debug modes, iPXE will modify pointers within SystemTable in order to implement strace-like functionality for loaded EFI binaries: https://github.com/ipxe/ipxe/blob/master/src/interface/efi/efi_wrap.c#L1243-L1265 so I would strongly suggest retaining only a pointer to SystemTable and dereferencing it at each point of use. Thanks, Michael -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#90651): https://edk2.groups.io/g/devel/message/90651 Mute This Topic: https://groups.io/mt/91894552/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] Discussing how SystemTable and its Pointers should be treated in Rust
Hello everyone, I wanted to discuss and get ideas about how I should implement the various services (like allocator and stdin) for UEFI in Rust. I have come up with two approaches: 1. Initialize the pointers needed for a module to work early on and keep them local to the module. This will mean that the allocator module will store the `allocate_pool` and `free_pool` pointers in a static private to the module which will be initialized by the std before the Rust main is run. 2. Only have one global pointer to the SystemTable and pass that to the functions (like allocate and deallocate) when needed. I am leaning more towards the first approach right now since it would mean that we will only need to assert that the local pointer is valid. However, the 1st approach is a NOGO if it is possible that the pointers in SysteTable can be changed by UEFI. By change, I mean that for example the `allocate_pool` pointer in SystemTable is replaced with a different pointer midway through the program. In that case, the pointer in the allocator module will become invalid but the SystemTable will contain the pointer to the new location of `allocate_pool` and stay valid. Yours Sincerely, Ayush Singh -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#90650): https://edk2.groups.io/g/devel/message/90650 Mute This Topic: https://groups.io/mt/91894552/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
