Re: 回复: [edk2-devel] [PATCH] MdeModulePkg\CoreDxe: Allow DXE Drivers to use untested memory
Hi Sean,
Setting all memory as tested in PEI is a workaround for the issue that this
patch addresses. However, promoting all memory in PEI is not a workable
solution for BIOSes that incorporate full memory testing functionality, as this
relies on the tested flag to determine which memory regions to test.
This patch addresses a discrepancy in EDK2 core regarding how untested memory
is treated for allocation by DXE drivers. In the case where a DXE driver does
not request a specific memory region DXE Core will promote untested memory if
necessary to provide memory to the driver. In the case where a DXE driver
requests a specific memory range of untested memory, DXE Core will currently
return an error instead of promoting untested memory to make the region
available for the driver.
Thanks,
Stacy
-Original Message-
From: Kinney, Michael D
Sent: Tuesday, January 11, 2022 10:57 AM
To: devel@edk2.groups.io; spbro...@outlook.com; Gao, Liming
; Howell, Stacy ; Kinney,
Michael D
Cc: Bi, Dandan
Subject: RE: 回复: [edk2-devel] [PATCH] MdeModulePkg\CoreDxe: Allow DXE Drivers
to use untested memory
Hi Sean,
The auto promotion of memory was only intended as a dev/debug feature to
maximize platform boot without having to tune what memory is tested in PEI
phase.
In my opinion, a production platform should never trigger any auto promotions
of untested to tested memory, and part of production validation should make
sure this event never occurs in any production boot scenarios.
The specific bug being fix here is that auto promotion was not symmetric across
all memory allocation types. It simply aligns this dev/debug feature.
Mike
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Sean
> Sent: Monday, January 10, 2022 6:47 PM
> To: devel@edk2.groups.io; Gao, Liming ;
> Howell, Stacy
> Cc: Bi, Dandan
> Subject: Re: 回复: [edk2-devel] [PATCH] MdeModulePkg\CoreDxe: Allow DXE
> Drivers to use untested memory
>
> if this is auto promotion is happening in the core then what is the
> value of memory testing and tracking that state. Is memory testing
> state a necessary feature of the Dxe Core?
>
>
> I think it makes more sense that if you platform wants to use a given
> range your platform should either test it and/or mark it as tested.
>
> OR
>
> The dxe core should do away with the memory testing tracking.
>
>
> On most platforms i have seen in the past few years all memory is
> marked as tested without doing any testing. The only value in the
> flag is keep the initial memory allocations in a given low range (below 4gb).
>
>
>
>
> On 1/10/2022 5:59 PM, gaoliming wrote:
> > Stacy:
> >This fix covers the case with AllocateAddress allocation type. I
> > agree this fix. Reviewed-by: Liming Gao
> >
> > Thanks
> > Liming
> >> -邮件原件-
> >> 发件人: devel@edk2.groups.io 代表 Stacy Howell
> >> 发送时间: 2022年1月8日 3:36
> >> 收件人: devel@edk2.groups.io
> >> 抄送: Stacy Howell ; Dandan Bi
> >> ; Liming Gao
> >> 主题: [edk2-devel] [PATCH] MdeModulePkg\CoreDxe: Allow DXE Drivers to
> >> use untested memory
> >>
> >> REF: https://https://bugzilla.tianocore.org/show_bug.cgi?id=3795
> >> CC: Dandan Bi
> >> CC: Liming Gao
> >>
> >> Updated CoreInternalAllocatePages() to call PromoteMemoryResource()
> >> and re-attempt the allocation if unable to convert the specified
> >> memory range
> >>
> >> Signed-off-by: Stacy Howell
> >> ---
> >> MdeModulePkg/Core/Dxe/Mem/Page.c | 14 ++
> >> 1 file changed, 14 insertions(+)
> >>
> >> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c
> >> b/MdeModulePkg/Core/Dxe/Mem/Page.c
> >> index 47d4c5d92e..cc0b90ac0d 100644
> >> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> >> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> >> @@ -1417,6 +1417,20 @@ CoreInternalAllocatePages (
> >> Status = CoreConvertPages (Start, NumberOfPages, MemoryType);
> >> }
> >>
> >> + if (EFI_ERROR (Status)) {
> >> +//
> >> +// If requested memory region is unavailable it may be
> >> + untested
> >> memory
> >> +// Attempt to promote memory resources, then re-attempt the
> >> allocation
> >> +//
> >> +if (PromoteMemoryResource ()) {
> >> + if (NeedGuard) {
> >> +Status = CoreConvertPagesWithGuard (Start, NumberOfPages,
> >> MemoryType);
> >> + } else {
> >> +Status = CoreConvertPages (Start, NumberOfPages, MemoryType);
> >> + }
> >> +}
> >> + }
> >> +
> >> Done:
> >> CoreReleaseMemoryLock ();
> >>
> >> --
> >> 2.32.0.windows.2
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#85717): https://edk2.groups.io/g/devel/message/85717
Mute This Topic: https://groups.io/mt/88340321/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header files of RISC-V processor package
Hi Abner, We already have a package for common platform content in the edk2 repo. This is the MdeModulePkg. However, the number of common platform features added to the MdeModulePkg over time has made this a very large package, and this can be measured by how complex the Maintainer.txt rules are for this package. The revised approach is to create feature packages that platforms can add if their platform requires that specific feature category. Examples are NetworkPkg, SecurityPkg, FmpDevicePkg, FatPkg, RedfishPkg, SourceLevelDebugPkg. Instead of adding another generic package such as CommonPlatformPkg, I would prefer to see the libs/modules either added to existing packages that match the feature category, or create new feature packages if there is a new feature category. We also try to limit the edk2 repo to components that are directly related the UEFI/PI specifications and are not Si/Platform specific. Si/Platform specific features go into the edk2-platforms repo. An example of a generic feature in the edk2-platforms repo is Features/Ext4. The UEFI spec only specifies FAT for UEFI boot from file system. There are a number of other feature packages in edk2-platforms in the Features directory, so you should review those as well to see if there is natural landing zone for any of your components. Mike > -Original Message- > From: Chang, Abner (HPS SW/FW Technologist) > Sent: Friday, January 14, 2022 3:15 AM > To: Kinney, Michael D ; Leif Lindholm > ; devel@edk2.groups.io; Ni, Ray > > Cc: Andrew Fish ; Sami Mujawar > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header > files of RISC-V processor package > > > > > -Original Message- > > From: Kinney, Michael D > > Sent: Friday, January 14, 2022 12:38 AM > > To: Chang, Abner (HPS SW/FW Technologist) ; Leif > > Lindholm ; devel@edk2.groups.io; Ni, Ray > > ; Kinney, Michael D > > Cc: Andrew Fish ; Sami Mujawar > > > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header > > files of RISC-V processor package > > > > Hi Abner, > > > > General recommendations included below. Of course each > > lib/modules/include needs to be reviewed and the > > best location selected. I am aware that there are components in edk2 that > > do not follow these general > > recommendations. This is due to content that was added before these > > recommendations were established > > and we have work to do to get everything aligned. > > > > Mike > > > > > -Original Message- > > > From: Chang, Abner (HPS SW/FW Technologist) > > > Sent: Wednesday, January 12, 2022 9:34 PM > > > To: Kinney, Michael D ; Leif Lindholm > > ; devel@edk2.groups.io; Ni, Ray > > > > > > Cc: Andrew Fish ; Sami Mujawar > > > > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add > > header files of RISC-V processor package > > > > > > HI Mike, > > > It is no problem to meet there. However, I am not available to join the > > design meeting in the next two weeks. Before we can get > > > together to discuss the best locations, do you have information regarding > > the rationale of driver/library location? > > > > > > What is the best location for, > > > - Processor ARCH dependent modules > > > > MdePkg for libs > > UefiCpuPkg for modules > > > > > - Common modules for all processor ARCHs > > > > Feature Packages based on the common feature. Add to existing if it fits. > > Create new for completely new feature area. > > > > > - Platform module that is specific to processor ARCH? > > > > edk2-platform repository > How about Leif's suggestion? The CommonPlatformPkg on edk2? > > Abner > > > > > The only exception so far are platform modules used to support > > OvmfPkg/QEMU to support CI. > > In this case the modules are added to OvmfPkg. > > > > > - Platform module that is common to processor ARCHs? > > > > edk2-platform repository > > > > The only exception so far are platform modules used to support > > OvmfPkg/QEMU to support CI. > > In this case the modules are added to OvmfPkg. > > > > > > > > Thanks > > > Abner > > > > > > > -Original Message- > > > > From: Kinney, Michael D > > > > Sent: Monday, January 10, 2022 11:58 PM > > > > To: Leif Lindholm ; devel@edk2.groups.io; Chang, > > Abner > > > > (HPS SW/FW Technologist) ; Kinney, Michael D > > > > ; Ni, Ray > > > > Cc: Andrew Fish ; Sami Mujawar > > > > > > > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add > > header > > > > files of RISC-V processor package > > > > > > > > Hi Abner, > > > > > > > > I see comments from Leif as well. > > > > > > > > Do you think a discussion in the design meeting Ray Ni runs would be > > > > valuable > > > > to review all the modules/libs/includes and discuss options for the best > > > > location for them to reside in the edk2 repos? > > > > > > > > Thanks, > > > > > > > > Mike > > > > > > > > > -Original Message- > > > > > From: Kinney, Michael D > > > > > Sent: Monday, January 10,
Re: [edk2-devel] [PATCH] UefiPayloadPkg: Not use BaseCpuTimerLib by default.
Reviewed-by: Maurice Ma > -Original Message- > From: Liu, Zhiguang > Sent: Thursday, January 13, 2022 22:15 > To: devel@edk2.groups.io > Cc: Dong, Guo ; Ni, Ray ; Ma, > Maurice ; You, Benjamin > > Subject: [PATCH] UefiPayloadPkg: Not use BaseCpuTimerLib by default. > > For recent X86 CPU, 0x15 CPUID instruction will return Time Stamp Counter. > This is recommended way to get the time, and also how BaseCpuTimerLib > works However, some CPU doesn't support this feature, so disable it by > default. > > Cc: Guo Dong > Cc: Ray Ni > Cc: Maurice Ma > Cc: Benjamin You > Signed-off-by: Zhiguang Liu > --- > UefiPayloadPkg/UefiPayloadPkg.dsc | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc > b/UefiPayloadPkg/UefiPayloadPkg.dsc > index 3d08edfe31..65c1bd610e 100644 > --- a/UefiPayloadPkg/UefiPayloadPkg.dsc > +++ b/UefiPayloadPkg/UefiPayloadPkg.dsc > @@ -111,6 +111,11 @@ >DEFINE SERIAL_DRIVER_ENABLE = TRUE DEFINE > PERFORMANCE_MEASUREMENT_ENABLE = FALSE + # For recent X86 CPU, > 0x15 CPUID instruction will return Time Stamp Counter.+ # This is > recommended way to get the time, and also how BaseCpuTimerLib works.+ > # However, some CPU doesn't support this feature, so disable it by default.+ > DEFINE CPU_TIMER_LIB_ENABLE = FALSE+ [BuildOptions] > *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES > GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG@@ -217,7 +222,7 > @@ ># # Platform #-!if $(UNIVERSAL_PAYLOAD) == TRUE+!if > $(CPU_TIMER_LIB_ENABLE) == TRUE > TimerLib|UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf !else > TimerLib|UefiPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf-- > 2.32.0.windows.2 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#85715): https://edk2.groups.io/g/devel/message/85715 Mute This Topic: https://groups.io/mt/88415742/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header files of RISC-V processor package
> -Original Message- > From: Kinney, Michael D > Sent: Friday, January 14, 2022 12:38 AM > To: Chang, Abner (HPS SW/FW Technologist) ; Leif > Lindholm ; devel@edk2.groups.io; Ni, Ray > ; Kinney, Michael D > Cc: Andrew Fish ; Sami Mujawar > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header > files of RISC-V processor package > > Hi Abner, > > General recommendations included below. Of course each > lib/modules/include needs to be reviewed and the > best location selected. I am aware that there are components in edk2 that > do not follow these general > recommendations. This is due to content that was added before these > recommendations were established > and we have work to do to get everything aligned. > > Mike > > > -Original Message- > > From: Chang, Abner (HPS SW/FW Technologist) > > Sent: Wednesday, January 12, 2022 9:34 PM > > To: Kinney, Michael D ; Leif Lindholm > ; devel@edk2.groups.io; Ni, Ray > > > > Cc: Andrew Fish ; Sami Mujawar > > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add > header files of RISC-V processor package > > > > HI Mike, > > It is no problem to meet there. However, I am not available to join the > design meeting in the next two weeks. Before we can get > > together to discuss the best locations, do you have information regarding > the rationale of driver/library location? > > > > What is the best location for, > > - Processor ARCH dependent modules > > MdePkg for libs > UefiCpuPkg for modules > > > - Common modules for all processor ARCHs > > Feature Packages based on the common feature. Add to existing if it fits. > Create new for completely new feature area. > > > - Platform module that is specific to processor ARCH? > > edk2-platform repository How about Leif's suggestion? The CommonPlatformPkg on edk2? Abner > > The only exception so far are platform modules used to support > OvmfPkg/QEMU to support CI. > In this case the modules are added to OvmfPkg. > > > - Platform module that is common to processor ARCHs? > > edk2-platform repository > > The only exception so far are platform modules used to support > OvmfPkg/QEMU to support CI. > In this case the modules are added to OvmfPkg. > > > > > Thanks > > Abner > > > > > -Original Message- > > > From: Kinney, Michael D > > > Sent: Monday, January 10, 2022 11:58 PM > > > To: Leif Lindholm ; devel@edk2.groups.io; Chang, > Abner > > > (HPS SW/FW Technologist) ; Kinney, Michael D > > > ; Ni, Ray > > > Cc: Andrew Fish ; Sami Mujawar > > > > > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add > header > > > files of RISC-V processor package > > > > > > Hi Abner, > > > > > > I see comments from Leif as well. > > > > > > Do you think a discussion in the design meeting Ray Ni runs would be > > > valuable > > > to review all the modules/libs/includes and discuss options for the best > > > location for them to reside in the edk2 repos? > > > > > > Thanks, > > > > > > Mike > > > > > > > -Original Message- > > > > From: Kinney, Michael D > > > > Sent: Monday, January 10, 2022 7:55 AM > > > > To: Leif Lindholm ; devel@edk2.groups.io; Chang, > > > Abner ; Kinney, Michael D > > > > > > > > Cc: Andrew Fish ; Sami Mujawar > > > > > > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add > > > header files of RISC-V processor package > > > > > > > > Hi Abner, > > > > > > > > I would also like to see some proposals on adding the RiscV CPU scoped > > > content > > > > to the existing MdePkg/UefiCpuPkg instead of adding a new top level > CPU > > > package. > > > > > > > > There is already some work started to move some of the ARM specific > > > content > > > > from ARM CPU packages into MdePkg. > > > > > > > > Thanks, > > > > > > > > Mike > > > > > > > > > -Original Message- > > > > > From: Leif Lindholm > > > > > Sent: Monday, January 10, 2022 5:11 AM > > > > > To: devel@edk2.groups.io; Chang, Abner > > > > > Cc: Andrew Fish ; Kinney, Michael D > > > ; Sami Mujawar > > > > > > Subject: Re: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add > > > header files of RISC-V processor package > > > > > > > > > > On Sat, Jan 08, 2022 at 12:07:53 +0800, Abner Chang wrote: > > > > > > (This is migrated from edk2-platforms:Silicon/RISC-V) > > > > > > > > > > > > RISC-V processor package library definitions. > > > > > > > > > > > > IndustryStandard/RiscV.h > > > > > > -Add RiscV.h which conform with RISC-V Privilege Spec v1.10. > > > > > > > > > > > > RiscVImpl.h > > > > > > -Definition of EDK2 RISC-V implementation. > > > > > > > > > > > > Signed-off-by: Abner Chang > > > > > > Co-authored-by: Daniel Schaefer > > > > > > Co-authored-by: Gilbert Chen > > > > > > Reviewed-by: Leif Lindholm > > > > > > > > > > Hmm, no. > > > > > I gave a reviewed-by for that patch to be merged into edk2-platforms > > > > > once upon a time. This is not relevant for migration to edk2. > > > > > > > > > > My proposal for
Re: [edk2-devel] [PATCH v4 00/11] Create new target for Cloud Hypervisor
Great, thank you! Sebastien From: Yao, Jiewen Sent: Thursday, January 13, 2022 3:56:09 PM To: Boeuf, Sebastien ; devel@edk2.groups.io Cc: Justen, Jordan L ; kra...@redhat.com Subject: RE: [PATCH v4 00/11] Create new target for Cloud Hypervisor Merged: https://github.com/tianocore/edk2/pull/2411 > -Original Message- > From: Boeuf, Sebastien > Sent: Tuesday, January 11, 2022 8:31 PM > To: devel@edk2.groups.io > Cc: Yao, Jiewen ; Justen, Jordan L > ; kra...@redhat.com; Boeuf, Sebastien > > Subject: [PATCH v4 00/11] Create new target for Cloud Hypervisor > > From: Sebastien Boeuf > > Since Cloud Hypervisor and QEMU pc/q35 are quite different, it makes > more sense to create a dedicated OVMF target for Cloud Hypervisor rather > than trying to support both VMMs from the same OvmfPkgX64 target. > > That's the reason why this series introduces a new target called > CloudHvX64, meant to be used with the Cloud Hypervisor VMM only. > > The new target is initially copied over from the OvmfPkgX64, then it is > trimmed down by removing what is not needed from a Cloud Hypervisor > perspective. > > Sebastien Boeuf (11): > OvmfPkg/CloudHv: Add new target for Cloud Hypervisor > OvmfPkg/CloudHv: Replace legacy 8254 PIT with local APIC timer > OvmfPkg/CloudHv: Connect serial console > OvmfPkg/CloudHv: Remove legacy 8259 PIC support > OvmfPkg/CloudHv: Remove Q35 specifics > OvmfPkg/CloudHv: Reduce dependency on QemuFwCfg > OvmfPkg/CloudHv: Remove video support > OvmfPkg/CloudHv: Remove USB support > OvmfPkg/CloudHv: Remove CSM support > OvmfPkg/CloudHv: add Maintainers.txt entry > OvmfPkg: Add CloudHvX64 to the CI > > Maintainers.txt | 5 + > OvmfPkg/CloudHv/CloudHvX64.dsc| 938 ++ > OvmfPkg/CloudHv/CloudHvX64.fdf| 503 ++ > .../PlatformBootManagerLib/BdsPlatform.c | 8 +- > .../.azurepipelines/Ubuntu-GCC5.yml | 9 + > OvmfPkg/PlatformCI/CloudHvBuild.py| 37 + > 6 files changed, 1499 insertions(+), 1 deletion(-) > create mode 100644 OvmfPkg/CloudHv/CloudHvX64.dsc > create mode 100644 OvmfPkg/CloudHv/CloudHvX64.fdf > create mode 100644 OvmfPkg/PlatformCI/CloudHvBuild.py > > -- > 2.30.2 - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#85713): https://edk2.groups.io/g/devel/message/85713 Mute This Topic: https://groups.io/mt/88347187/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH EDK2 v1 1/1] MdeModulePkg/PciBucDxe:Fix issue when initial SR-IVO
Reference:https://bugzilla.tianocore.org/show_bug.cgi?id=3804 When calculating SR-IOV reserve bus in function CreatePciIoDevice(), there are two points may have problem. LastVF = PFRid + FirstVFOffset + (PciIoDevice->InitialVFs - 1) * VFStride; PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) - Bus + 1); The first is that if the value of PciIoDevice->InitialVFs is 0, it will cause overflow, it's better to check InitialVFs before used. The second is that if number of bus is not enough for all PF and still allocate bus for VF, it will lead to PCI enumerating failure. Cc: Jian J Wang Cc: Liming Gao Cc: Hao A Wu Cc: Ray Ni Signed-off-by: Wenyi Xie --- MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c index 9251388bc268..a4d1db534276 100644 --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c @@ -2402,12 +2402,12 @@ CreatePciIoDevice ( // Calculate LastVF // PFRid = EFI_PCI_RID (Bus, Device, Func); - LastVF = PFRid + FirstVFOffset + (PciIoDevice->InitialVFs - 1) * VFStride; + LastVF = PFRid + FirstVFOffset + (PciIoDevice->InitialVFs == 0 ? 0 : PciIoDevice->InitialVFs - 1) * VFStride; // // Calculate ReservedBusNum for this PF // - PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) - Bus + 1); + PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) - Bus); DEBUG (( DEBUG_INFO, -- 2.20.1.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#85712): https://edk2.groups.io/g/devel/message/85712 Mute This Topic: https://groups.io/mt/88417561/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH EDK2 v1 0/1] MdeModulePkg/PciBucDxe:Fix issue when initial SR-IVO
Main Changes : 1.Add check before using InitialVFs. 2.Don't allocate bus for VF. Wenyi Xie (1): MdeModulePkg/PciBucDxe:Fix issue when initial SR-IVO MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.20.1.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#85711): https://edk2.groups.io/g/devel/message/85711 Mute This Topic: https://groups.io/mt/88417560/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 08/10] OvmfPkg: Update Sec to support Tdvf Config-B
Hi, > > I don't see that PEI-less boot is required for that. Sure, when stripping > > down > > the build and removing all the features which require PEIMs there isn't much > > left to do for the PEI phase. So it makes sense to look into dropping PEI > > altogether. But it's more a "nice to have" > > than a hard requirement, no? > No. I have to say PEI-less boot in Config-B is a hard requirement. I'm still wondering why though. I have not yet seen a reason why config-b can't use the PEI-based boot flow. > > > 4. But a basic version of PlatformInitLib is a good start. > > > > Yes. Having initially only the functions needed by config-b in > > PlatformInitLib > > is perfectly fine, but this should be a code *move* not a copy. > > > > > During the development and community review, we can understand better > > > what functions should be wrapped into PlatformInitLib. After that > > > PlatformInitLib can be evolved for OvmfPkg/PlatformPei, > > > Bhyve/PlatformPei, XenPlatformPei. > > > > Yes, most likely there are a number of opportunities to reduce code > > duplication in the three PlatformPei variants we have by moving code to the > > (shared) PlatformInitLib. > > > > That can be looked at later. > > So let me summarize the discussion about PlatformInitLib. > 1. PlatformInitLib wraps the common functions in OvmfPkg/PlatformPei. > These common functions covers the memory detection via fw_cfg, pci > init, cmos, (MemDetect.c/Platform.c/Cmos.c). Yes. Everything needed for PEI-less / config-b boot moves to PlatformInitLib. PlatformInitLib is added as dependency to OvmfPkg/PlatformPei, so PlatformPei can call those functions when booting with PEI. PEI-less boot will add PlatformInitLib to SEC (and DXE) instead so the same code can be used then. Not sure how to handle cmos best. Not needed for memory detection on qemu, but cloudhw depends on it so it is back for now. Will cloudhw support tdx too btw? > And PlatformInitLib will > not handle the S3/SMM variants. At least not initially. Maybe later when we move more code to the lib to reduce code duplication in xen/bhyve/qemu PlatformPei variants. > 2. OvmfPkg/PlatformPei will be refactored with PlatformInitLib. The > functions not needed by config-b stay in PlatformPei. > 3. Config-B support PEI-less boot for both legacy guest and td guest. Yes. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#85710): https://edk2.groups.io/g/devel/message/85710 Mute This Topic: https://groups.io/mt/87720802/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
