[edk2] [PATCH v3 0/2] Report ACPI NFIT for reserved memory RAM disks

Changes compared with V2: 1. RamDiskDxe driver now will register an EFI event in the Ready To Boot Event Group to a). detect whether EFI_ACPI_TABLE_PROTOCOL and EFI_ACPI_SDT_PROTOCOL are both produced; b). publish all the reserved memory type RAM disks registered at this point to the NFIT

[edk2] [PATCH v3 2/2] OvmfPkg: Modify fdf files due to RamDiskDxe driver's adding ASL code

The RamDiskDxe driver in MdeModulePkg now will sometimes report a NVDIMM Root Device using ASL code which is put in a Secondary System Description Table (SSDT) according to the ACPI 6.1 spec. Locating the SSDT requires modifying the fdf files in OvmfPkg. Cc: Laszlo Ersek Cc:

Re: [edk2] [PATCH 1/3] MdeModulePkg: PiDxeS3BootScriptLib: honor PcdAcpiS3Enable

Reviewed by: jiewen@intel.com > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Thursday, April 28, 2016 3:21 AM > To: edk2-devel-01 > Cc: Tian, Feng ; Yao, Jiewen ; > Justen, Jordan L

Re: [edk2] [Patch 0/3] Improve Fixed-MTRR programming performance

For patch #1, I have comment: 1. the parameter name is StartMsrNum, but the parameter comment is MsrNum. 2. the algorithm is calculating the MsrNum from *StartMsrNum + 1, it seems not match the comment "The start index of the fixed MTRR MSR to program". Other looks good to me. Reviewed-by: Feng

Re: [edk2] [PATCH 0/3] OvmfPkg: tighten the SMM lockdown

On 2016/4/28 3:20, Laszlo Ersek wrote: The first patch (for MdeModulePkg) fixes a bug that is exposed (triggered) by the third patch. The second and third patches fix a security vulnerability in OVMF that I reported to the UEFI SRT more than three weeks ago: To: secur...@uefi.org,

Re: [edk2] [PATCH] MdeModulePkg/TerminalDxe: Set polling rate by serial IO mode

> On Apr 27, 2016, at 8:10 PM, Ni, Ruiyu wrote: > >> >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi >> Guo >> Sent: Saturday, April 23, 2016 4:54 PM >> To: edk2-devel@lists.01.org >> Cc: Kinney, Michael D

Re: [edk2] [PATCH] MdeModulePkg/TerminalDxe: Set polling rate by serial IO mode

>-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo >Sent: Saturday, April 23, 2016 4:54 PM >To: edk2-devel@lists.01.org >Cc: Kinney, Michael D ; Heyi Guo >; Tian, Feng

Re: [edk2] [Patch] ShellPkg: Enhance ping to select the interface automatically

Hi, Jiaxin A interface with only link local address should be allowed as the src if the dest is also an link local address, right? And the 2 if conditions in line 1052 is better to change to a "if (UnspecifiedSrc) else ..." so it's more readable. If (UnspecifiedSrc &&

Re: [edk2] [Patch] NetworkPkg: Avoid the indefinite wait case in HttpDxe

Reviewed-by: Fu Siyuan > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Jiaxin Wu > Sent: Tuesday, April 26, 2016 6:39 PM > To: edk2-devel@lists.01.org > Cc: Ye, Ting ; Zhang, Lubo

Re: [edk2] [Patch] MdeModulePkg: DxeCore MemoryPool Algorithm Update

With that update, Reviewed-by: Michael Kinney Mike From: Gao, Liming Sent: Wednesday, April 27, 2016 5:51 PM To: Ard Biesheuvel Cc: edk2-devel-01 ; Kinney, Michael D Subject: RE:

Re: [edk2] [Patch v3 02/23] OvmfPkg/PlatformPei: Add memory above 4GB as tested

Regards, Ray >-Original Message- >From: Laszlo Ersek [mailto:ler...@redhat.com] >Sent: Tuesday, April 26, 2016 5:27 AM >To: Ni, Ruiyu >Cc: edk2-de...@ml01.01.org; Justen, Jordan L >Subject: Re: [edk2] [Patch v3 02/23] OvmfPkg/PlatformPei:

Re: [edk2] [Patch] MdeModulePkg: DxeCore MemoryPool Algorithm Update

