Jeff,
Yes. That is ASSERT() location I was suggesting.
Does is also makes sense to fall back to GetInitialApicId() if CPUID leaf is
not supported? Or is this really a condition that should never occur?
Mike
> -Original Message-
> From: Fan, Jeff
> Sent: Monday, November 23, 2015 11:3
On 23 November 2015 at 20:23, Leif Lindholm wrote:
> On Mon, Nov 23, 2015 at 05:56:29PM +0100, Ard Biesheuvel wrote:
>> The way the v7 MMU code is invoked by the Xen port is somewhat of
>> a pathological case, since it describes its physical memory space
>> using a single cacheable region that cov
On 23 November 2015 at 21:55, Wei Huang wrote:
>
>
> On 11/23/2015 11:10 AM, Ard Biesheuvel wrote:
>> Hello all,
>>
>> After Drew pointed out that mach-virt now populates the memory region beyond
>> DRAM, I am proposing this approach instead. Since KVM limits its IPA space to
>> 40 bits, there is
Mike,
OK. So, if 0xB leaf is not supported, then ASSERT() in GetX2ApicIdFromCpuId();
//
// Get the maximum index of basic CPUID
//
AsmCpuid (CPUID_SIGNATURE, &MaxCpuIdIndex, NULL, NULL, NULL);
ASSERT (MaxCpuIdIndex >= CPUID_EXTENDED_TOPOLOGY);
Jeff
-Original Message-
From: K
Jiewen,
I agree making the behavior the same as DXE Core makes more sense.
Thanks,
Mike
> -Original Message-
> From: Yao, Jiewen
> Sent: Monday, November 23, 2015 11:22 PM
> To: edk2-de...@ml01.01.org
> Cc: Zeng, Star ; Fan, Jeff ; Kinney,
> Michael D
> Subject: RE: [patch] MdeModuleP
On 24 November 2015 at 00:38, Vladimir Olovyannikov
wrote:
>
>
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Tuesday, November 10, 2015 10:04 AM
>> To: Vladimir Olovyannikov
>> Cc: Cohen, Eugene; edk2-devel@lists.01.org
>> Subject: Re: [edk2] Str
On 24 November 2015 at 00:05, Vladimir Olovyannikov
wrote:
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Wednesday, November 18, 2015 11:32 PM
>> To: Vladimir Olovyannikov
>> Cc: Mark Rutland; edk2-devel@lists.01.org
>> Subject: Re: [edk2] Armv8
Reviewed-by: Michael Kinney
> -Original Message-
> From: Yao, Jiewen
> Sent: Monday, November 23, 2015 5:34 AM
> To: edk2-de...@ml01.01.org
> Cc: Yao, Jiewen ; Zeng, Star ;
> Fan, Jeff ; Kinney, Michael D
>
> Subject: [patch] MdeModulePkg/PiSmmIpl: Install LoadedImage protocol for
> Pi
HI
I just discussed with Star.
We decide to let PiSmmCore install LoadedImage protocol - same way as DxeCore.
If so, we can assign correct FilePath there. Then we do not need update
PiSmmIpl.
I will send another patch. This update can be discard.
-Original Message-
From: Yao, Jiewen
S
BDS puts a special GUID in boot option optional data for
auto-discovered boot option. But when launching that boot
option, the BDS core unconditionally pass the special GUID
to the executable.
A good written application/OS loader can ignore the unexpected
parameters, but BDS core should still avoi
Yes, I agree.
It seems I miss this line when I sync update. I will add below line at
beginning.
Hdr = NULL;
-Original Message-
From: Kinney, Michael D
Sent: Tuesday, November 24, 2015 3:14 PM
To: Yao, Jiewen; edk2-de...@ml01.01.org; Kinney, Michael D
Cc: Zeng, Star; Fan, Jeff
Subject
Reviewed-by: Michael Kinney
> -Original Message-
> From: Yao, Jiewen
> Sent: Monday, November 23, 2015 5:29 AM
> To: edk2-de...@ml01.01.org
> Cc: Yao, Jiewen ; Zeng, Star ;
> Fan, Jeff ; Kinney, Michael D
>
> Subject: [patch] MdeModulePkg/PiSmmCore: Uninstall LoadedImage protocol if
>
Jiewen,
I think same issue is in line 133 of that same file. If
InternalAllocPoolByIndex() returns an error, then *FreePoolHdr is assigned to
an uninitialized value.
If you agree, then I think we should fix both issues in this patch.
Best regards,
Mike
> -Original Message-
> From: Ya
Reviewed-by: Michael Kinney
> -Original Message-
> From: Yao, Jiewen
> Sent: Monday, November 23, 2015 5:13 AM
> To: edk2-de...@ml01.01.org
> Cc: Yao, Jiewen ; Fan, Jeff ;
> Kinney, Michael D
> Subject: [patch] UefiCpuPkg/PiSmmCpu: Correct TSS segment.
>
> TSS segment should use (SIZE
Laszlo,
I other modules where we want to halt no matter what, the following 2
statements are used together. ASSERT() could be removed by PCD settings, so
dead loop catches that case. If ASSERT() is enabled, then the ASSERT()
behavior of BP or dead loop is controlled by PCD.
ASSERT (F
Jeff,
Can you move the ASSERT() for no APIC ID available into GetX2ApicIdFromCpuId().
Then you do not need special APIC ID value of 0x.
Mike
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeff
> Fan
> Sent: Monday, November 23, 20
Reviewed-by: Michael Kinney
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu
> Ni
> Sent: Sunday, November 22, 2015 5:30 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Qiu, Shumin
> Subject: [edk2] [Patch] MdeModulePkg/BdsDxe: Fix E
On 2015/11/24 14:06, Qiu Shumin wrote:
When CustomCumulativeToken is not NULL, the CustomCumulativeData is expected
non-NULL.
Add 'ASSERT' statement to ensure this.
Cc: Star Zeng
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin
---
PerformancePkg/Dp_App/Dp.c
Reviewed-by: Michael Kinney
> -Original Message-
> From: Ni, Ruiyu
> Sent: Sunday, November 22, 2015 5:21 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Kinney, Michael D
>
> Subject: [Patch] MdeModulePkg/UefiBootManagerLib: Always create
> MemoryTypeInfo variable
>
> Align to old
This module initializes the ACPI_CPU_DATA structure and registers the
address of this structure in the PcdCpuS3DataAddress PCD. This is
simplest version of this module. It does not provide a machine check
handler or CPU register initialization tables for ACPI S3 resume.
This module can be copied
Provide a more detailed description of each field of the
ACPI_CPU_DATA and CPU_REGISTER_TABLE structures.
Cc: Laszlo Ersek
Cc: "Yao, Jiewen"
Cc: "Fan, Jeff"
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney
---
UefiCpuPkg/Include/AcpiCpuData.h | 116 +++
This patch series adds a generic/simple module that allocates,
initializes, and registers the ACPI_CPU_DATA structure required
to support ACPI S3 resume. This patch series is in response to
the OvmfPkg patch series from Laszlo Ersek that enables SMM on
OVMF. The v4 version of that patch serie
when multiple Dynamic PCD have different token space guid but same PCD
name, it is difficult for user to check why the generated autogen.c and
autogen.h are not consistent. so we add a check before generating
autogen.c and report error directly that user can know what happened
immediately.
Contrib
When CustomCumulativeToken is not NULL, the CustomCumulativeData is expected
non-NULL.
Add 'ASSERT' statement to ensure this.
Cc: Jaben Carsey
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin
---
ShellPkg/Library/UefiDpLib/Dp.c | 3 ++-
1 file changed, 2 insert
Qiu Shumin (2):
PerformancePkg\Dp_App: Add NULL check to pointer returned from
'AllocateZeroPool'.
ShellPkg: Add NULL check to pointer returned from 'AllocateZeroPool'.
PerformancePkg/Dp_App/Dp.c | 3 ++-
ShellPkg/Library/UefiDpLib/Dp.c | 3 ++-
2 files changed, 4 insertions(+), 2 de
When CustomCumulativeToken is not NULL, the CustomCumulativeData is expected
non-NULL.
Add 'ASSERT' statement to ensure this.
Cc: Star Zeng
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin
---
PerformancePkg/Dp_App/Dp.c | 3 ++-
1 file changed, 2 insertions(+),
Yes, I will. Thanks!
-Original Message-
From: Fan, Jeff
Sent: Tuesday, November 24, 2015 11:35 AM
To: Yao, Jiewen; edk2-de...@ml01.01.org
Cc: Kinney, Michael D
Subject: RE: [patch] UefiCpuPkg/PiSmmCpu: Remove TSS fixup in GDT.
Jiewen,
Could you combine this patch with [patch] UefiCpuPkg
Agree. Thanks!
-Original Message-
From: Fan, Jeff
Sent: Tuesday, November 24, 2015 11:33 AM
To: Yao, Jiewen; edk2-de...@ml01.01.org
Cc: Kinney, Michael D
Subject: RE: [patch] UefiCpuPkg/PiSmmCpu: Eliminate
EFI_IMAGE_MACHINE_TYPE_SUPPORTED(EFI_IMAGE_MACHINE_X64).
This commit title is too
Jiewen,
Could you combine this patch with [patch] UefiCpuPkg/PiSmmCpu: Eliminate
EFI_IMAGE_MACHINE_TYPE_SUPPORTED(EFI_IMAGE_MACHINE_X64)?
Reviewed-by: Jeff Fan
Jeff
-Original Message-
From: Yao, Jiewen
Sent: Monday, November 23, 2015 10:15 PM
To: edk2-de...@ml01.01.org
Cc: Yao, Jiewen
This commit title is too large ( > 70 character), could you update it as below.
"UefiCpuPkg/PiSmmCpu: Eliminate EFI_IMAGE_MACHINE_TYPE_SUPPORTED"
Reviewed-by: Jeff Fan
Thanks!
-Original Message-
From: Yao, Jiewen
Sent: Monday, November 23, 2015 10:06 PM
To: edk2-de...@ml01.01.org
Cc: Y
Reviewed-by: Jeff Fan
-Original Message-
From: Yao, Jiewen
Sent: Monday, November 23, 2015 9:13 PM
To: edk2-de...@ml01.01.org
Cc: Yao, Jiewen; Fan, Jeff; Kinney, Michael D
Subject: [patch] UefiCpuPkg/PiSmmCpu: Correct TSS segment.
TSS segment should use (SIZE - 1) as limit, and do not s
On 2015/11/23 21:29, jiewen yao wrote:
Original code does not uninstall LoadedImage protocol if SMM driver returns
error and is unloaded.
It causes a wrong LoadedImage protocol existing in system.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yao, Jiewen
Cc: Zeng, Star
Sorry, please ignore this patch.
I just realized that mLoadPe32Image->LoadPeImage() can install LoadedImage
protocol.
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of jiewen
yao
Sent: Monday, November 23, 2015 9:41 PM
To: edk2-de...@ml01.01.org
C
More comments below.
On 2015/11/24 9:01, Zeng, Star wrote:
Laszlo,
Explain more below.
On 2015/11/23 22:01, Laszlo Ersek wrote:
Star,
On 11/23/15 02:44, Star Zeng wrote:
Beyond just changing the directly related lines in the FDF and DSC
files,
we have to adapt the EarlyFdtPL011SerialPortLib
David,
When using BEFORE and AFTER, you have to provide a GUID C name for the FFS file
GUID of the driver you want to run before or after
The supported syntax is
BEFORE
AFTER
This means you have to declare a GUD in a DEC file that is mapped to the same
GUID value of the dri
Laszlo,
Explain more below.
On 2015/11/23 22:01, Laszlo Ersek wrote:
Star,
On 11/23/15 02:44, Star Zeng wrote:
Beyond just changing the directly related lines in the FDF and DSC files,
we have to adapt the EarlyFdtPL011SerialPortLib and FdtPL011SerialPortLib
instances as well, in the same pat
Reviewed-by: Qiu Shumin
-Original Message-
From: Long, Qin
Sent: Monday, November 23, 2015 4:39 PM
To: edk2-devel@lists.01.org
Cc: Qiu, Shumin
Subject: [Patch] [CryptoPkg] Correct one typo in the API comments.
Correct one typo (SingerChainCerts --> SignerChainCerts) in the comments for
Hi Laszlo
For 3), I see your point.
I think 2) again, and realize there might be a corner case.
A) There is SMI handler issue which might call-out SMRAM.
B) Malicious software may construct such environment in OS. (But not trigger
it, because it will be blocked by code access)
C) SMM CPU driver d
I'm trying to make one DXE driver dependent upon another. From the INF spec, it
appears that I can put "AFTER path/to/dependency.inf" in my driver's Depex
section. If I try this I get the error below.
(Python 2.7.3 on win32) Traceback (most recent call last):
File "build.py", line 2032, in Mai
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, November 10, 2015 10:04 AM
> To: Vladimir Olovyannikov
> Cc: Cohen, Eugene; edk2-devel@lists.01.org
> Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with
> step-by-step de
> On Nov 23, 2015, at 2:03 PM, Narinder Dhillon wrote:
>
> Hi Andrew,
>
> I looked at the ArmVirtPkg and did the same before I sent the previous
> email. I am missing some step that is causing the null package to be
> picked up. Here are my changes, I think I covered most but still
> missing so
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, November 18, 2015 11:32 PM
> To: Vladimir Olovyannikov
> Cc: Mark Rutland; edk2-devel@lists.01.org
> Subject: Re: [edk2] Armv8 64bit: System error booting linux from the UEFI
>
> On 19 Novembe
Hi Andrew,
I looked at the ArmVirtPkg and did the same before I sent the previous
email. I am missing some step that is causing the null package to be
picked up. Here are my changes, I think I covered most but still
missing something.
Thanks for your help,
Laszlo,
The section [UserExtensions.TianoCore."ExtraFiles"] can be used to list files
not required to build and support incremental builds, but need to be included
in a UDP package.
Mike
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, November 23, 2
On 11/23/15 22:01, Kinney, Michael D wrote:
> Laszlo,
>
> Based on size analysis of compiler output, (3) is not the smallest size.
> That is why we prefer pre-init global.
Ugh, I completely forgot about physical flash, where size is a premium...
>
> Using your current patch style (1) in OvmfP
Laszlo,
Based on size analysis of compiler output, (3) is not the smallest size. That
is why we prefer pre-init global.
Using your current patch style (1) in OvmfPkg specific modules is ok until you
can find a solution to your ctags issue.
Mike
> -Original Message-
> From: edk2-devel
On 11/23/15 21:28, Kinney, Michael D wrote:
> Laszlo,
>
> There are 2 reasons to list all source files used in a module build in the
> [Sources] section.
>
> 1) Support incremental builds. If a change to the .h file is made,
> then the module may not be rebuilt if the .h file is not listed in
Laszlo,
There are 2 reasons to list all source files used in a module build in the
[Sources] section.
1) Support incremental builds. If a change to the .h file is made, then the
module may not be rebuilt if the .h file is not listed in [Sources]
2) Support of UEFI Distribution Package distrib
On 11/23/15 21:13, Kinney, Michael D wrote:
> Laszlo,
>
> Comments below.
>
> Mike
>
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Monday, November 23, 2015 4:34 AM
>> To: Kinney, Michael D ; edk2-de...@ml01.01.org
>> Cc: Justen, Jordan L
>> Subject: Re
On 11/23/15 21:04, Wei Huang wrote:
>
>
> On 11/23/2015 11:16 AM, Laszlo Ersek wrote:
>> On 11/23/15 18:10, Ard Biesheuvel wrote:
>>> The ID mapping routines on virtual platforms simply map the entire
>>> address space as device memory, and then punch some holes for regions
>>> that need to be ma
Laszlo,
Comments below.
Mike
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, November 23, 2015 4:34 AM
> To: Kinney, Michael D ; edk2-de...@ml01.01.org
> Cc: Justen, Jordan L
> Subject: Re: [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-SMR
I'll take that as a reviewed-by, thanks :)
Pushed as r18925.
On Mon, Nov 23, 2015 at 05:21:16PM +, Carsey, Jaben wrote:
> Not sure how to RB this ... it's fine with me to commit it.
>
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Monday,
On Mon, Nov 23, 2015 at 05:56:29PM +0100, Ard Biesheuvel wrote:
> The way the v7 MMU code is invoked by the Xen port is somewhat of
> a pathological case, since it describes its physical memory space
> using a single cacheable region that covers the entire addressable
> range. When clipping this re
Hi, Eugene,
Sorry, I have no RVCT environment for more investigations.
Could you help to double-check if this is caused by any CryptoPkg updates? Or
It is one OpenSSL-native issue?
Could we silence this simply with any build flag, such as " --diag_suppress"?
Moreover, some old RVCT release may
Not sure how to RB this ... it's fine with me to commit it.
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, November 23, 2015 5:22 AM
> To: Leif Lindholm
> Cc: edk2-devel@lists.01.org; Carsey, Jaben ; Qiu,
> Shumin
> Subject: Re: [PATCH] She
KVM uses a fixed size of 40 bits for its intermediate physical address
space, so there is no need to support anything beyond that even if the
host hardware does.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Reviewed-by: Laszlo Ersek
---
ArmVirtPkg/ArmVir
On 11/23/15 18:10, Ard Biesheuvel wrote:
> The ID mapping routines on virtual platforms simply map the entire
> address space as device memory, and then punch some holes for regions
> that need to be mapped cacheable. On virtual platforms hosted on CPUs
> that support a large physical address range
On 11/23/15 17:56, Ard Biesheuvel wrote:
> By special request, this implements ARM support to the ArmVirtXen
> platform. This is probably still rough around the edges, since I have
> not tested it myself under Xen yet. I did test all the code changes in
> this series under QEMU. (This is possible s
The ID mapping routines on virtual platforms simply map the entire
address space as device memory, and then punch some holes for regions
that need to be mapped cacheable. On virtual platforms hosted on CPUs
that support a large physical address range, this may result in a lot
of overhead, i.e., 4 K
Hello all,
After Drew pointed out that mach-virt now populates the memory region beyond
DRAM, I am proposing this approach instead. Since KVM limits its IPA space to
40 bits, there is simply no point in supporting anything beyond that for
ArmVirtQemu.
I am cc'ing the Xen guys since they may run i
On 23 November 2015 at 17:56, Ard Biesheuvel wrote:
> By special request, this implements ARM support to the ArmVirtXen
> platform. This is probably still rough around the edges, since I have
> not tested it myself under Xen yet. I did test all the code changes in
> this series under QEMU. (This i
This adds ARM support to the ArmVirtXen platform. As is the case for
AARCH64, the ARM port adheres to the ARM Linux boot protocol, i.e.,
it expects the address of a DTB describing the platform to be passed
in r2, and relocates itself at runtime to the actual load time memory
offset.
Contributed-un
This is a port of the AARCH64 low level init routines to ARM. This
mainly covers the platform boot code that extracts the system base
and size from the DTB, copies it and updates the FD and FV base
addresses according to the load time offset.
Contributed-under: TianoCore Contribution Agreement 1.0
This adds support to the self relocating PrePi instance that is built
as a PIE ET_DYN executable. It primarily involves porting the relocation
routine to use ELF32 REL entries instead of ELF64 RELA entries which is
what AArch64 uses.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-o
Parsing the DTB early on using a handcoded assembly routine is a pointless
waste of brain cycles, since the UEFI firmware always executes from RAM
under Xen. So instead, set up a temporary stack in the memory region at the
beginning of the image, and use the libfdt C library.
Contributed-under: Ti
The way the v7 MMU code is invoked by the Xen port is somewhat of
a pathological case, since it describes its physical memory space
using a single cacheable region that covers the entire addressable
range. When clipping this region to the part that is 1:1 addressable,
we end up with a region of exa
By special request, this implements ARM support to the ArmVirtXen
platform. This is probably still rough around the edges, since I have
not tested it myself under Xen yet. I did test all the code changes in
this series under QEMU. (This is possible since the early code only depends
on the Linux boo
R_ARM_REL32 are relative relocations, so we don't need to do anything
special when performing the ELF to PE/COFF conversion, since our memory
layout is identical between the two binary formats. So just allow them.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuve
On 11/23/15 16:32, Yao, Jiewen wrote:
> Comments below:
>
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, November 23, 2015 10:39 PM
> To: Yao, Jiewen; edk2-de...@ml01.01.org
> Cc: Kinney, Michael D; Fan, Jeff
> Subject: Re: [edk2] [patch] UefiCpuPkg/P
Comments below:
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Monday, November 23, 2015 10:39 PM
To: Yao, Jiewen; edk2-de...@ml01.01.org
Cc: Kinney, Michael D; Fan, Jeff
Subject: Re: [edk2] [patch] UefiCpuPkg/PiSmmCpu: Move
RestoreSmmConfigurationInS3 from BSPHan
Using RVCT 4, I get the following error building openssl-1.0.2d:
1> Building ... c:\bios_24s\edk2\CryptoPkg\Library\OpensslLib\OpensslLib.inf
[ARM]
[snip]
c:\bios_24s\edk2\CryptoPkg\Library\OpensslLib\openssl-1.0.2d\crypto\cryptlib.c
1>c:\bios_24s\edk2\CryptoPkg\Library\OpensslLib\openssl-1.0.2d
Hi Jiewen,
On 11/23/15 14:50, jiewen yao wrote:
> In this way, we can centralize the silicon configuration in
> PerformRemainingTasks() function.
> If there are more features need to be configured, they can put in
> PerformRemainingTasks() only.
>
> Contributed-under: TianoCore Contribution Agr
On 11/23/15 12:53, Ard Biesheuvel wrote:
> On 23 November 2015 at 12:41, Laszlo Ersek wrote:
>> On 11/21/15 10:44, Ard Biesheuvel wrote:
>>> The ID mapping routines on virtual platforms simply map the entire
>>> address space as device memory, and then punch some holes for regions
>>> that need to
The TSS is already fixed in PiSmmCpuDxeSmm/X64/SmmFuncsArch.c, InitGdt().
There is no need to fix it again.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yao, Jiewen
Cc: Fan, Jeff
Cc: Kinney, Michael D
---
UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S | 8
UefiCp
Move Gdt initialization from InitializeMpServiceData() to CPU Arch specific
function.
We create SmmFuncsArch.c for hold CPU specific function, so that
EFI_IMAGE_MACHINE_TYPE_SUPPORTED(EFI_IMAGE_MACHINE_X64) can be removed.
For IA32 version, we always allocate new page for GDT entry, for easy
mai
Star,
On 11/23/15 02:44, Star Zeng wrote:
> Beyond just changing the directly related lines in the FDF and DSC files,
> we have to adapt the EarlyFdtPL011SerialPortLib and FdtPL011SerialPortLib
> instances as well, in the same patch. This is because the EmbeddedPkg
> driver expects the SerialPortS
In this way, we can centralize the silicon configuration in
PerformRemainingTasks() function.
If there are more features need to be configured, they can put in
PerformRemainingTasks() only.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yao, Jiewen
Cc: Fan, Jeff
Cc: Kin
On 11/23/15 02:44, Star Zeng wrote:
> Cc: Michael D Kinney
> Cc: Liming Gao
> Cc: Jordan Justen
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng
> ---
> .../XenConsoleSerialPortLib.c | 95
> ++
>
PiSmmCore installs LoadedImage for each SMM driver. However ECP SMM driver is
missing.
Since SmmBaseHelper loads ECP SMM driver, we let SmmBaseHelper installs
LoadedImage protocol for SMM driver.
So that the SMM image information is complete.
Contributed-under: TianoCore Contribution Agreement 1
PiSmmCore installs LoadedImage for each SMM driver. However itself is missing.
Since PiSmmIpl loads PiSmmCore, we let PiSmmIpl installs LoadedImage protocol
for PiSmmCore.
So that the SMM image information is complete.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yao, Ji
Original code does not uninstall LoadedImage protocol if SMM driver returns
error and is unloaded.
It causes a wrong LoadedImage protocol existing in system.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yao, Jiewen
Cc: Zeng, Star
Cc: Fan, Jeff
Cc: Kinney, Michael D
-
Original code refers FreePoolHdr without check Status. It is obvious wrong and
has risk.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zeng, Star
Reviewed-by: Yao, Jiewen
Cc: Fan, Jeff
Cc: Kinney, Michael D
---
MdeModulePkg/Core/PiSmmCore/Pool.c | 4 +++-
1 file chan
On 23 November 2015 at 14:20, Leif Lindholm wrote:
> The binaries of ShellBinPkg are generated with ShellPkg from r18915.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Leif Lindholm
> ---
>
> Patch generated with --no-binary, actual binaries available from
> https:/
The binaries of ShellBinPkg are generated with ShellPkg from r18915.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm
---
Patch generated with --no-binary, actual binaries available from
https://git.linaro.org/people/leif.lindholm/edk2.git/shortlog/refs/heads/
TSS segment should use (SIZE - 1) as limit, and do not set G bit (highest bit
of LimitHigh) because limit means byte count.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yao, Jiewen
Cc: Fan, Jeff
Cc: Kinney, Michael D
---
UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiException.S
On 11/21/15 07:17, Kinney, Michael D wrote:
> Laszlo,
>
> Minor comments included below.
>
> Reviewed-by: Michael Kinney
Thank you. I'll pick up this tag. Answers and further questions below:
>
> Mike
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org
On 11/21/15 07:36, Kinney, Michael D wrote:
> Laszlo,
>
> Minor comments included below. I know from later items in this thread that
> SMM_COMMUNICATE has already been removed in your local branch.
>
> Reviewed-by: Michael Kinney
Thank you. I've picked this up now.
As far as I can see your c
On 11/21/15 07:03, Kinney, Michael D wrote:
> Laszlo,
>
> Minor comments included below.
>
> Reviewed-by: Michael Kinney
Thank you. I'll pick up your R-b, but I'll also respond to your comments
below:
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
On 23 November 2015 at 12:41, Laszlo Ersek wrote:
> On 11/21/15 10:44, Ard Biesheuvel wrote:
>> The ID mapping routines on virtual platforms simply map the entire
>> address space as device memory, and then punch some holes for regions
>> that need to be mapped cacheable. On virtual platforms host
On 11/21/15 10:44, Ard Biesheuvel wrote:
> The ID mapping routines on virtual platforms simply map the entire
> address space as device memory, and then punch some holes for regions
> that need to be mapped cacheable. On virtual platforms hosted on CPUs
> that support a large physical address range
On 11/21/15 10:44, Ard Biesheuvel wrote:
> Hello all,
>
> After Drew pointed out that mach-virt now populates the memory region beyond
> DRAM, I am proposing this approach instead. Since KVM limits its IPA space to
> 40 bits, there is simply no point in supporting anything beyond that for
> ArmVir
Hi everyone,
I'd like to integrate a few applications into the shell so they are directly
available when booting the shell vie PXE. One of the applications I wanted to
include in the shell is made using EADK, specifically the socket library. I got
it integrated and can run it from the shell, ho
Correct one typo (SingerChainCerts --> SignerChainCerts) in the comments
for Pkcs7GetCertificatesList() API.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long
CC: Shumin Qiu
---
CryptoPkg/Include/Library/BaseCryptLib.h | 2 +-
CryptoPkg
Load File protocol requires remaining device path rather than whole
device path. For PXE, it actually requires end node device path only,
or else invalid parameter will be returned directly.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo
Cc: Leif Lindholm
Cc: Ard
If there are any logical processor reporting an APIC ID of 255 or greater, set
X2ApicEnable flag.
Cc: Feng Tian
Cc: Michael Kinney
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan
---
UefiCpuPkg/CpuMpPei/CpuMpPei.c | 32 +---
UefiCpuPk
If there are any logical processor reporting an APIC ID of 255 or greater. We
should enable x2APIC mode.
Jeff Fan (3):
UefiCpuPkg/CpuMpPei: Get APIC ID from CPUID if x2APIC supported
UefiCpuPkg/CpuMpPei: Set X2APIC flag if one x2APIC ID larger than 254
UefiCpuPkg/CpuMpPei: Enable x2APIC mode
If x2APIC flag is set, enable x2APIC mode on all APs and BSP. Before we wakeup
APs to enable x2APIC mode, we should wait all APs have finished initialization.
Cc: Feng Tian
Cc: Michael Kinney
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan
---
UefiCpuPkg/CpuMpPe
If x2APIC is supported by processor, get the APIC ID from
CPUID.(EAX=0BH, ECX=0H):EDX instead of legacy APIC ID. It is used to check if
need to enable x2APIC mode.
Cc: Feng Tian
Cc: Michael Kinney
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan
---
UefiCpuPkg/Cp
98 matches
Mail list logo