[edk2] RE uses the version information in application .EFI file: edk2-devel Digest, Vol 4, Issue 214

Liming, the reason i want to maintain the version information is so that I can deduce the version of the file by parsing the PE header, from a non-efi environment. -- Message: 7 Date: Thu, 29 Oct 2015 09:15:07 + From: "Gao, Liming" To:

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

On 10/29/15 02:32, Jordan Justen wrote: > 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

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

Hi Feng, On Thu, Oct 29, 2015 at 12:23:04AM +, Tian, Feng wrote: > Ray has sent the patch for review, you may ignore > it. (http://article.gmane.org/gmane.comp.bios.edk2.devel/3484) Yes, I see it has now been committed - which solves the known bug. But this still leaves us with a clearly

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

On 29 October 2015 at 02:30, 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] UefiCpuPkg/PiSmmCpuDxeSmm: Shouldn't use gSmst->CurrentlyExecutingCpu

Laszlo, SmmCoreEntry() is from the following code, and it is just PiSmmCore's SmmEntryPoint(). // // Invoke SMM Foundation EntryPoint with the processor information context. // gSmmCpuPrivate->SmmCoreEntry (>SmmCoreEntryContext); Yes. gSmst->CurrentlyExecutingCpu is not set in

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

On 10/29/15 02:32, Jordan Justen wrote: > 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

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Shouldn't use gSmst->CurrentlyExecutingCpu

On 10/29/15 14:17, Fan, Jeff wrote: > Laszlo, > > SmmCoreEntry() is from the following code, and it is just PiSmmCore's > SmmEntryPoint(). > // > // Invoke SMM Foundation EntryPoint with the processor information context. > // > gSmmCpuPrivate->SmmCoreEntry (>SmmCoreEntryContext); > >

Re: [edk2] about the SMM_S3_RESUME_SMM_64 branch in S3Resume2Pei

Hi Jiewen, On 10/29/15 03:28, Yao, Jiewen wrote: > 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. I think I have found the bug. (1) I added a debug patch to OvmfPkg/QuarkPort/CpuS3DataDxe. I'm

Re: [edk2] about the SMM_S3_RESUME_SMM_64 branch in S3Resume2Pei

Laszlo, Thanks for the very detailed and complete root cause on this issue. I agree that the change you suggest is functional, but I am going to recommend a different solution. Unfortunately, there are several modules that set up a GDT and it is easier from an implementation perspective and

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

On 2015-10-29 04:45:37, Laszlo Ersek wrote: > On 10/29/15 02:32, Jordan Justen wrote: > > +ASSERT (MaxProcessors > 0); > > +PcdSet32 (PcdCpuMaxLogicalProcessorNumber, MaxProcessors); > > I think that when this branch is active, then > PcdCpuApInitTimeOutInMicroSeconds should *also* be

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

On 10/29/15 19:39, Jordan Justen wrote: > On 2015-10-29 04:45:37, Laszlo Ersek wrote: >> On 10/29/15 02:32, Jordan Justen wrote: >>> +ASSERT (MaxProcessors > 0); >>> +PcdSet32 (PcdCpuMaxLogicalProcessorNumber, MaxProcessors); >> >> I think that when this branch is active, then >>

Re: [edk2] [PATCH] UefiCpuPkg: CpuDxe: Update GDT to be consistent with DxeIplPeim

On 10/29/15 21:35, Michael Kinney wrote: > The PiSmmCpuDxeSmm module makes some assumptions about GDT selectors > that are based on the GDT layout from the DxeIplPeim. This updates the > CpuDxe module to use the same GDT layout as the DxeIplPeim. > > Using a consistent GDT also improves debug

[edk2] [PATCH] UefiCpuPkg: CpuDxe: Update GDT to be consistent with DxeIplPeim

The PiSmmCpuDxeSmm module makes some assumptions about GDT selectors that are based on the GDT layout from the DxeIplPeim. This updates the CpuDxe module to use the same GDT layout as the DxeIplPeim. Using a consistent GDT also improves debug experience. Contributed-under: TianoCore

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

On 10/29/15 22:13, Laszlo Ersek wrote: > On 10/29/15 19:39, Jordan Justen wrote: >> On 2015-10-29 04:45:37, Laszlo Ersek wrote: >>> On 10/29/15 02:32, Jordan Justen wrote: +ASSERT (MaxProcessors > 0); +PcdSet32 (PcdCpuMaxLogicalProcessorNumber, MaxProcessors); >>> >>> I think

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

I agree with this fix. Reviewed-by: Jeff Fan -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael Kinney Sent: Thursday, October 29, 2015 11:19 AM To: edk2-devel@lists.01.org Subject: [edk2] [PATCH 0/2] Add API to manage

Re: [edk2] [PATCH] UefiCpuPkg: CpuDxe: Update GDT to be consistent with DxeIplPeim

comments below On 10/29/15 21:35, Michael Kinney wrote: > The PiSmmCpuDxeSmm module makes some assumptions about GDT selectors > that are based on the GDT layout from the DxeIplPeim. This updates the > CpuDxe module to use the same GDT layout as the DxeIplPeim. > > Using a consistent GDT also

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Shouldn't use gSmst->CurrentlyExecutingCpu

Laszlo, Thanks your suggestion. I will add the code in commit log. Jeff -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Thursday, October 29, 2015 10:43 PM To: Fan, Jeff; edk2-de...@ml01.01.org Cc: Kinney, Michael D Subject: Re: [edk2] [Patch]

[edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Shouldn't use gSmst->CurrentlyExecutingCpu

In ConfigSmmCodeAccessCheck(), we used gSmst->CurrentlyExecutingCpu to get the current SMM BSP. But ConfigSmmCodeAccessCheck() maybe invoked before executing SmmCoreEntry() and gSmst->CurrentlyExecutingCpu hasn't been updated to the latest value. Instead, we should use

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

It's good! Reviewed-by: Jeff Fan -Original Message- From: Justen, Jordan L Sent: Thursday, October 29, 2015 9:33 AM To: edk2-devel@lists.01.org Cc: Justen, Jordan L; Fan, Jeff; Laszlo Ersek Subject: [PATCH 1/6] UefiCpuPkg/CpuDxe: Don't use gBS->Stall The CpuDxe

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

Jordan, I think we could ASSERT() if the actually processors number is larger than maximum number supported in system. Otherwise, send broadcast SMI or IPI may break the system. Jeff -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan

Re: [edk2] [PATCH] BaseTools/GenFw: add option to retain image version info

Carl: Could you let me how you uses the version information in application .EFI file? Thanks Liming From: Miller, Carl H [mailto:carl.mil...@pnnl.gov] Sent: Wednesday, October 28, 2015 10:32 PM To: edk2-devel@lists.01.org Cc: Zhu, Yonghong; Gao, Liming Subject: [PATCH] BaseTools/GenFw: add

Re: [edk2] PATCH BaseTools/toolsetup.bat : enquote PATH reassignment

Hi Carl, May I know the detail error we would meet if we don't add the quotes ? Best Regards, Zhu Yonghong From: Miller, Carl H [mailto:carl.mil...@pnnl.gov] Sent: Wednesday, October 28, 2015 11:03 PM To: edk2-devel@lists.01.org Cc: Zhu, Yonghong; Gao, Liming Subject: PATCH

Re: [edk2] about the SMM_S3_RESUME_SMM_64 branch in S3Resume2Pei

On 10/29/15 03:28, Yao, Jiewen wrote: > 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. Right. I'll ask Paolo for help when he's back from his trip. > > For "RSM from 64-bit mode ", I have

Re: [edk2] [PATCH] OvmfPkg: increase MP services startup timeout

On 10/20/15 21:27, Laszlo Ersek wrote: > Due to Linux kernel commit b18d5431acc7 ("KVM: x86: fix CR0.CD > virtualization"), vCPUs need more time to start up, because: > > - KVM now zaps all the mappings for the guest memory in EPT or shadow page > table, hence more VM exits are required to

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

Leif, Feng, Ok I will revert the two patches I committed (big patch + small patch). But I want to clarify one thing that not every big patch can be easily understood by just splitting to small patches. Thanks, Ray -Original Message- From: Tian, Feng Sent: Friday, October 30, 2015 9:57

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

Hi Ray, Thanks for the information. However, the Status codes you mentioned in EfiBootManagerBoot() is for indicating booting a specific boot option failure rather than booting ALL boot options failure, so I can't use these Status codes for my purpose. The following two are detailed reasons: -

[edk2] [Patch 1/3] Revert "MdeModulePkg: Fix a PciBusDxe hot plug bug"

This reverts commit 73b7f115c653c807b9d0be97bf516871d8aff7ba. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni --- .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.c | 80 +-- .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.h | 13 --

[edk2] [Patch 0/3] MdeModulePkg: Fix a PciBusDxe hot plug bug

For a hot plug bridge with device attached, PciBusDxe driver reserves the resources which equal to the total amount of padding resource returned from HotPlug->GetResourcePadding() and the actual occupied resource by the attached device. The behavior is incorrect. Correct behavior is to reserve the

[edk2] [PATCH 1/2] MdeModulePkg/RegularExpressionDxe: Correct copyright

Correct copyrights in RegularExpressionDxe Signed-off-by: Cinnamon Shia --- .../Universal/RegularExpressionDxe/Oniguruma/OnigurumaIntrinsics.c | 2 +- .../Universal/RegularExpressionDxe/Oniguruma/OnigurumaUefiPort.c| 2 +-

[edk2] [PATCH 2/2] MdeModulePkg/RegularExpressionDxe: Add missing PrintLib

AsciiVSPrint is used in RegularExpressionDxe/Oniguruma/OnigurumaUefiPort.c. But PrintLib is missing in RegularExpressionDxe.inf. Signed-off-by: Cinnamon Shia --- MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf | 1 + 1 file changed, 1 insertion(+)

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

Leif, Thanks for raising this issue. I agree with you that the patch should be split to small ones and make it more readable. I also agree we should give community more time to review those big patch before getting committed in. Ray, who is the module owner, will follow up your suggestions.

[edk2] [PATCH] MdeModulePkg SmbiosMeasurementDxe: NULL check to String from GetSmbiosStringById

When StringId is not 0, String returned from GetSmbiosStringById is expected to non-NULL. Add ASSERT (String != NULL); to ensure this. Cc: Jiewen Yao Cc: Shumin Qiu Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng

Re: [edk2] [PATCH] MdeModulePkg SmbiosMeasurementDxe: NULL check to String from GetSmbiosStringById

Reviewed-by: Qiu Shumin -Original Message- From: Zeng, Star Sent: Friday, October 30, 2015 10:12 AM To: edk2-devel@lists.01.org Cc: Yao, Jiewen; Qiu, Shumin Subject: [PATCH] MdeModulePkg SmbiosMeasurementDxe: NULL check to String from GetSmbiosStringById When

Re: [edk2] [PATCH] MdeModulePkg SmbiosMeasurementDxe: NULL check to String from GetSmbiosStringById

Reviewed-by: jiewen@intel.com -Original Message- From: Zeng, Star Sent: Friday, October 30, 2015 10:12 AM To: edk2-devel@lists.01.org Cc: Yao, Jiewen; Qiu, Shumin Subject: [PATCH] MdeModulePkg SmbiosMeasurementDxe: NULL check to String from GetSmbiosStringById When StringId is not