Good catch. I will update it. From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Thursday, April 28, 2016 12:05 AM To: Gao, Liming Cc: edk2-devel-01 ; Kinney, Michael D Subject: Re: [Patch] MdeModulePkg:

Re: [edk2] [PATCH 1/3] MdeModulePkg: PiDxeS3BootScriptLib: honor PcdAcpiS3Enable

thanks for the explanation. I agree that libraries must be designed for this feature from the beginning. I also know that people use libraries for purposes other than their original intent. I think it would be best to plan for this by having properly coded destructors in libraries whenever

Re: [edk2] [PATCH] ShellPkg: Fix pci command for '_e' option

Done. > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Attar, Abdul Lateef > Sent: Tuesday, April 26, 2016 3:42 AM > To: Qiu, Shumin ; Carsey, Jaben > ; Ni, Ruiyu ; edk2- >

[edk2] [PATCH] ShellPkg: Update smbiosview for latest Type 17 devices

Update smbiosview to understand latest SMBIOS Type 17 devices from SMBIOS 3.0.0 spec Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Samer El-Haj-Mahmoud --- .../SmbiosView/QueryTable.c | 21 + 1 file changed, 21

[edk2] [PATCH] [BaseTools]/Build: Better DSC arch filtering

Description: When building for any specific architecture, the build script today is loading DSC sections for other architectures not in the build. The build process should disregard DSC sections that are not relevant to the build. My previous patch only fixed issue for one section type

Re: [edk2] [PATCH 1/3] MdeModulePkg: PiDxeS3BootScriptLib: honor PcdAcpiS3Enable

Laszlo, Does the library destructor not get called? Shouldn't that destructor unregister the protocol notify and leave the callback pointer in DXE core correct? -Jaben > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Laszlo Ersek > Sent:

[edk2] [PATCH 2/3] OvmfPkg: PlatformBdsLib: lock down SMM in PlatformBdsInit()

OVMF's PlatformBdsLib currently makes SMM vulnerable to the following attack: (1) a malicious guest OS copies a UEFI driver module to the EFI system partition, (2) the OS adds the driver as a Driver option, and references it from DriverOrder, (3) at next boot, the BdsEntry()

[edk2] [PATCH 3/3] OvmfPkg: PlatformBdsLib: lock down SMM regardless of S3

At the moment, the EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is only installed if S3 is enabled -- at the end of SaveS3BootScript(). While a runtime OS is never booted with SMM unlocked (because the SMM IPL locks down SMM as a last resort: > SMM IPL! DXE SMM Ready To Lock Protocol not installed before

[edk2] [PATCH 1/3] MdeModulePkg: PiDxeS3BootScriptLib: honor PcdAcpiS3Enable

In the edk2 tree, there are currently four drivers that consume PcdAcpiS3Enable: IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe/AcpiS3SaveDxe.inf MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf

[edk2] [PATCH 0/3] OvmfPkg: tighten the SMM lockdown

The first patch (for MdeModulePkg) fixes a bug that is exposed (triggered) by the third patch. The second and third patches fix a security vulnerability in OVMF that I reported to the UEFI SRT more than three weeks ago: To: secur...@uefi.org, secal...@redhat.com [...] From: Laszlo Ersek

Re: [edk2] HMAC calculation clarification for TPM 1.2

On 04/26/2016 09:46 PM, Long, Qin wrote: > David, > > I think your original understanding should be correct. (I am not 100% sure. > Still need to double-confirm.) > For one OSAP session, > sharedSecret = HMAC(key.usageAuth, nonceEvenOSAP, nonceOddOSAP) > The shared secret will be

Re: [edk2] [PATCH] ShellPkg: Fix typos and EDK2 coding style issues

Reviewed-by: Jaben Carsey > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of El- > Haj-Mahmoud, Samer > Sent: Wednesday, April 27, 2016 8:11 AM > To: Shah, Tapan ; edk2-devel@lists.01.org > Cc: Carsey,

Re: [edk2] [PATCH] ArmPlatformPkg: implement CpuIo2 protocol driver specific for PCI

On Wed, Apr 27, 2016 at 05:48:55PM +0200, Ard Biesheuvel wrote: > >> So we can implement this protocol using MMIO operations only, and take the > >> PCI I/O translation offset into account when performing I/O port accesses. > > > > Some of these lines look a bit long? > > Will fix that Thanks.

Re: [edk2] [Patch] MdeModulePkg: DxeCore MemoryPool Algorithm Update

On 27 April 2016 at 08:40, Liming Gao wrote: > Use 128 bytes as the start size region to be same to previous one. > > 64 bytes is small as the first range. On X64 arch, POOL_OVERHEAD > takes 40 bytes, the pool data less than 24 bytes can be fit into > it. But, the real

Re: [edk2] [PATCH] MdeModulePkg/TerminalDxe: Set polling rate by serial IO mode

Heyi, 1) A couple ways to measure. a) Loop calling gBS->Stall() and counting number of stall calls between 2 periodic timer event notifications. The accuracy of the measurement depends on the granularity and accuracy of the Stall service. For your use case, using a Stall()

