Feng,
Thanks your comments.
I will update the parameter name to LastMsrNum to match its meaning more
exactly.
@param LastMsrNum On input, the last index of the fixed MTRR MSR to program.
On return, the current fixed MTRR
MSR to program.
Thanks!
Jeff
Regards,
Ray
>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Wednesday, April 27, 2016 6:44 PM
>To: Ni, Ruiyu ; Gary Lin
>Cc: edk2-devel@lists.01.org ; Xen Devel
>; Kinney, Michael D
>
>Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
>
>On 04
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
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: Jordan Justen
Contr
The RamDiskDxe now will report RAM disks with reserved memory type to NFIT
in the ACPI table.
This commit will also make sure that an NVDIMM root device exists in the
\SB scope before reporting any RAM disk to NFIT.
To properly report the NVDIMM root device, one will need to append the
following
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 ; Ni, Ruiyu
> ; Zeng, Star
> Subject: [PATCH 1/3] MdeModulePkg: PiDxeS3
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
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, secal...@r
> 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 ; Heyi Guo
>> ; Tian, Feng
>-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 ;
>Zeng, Star
>Subject: [edk2] [PATCH] MdeModulePkg/TerminalDxe: Set p
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 && !NetIp6IsUnspecif
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 ; Fu,
> Siyuan
> Subject: [edk2] [Patch] NetworkPkg: Avoid t
Regards,
Ray
>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Tuesday, April 26, 2016 11:02 PM
>To: Ni, Ruiyu ; edk2-de...@ml01.01.org
>Cc: Justen, Jordan L
>Subject: Re: [edk2] [Patch v3 04/23] OvmfPkg/QemuNewBootOrderLib: Build with
>UefiBootManagerLib
>
>Thi
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: [Patch] MdeModulePkg: DxeCore MemoryPool Algorithm Update
Good catch. I will update it.
From: Ard Biesheuvel
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: Add memory above 4GB
>as tested
>
>On 04/21/16
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: DxeCore MemoryPool Algorithm Update
On 27 April 2016 at 08:40, Liming Gao wrote
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 po
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-
> de...@lists.01.org
> Cc: Parthasarathy, Mohan (HPE Servers) ;
> Lakshm
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 insertions(+)
d
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 (Components
On 04/27/16 21:45, Carsey, Jaben wrote:
> 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?
PiDxeS3BootScriptLib doesn't have a DESTRUCTOR at the moment.
I would prefer not a
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:
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() function
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
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
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
Su
aside:
On 04/27/16 18:40, Blank Field wrote:
>>> Your NvVars file could be very old, maybe a remnant of your earlier
>> Will check the date, but i doubt about this. Maybe there was no problem at
>> all and i just need to create a normal BootOrder entry.
> Oct 9 2015. Old. Okay.
>> Separate VARS...
>> Your NvVars file could be very old, maybe a remnant of your earlier
> Will check the date, but i doubt about this. Maybe there was no problem at
> all and i just need to create a normal BootOrder entry.
Oct 9 2015. Old. Okay.
> Separate VARS...
hvm
/usr/share/edk2.git/ovmf-x64/OVMF_CO
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 calculate
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, Jaben
> Subject: Re: [edk2] [PATCH] ShellPk
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.
>
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 allocation is few that can't
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() per
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 no native I/O port equival
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, such
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, such accesses can only originate
> from PCI drive
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 a
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 typos and EDK2 cod
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 spa
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, Siyuan
> Subject: RE: [edk2] [Patch] ShellPkg: Enhance ping6 to select the interface
> automatic
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()
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 deletions(-)
diff --git
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 | 6 +++---
> OvmfPkg/Library/PlatformBootManagerLib/PlatformBo
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 | 2 +-
> OvmfPkg/Library/PlatformBootManagerLib/PlatformBootMa
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
> Cc: Jordan Justen
>
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 i
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 Ersek
> ---
> .../Library/PlatformBootManagerLib
> 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
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
> 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 variables in a file called
> NvVars on the
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
>> Subject: RE: [edk2] OVMF broken under Xen (in PC
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 v
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 her
>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.
__
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:
> >
> > On 04/26/16 17:38, Michael Zi
> 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 V
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 PCI initialisation)
>
>Gary,
>Thanks for the try.
>
>I now und
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 PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResour
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 UE
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 pu
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 incorrect buffer free in HttpDxe
FragmentBuffer of each TcpWrap in HttpDxe should not
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 PciGetB
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().
Regards,
Ray
>-Original Message-
>From: Gary Lin [mailto:g...@suse.com]
>Sent: We
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
Contributed-under: TianoCore Contribution Agreem
64 matches
Mail list logo
