On 11 June 2018 at 07:42, Gao, Liming wrote:
> Ard:
> The function MmioRead8Internal() .. MmioWrite64Internal() miss the function
> header comments. Please add them.
>
OK
> Thanks
> Liming
>>-Original Message-
>>From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>>Sent: Monday,
The SMM version of MemoryAllocationLib allows to free memory allocated
in DXE (before EndOfDxe). This is done by checking the memory range and
calling gBS services to do real operation if the memory to free is out
of SMRAM. This would cause problem if some memory related features, like
Heap Guard,
CpuDxe driver is updated to be able to access DXE page table in SMM mode,
which means Heap Guard can get correct memory paging attributes in what
ever modes. It's not necessary to exclude SMM from detecting Heap Guard
feature support.
Change-Id: I5310e6e49a258ac7a9240e40c8c99cdb692c1e02
Cc: Star
This patch series try to fix an issue caused by trying to free memory
allocated in DXE but freed in SMM mode. This happens only if Heap
Guard feature is enabled, which needs to update page table. The root
cause is that DXE and SMM don't share the same paging configuration
but CpuDxe driver still
KVM on ARM refuses to decode load/store instructions used to perform
I/O to emulated devices, and instead relies on the exception syndrome
information to describe the operand register, access size, etc.
This is only possible for instructions that have a single input/output
register (as opposed to
Switch to the new IoLib implementation that will only use KVM
safe instructions to perform MMIO memory accesses.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
v2: split off from 1/1
ArmVirtPkg/ArmVirt.dsc.inc | 2 +-
1 file changed, 1 insertion(+), 1
On 10 June 2018 at 21:21, Yao, Jiewen wrote:
> Just got some idea since I am also reviewing FmpDevicePkg patch.
>
>
> The key problem we are trying to resolve that is: The core code uses EndOfDxe
> as the lock event for system firmware, but an ARM platform may want to lock
> system firmware
Run dp command now:
Firstly it will get performance records from FPDT and then
parse the DP command. And if encounter invalid parameters,
it will exit directly. Thus the performance records got before
are invalid. And what's worse is that the memory allocated in
getting performance records phase
Ard:
Do you mean the default GCC compiler disables PIC and PIE for IA32 arch? But
now, some distribution GCC compiler enables PIC and PIE by default. So, we have
to obviously disable PIC and PIE in tools_def.txt.
Thanks
Liming
>-Original Message-
>From: Ard Biesheuvel
EFI_CALCULATE_CRC32() just calculate the crc for the given address and
size.
my question is whether PEI *code *is loaded into the RAM or not.
if it doesn't which seems reasonable, how can i reach it? some interface
for accessing the whole flash data.
Thanks,
On Mon, Jun 11, 2018 at 5:34 AM
Hi Ard,
After a quick check on the behavior of other storage device drivers, it seems
to me that they are not using the same debug levels for this kind of debug
message:
ATA and USB mass storage - BLKIO
NVM Express - VERBOSE
SD/eMMC - INFO
SCSI - actually no such debug message
My preference is
Reviewed-by: Yonghong Zhu
Best Regards,
Zhu Yonghong
-Original Message-
From: Lin, Derek (HPS UEFI Dev) [mailto:derek.l...@hpe.com]
Sent: Wednesday, May 09, 2018 5:03 PM
To: edk2-devel@lists.01.org
Cc: Zhu, Yonghong ; Lin, Derek (HPS UEFI Dev)
Subject: [PATCH] BaseTools: Remove dsc
On 11 June 2018 at 10:38, Gao, Liming wrote:
> Ard:
> Do you mean the default GCC compiler disables PIC and PIE for IA32 arch?
> But now, some distribution GCC compiler enables PIC and PIE by default. So,
> we have to obviously disable PIC and PIE in tools_def.txt.
>
Yes. On my x86 Ubuntu
On 11 June 2018 at 10:38, Wu, Hao A wrote:
> Hi Ard,
>
> After a quick check on the behavior of other storage device drivers, it seems
> to me that they are not using the same debug levels for this kind of debug
> message:
>
> ATA and USB mass storage - BLKIO
> NVM Express - VERBOSE
> SD/eMMC -
Let's go to use DEBUG_BLKIO to be consistent.
Ard, Reviewed-by: Star Zeng .
Hao, you can submit ticket on bugzilla and submit patch for NvmExpressDxe.
Thanks,
Star
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Monday, June 11, 2018 4:54 PM
To: Wu, Hao
On 06/11/18 09:42, Ard Biesheuvel wrote:
> As a security measure, some distros now build their GCC toolchains with
> PIE code generation enabled by default, because it is a prerequisite
> for ASLR to be enabled when running the executable.
>
> This typically results in slightly larger code, but
On 11 June 2018 at 11:12, Zeng, Star wrote:
> Let's go to use DEBUG_BLKIO to be consistent.
>
> Ard, Reviewed-by: Star Zeng .
> Hao, you can submit ticket on bugzilla and submit patch for NvmExpressDxe.
>
Thanks all
Pushed as 9dca2105ad96
> -Original Message-
> From: Ard Biesheuvel
Hello Younas,
On 06/11/18 09:17, Mohammad Younas Khan Pathan wrote:
> Hi all,
>
> Please find the differences updated below, review and share your comments:
(1) Please submit the patch according to the edk2 development process.
On 06/11/18 11:47, Laszlo Ersek wrote:
> On 06/11/18 09:17, Mohammad Younas Khan Pathan wrote:
> (4) Please split the patch to one patch per top-level directory. For
> example, you should have a separate patch for OvmfPkg.
This is required by our development workflow, but it's also required for
Hello Udit,
Apologies for not bringing this up the first time, but I have some
additional comments. The first time around, I only had a cursory look
because at that point I was still skeptical whether we needed this
library in the first place.
On 5 June 2018 at 19:59, Udit Kumar wrote:
> Some
On 5 June 2018 at 19:59, Udit Kumar wrote:
> This patch includes, PL011UartClock lib.
>
> In case of no implemenation of this Clock Lib,
> Pcd value will be used for PL011 frequency.
>
Please improve the commit log. You are modifying the code to obtain
the PL011 baud clock frequency from a
On 5 June 2018 at 20:00, Udit Kumar wrote:
> [v2]
> Updated name of clock lib
>
Please add a commit log
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Meenakshi Aggarwal
> ---
> Platform/AMD/OverdriveBoard/OverdriveBoard.dsc | 1 +
>
Thanks Ard
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, June 11, 2018 3:37 PM
> To: Udit Kumar
> Cc: Leif Lindholm ; edk2-devel@lists.01.org
> Subject: Re: [PATCH 2/2] ArmPlatformPkg: Include PL011UartClock Lib
>
> On 5 June 2018 at
Thanks for review Ard.
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, June 11, 2018 3:35 PM
> To: Udit Kumar
> Cc: Leif Lindholm ; edk2-devel@lists.01.org
> Subject: Re: [PATCH 1/2] ArmPlatformPkg: PL011 Dynamic clock freq
> Support
>
>
On 06/11/18 09:25, Ard Biesheuvel wrote:
> KVM on ARM refuses to decode load/store instructions used to perform
> I/O to emulated devices, and instead relies on the exception syndrome
> information to describe the operand register, access size, etc.
> This is only possible for instructions that
Marcin,
I am a bit reluctant to review another huge set of Armada patches
while we are still waiting for MacchiatoBin support to land. The only
hardware i have access to is MacchiatoBin, and it has been well over a
year now that MacchiatoBin support has been between 'under
construction' and
Hi Ard,
2018-06-11 13:00 GMT+02:00 Ard Biesheuvel :
> Marcin,
>
> I am a bit reluctant to review another huge set of Armada patches
> while we are still waiting for MacchiatoBin support to land. The only
> hardware i have access to is MacchiatoBin, and it has been well over a
> year now that
On 11 June 2018 at 13:49, Marcin Wojtas wrote:
> Hi Ard,
>
> 2018-06-11 13:00 GMT+02:00 Ard Biesheuvel :
>> Marcin,
>>
>> I am a bit reluctant to review another huge set of Armada patches
>> while we are still waiting for MacchiatoBin support to land. The only
>> hardware i have access to is
Hi Ard,
2018-06-11 14:01 GMT+02:00 Ard Biesheuvel :
> On 11 June 2018 at 13:49, Marcin Wojtas wrote:
>> Hi Ard,
>>
>> 2018-06-11 13:00 GMT+02:00 Ard Biesheuvel :
>>> Marcin,
>>>
>>> I am a bit reluctant to review another huge set of Armada patches
>>> while we are still waiting for MacchiatoBin
Hi Jian,
On 06/11/18 09:08, Jian J Wang wrote:
> The SMM version of MemoryAllocationLib allows to free memory allocated
> in DXE (before EndOfDxe). This is done by checking the memory range and
> calling gBS services to do real operation if the memory to free is out
> of SMRAM. This would cause
If all fmp can be processed one time，you just need call once. Then system reset.
thank you!
Yao, Jiewen
> 在 2018年6月11日，上午12:27，Ard Biesheuvel 写道：
>
>> On 10 June 2018 at 21:21, Yao, Jiewen wrote:
>> Just got some idea since I am also reviewing FmpDevicePkg patch.
>>
>>
>> The key problem
On 11 June 2018 at 14:37, Yao, Jiewen wrote:
> If all fmp can be processed one time，you just need call once. Then system
> reset.
>
I understand that. But if the capsule has embedded drivers, the
library will only dispatch them on the second call, even if the
platform does not require making
Hi Gerd,
On 06/08/18 13:39, Gerd Hoffmann wrote:
> Add GUID header file for the QemuRamfbDxe driver.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Gerd Hoffmann
> ---
> OvmfPkg/Include/Guid/QemuRamfb.h | 25 +
> OvmfPkg/OvmfPkg.dec
Ah. Good point.
I think the embedded driver dispatch can be controlled by EndOfDxe, which is
similar to MdeModulePkg\Universal\SecurityStubDxe.
So we can have both EndOfDxe and PcdSystemFmpLockEventGuid.
EndOfDxe controls embedded driver dispatch.
PcdSystemFmpLockEventGuid controls 1st call and
On 11 June 2018 at 15:55, Yao, Jiewen wrote:
> Ah. Good point.
>
> I think the embedded driver dispatch can be controlled by EndOfDxe, which is
> similar to MdeModulePkg\Universal\SecurityStubDxe.
>
> So we can have both EndOfDxe and PcdSystemFmpLockEventGuid.
> EndOfDxe controls embedded driver
Jiewen,
A platform can have multiple FMP protocols to
update system firmware and may be mapped to
different FW storage devices with different
security attributes. I think your proposal
would treat them all the same. Right?
Mike
> -Original Message-
> From: Yao, Jiewen
> Sent: Monday,
Reviewed-by: Liming Gao
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
> Biesheuvel
> Sent: Monday, June 11, 2018 3:26 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; ler...@redhat.com; Gao,
> Liming ;
>
On 06/08/18 13:39, Gerd Hoffmann wrote:
> diff --git a/OvmfPkg/QemuRamfbDxe/QemuRamfb.c
> b/OvmfPkg/QemuRamfbDxe/QemuRamfb.c
> new file mode 100644
> index 00..f04a314c24
> --- /dev/null
> +++ b/OvmfPkg/QemuRamfbDxe/QemuRamfb.c
> @@ -0,0 +1,308 @@
> +#include
(1) I think we should be
On 11 June 2018 at 12:44, Laszlo Ersek wrote:
> On 06/11/18 09:25, Ard Biesheuvel wrote:
>> Switch to the new IoLib implementation that will only use KVM
>> safe instructions to perform MMIO memory accesses.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard
On 11 June 2018 at 17:51, Gao, Liming wrote:
> Reviewed-by: Liming Gao
>
Pushed as 4134f2bddcb68d2e20ed000cdf54abf3f1140904
Thanks all
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
>> Biesheuvel
>> Sent: Monday, June 11, 2018 3:26
Ard:
GCC49 tool chain can be used by GCC4.9 and above compiler. It provides the
GCC setting without LTO. GCC5 tool chain provides GCC setting with LTO. So, I
suggest to disable it also in GCC49 tool chain.
Thanks
Liming
> -Original Message-
> From: Ard Biesheuvel
On 06/08/18 13:39, Gerd Hoffmann wrote:
> Add QemuRamfbDxe device path to the list of platform console devices,
> so ConSplitter will pick up the device even though it isn't a PCI GPU.
This explanation is not wrong, but I'll list more details, just in case.
By adding the devpath to
On 11 June 2018 at 18:09, Gao, Liming wrote:
> Ard:
> GCC49 tool chain can be used by GCC4.9 and above compiler. It provides the
> GCC setting without LTO. GCC5 tool chain provides GCC setting with LTO. So, I
> suggest to disable it also in GCC49 tool chain.
>
OK that works for me.
>>
As a security measure, some distros now build their GCC toolchains with
PIE code generation enabled by default, because it is a prerequisite
for ASLR to be enabled when running the executable.
This typically results in slightly larger code, but it also generates
ELF relocations that our tooling
On 06/08/18 13:39, Gerd Hoffmann wrote:
> Build wireup for ArmVirt.
Ard requested earlier that we include the meaning of the subject line in
the body of the commit message as well, so that the commit message can
be sensibly read without looking at the subject line.
With a bit more elaboration
Reviewed-by: Yonghong Zhu
Best Regards,
Zhu Yonghong
-Original Message-
From: Kinney, Michael D
Sent: Saturday, June 09, 2018 2:15 PM
To: edk2-devel@lists.01.org
Cc: Sun, Yanyan ; Zhu, Yonghong ;
Gao, Liming ; Kinney, Michael D
Subject: [Patch 0/5] BaseTools/BinToPcd: Multiple
Sorry, fix typo.
DXE > (SMM communcation) > InSmm = TRUE > SMM driver dispatcher/SMM handler >
InSmm = FALSE > (exit SMM communication) > DXE
-Original Message-
From: Zeng, Star
Sent: Tuesday, June 12, 2018 11:35 AM
To: Laszlo Ersek ; Wang, Jian J ;
edk2-devel@lists.01.org
Cc: Ni,
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=980
Adjust the DEBUG prints within function:
NvmeRead(), NvmeWrite(), AsyncNvmeRead() and AsyncNvmeWrite()
to DEBUG_BLKIO for the consistency with other storage device drivers
(e.g. ATA, USB and etc.).
Cc: Ard Biesheuvel
Cc: Star Zeng
Cc:
For the SdDxe and NvmExpressDxe drivers, adjust the level of I/O
information related DEBUG prints to DEBUG_BLKIO.
Cc: Ard Biesheuvel
Cc: Star Zeng
Cc: Eric Dong
Hao Wu (2):
MdeModulePkg/NvmExpressDxe: Adjust R/W DEBUG prints to BLKIO level
MdeModulePkg/SdDxe: Demote DEBUG print to
Reviewed-by: Liming Gao
> -Original Message-
> From: Bi, Dandan
> Sent: Monday, June 11, 2018 4:32 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Ni, Ruiyu ;
> Carsey, Jaben
> Subject: [patch V2 3/3] ShellPkg/Dp: Make the help info align with code
>
> Currently in DP, the Trace
Ard,
What about memory init when the memory HOBs are
created. Could you flush all the ranges of
initialized memory by HOB as the HOBs are created?
PEI and DXE can not use memory not described by
the HOBs. More memory can be added in DXE phase
through the GCD services, and additional flush
Tested-by: Michael D Kinney
Mike
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Yonghong Zhu
> Sent: Monday, June 11, 2018 6:01 PM
> To: edk2-devel@lists.01.org
> Cc: Feng, YunhuaX ; Gao, Liming
>
> Subject: [edk2] [Patch] BaseTools:
From: Yunhua Feng
The case is DSC file include file1, file1 include file2, after parse
file2 finished, DSC parser get the wrong section type, then it would
report invalid error.
Cc: Liming Gao
Cc: Yonghong Zhu
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng
Reviewed-by: Star Zeng
-Original Message-
From: Wu, Hao A
Sent: Tuesday, June 12, 2018 11:37 AM
To: edk2-devel@lists.01.org
Cc: Wu, Hao A ; Ard Biesheuvel ;
Zeng, Star ; Dong, Eric
Subject: [PATCH 1/2] MdeModulePkg/NvmExpressDxe: Adjust R/W DEBUG prints to
BLKIO level
"to DEBUG_INFO" should be "DEBUG_BLKIO".
With that updated, Reviewed-by: Star Zeng
-Original Message-
From: Wu, Hao A
Sent: Tuesday, June 12, 2018 11:37 AM
To: edk2-devel@lists.01.org
Cc: Wu, Hao A ; Ard Biesheuvel ;
Zeng, Star ; Dong, Eric
Subject: [PATCH 2/2] MdeModulePkg/SdDxe:
Reviewed-by: Liming Gao
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, June 12, 2018 12:29 AM
> To: edk2-devel@lists.01.org
> Cc: ler...@redhat.com; Gao, Liming ; Zhu, Yonghong
> ; Ard Biesheuvel
>
> Subject: [PATCH v2]
Yes, BZ 980 was filed, and I will propose a patch for it.
Best Regards,
Hao Wu
> -Original Message-
> From: Zeng, Star
> Sent: Monday, June 11, 2018 5:13 PM
> To: Ard Biesheuvel; Wu, Hao A
> Cc: edk2-devel@lists.01.org; Laszlo Ersek; Zeng, Star
> Subject: RE: [edk2] [PATCH]
Hi Laszlo,
Thank you very much for such thorough review. I'd like to explain a bit in
advance.
Putting aside the specific coding issues in my patch, one thing is clear that
SMM mode
has its own page table. CpuDxe should not touch it even if its public interface
is called
via gBS services,
Share some information here according to my knowledge.
The EFI_SMM_BASE2_PROTOCOL.InSmm definition in PI spec is really very
confusion. The naming for it are not consistent.
The interface name: In*Smm*
The typedef name of InSmm: EFI_*SMM_INSIDE_OUT*2
The second parameter name of InSmm: In*Smram*
I need to reach the pre memory code. Is it also loaded to the RAM(even
though it is already been executed?)
On Mon, 11 Jun 2018, 18:44 Gao, Liming, wrote:
> In pre memory, PEI code run in flash. After memory is ready, PEI code will
> be loaded into memory. There is no interface to access the
Thanks for the catch. I will update the commit log when pushing this change.
Best Regards,
Hao Wu
> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, June 12, 2018 1:07 PM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Ard Biesheuvel; Dong, Eric; Zeng, Star
> Subject: RE: [PATCH
On 06/11/18 18:24, Laszlo Ersek wrote:
> On 06/08/18 13:39, Gerd Hoffmann wrote:
>> Add QemuRamfbDxe device path to the list of platform console devices,
>> so ConSplitter will pick up the device even though it isn't a PCI GPU.
>
> This explanation is not wrong, but I'll list more details, just
From: Michael D Kinney
Stack overflows were observed at the default SMM stack
size of 8 KB. Increase stack size to 16 KB to prevent
SMM stack overflows.
Cc: David Wei
Cc: Mang Guo
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney
---
On 06/08/18 13:39, Gerd Hoffmann wrote:
> This is the efi driver for qemu ramfb, a simple boot framebuffer.
> Qemu patches just have been posted to qemu-devel.
>
> Gerd Hoffmann (4):
> OvmfPkg: add QEMU_RAMFB_GUID
> OvmfPkg: add QemuRamfbDxe
> OvmfPkg: add QemuRamfb to platform console
>
On 06/11/18 18:29, Ard Biesheuvel wrote:
> As a security measure, some distros now build their GCC toolchains with
> PIE code generation enabled by default, because it is a prerequisite
> for ASLR to be enabled when running the executable.
>
> This typically results in slightly larger code, but
On 8 June 2018 at 08:58, Ard Biesheuvel wrote:
> When capsule updates are staged for processing after a warm reboot,
> they are copied into memory with the MMU and caches enabled. When
> the capsule PEI gets around to coalescing the capsule, the MMU and
> caches may still be disabled, and so on
Hi Ard
May I suggest that we split the Capsule Dispatch patch from the cache
maintenance patch?
I think the former may require more time for design discussion.
Thank you
Yao Jiewen
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, June 11,
On 11 June 2018 at 23:27, Yao, Jiewen wrote:
> Hi Ard
> May I suggest that we split the Capsule Dispatch patch from the cache
> maintenance patch?
>
> I think the former may require more time for design discussion.
>
Yes, that is fine. As I explained, it has mainly to do with
dispatching the
Hi Ard,
I would still prefer the cache maintenance be done independent
of capsules in case there is other memory ranges that need to
be flushed for other features.
The CacheMaintenanceLib for ARM has several services that are
not implemented and ASSERT(). I found some ARM documentation
that
On 11 June 2018 at 23:40, Kinney, Michael D wrote:
> Hi Ard,
>
> I would still prefer the cache maintenance be done independent
> of capsules in case there is other memory ranges that need to
> be flushed for other features.
>
> The CacheMaintenanceLib for ARM has several services that are
> not
70 matches
Mail list logo