Re: [edk2] [PATCH] ArmPlatformPkg: implement CpuIo2 protocol driver specific for PCI

On 27 April 2016 at 17:44, Leif Lindholm wrote: > On Wed, Apr 27, 2016 at 02:58:29PM +0200, Ard Biesheuvel wrote: >> The CpuIo2 protocol is required by the generic PciHostBridgeDxe driver, >> which relies on it to back its own I/O and MMIO operations. >> >> Since ARM has

Re: [edk2] [PATCH] ArmPlatformPkg: implement CpuIo2 protocol driver specific for PCI

On 04/27/16 17:44, Leif Lindholm wrote: > On Wed, Apr 27, 2016 at 02:58:29PM +0200, Ard Biesheuvel wrote: >> The CpuIo2 protocol is required by the generic PciHostBridgeDxe driver, >> which relies on it to back its own I/O and MMIO operations. >> >> Since ARM has no native I/O port equivalent,

Re: [edk2] [PATCH] MdeModulePkg/TerminalDxe: Set polling rate by serial IO mode

Hi Michael, I still have questions about measuring timer tick by event: 1. How can we measure the time elapsed? TimerLib is not in UEFI spec, and shall we use gBS->Stall in a loop to measure the time? 2. By using a periodic timer event, I think we need to drop the 1st trigger as it is random

Re: [edk2] [PATCH] ShellPkg: Fix typos and EDK2 coding style issues

Reviewed-by: Samer El-Haj-Mahmoud -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Shah, Tapan Sent: Wednesday, April 27, 2016 9:56 AM To: edk2-devel@lists.01.org Cc: jaben.car...@intel.com Subject: [edk2] [PATCH] ShellPkg: Fix

Re: [edk2] [PATCH] ArmPlatformPkg: implement CpuIo2 protocol driver specific for PCI

On 04/27/16 14:58, Ard Biesheuvel wrote: > The CpuIo2 protocol is required by the generic PciHostBridgeDxe driver, > which relies on it to back its own I/O and MMIO operations. > > Since ARM has no native I/O port equivalent, such accesses can only originate > from PCI drivers, and the PCI I/O

Re: [edk2] [Patch] ShellPkg: Enhance ping6 to select the interface automatically

Reviewed-by: Jaben Carsey > -Original Message- > From: Wu, Jiaxin > Sent: Tuesday, April 26, 2016 6:21 PM > To: Bhupesh Sharma ; edk2-devel@lists.01.org > Cc: Carsey, Jaben ; Ye, Ting ; > Fu,

Re: [edk2] [Patch v3 11/23] OvmfPkg/PlatformBds: Initialize console variables in *BeforeConsole()

On 04/21/16 08:58, Ruiyu Ni wrote: > The major difference between IntelFrameworkModulePkg/BDS and > MdeModulePkg/BDS is the latter connects the consoles in core > code while the former connects in platform code. > The change initializes the console variables in > PlatformBootManagerBeforeConsole()

[edk2] [PATCH] ShellPkg: Fix typos and EDK2 coding style issues

Fixing typos and EDK2 coding style issues found from previous submit Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Tapan Shah --- .../UefiHandleParsingLib/UefiHandleParsingLib.c | 20 ++-- 1 file changed, 10 insertions(+), 10

Re: [edk2] [Patch v3 10/23] OvmfPkg/PlatformBds: Use ConvertDevicePathToText in DevicePathLib

