1) No impact at all.
2)
Page at stack base will be disabled.
If Arch == IA32,
The stack switch for handler of #PF/#DD will be setup for BSP and AP
Else
The handler of #PF/#DD keeps the same
EndIf
If StackOverFlow,
If Arch == IA32,
#PF is
Hi Karunakar,
I think most cases failure are related to the lack of modules in your platform,
detailed see below:
c:\work\sct\utwg\uefi-sct\SctPkg\TestCase\UEFI\EFI\Generic\EfiCompliant\BlackBoxTest\EfiCompliantBBTestPlatform_uefi.c:1428:SetupMode
equal zero - No
Jiaxin: That's because you set
1.1) Got your point. I'll add dummy function in this patch.
1.2) Yep, we're on the same page.
1.3) Here's my opinion:
Actually almost all MP code has such assumption: any AP configuration will copy
from BSP. If we allow AP to call InitializeCpuExceptionHandlers(), we have to
do a lot
of other
I am ok to keep FALSE by default. But I still suggest we test existing UEFI OS
behavior.
Please help me understand below condition, if we do not change a platform
specific CPU driver:
1) If PcdCpuStackGuard is FALSE, and CPU driver is still consuming existing API
in ExceptionLib. Is there any
Here is my thought for 1)
1.1) We must provide the InitializeCpuExceptionStackSwitchHandlers()
implementation in Pei instance and Smm instance.
The basic requirement is a library instance must provide symbol for functions
declared in header file.
It is ok to return unsupported. But we MUST
Add toolchain for VS2015 build.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lushifex
---
.../PlatformSetupDxe/SetupInfoRecords.c| 30 +++
.../SmBiosMiscDxe/MiscProcessorCacheFunction.c | 8 ++--
If PcdCpuStackGuard is not enabled, there's no impact. If it's enabled, the only
issue is that the exception dump cannot be done but no other impact. From this
point of view, maybe PcdCpuStackGuard should be FALSE by default.
> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday,
> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 23, 2017 1:50 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Zeng, Star ; Dong, Eric ;
> Kinney, Michael D
> Subject:
One more question:
I notice not all platforms are using the CpuDxe in UefiCpuPkg.
If so, is there any impact to the platform whose CPU driver does not have such
InitializeCpuExceptionStackSwitchHandlers() call?
Have you tested that condition?
Thank you
Yao Jiewen
> -Original Message-
>
Some thought:
1) I found InitializeCpuExceptionStackSwitchHandlers() is only implemented in
DxeException.c.
What about Pei/Smm instance?
I think it is OK to not implement it at this moment. But we need make sure no
architecture issue if we want to enable it some time later.
2) #define
If we do not see any compatibility problem with Linux or Windows, we can enable
it by default.
Or we have to disable it by default.
It is always good to have a try. Let's see.
Thank you
Yao Jiewen
> -Original Message-
> From: Wang, Jian J
> Sent: Thursday, November 23, 2017 1:09 PM
>
Got it. I like this idea.
It is better to hide it from DxeCore.
Thank you
Yao Jiewen
> -Original Message-
> From: Wang, Jian J
> Sent: Thursday, November 23, 2017 1:19 PM
> To: Wang, Jian J ; Yao, Jiewen ;
> edk2-devel@lists.01.org
> Cc:
Andrew:
To compile BaseTools C tools is a separate step. It happens before build. I
review BaseTools C tool top GNUmakefile. It can be enhanced to support make -j
N that has the better performance. I will provide my patch for code review.
Thanks
Liming
>-Original Message-
>From:
Laszlo,
When booting a boot option, UefiBootManagerBoot() sets a Boot variable
and saves to BootCurrent variable.
So all the details (except the EDKII_OS_LOADER_DETAIL.Status) can be retrieved
from reading Boot variable.
4 more comments below.
Thanks/Ray
> -Original
About 1), the code is in [PATCH v2 7/8]. Following is part of it.
@@ -63,10 +67,34 @@ InitializeCpuExceptionHandlers (
IN EFI_VECTOR_HANDOFF_INFO *VectorInfo OPTIONAL
)
{
+ EFI_STATUSStatus;
+ EXCEPTION_STACK_SWITCH_DATA StackSwitchData;
+
I did test it with disabled. I'll try it enabled. Do you think this feature
should be enabled
by default or not, just like the PcdCpuSmmStackGuard?
> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 23, 2017 11:48 AM
> To: Wang, Jian J ;
Good idea. I think it should be defined in also in following file besides the
new API
MdeModulePkg\Include\Library\CpuExceptionHandlerLib.h
> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 23, 2017 12:08 PM
> To: Wang, Jian J ;
Hi,
> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 23, 2017 12:14 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Dong, Eric ; Laszlo Ersek ;
> Kinney, Michael D
>
Hi Karunakar,
We're going to update the below description in UEFI Spec section of 2.6.2, not
SCT Spec:
If the network environment requires TLS features,
EFI_TLS_SERVICE_BINDING_PROTOCOL,EFI_TLS_PROTOCOL and
EFI_TLS_CONFIGURATION_PROTOCOL are required.
The SCT test case was drafted by according
Hi
1) Can we enable this feature in early DxeCore?
Current DxeCore still calling InitializeCpuExceptionHandlers().
But I hope InitializeExceptionStackSwitchHandlers() can be used here.
In order to handle buffer from different arch, the DxeIpl can help provide some
data in hob and pass to
Hi
I am a little worried about the way to use VOID * to pass arch dependent data.
Can we define it clearly in each ARCH in the header file, and use a UNION to
include all arch?
I think both the caller and the callee need parse it. As such, VOID * is not a
good way.
Thank you
Yao Jiewen
>
For test, can we test boot OS (windows/Linux) with PcdCpuStackGuard enabled?
Thank you
Yao Jiewen
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Wednesday, November 22, 2017 4:46 PM
> To: edk2-devel@lists.01.org
>
Thanks for the patch. It follows the idea described in:
https://lists.01.org/pipermail/edk2-devel/2017-April/010294.html.
Reviewed-by: Ruiyu Ni
Thanks/Ray
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, November 23, 2017 7:59
UPD allocation and patching can be done outside FspWrapper
as implementation choice so adding a PCD to select between
original FspWrapper allocation model or outside model
Cc: Jiewen Yao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chasel Chiu
I cannot explain precisely why the S4 resume fails.
I can just guess: Windows might have some assumptions on the BM bit.
Thanks/Ray
> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, November 22, 2017 6:26 PM
> To: Ni, Ruiyu ; Laszlo Ersek ;
> v8:
>Remove merge code but keep code to remain MemoryMapStart
> v7:
>Merge memory map after filtering paging attributes
> v6:
>Add ExecuteDisable feature check to include/exclude EFI_MEMORY_XP
> v5:
>Coding style clean-up
> v4:
> a. Remove DoUpdate and check attributes
> v7/v8:
>No change.
> v6:
>Add ExecuteDisable feature check to include/exclude EFI_MEMORY_XP
> v5:
>Coding style clean-up
> v4:
> a. Remove DoUpdate and check attributes mismatch all the time to avoid
>a logic hole
> b. Add warning message if failed to update capability
> c.
> v8:
> Remove merge code but keep code to remain MemoryMapStart
> v7:
> Merge memory map after filtering code
> v6:
> Add code filter out all paging capabilities
Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really
set attributes and change memory paging attribute accordingly.
Update Minor version of BIOS ID.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lushifex
---
Platform/BroxtonPlatformPkg/BiosId.env | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Platform/BroxtonPlatformPkg/BiosId.env
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Wang, Jian J
> Sent: Thursday, November 23, 2017 9:06 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; Zeng, Star; Dong, Eric
> Subject: [PATCH] MdeModulePkg/Core: Fix potential array overflow
>
Reviewed-by: Dandan Bi
Thanks,
Dandan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
Wang
Sent: Thursday, November 23, 2017 9:19 AM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan ; Dong, Eric
Tested-by: jiewen@intel.com
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: Zeng, Star
> Sent: Thursday, November 23, 2017 9:11 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Yao, Jiewen
> Subject: [PATCH]
The coding style requires that header files must be also added in module's inf
file, as long as they're included by c files. This patch will fix this issue.
Cc: Dandan Bi
Cc: Star Zeng
Cc: Eric Dong
Contributed-under: TianoCore
Hi Fan,
Looks this patch will cause the null pointer dereference issue, see below
analysis:
With this patch, the NET_BUF will be freed and the corresponding Arg (Packet)
will also be freed in DhcpReleasePacket.
Wrap = NetbufFromExt (, 1, 0, 0, DhcpReleasePacket, Packet);
That's
Cc: Jiewen Yao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng
---
IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.c | 3 +++
IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.h | 5 +++--
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Zeng, Star
> Sent: Thursday, November 23, 2017 9:04 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star; Wu, Hao A; Yao, Jiewen
> Subject: [PATCH] MdeModulePkg UhciPei: Also check TempPtr against
In the method DumpGuardedMemoryBitmap() and SetAllGuardPages(), the code
didn't check if the global mMapLevel is legal value or not, which leaves
a logic hole causing potential array overflow in code followed.
This patch adds sanity check before any array reference in those methods.
Cc: Wu Hao
Cc: Hao Wu
Cc: Jiewen Yao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng
---
MdeModulePkg/Bus/Pci/UhciPei/UhcPeim.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
> On Nov 16, 2017, at 1:37 PM, Desimone, Nathaniel L
> wrote:
>
> Hi Liming,
>
> I chatted with Aaron on the phone today. The VfrCompiler race condition was
> discovered using "make -j " (where n > 1). I have filed the bug in
> Bugzilla:
>
I think there are
Parse and print the EDKII_OS_LOADER_DETAIL debug codes from
UefiBootManagerLib (when it acts as part of BdsDxe -- not as part of
UiApp, for example). In effect this displays LoadImage() and StartImage()
attempts and failures on the splash screen, visibly to end-users.
While at it, print two other
Under the following scenario:
- no UEFI bootable application available anywhere in the system,
- ... not even for the default platform recovery option,
- no shell is built into the firmware image,
- but UiApp is available in the firmware image,
we should preferably not just hang in BdsEntry()
The EfiBootManagerBoot() function reports progress codes about LoadImage()
preparation and failure, and StartImage() preparation and failure. These
codes are flat (scalar) constants.
Extend this by "broadcasting" the Boot option number, description,
device path, and -- on load / start failure
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Ruiyu Ni
Cc: Anthony Perard
Cc: Julien Grall
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Contributed-under:
Repo: https://github.com/lersek/edk2.git
Branch: boot_diags
The point of this series is to communicate OVMF boot progress and boot
failure in a way that is easier to consume for users who aren't versed
in OVMF debug log capturing and analysis. This means that we have to
write stuff about
The EfiBootManagerBoot() function in UefiBootManagerLib is the central
function for loading and starting Boot options. The library is built
into multiple drivers and applications (such as BdsDxe and UiApp),
therefore it is careful not to print anything to the system console. All
progress
https://bugzilla.tianocore.org/show_bug.cgi?id=793
Thanks,
Nate
-Original Message-
From: Gao, Liming
Sent: Friday, November 17, 2017 12:46 AM
To: Desimone, Nathaniel L ; Aaron Durbin
Cc: edk2-devel@lists.01.org
Subject: RE: [edk2]
On 22/11/17 19:39, Ard Biesheuvel wrote:
On 22 November 2017 at 11:30, Daniel Thompson
wrote:
On 21/11/17 18:10, Udit Kumar wrote:
Thanks Ard,
For internal SOC devices, this is perfectly ok to drop PRP0001 from CID.
This could be a valid reason to use PRP0001 +
On 22 November 2017 at 11:30, Daniel Thompson
wrote:
> On 21/11/17 18:10, Udit Kumar wrote:
>>
>> Thanks Ard,
>> For internal SOC devices, this is perfectly ok to drop PRP0001 from CID.
>>
>>> This could be a valid reason to use PRP0001 + compatible, for things like
FYI now that the UEFI Forum owns the ACPI Spec here is the location to register
a new PNP ID or ACPI ID:
https://stash.sd.apple.com/projects/COREOSMACFW/repos/macefifirmware/pull-requests/630/overview
Hi Ard,
On 11/22/2017 10:07 AM, Ard Biesheuvel wrote:
Clone the existing ArmPlatformGetVirtualMemoryMap () for this platform,
clean it up slightly (by using a static buffer rather than a heap
allocation, and removing the support for uncached DRAM mappings), and
turn it into a new
This is a re-send of v2, with a small comment update to indicate that
VS2017 v15.2 or later is required, due to the vswhere.exe requirement.
This patch serial adds VS2017 tool chain in BaseTools tools_def.template.
It enables /WHOLEARCHIVE option to detect the potential code issue.
It can be used
From: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao
---
Nt32Pkg/Sec/SecMain.inf | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Nt32Pkg/Sec/SecMain.inf b/Nt32Pkg/Sec/SecMain.inf
index
From: Liming Gao
VS2017 tool chain enables /WHOLEARCHIVE linker option
Split host-related and arch-related elements
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao
Signed-off-by: Pete Batard
---
From: Liming Gao
This way depends on VS vswhere.exe to find VS2017 installed directory.
vswhere.exe starts in Visual Studio 2017 version 15.2.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao
Signed-off-by: Pete
From: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao
---
MdePkg/Include/Ia32/ProcessorBind.h | 4 ++--
MdePkg/Include/X64/ProcessorBind.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff
Yes. I mean to update comments in tools_def.template.
Edk2 BaseTools doesn't include the party tools. And, without vswhere.exe, we
don't know whether VS2017 is installed or not. For now, we only mention it in
comments.
Thanks
Liming
> -Original Message-
> From: Pete Batard
Hi Daniel
> > For external devices (for which HID is not available), you suggest to
> > go with PRP0001 + compatible or that device driver needs add ACPI HID
> support.
>
> I don't think internal or external to the SoC would be any kind of deciding
> factor
> in how to best to bind, simply
On 21/11/17 18:10, Udit Kumar wrote:
Thanks Ard,
For internal SOC devices, this is perfectly ok to drop PRP0001 from CID.
This could be a valid reason to use PRP0001 + compatible, for things like I2C
slaves that are external to the SoC
For external devices (for which HID is not available),
Ray,
You may explain more why Win10 S4 resume fails with only BM disabled, then
Laszlo can know the issue well.
Thanks,
Star
-Original Message-
From: Ni, Ruiyu
Sent: Wednesday, November 22, 2017 6:06 PM
To: Laszlo Ersek ; edk2-devel-01
Cc:
These libraries are no longer used, so remove them from the tree.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Reviewed-by: Laszlo Ersek
---
ArmVirtPkg/ArmVirtQemuKernel.dsc
The QemuVirtMemInfoLib ArmVirtMemInfoLib implementation created for
ArmVirtQemuKernel does exactly what we need for ArmVirtQemu, the only
difference being that the latter is PrePeiCore based, and so it uses
a different method to ensure that PcdSystemMemorySize is set when
ArmVirtGetMemoryMap() is
Move to the new ArmVirtMemInfoLib library to retrieve DRAM information
from the platform, so that we can phase out ArmPlatformLib going forward.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
ArmVirtPkg/ArmVirtQemu.dsc
PrePi doesn't use anything defined by this package so drop the bogus
dependency.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Reviewed-by: Laszlo Ersek
---
ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
QEMU and KVM based ARM/AARCH64 virtual machines only enter UEFI on
a single core, so ArmPlatformIsPrimaryCore() always returns true.
And even if it didn't, our code does absolutely nothing meaningful
based on its return value, so don't bother calling it, and remove
another frivolous dependency on
Remove the pointless dependency on ArmPlatformLib: none of the code we
call from it actually does anything useful.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Reviewed-by: Laszlo Ersek
---
QEMU/KVM has very little tolerance for using anything except writeback
cacheable mappings of DRAM, so let's remove the 'feature' that allows
us to select uncached mappings at build time.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Clone the existing ArmPlatformGetVirtualMemoryMap () for this platform,
clean it up slightly (by using a static buffer rather than a heap
allocation, and removing the support for uncached DRAM mappings), and
turn it into a new ArmVirtMemInfoLib implementation.
Contributed-under: TianoCore
ArmVirtQemuKernel and ArmVirtXen use essentially the same code to
retrieve DRAM information from the DT /memory node at early boot,
and invoke it via the ArmPlatformPeiBootAction () hook exposed by
ArmPlatformLib. Let's move this code into the PrePi implementation
these platforms share between
Instead of invoking the library constructors of some libraries by
hand, invoke the generated function ProcessLibraryConstructorList
in AutoGen.c so all constructors are executed.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Remove GetPlatformPpi() from PrePi: it is not used anywhere.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Reviewed-by: Laszlo Ersek
---
ArmVirtPkg/PrePi/PrePi.c | 24
Create a new ArmVirtMemInfoLib for ArmVirtQemuKernel by cloning the
existing ArmPlatformGetVirtualMemoryMap () for this platform,
(ArmQemuRelocatablePlatformLib *not* ArmVirtPlatformLib), and cleaning
it up:
- remove support for uncached DRAM mappings
- replace EFI_D_xxx with DEBUG_xxx throughout
As part of the effort to get rid of ArmPlatformLib (which incorporates
far too many duties in a single library), introduce ArmVirtMemInfoLib
which will be invoked by our ArmVirtMemoryInitPeiLib implementation to
get a description of the virtual address space. This will allow us to
remove this
ArmPlatformStackLib has hooks into primary/secondary core PCDs and
other ArmPlatformLib related junk, so let's simply set the stack
pointer directly. This is trivial given that our PrePi is unicore
only.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
ArmPlatformLib is a mixed bag of platform specific hooks, some of which
are called from early startup code, and some of which are called from C
code, to get the boot mode, memory layout etc.
This library class is tightly coupled to the old ARM implementations that
ran some parts of UEFI in the
Laszlo,
Our QA found Win10 S4 resume fails due to your change.
As you might notice that I just rolled back the BM disabling patches in PciBus
module,
I am thinking about maybe you need to rollback the whole ExitBootServices
callback
as well to fix the compatibility issue.
Thanks/Ray
>
The firmware device, description and declaration files.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal
---
Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dec | 29 ++
Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc | 77 +
Build script and Environment setup script.
Readme to explain how to run build script
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal
---
Platform/NXP/Env.cshrc | 77
Real time clock Apis on top of I2C Apis
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal
---
Silicon/Maxim/Library/Ds1307RtcLib/Ds1307Rtc.h | 59
Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.c | 327
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal
---
.../Library/PlatformLib/ArmPlatformLib.c | 105
.../Library/PlatformLib/ArmPlatformLib.inf | 70
I2C driver produces gEfiI2cMasterProtocolGuid which can be
used by other modules.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal
---
Platform/NXP/Drivers/I2cDxe/I2cDxe.c | 728 +
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal
---
Platform/NXP/Library/DUartPortLib/DUart.h | 128
Platform/NXP/Library/DUartPortLib/DUartPortLib.c | 331 +
This library add supports for BE read/write and other
MMIO helper function.
In this data swapped after reading from MMIO and before
write using MMIO.
It can be used by any module with BE address space.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal
Add SocInit function that initializes peripherals
and print board and soc information.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal
---
Platform/NXP/Include/Bitops.h | 179 +
Installs watchdog timer arch protocol
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal
---
Platform/NXP/Drivers/WatchDog/WatchDog.c | 421 ++
Platform/NXP/Drivers/WatchDog/WatchDog.h | 37 +++
Sorry just see this email. I just replied another one. Great to know it works
for both of us.
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, November 22, 2017 5:05 PM
> To: Zeng, Star ; Wang, Jian J
>
Laszlo,
Thanks for the comments. Sorry for the commit log which doesn't meet the
requirement.
I appreciate everything you did to this patch series. It's not intended to
ignore them in log.
I think I just need more time to get used to the commit conventions.
I've explained the reason why v7
On 11/22/17 08:56, Zeng, Star wrote:
> How about we have the v6 patch series in first with the feedback from Jiewen
> (about comments) and you (about MemoryMapStart) addressed?
>
> Then we can have a separated patch for the merging.
Good idea!
Thanks!
Laszlo
>
>
> Thanks,
> Star
>
> v2:
>a. Move common TSS structure and API definitions to BaseLib.h
>b. Add EXCEPTION_STACK_SWITCH_DATA to convery data used to setup stack
> switch. This can avoid allocating memory for it in this library.
>c. Add globals to reserve memory for stack switch initialized in early
> v2:
>Add code to reserve resources and initialize AP exception with stack
>switch besides BSP, if PcdCpuStackGuard is enabled.
In current MP implementation, BSP and AP shares the same exception
configuration. Stack switch required by Stack Guard feature needs that BSP
and AP have their
> v2:
>Add new definitions required by stack switch in IA32
The new definitions include two structures
IA32_TASK_STATE_SEGMENT
IA32_TSS_DESCRIPTOR
and one API
VOID
EFIAPI
AsmWriteTr (
IN UINT16 Selector
);
They're needed to setup task gate and interrupt stack table for
> v2:
>Add code to save/restore GDTR, IDTR and TR for AP.
In current implementation of CPU MP, AP is initialized with data copied from
BSP. Stack switch required by Stack Guard feature needs different GDT, IDT
table and task gates for each logic processor. This patch adds GDTR, IDTR and
TR
Stack guard feature makes use of paging mechanism to monitor if there's a
stack overflow occurred during boot. A new PCD PcdCpuStackGuard is added to
enable/disable this feature. PCD PcdCpuStackSwitchExceptionList and
PcdCpuKnownGoodStackSize are introduced to configure the required exceptions
and
PcdCpuStackGuard is introduced to enable/disable Stack Guard feature.
Its value is FALSE by default.
Cc: Star Zeng
Cc: Eric Dong
Suggested-by: Ayellet Wolman
Contributed-under: TianoCore Contribution Agreement 1.1
> v2:
>Add prototype definition of InitializeCpuExceptionStackSwitchHandlers()
A new API InitializeCpuExceptionStackSwitchHandlers() is introduced to support
initializing exception handlers being able to switch stack. StackSwitchData is
arch dependent and required by IA32 processor to convey
> v2:
>Add two new PCDs to configure exception stack switch.
Stack switch is required by Stack Guard feature. Following two PCDs are
introduced to simplify the resource allocation for initializing stack switch.
gUefiCpuPkgTokenSpaceGuid.PcdCpuStackSwitchExceptionList
Stack guard feature makes use of paging mechanism to monitor if there's a
stack overflow occurred during boot.
This patch will check setting of PCD PcdCpuStackGuard. If it's TRUE, DxeIpl
will setup page table and set the page at which the stack base locates to be
NOT PRESENT. If stack is used up
On 11/21/17 21:32, Ard Biesheuvel wrote:
> On 21 November 2017 at 20:17, Laszlo Ersek
> wrote:
>> On 11/21/17 18:57, Ard Biesheuvel wrote:
>>> So how do you propose i go about creating two versions of
>>> QemuVirtMemInfoLib, only one of which has a constructor? Share
>>> the
Hi Karunakar,
I didn't see the SCT crash issue but also see the TLS test failure you attached.
For the failure, it's related to the EFI compliant test. According the UEFI
Spec, section of 2.6.2:
If the network environment requires TLS features,
EFI_TLS_SERVICE_BINDING_PROTOCOL,EFI_TLS_PROTOCOL
BTW: I notice that we have exit boot service callback in ATA bus driver, which
may also clear some command register.
I think we need validate that too.
Thank you
Yao Jiewen
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao,
> Jiewen
>
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: Ni, Ruiyu
> Sent: Monday, November 20, 2017 11:06 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Michael Turner
> ; Kinney, Michael D
> ; Yao,
1 - 100 of 103 matches
Mail list logo