Re: [edk2] [PATCH] NetworkPkg: HttpDxe: Address double FreePool issue

Reviewed-by: Samer El-Haj-Mahmoud -Original Message- From: Hegde, Nagaraj P Sent: Wednesday, October 28, 2015 3:50 AM To: edk2-devel@lists.01.org Cc: El-Haj-Mahmoud, Samer ; Hegde, Nagaraj P Subject: [PATCH]

Re: [edk2] [Patch 2/2] UefiCpuPkg/CpuDxe: Fix one dead lock issue in ProcessorToIdleState()

On 10/28/15 07:42, Jeff Fan wrote: > There is one dead lock issue between BSP and AP. AP has one logic to enter > into > Sleep state (hlt) if it found its state is Idle state in one loop. > In ProcessorToIdleState() function, AP will get current AP state, if its state > is Sleep state, then it

Re: [edk2] [PATCH 1/1] EmbeddedPkg: Add EFIAPI to several Ebl functions

On 28 October 2015 at 14:35, Thomas Palmer wrote: > The EFIAPI function declaration is missing for several functions in the > EmbeddedPkg/Ebl directory. A few function pointer struct members expect > EFIAPI though and GCC46/X64 will fail to compile the directory without

Re: [edk2] [Patch 1/2] UefiCpuPkg/CpuDxe: Fix one dead lock issue in StartupThisAP()

> On Oct 28, 2015, at 4:47 AM, Laszlo Ersek wrote: > > On 10/28/15 07:42, Jeff Fan wrote: >> There is one dead lock issue between BSP and AP. AP has one logic to enter >> into >> Sleep state (hlt) if it found its state is Idle in one loop. >> In StartupThisAp() function, BSP

Re: [edk2] [Patch] MdeModulePkg: Fix a PciBusDxe hot plug bug

Feng, Any update on the below? The hard crash bug is still in SVN r18690. Regards, Leif On Mon, Oct 26, 2015 at 03:35:15PM +, Leif Lindholm wrote: > Hi Ray, > > On Mon, Oct 26, 2015 at 03:17:22PM +, Ni, Ruiyu wrote: > > Can you add a null pointer check to > >

[edk2] [Patch 1/2] UefiCpuPkg/CpuDxe: Fix one dead lock issue in StartupThisAP()

There is one dead lock issue between BSP and AP. AP has one logic to enter into Sleep state (hlt) if it found its state is Idle in one loop. In StartupThisAp() function, BSP will get current AP state (Sleep or Idle) to know how to wakeup AP. If AP is in Idle state, BSP will write one semaphore to

[edk2] [Patch 2/2] UefiCpuPkg/CpuDxe: Fix one dead lock issue in ProcessorToIdleState()

There is one dead lock issue between BSP and AP. AP has one logic to enter into Sleep state (hlt) if it found its state is Idle state in one loop. In ProcessorToIdleState() function, AP will get current AP state, if its state is Sleep state, then it will go into real sleep(hlt) state. The dead

Re: [edk2] about the SMM_S3_RESUME_SMM_64 branch in S3Resume2Pei

Laszlo, I do not believe any X64 PEI testing has not been performed with this module. We will investigate a fix. Thanks, Mike >-Original Message- >From: Laszlo Ersek [mailto:ler...@redhat.com] >Sent: Wednesday, October 28, 2015 8:57 AM >To: Fan, Jeff; Yao, Jiewen >Cc: edk2-devel-01;

Re: [edk2] about the SMM_S3_RESUME_SMM_64 branch in S3Resume2Pei