On 04/21/16 08:58, Ruiyu Ni wrote: > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ruiyu Ni > Cc: Jordan Justen > Cc: Laszlo Ersek > --- > OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c

Re: [edk2] [Patch v3 09/23] OvmfPkg/PlatformBds: link to UefiBootManagerLib

On 04/21/16 08:57, Ruiyu Ni wrote: > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ruiyu Ni > Cc: Jordan Justen > Cc: Laszlo Ersek > --- > OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h

Re: [edk2] [Patch v3 08/23] OvmfPkg/PlatformBds: use EfiBootManagerUpdateConsoleVariable

On 04/21/16 08:57, Ruiyu Ni wrote: > Call EfiBootManagerUpdateConsoleVariable in UefiBootManagerLib > instead of BdsLibUpdateConsoleVariable in GenericBdsLib. > > Still cannot pass build. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ruiyu Ni >

[edk2] [PATCH] ArmPlatformPkg: implement CpuIo2 protocol driver specific for PCI

The CpuIo2 protocol is required by the generic PciHostBridgeDxe driver, which relies on it to back its own I/O and MMIO operations. Since ARM has no native I/O port equivalent, such accesses can only originate from PCI drivers, and the PCI I/O space is translated to MMIO in this case. So we can

Re: [edk2] [Patch v3 07/23] OvmfPkg/PlatformBds: Follow PlatformBootManagerLib interfaces

On 04/21/16 08:57, Ruiyu Ni wrote: > Change the function name to follow new library class > PlatformBootManagerLib interfaces. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ruiyu Ni > Cc: Jordan Justen > Cc: Laszlo

Re: [edk2] Minor problems with dualboot VM. EFIVars?

> Yes, they are /var/lib/libvirt/qemu/nvram/${vmname}_VARS.fd. So the VM is(should be) configured properly - one r/o .fd with the OVMF_CODE, one r/w .fd with vars per VM. > Your NvVars file could be very old, maybe a remnant of your earlier Will check the date, but i doubt about this. Maybe there

Re: [edk2] Minor problems with dualboot VM. EFIVars?

