From: zhijufan
Fix a regression issue caused by ac4578af364, when there doesn't exist
not used PCD, it also display the not used Pcd section in the report.
Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=1170
Cc: Liming Gao
Cc: Yonghong Zhu
Contributed-under: TianoCore Contribution
I checked the UEFI shell implementation. It uses below:
//
// If this is not a multi-function device, we can leave the
loop
// to deal with the next device.
//
if (Func == 0 && ((PciHeader.HeaderType &
On 13 September 2018 at 02:47, Shi, Steven wrote:
> Hi Ard,
> Just my curious, are you supporting the below idea of QEMU in UEFI?
>
> QEMU in UEFI - Alexander Graf
> https://www.youtube.com/watch?v=uxvAH1Q4Mx0
> http://events17.linuxfoundation.org/sites/events/files/slides/QEMU%20in%20UEFI.pdf
>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Guo Mang
---
Vlv2TbltDevicePkg/BiosId.env | 2 +-
Vlv2TbltDevicePkg/BiosIdD.env| 2 +-
Vlv2TbltDevicePkg/BiosIdR.env| 2 +-
Vlv2TbltDevicePkg/BiosIdx64D.env | 2 +-
Vlv2TbltDevicePkg/BiosIdx64R.env | 2 +-
5
Correct one field of UUID.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Guo Mang
CC: David Wei
---
.../SmBiosMiscDxe/MiscSystemManufacturerFunction.c | 30 ++
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git
On 9/13/2018 10:10 AM, Star Zeng wrote:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1169
PCI spec:
They are also required to always implement function 0 in the device.
Implementing other functions is optional and may be assigned in any
order (i.e., a two-function device must respond to
Reviewed-by: Ruiyu Ni
Thanks/Ray
> -Original Message-
> From: edk2-devel On Behalf Of
> Robinson, Herbie
> Sent: Friday, September 7, 2018 8:07 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH 1/1] FatPkg/EnhancedFatDxe Fix Double Cluster
> Allocation
>
> This is a fix for a
Leo,
Sorry I was in leave yesterday so didn't see the mail.
Which MSRs are shared? Only the MSR_IA32_MTRR_DEF_TYPE_REGISTER?
Or all the MSRs that configures the CPU MTRR setting?
I also agree with Laszlo's comments to fix the caller if all MSRs relating to
MTRR are shared.
That will be to fix
Reviewed-by: Ye Ting
-Original Message-
From: Wu, Jiaxin
Sent: Tuesday, September 4, 2018 3:17 PM
To: edk2-devel@lists.01.org
Cc: Stephen Benjamin ; Laszlo Ersek ;
Ye, Ting ; Fu, Siyuan ; Wu, Jiaxin
Subject: [Patch] MdeModulePkg/Library/DxeHttpLib: Handle the blank value in
HTTP
Reviewed-by: Ruiyu Ni
Thanks/Ray
> -Original Message-
> From: Bi, Dandan
> Sent: Monday, September 10, 2018 3:12 PM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan ; Ni, Ruiyu ; Zeng,
> Star
> Subject: [patch 3/3] MdeModulePkg: Avoid key notification called more than
> once
>
> From:
Reviewed-by: Ruiyu Ni
Thanks/Ray
> -Original Message-
> From: Bi, Dandan
> Sent: Monday, September 10, 2018 3:12 PM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan ; Ni, Ruiyu ; Ard
> Biesheuvel ; Leif Lindholm
>
> Subject: [patch 1/3] EmbeddedPkg/VirtualKeyboard: Avoid notification
Reviewed-by: Ruiyu Ni
Thanks/Ray
> -Original Message-
> From: Bi, Dandan
> Sent: Monday, September 10, 2018 3:12 PM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan ; Ni, Ruiyu ; Gao,
> Liming
> Subject: [patch 2/3] IntelFrameworkModulePkg: Avoid key notification called
> more than once
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1169
PCI spec:
They are also required to always implement function 0 in the device.
Implementing other functions is optional and may be assigned in any
order (i.e., a two-function device must respond to function 0 but
can choose any of the other
Reviewed-by: Yonghong Zhu
Best Regards,
Zhu Yonghong
-Original Message-
From: Carsey, Jaben
Sent: Tuesday, September 11, 2018 6:16 AM
To: edk2-devel@lists.01.org
Cc: Zhu, Yonghong ; Gao, Liming
Subject: [PATCH v1 1/1] BaseTools\GenFds: remove extra content
remove uncalled functions
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunshan Tu
---
.../Common/Features/UsbDeviceDxe/XdciDWC.c | 12 ++--
.../PeiFspPolicyInitLib/PeiFspCpuPolicyInitLib.c | 1 +
.../PlatformBootManagerLib/PlatformBootManager.c | 2 ++
Reviewed-by: Yonghong Zhu
Best Regards,
Zhu Yonghong
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yonghong
Zhu
Sent: Wednesday, September 12, 2018 9:50 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming
Subject: [edk2] [Patch] BaseTools: Align
Hi Ard,
Just my curious, are you supporting the below idea of QEMU in UEFI?
QEMU in UEFI - Alexander Graf
https://www.youtube.com/watch?v=uxvAH1Q4Mx0
http://events17.linuxfoundation.org/sites/events/files/slides/QEMU%20in%20UEFI.pdf
Steven Shi
Intel\SSG\STO\UEFI Firmware
Tel: +86 021-61166522
Laszlo,
> My understanding has been that it's not about enabling/disabling a CPU
> feature, but about marking specific pages as non-executable. Under that
> interpretation, it should be possible to mark pages used for stack
> purposes as non-executable, and leave everything else executable, even
On 09/12/18 17:42, Gao, Liming wrote:
> Laszlo:
> Before commit e21e355e2ca7fefb15b4df7078f995d3fb9c2b89, jmp _SmiHandler is
> commented. And below code, ASM_PFX(CpuSmmDebugEntry) is moved into rax, then
> call it. But, this code doesn't work in XCODE5 tool chain. Like you say,
> XCODE5
I like this approach too
Vincent
> On Sep 12, 2018, at 5:48 PM, Carsey, Jaben wrote:
>
> Reviewed-by: Jaben Carsey
>
> Code looks good to me.
>
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Ard Biesheuvel
>> Sent: Wednesday,
> -Original Message-
> From: Laszlo Ersek
> Sent: Wednesday, September 12, 2018 12:59 PM
> To: Duran, Leo ; edk2-devel@lists.01.org
> Cc: Eric Dong ; Ruiyu Ni
> Subject: Re: [PATCH] UefiCpuPkg/MtrrLib: Add flag to skip disabling MTRRs
> prior to MTRR change.
>
> On 09/12/18 17:17,
On 09/12/18 17:17, Duran, Leo wrote:
> Laszlo, et al,
>
> Perhaps it would be best if I provide an example of the problem I'm trying to
> solve, and perhaps we may chime in with suggestions.
>
> Again,
> The fundamental issue has to do with shared MTRR control by set of threads
> within a core
Laszlo, et al,
Perhaps it would be best if I provide an example of the problem I'm trying to
solve, and perhaps we may chime in with suggestions.
Again,
The fundamental issue has to do with shared MTRR control by set of threads
within a core with SMT enabled.
So ideally only one thread (the
Liming,
Your analysis is correct. In the end there will be 2.
Mike
> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, September 12, 2018 8:08 AM
> To: Kinney, Michael D ; Ni,
> Ruiyu ; 'edk2-devel@lists.01.org'
>
> Cc: Yao, Jiewen
> Subject: RE: [PATCH]
On 12 September 2018 at 17:07, Carsey, Jaben wrote:
> Ard,
>
> What happens when more than one emulators want to co-exist?
>
The protocol does not support that at the moment, and it is doubtful
that it would work in practice: the X86-on-AARCH64 emulator works by
mapping the X86 PE/COFF code
Ard,
I think there may be a lot of assumptions in this
proposal that are not documented.
I do not see any description of how an image is
started or how calls between native code and emulated
code are handled.
Also, are multiple emulated CPUs supported? It looks
like there can only be one
Mike:
For this case InternalSyncDecrement, there are three implementations in
SynchronizationLib library.
One is C inline assembly for GCC, another is intrinsic function for MSFT, last
one is nasm implementation for INTEL compiler. We would like to keep one
implementation. If intrinsic one
Ard,
What happens when more than one emulators want to co-exist?
-Jaben
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ard Biesheuvel
> Sent: Wednesday, September 12, 2018 7:57 AM
> To: Gao, Liming
> Cc: Ni, Ruiyu ; Zimmer, Vincent
> ;
On 12 September 2018 at 02:55, Ni, Ruiyu wrote:
>
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
>> Biesheuvel
>> Sent: Wednesday, September 12, 2018 5:03 AM
>> To: Ni, Ruiyu
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: [edk2]
On 12 September 2018 at 16:55, Gao, Liming wrote:
> Ard:
> What's purpose to run the not native image in emulator? And, what should be
> done in the emulator driver, such as X64Emulator? Is the emulator responsible
> to translate the instruction between the different arch? I see X64Emualtor
Ard:
What's purpose to run the not native image in emulator? And, what should be
done in the emulator driver, such as X64Emulator? Is the emulator responsible
to translate the instruction between the different arch? I see X64Emualtor
bases on qemu code.
Thanks
Liming
> -Original
Ray,
Yes. This provides best size with optimizations enabled.
Mike
> -Original Message-
> From: Ni, Ruiyu
> Sent: Tuesday, September 11, 2018 7:16 PM
> To: Ni, Ruiyu ; Kinney, Michael D
> ; 'edk2-devel@lists.01.org'
>
> Cc: Yao, Jiewen ; Gao, Liming
>
> Subject: RE: [PATCH]
Reviewed-by: Liming Gao
> -Original Message-
> From: Zhu, Yonghong
> Sent: Wednesday, September 12, 2018 8:45 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Kinney, Michael D
> ; Shaw, Kevin W
> Subject: [Patch V2] INF spec: Correct some items in the Table 1 EDK II
> [Defines]
On 09/12/18 07:13, Liming Gao wrote:
> 1. Remove jmp _SmiHandler, and run the code at the same position.
> 2. Fix up the function call address as the absolute address.
> Verify OVMF SMM boot to shell with VS2017, GCC5 and XCODE5 tool chain.
>
> Contributed-under: TianoCore Contribution Agreement
When encountering PE/COFF images that cannot be supported natively,
attempt to locate an instance of the PE/COFF image emulator protocol,
and if it supports the image, proceed with loading it and register it
with the emulator.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by:
Add the basic plumbing to DXE core, the PCI bus driver and the boot manager
to allow PE/COFF images to be dispatched that target an architecture that is
not native for the platform, but which is supported by an emulator.
One implementation of such an emulator can be found here:
When enumerating option ROM images, take into account whether an emulator
exists that would allow dispatch of PE/COFF images built for foreign
architectures.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
Allow PE/COFF images that must execute under emulation for Driver
options, by relaxing the machine type check to include support for
machine types that is provided by the emulator.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Introduce a protocol that can be invoked by the image loading services
to execute foreign architecture PE/COFF images via an emulator.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
MdeModulePkg/Include/Protocol/PeCoffImageEmulator.h | 51
V2: list the updated items
Remove 'EDK_RELEASE_VERSION', 'DEFINE'
Add 'PCI_REVISION'
Update 'VERSION_STRING''s required attrubute in the table to Optional.
Update 'LIBRARY_CLASS' and UEFI PCI Option ROM's value in the table per 3.4
section
Update the table's format because current in the PDF
On 09/12/18 04:11, Wang, Jian J wrote:
> Hi Laszlo and Ard,
>
> Retiring the PcdSetNxForStack is not the intention of this patch series. It's
> just
> a side effect of solving problem stated in BZ#1116. Sorry again for the
> misleading
> title. I'm not insisting that we have to remove this PCD
On 09/12/18 02:49, Wang, Jian J wrote:
> Laszlo,
>
> Thanks for the comments.
>
>
> (1)Agree. It’ll be updated in v2.
>
> (2)DEBUG_ERROR level won’t print word “ERROR” on console. I think an
> “ERROR”
>
> word in log should get the attention more easily.
>
> (3)How about log
On 09/12/18 02:32, Wang, Jian J wrote:
> Laszlo,
>
> Thanks for the comment. I think it’ll ok to add it in a separate patch.
>
> Just a little confuse about “a separate patch”. Does it mean a separate patch
> file
> in the same patch series or a separate patch which needs a separate BZ
>
On 09/11/18 21:47, Duran, Leo wrote:
>
>
>> -Original Message-
>> From: Laszlo Ersek
>> Sent: Tuesday, September 11, 2018 1:50 PM
>> To: Duran, Leo ; edk2-devel@lists.01.org
>> Cc: Eric Dong ; Ruiyu Ni
>> Subject: Re: [PATCH] UefiCpuPkg/MtrrLib: Add flag to skip disabling MTRRs
>>
For structure Pcd, the latter full assign value in commandLine should
override the former field assign value. For example in commandLine,
build --pcd Token.pcd.field="haha" --pcd Token.pcd=H"{0x01,0x02}",
the former field value "haha" will be ignored and overwrite by the latter
full value
Reviewed-by: Fu Siyuan
> -Original Message-
> From: Wu, Jiaxin
> Sent: Tuesday, September 4, 2018 3:17 PM
> To: edk2-devel@lists.01.org
> Cc: Stephen Benjamin ; Laszlo Ersek
> ; Ye, Ting ; Fu, Siyuan
> ; Wu, Jiaxin
> Subject: [Patch] MdeModulePkg/Library/DxeHttpLib: Handle the blank
Reviewed-by: Fu Siyuan
> -Original Message-
> From: Wu, Jiaxin
> Sent: Tuesday, September 4, 2018 3:38 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin
> Subject: [Patch v2] MdeModulePkg/Ip4Dxe: Sync the direct route entry
> setting.
>
> v2: use "IP &
V2:
1. Add comments for each ASSERT.
2. ASSERT need to skip the case of array size of array as zero. For
example, TestArray[] in struct in header file.
V1:
For structure PCD,
1. use compiler time assert to check the array index, report error
if the buffer overflow happens.
2. use compiler time
Zhiqiang:
I have two comments.
1. Please update commit title with the detail message.
2. Please update the patch to skip the case of file size as zero, and also add
comments for each ASSERT.
Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
Hi,
So far there was one minor remark from Ard (about macro definition) - I
would appreciate any comments before I can submit v3.
Thanks,
Marcin
pt., 7 wrz 2018 o 13:04 Ard Biesheuvel
napisał(a):
> +Hao
>
> On 7 September 2018 at 11:10, Marcin Wojtas wrote:
> > Hi,
> >
> > Answering the
On Mon, 27 Aug 2018 at 17:20, Sumit Garg wrote:
>
> Changes in v2:
> 1. Separate patch for MdePkg/Include/IndustryStandard/GlobalPlatform.h.
> 2. Correct comments style for struct members.
> 3. Update commit message.
>
> Sumit Garg (2):
> MdePkg/IndustryStandard: Add Global Plaform header file
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: xianhu2x
---
.../Common/PlatformSettings/PlatformSetupDxe/Cpu.vfi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
Disable the fourth PCIE port for UP2 board because it caused Yocto S3 failure.
It is a temporary solution of platform.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Guo Mang
CC: David Wei
---
Platform/BroxtonPlatformPkg/Board/UP2/BoardInitPostMem/BoardInit.c | 5
Thank you!
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, September 12, 2018 1:14 PM
> To: edk2-devel@lists.01.org
> Cc: Laszlo Ersek ; Dong, Eric ;
> Yao, Jiewen
> Subject: [Patch] UefiCpuPkg PiSmmCpuDxeSmm: Update SmiEntry function
> run
From: "bob.c.f...@intel.com"
If Structure PCD and Normal Pcd refer to the
same EFI variable, do EFI variable merge, otherwise, do
EFI variable combination.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng
Cc: Liming Gao
---
55 matches
Mail list logo