On 10/28/15 17:54, Kinney, Michael D wrote: > Laszlo, > > I do not believe any X64 PEI testing has not been performed with this module. > We will investigate a fix. Thank you. In any case, in OVMF we might be able to use this module nonetheless, with the OvmfPkgIa32X64.dsc build (== 32-bit

Re: [edk2] [Patch] MdeModulePkg FileExplorerLib: Create file explorer library.

You need to clarify in the function header comment for ChooseFile API if the caller needs to free the returned DevicePath (File parameter). Also, ChooseFile API may fail to de-allocate memory upon some failure conditions. Reviewed-by: Jaben Carsey > -Original

Re: [edk2] [Patch] MdeModulePkg: Fix a PciBusDxe hot plug bug

Leif, Please test the patch I just sent to see if it resolves your issue. Thanks, Mike >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif >Lindholm >Sent: Wednesday, October 28, 2015 7:51 AM >To: Tian, Feng >Cc: Ni, Ruiyu;

[edk2] [PATCH] MdeModulePkg: PciBusDxe: Check for valid ResourcePaddingDescriptors

Add a check for ResourcePaddingDescriptors being a valid pointer in DumpPpbPaddingResource() to prevent looping on memory not owned by PciBusDxe. The ResourcePaddingDescriptors is initialized to NULL when the PCI_IO_DEVICE structure is allocated and remains NULL if no PCI hot plug controllers are

[edk2] [PATCH 2/6] UefiCpuPkg/CpuDxe: Ignore extra APs in the system

The PcdCpuMaxLogicalProcessorNumber specifies the maximum number of logical processors which are expected to be seen by the system. If more APs actually are available in the system, we should prevent them from being used. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by:

Re: [edk2] about the SMM_S3_RESUME_SMM_64 branch in S3Resume2Pei

On 10/29/15 01:31, Yao, Jiewen wrote: > Hi Ersek > I think S3ResumePei supports Ia32 and Ia32X64. It does not support X64. So I > believe Ia32X64 crash is a bug somewhere. > > Since you already run into SmmRestoreCpu(), would you please help to check > where is last instruction causing crash?

[edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

By setting this PCD, we allow the CpuDxe driver to proceed earlier after all of the processors have started. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen Cc: Jeff Fan Cc: Laszlo Ersek ---

[edk2] [PATCH 5/6] UefiCpuPkg: Allow PcdCpuMaxLogicalProcessorNumber to be dynamic

Move from [PcdsFixedAtBuild, PcdsPatchableInModule] to [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]. This will allow a platform to set this PCD dynamically if it knows how many logical processors the system has. The CpuDxe driver can then use this information during

[edk2] [PATCH 0/6] UefiCpuPkg/CpuDxe MP Startup Fixes / Optimizations

web: https://github.com/jljusten/edk2/tree/mp-startup-early-exit git: https://github.com/jljusten/edk2.git mp-startup-early-exit Patches 1 & 2 are fixes to the CpuDxe MP support. Patches 3 & 4 allow the MP support initialization to proceed ealier if the maximum number of APs have been started.

Re: [edk2] about the SMM_S3_RESUME_SMM_64 branch in S3Resume2Pei

Thanks for the info. I think we might have to dig out why LONG_JUMP fail here. Most our IA BIOS support Ia32X64 mode, so I am sure it should work. For "RSM from 64-bit mode ", I have already confirmed with IA32 SDM owner that it is just typo. RSM should work in 64bit mode, so this patch is

[edk2] [PATCH 1/6] UefiCpuPkg/CpuDxe: Don't use gBS->Stall

The CpuDxe driver may run before the gEfiMetronomeArchProtocolGuid protocol is installed. gBS->Stall does not work until this arch protocol is installed. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen Cc: Jeff Fan

[edk2] [PATCH 4/6] UefiCpuPkg/CpuDxe: Allow BSP to continue once max APs are awake

Since the CpuDxe has a fixed maximum number of APs that are controlled with PcdCpuMaxLogicalProcessorNumber, if the maximum number of APs are awake, then the BSP should be able to continue. Since the APs may be updating the mMpSystemData.NumberOfProcessors during this early init phase, we use

[edk2] [PATCH 0/2] Add API to manage Local APIC SoftwareEnable

The LocalApicLib does not provide any APIs to manage the Local APIC SoftwareEnable state without side effects on other registers. This feature is required by the SourceLevelDebugAgent to make sure the Local APIC is in the correct state to use the Local APIC Timer. Contributed-under: TianoCore

[edk2] [PATCH 1/2] UefiCpuPkg: LocalApicLib: Add API to set SoftwareEnable bit

The LocalApicLib does not provide a function to manage the state of the Local APIC SoftwareEnable bit in the Spurious Vector register. There are cases where this bit needs to be managed without side effects to. other Local APIC registers. One use case is in the DebugAgent in the

[edk2] [PATCH 2/2] SourceLevelDebugPkg: DebugAgent: Set Local APIC SoftwareEnable

Update DebugAgent to make sure the Local APIC SoftwareEnable bit is set before using the Local APIC Timer. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney --- SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugTimer.c

Re: [edk2] [PATCH] MdeModulePkg: Add a BDS platform hook function PlatformBootManagerDefaultBootFail to PlatformBootManagerLib

Samer, EfiBootManagerBoot() function reports the failure to load boot option and the failure to start boot option through status code. // // Report Status Code to indicate that the failure to load boot option // REPORT_STATUS_CODE ( EFI_ERROR_CODE | EFI_ERROR_MINOR,

Re: [edk2] about the SMM_S3_RESUME_SMM_64 branch in S3Resume2Pei

On 10/29/15 02:32, Laszlo Ersek wrote: > On 10/29/15 01:31, Yao, Jiewen wrote: >> Hi Ersek >> I think S3ResumePei supports Ia32 and Ia32X64. It does not support X64. So I >> believe Ia32X64 crash is a bug somewhere. >> >> Since you already run into SmmRestoreCpu(), would you please help to check

[edk2] [PATCH v2 4/4] UefiCpuPkg/CpuDxe: Release AP startup code after ExitBootServices()

Because now we exit the boot services with the original AP startup code abandoned by all APs, we can allocate that startup code in Boot Services Code type memory; only the new stub (with the final HLT loop) has to reside in EfiACPIMemoryNVS. Cc: Chen Fan Cc: Jeff

[edk2] [PATCH v2 2/4] UefiCpuPkg/CpuDxe: Prepare final HALT loop for APs

Our current ExitBootServices() callback puts the APs in wait-for-SIPI state, by sending them an INIT IPI. This works fine as long as the APs are not woken between ExitBootServices() and the time the runtime OS boots the APs. However, if a platform includes PiSmmCpuDxeSmm, and bases the runtime

[edk2] [PATCH v2 0/4] UefiCpuPkg/CpuDxe: Fix ExitBootServices() callback in the presence of SMIs

This is version 2 of . Public branch: . As suggested by Jordan, I'll keep this at the front of my SMM-for-OVMF series. I'm posting it now for getting reviews, but I won't commit it

Re: [edk2] about the SMM_S3_RESUME_SMM_64 branch in S3Resume2Pei

On 10/28/15 23:41, Laszlo Ersek wrote: > On 10/28/15 23:26, Yao, Jiewen wrote: >> Right. It seems S3Resume2Pei does not consider X64 mode. I found at least 3 >> functions need enhancement on mode transition: >> 1) S3RestoreConfig2() - S3Resume <-> SmmCpu (DXE mode); >> 2)

Re: [edk2] [Patch] MdeModulePkg: Do not dump NULL padding resource descriptor

Reviewed-by: Feng Tian -Original Message- From: Ni, Ruiyu Sent: Wednesday, October 28, 2015 13:21 To: edk2-devel@lists.01.org Cc: Ni, Ruiyu; Tian, Feng Subject: [Patch] MdeModulePkg: Do not dump NULL padding resource descriptor Contributed-under: TianoCore