On 04/27/16 12:43, Blank Field wrote: >> Because your VM configuration is incorrect (you didn't configure two >> pflash chips, one for storing the UEFI variables, another (r/o) for >> presenting the firmware binary). Hence OVMF fell back to the historical >> hack where it stored (some of) the UEFI

Re: [edk2] OVMF broken under Xen (in PCI initialisation)

On 04/27/16 11:50, Ni, Ruiyu wrote: > Copying Mike. > > Regards, > Ray > >> -Original Message- >> From: Ni, Ruiyu >> Sent: Wednesday, April 27, 2016 5:49 PM >> To: 'Gary Lin' >> Cc: edk2-devel@lists.01.org; Xen Devel ; Laszlo >> Ersek

Re: [edk2] Minor problems with dualboot VM. EFIVars?

On 04/27/16 11:52, Blank Field wrote: > And i've thought that efivars on a physical platform are located > somewhere in a separate chip on the motherboard. Why i've found it on > the ESP? Because your VM configuration is incorrect (you didn't configure two pflash chips, one for storing the UEFI

Re: [edk2] [Patch v3 00/23] Use MdeModulePkg/BDS in OVMF platform

On 04/27/16 11:53, Michael Zimmermann wrote: > well all ARM targets are still using Intel's BDS and iirc this even is > the "new" one for them because previously they were using the ARM bds. Once this series converges for OvmfPkg, we intend to port ArmVirtPkg as well, using the lessons learned

Re: [edk2] Minor problems with dualboot VM. EFIVars?

>Since the ESP and the main partitions are also accessible from the host(which would be almost impossible to achieve if the VM would be stored in a file)... ...i was able to boot it bare-metal. Sorry, lost a bit of text due to small screen size on a mobile client.

Re: [edk2] [Patch v3 00/23] Use MdeModulePkg/BDS in OVMF platform

well all ARM targets are still using Intel's BDS and iirc this even is the "new" one for them because previously they were using the ARM bds. Michael On Wed, Apr 27, 2016 at 3:32 AM, Andrew Fish wrote: > > > On Apr 26, 2016, at 8:58 AM, Laszlo Ersek wrote:

Re: [edk2] Minor problems with dualboot VM. EFIVars?

> I don't know what "windows exVM" means. It is my fault not giving enough backstory, sorry. The windows system was previously installed in a VM using host disk as a storage. Since the ESP and the main partitions are also accessible from the host(which would be almost impossible to achieve if the

Re: [edk2] OVMF broken under Xen (in PCI initialisation)

Copying Mike. Regards, Ray >-Original Message- >From: Ni, Ruiyu >Sent: Wednesday, April 27, 2016 5:49 PM >To: 'Gary Lin' >Cc: edk2-devel@lists.01.org; Xen Devel ; Laszlo Ersek > >Subject: RE: [edk2] OVMF broken under Xen (in

Re: [edk2] OVMF broken under Xen (in PCI initialisation)

Gary, Thanks for the try. I now understand why the issue happens. 1. PciEnumeratorLight() depends on the MinBus returned from PciRootBridgeIo.Configuration(). 2. PciRootBridgeIo.Configuration() returns the resource descriptors initialized by

Re: [edk2] Minor problems with dualboot VM. EFIVars?

On 04/27/16 11:13, Laszlo Ersek wrote: > On 04/27/16 01:51, Blank Field wrote: >> Hi. I am attempting to rebuild my system with a host EFI bootloader, >> namely GRUB. >> I did a fresh install of F23(i've found that way easier than figuring >> out how to migrate to EFI), turned off my CSM in host

Re: [edk2] Minor problems with dualboot VM. EFIVars?

On 04/27/16 01:51, Blank Field wrote: > Hi. I am attempting to rebuild my system with a host EFI bootloader, > namely GRUB. > I did a fresh install of F23(i've found that way easier than figuring > out how to migrate to EFI), turned off my CSM in host UEFI setup, got > my windows exVM booting in

Re: [edk2] [Patch] NetworkPkg: Fix incorrect buffer free in HttpDxe

Reviewed-by: Ye Ting -Original Message- From: Wu, Jiaxin Sent: Wednesday, April 27, 2016 3:08 PM To: edk2-devel@lists.01.org Cc: Ye, Ting ; Fu, Siyuan ; Zhang, Lubo Subject: [Patch] NetworkPkg: Fix

Re: [edk2] OVMF broken under Xen (in PCI initialisation)

On Wed, Apr 27, 2016 at 07:18:21AM +, Ni, Ruiyu wrote: > Gary, > In PciEnumeratorLight(), please directly assign 0 to MinBus when > Configuration() returns error, instead of calling PciGetBusRange() to > extract MinBus from the descriptors returned from Configuration(). > OK, I ignored

[edk2] [Patch] NetworkPkg: Fix incorrect buffer free in HttpDxe

FragmentBuffer of each TcpWrap in HttpDxe should not be freed in HttpTcpTokenCleanup(). This buffer points to HttpMsg body actually, which is the responsibility of the caller to allocate a buffer for Body. Cc: Ye Ting Cc: Fu Siyuan Cc: Zhang Lubo

Re: [edk2] OVMF broken under Xen (in PCI initialisation)

On Wed, Apr 27, 2016 at 05:39:40AM +, Ni, Ruiyu wrote: > > > Regards, > Ray > > >-Original Message- > >From: Gary Lin [mailto:g...@suse.com] > >Sent: Wednesday, April 27, 2016 12:29 PM > >To: Ni, Ruiyu > >Cc: edk2-devel@lists.01.org; Xen Devel

[edk2] [Patch] MdeModulePkg: DxeCore MemoryPool Algorithm Update

Use 128 bytes as the start size region to be same to previous one. 64 bytes is small as the first range. On X64 arch, POOL_OVERHEAD takes 40 bytes, the pool data less than 24 bytes can be fit into it. But, the real allocation is few that can't reduce its free pool link list. And, the second range

Re: [edk2] [PATCH] Vlv2TbltDevicePkg: Modify DSC file to ensure PlatformPkgIA32.dsc is sync with PlatformPkgX64.dsc.

Reviewed-by: David Wei Thanks, David Intel SSG BIOS -Original Message- From: Guo, Mang Sent: Wednesday, April 27, 2016 10:38 AM To: edk2-devel@lists.01.org Cc: Wei, David Subject: [PATCH] Vlv2TbltDevicePkg: Modify DSC file to ensure