Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Wang, Jian J]

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 triggered and its handler is called with KnownGoodStack.
CPU context is dumped successfully.
Else
#PF handler is triggered but its handler is called with corrupted 
stack.
CPU context cannot be dumped.
EndIf
EndIf

3) 
If Cpu == BSP,
Only Exceptions will be handled. Interrupts will not.
Else,
No exceptions and interrupts will be handled.
EndIf

4) 
Page at stack base will be disabled.
If Cpu == BSP,
Only Exceptions will be handled. Interrupts will not.

If Arch == IA32,
The stack switch for handler of #PF/#DD will be setup for BSP
Else
The handler of #PF/#DD keeps the same
EndIf

If StackOverFlow,
If Arch == IA32,
#PF is triggered and its handler is called with KnownGoodStack.
CPU context is dumped successfully.
Else
#PF handler is triggered but its handler is called with 
corrupted stack.
CPU context cannot be dumped.
EndIf
EndIf
Else,
No exceptions and interrupts will be handled.
EndIf

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 23, 2017 2:25 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Dong, Eric
> ; Zeng, Star 
> Subject: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch support
> 
> 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 impact?
> 2) If PcdCpuStackGuard is TRUE, and CPU driver is still consuming existing 
> API in
> ExceptionLib. Is there any impact?
> 3) If PcdCpuStackGuard is FALSE, and CPU driver is not consuming existing API 
> in
> ExceptionLib. Is there any impact?
> 4) If PcdCpuStackGuard is TRUE, and CPU driver is not consuming existing API 
> in
> ExceptionLib. Is there any impact?
> 
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, November 23, 2017 2:09 PM
> > To: Yao, Jiewen ; edk2-devel@lists.01.org
> > Cc: Kinney, Michael D ; Dong, Eric
> > ; Zeng, Star 
> > Subject: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > switch support
> >
> > 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, November 23, 2017 1:59 PM
> > > To: Yao, Jiewen ; Wang, Jian J
> > ;
> > > edk2-devel@lists.01.org
> > > Cc: Kinney, Michael D ; Dong, Eric
> > > ; Zeng, Star 
> > > Subject: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > > switch support
> > >
> > > 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-
> > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Yao,
> > > > Jiewen
> > > > Sent: Thursday, November 23, 2017 1:50 PM
> > > > To: Wang, Jian J ; edk2-devel@lists.01.org
> > > > Cc: Kinney, Michael D ; Dong, Eric
> > > > ; Zeng, Star 
> > > > Subject: Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib:
> Add
> > > > stack switch support
> > > >
> > > > 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 IA32_GDT_TYPE_TSS   0x9
> > > > This is generic, can we move to BaseLib.h?
> > > 

Re: [edk2] SCT Test crashes After HTTPS boot success.

[Wu, Jiaxin]

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 ValidateBootImageThruNet to yes in 
EfiCompliant.ini file but the SetupMode in your platform is 1, which means the 
platform doesn't support to validate a boot image.

c:\work\sct\utwg\uefi-sct\SctPkg\TestCase\UEFI\EFI\Generic\EfiCompliant\BlackBoxTest\EfiCompliantBBTestPlatform_uefi.c:2185:NVM
 Express Pass Thru protocol - No
c:\work\sct\utwg\uefi-sct\SctPkg\TestCase\UEFI\EFI\Generic\EfiCompliant\BlackBoxTest\EfiCompliantBBTestPlatform_uefi.c:2306:NVMExpressPassThru
 - No
Jiaxin: No NvmExpressDxe Module in your platform.

c:\work\sct\utwg\uefi-sct\SctPkg\TestCase\UEFI\EFI\Generic\EfiCompliant\BlackBoxTest\EfiCompliantBBTestPlatform_uefi.c:2379:Ext
 SCSI Pass Thru - No
c:\work\sct\utwg\uefi-sct\SctPkg\TestCase\UEFI\EFI\Generic\EfiCompliant\BlackBoxTest\EfiCompliantBBTestPlatform_uefi.c:2478:SCSI
 IO - No, Block IO - Yes
Jiaxin: No driver produce the ExtScsiPassThruProtocol, so your platform doesn't 
include an I/O system that uses SCSI command packets. For this case, you can 
setup ISCSI connection, then the failure should be gone. Or set the value of 
ExtScsiPassThru to no in EfiCompliant.ini file if you don't care about it.

c:\work\sct\utwg\uefi-sct\SctPkg\TestCase\UEFI\EFI\Generic\EfiCompliant\BlackBoxTest\EfiCompliantBBTestPlatform_uefi.c:2690:Debug
 Support - Yes, Debug Port - No
Jiaxin: No DebugPortDxe Module in your platform.

c:\work\sct\utwg\uefi-sct\SctPkg\TestCase\UEFI\EFI\Generic\EfiCompliant\BlackBoxTest\EfiCompliantBBTestPlatform_uefi.c:2829:Ata
 Pass Thru - No
Jiaxin: No AtaBusDxe Module in your platform.

c:\work\sct\utwg\uefi-sct\SctPkg\TestCase\UEFI\EFI\Generic\EfiCompliant\BlackBoxTest\EfiCompliantBBTestPlatform_uefi.c:3558:EAP
 - No, EAP Config - No, EAP Management2 - No
c:\work\sct\utwg\uefi-sct\SctPkg\TestCase\UEFI\EFI\Generic\EfiCompliant\BlackBoxTest\EfiCompliantBBTestPlatform_uefi.c:3653:BLUETOOTH
 HC - No, BLUETOOTH Service Binding - No, BLUETOOTH Config - No
Jiaxin: No EAP/ BLUETOOTH modules in your platform.

For the Hii part, I can't reproduce the failure with UDK2017 code base. I think 
it's much related to your platform.

Thanks,
Jiaxin

From: Wu, Jiaxin
Sent: Thursday, November 23, 2017 12:51 PM
To: Karunakar P ; 'edk2-devel@lists.01.org' 

Cc: Fu, Siyuan ; Ye, Ting ; Jin, Eric 

Subject: RE: SCT Test crashes After HTTPS boot success.

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 to the above sentence that all of 
the TlsSB/TlsProtocol/TlsConfigProtocol must exist, if not, the failure happen.

For other cases, we will review them, then feedback to you.

Thanks,
Jiaxin




From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Wednesday, November 22, 2017 6:25 PM
To: Wu, Jiaxin >; 
'edk2-devel@lists.01.org' 
>
Cc: Fu, Siyuan >; Ye, Ting 
>; Jin, Eric 
>
Subject: RE: SCT Test crashes After HTTPS boot success.

Hi Jiaxin,

Thank you very much for your detailed explanation.

After talk with SCT expert (Jin, Eric 
>) , we agree the Spec may need 
to be updated since it can mislead the caller.
Sorry, I didn't get the point here, whether we're going to update SCT spec to 
resolve this TLS failure?

And regards other failures

? The platform have SCSI module, PXE_BC protocols and one of UNDI/SNP/MNP are 
present, But still I'm getting SCT failures related to this.

? Also there are some failures in HiiTest

Could you please provide your comments/Suggestions on other failures too.

Thank You.
Karunakar

From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Wednesday, November 22, 2017 2:13 PM
To: Karunakar P; 'edk2-devel@lists.01.org'
Cc: Fu, Siyuan; Ye, Ting; Jin, Eric
Subject: RE: SCT Test crashes After HTTPS boot success.

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 and
EFI_TLS_CONFIGURATION_PROTOCOL are required.

So, the SCT will check the EFI_TLS_SERVICE_BINDING_PROTOCOL, EFI_TLS_PROTOCOL 

Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Wang, Jian J]

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 changes than just updating InitializeCpuExceptionHandlers(). If so, it 
may
be premature to figure out a solution at this patch.

In addition, CpuDxe actually calls InitializeCpuInterruptHandlers() which 
covers the
functionalities of InitializeCpuExceptionHandlers() (its settings will be 
overwritten).
If we want AP to initialize interrupt and exception individually, maybe we 
should
let AP call InitializeCpuInterruptHandlers() instead.

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 23, 2017 2:16 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Zeng, Star ; Dong, Eric ;
> Kinney, Michael D 
> Subject: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch support
> 
> 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 provide the symbol.
> 
> 1.2) For SMM, I think our ultimate goal is to remove SMM specific stack guard,
> and use the common one. Duplicating code is completely unnecessary, and it is
> easy to introduce bug. And unfortunately, we already have bug in existing SMM
> exception handler. -- That is a good reason to remove duplication.
> 
> Again, it is not necessary to do it in this patch. I am totally OK to do it 
> in another
> patch.
> 
> 1.3) For PEI, I do not think we can use current way to allocate stack in data
> section, because it might be readonly in pre-mem phase. We must use some
> other way.
> 
> 1.4) I believe this patch has a hidden assumption is that:
> InitializeCpuExceptionHandlers() won't be called by multiple APs.
> If 2 or more APs call the it at same time, it might be broken because you use
> mNewStack for all the callers
> Is that right?
> 
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, November 23, 2017 2:06 PM
> > To: Yao, Jiewen ; edk2-devel@lists.01.org
> > Cc: Zeng, Star ; Dong, Eric ;
> Kinney,
> > Michael D 
> > Subject: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > switch support
> >
> >
> >
> > > -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: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > > switch support
> > >
> > > 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.
> > >
> > Like what we discussed before, this series of patch is for Stack Guard 
> > feature
> > which
> > is only available for DXE (because Stack Guard needs paging to work). Stack
> > switch
> > is enabled for the sake of Stack Guard feature. So I think it's enough to
> > implement
> > it in DxeException.c. In addition, SMM has its own implementation of stack
> guard
> > and stack switch. It's not necessary to do it again.
> >
> > I agree with you that we should merge those common code but I think we
> should
> > do
> > it in a separate patch series since it's not Stack Guard relevant. And I've
> removed
> > all architecture issues I can think of. Current stack switch initialization 
> > should
> work
> > for both PEI and SMM as well.
> >
> > > 2) #define IA32_GDT_TYPE_TSS   0x9
> > > This is generic, can we move to BaseLib.h?
> > >
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > >
> > > > -Original Message-
> > > > From: Wang, Jian J
> > > > Sent: Wednesday, November 22, 2017 4:46 PM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Zeng, Star ; Dong, Eric ;
> Yao,
> > > > Jiewen ; Kinney, Michael D
> > > > 
> > > > Subject: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > > switch
> > > > support
> > > >
> > > > > v2:
> > > > >a. Move common TSS structure and API definitions to BaseLib.h
> > > > >b. Add EXCEPTION_STACK_SWITCH_DATA to convery data used 

Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Yao, Jiewen]

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 impact?
2) If PcdCpuStackGuard is TRUE, and CPU driver is still consuming existing API 
in ExceptionLib. Is there any impact?
3) If PcdCpuStackGuard is FALSE, and CPU driver is not consuming existing API 
in ExceptionLib. Is there any impact?
4) If PcdCpuStackGuard is TRUE, and CPU driver is not consuming existing API in 
ExceptionLib. Is there any impact?


Thank you
Yao Jiewen

> -Original Message-
> From: Wang, Jian J
> Sent: Thursday, November 23, 2017 2:09 PM
> To: Yao, Jiewen ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Dong, Eric
> ; Zeng, Star 
> Subject: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch support
> 
> 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, November 23, 2017 1:59 PM
> > To: Yao, Jiewen ; Wang, Jian J
> ;
> > edk2-devel@lists.01.org
> > Cc: Kinney, Michael D ; Dong, Eric
> > ; Zeng, Star 
> > Subject: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > switch support
> >
> > 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-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Yao,
> > > Jiewen
> > > Sent: Thursday, November 23, 2017 1:50 PM
> > > To: Wang, Jian J ; edk2-devel@lists.01.org
> > > Cc: Kinney, Michael D ; Dong, Eric
> > > ; Zeng, Star 
> > > Subject: Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add
> > > stack switch support
> > >
> > > 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 IA32_GDT_TYPE_TSS   0x9
> > > This is generic, can we move to BaseLib.h?
> > >
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > >
> > > > -Original Message-
> > > > From: Wang, Jian J
> > > > Sent: Wednesday, November 22, 2017 4:46 PM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Zeng, Star ; Dong, Eric ;
> > Yao,
> > > > Jiewen ; Kinney, Michael D
> > > > 
> > > > Subject: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > switch
> > > > support
> > > >
> > > > > 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
> > > > >   phase of DXE core.
> > > > >d. Remove the filter code used to exclude boot modes which doesn't
> > > > support
> > > > >   memory allocation because those memory can passed in by
> > > parameter
> > > > now.
> > > > >e. Remove the nasm macro to define exception handler one by one
> and
> > > > add a
> > > > >   function to return the start address of each handler.
> > > >
> > > > If Stack Guard is enabled and there's really a stack overflow happened
> during
> > > > boot, a Page Fault exception will be triggered. Because the stack is 
> > > > out of
> > > > usage, the exception handler, which shares the stack with normal UEFI
> driver,
> > > > cannot be executed and cannot dump the processor information.
> > > >
> > > > Without those information, it's very difficult for the BIOS developers 
> > > > locate
> > > > the root cause of stack overflow. And without a workable stack, the
> > developer
> > > > cannot event use single step to debug the UEFI driver with JTAG 
> > > > debugger.
> > > >
> > > > In order to make sure the exception handler to execute normally after 
> > > > stack
> > > > overflow. We need 

Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Yao, Jiewen]

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 provide the symbol.

1.2) For SMM, I think our ultimate goal is to remove SMM specific stack guard, 
and use the common one. Duplicating code is completely unnecessary, and it is 
easy to introduce bug. And unfortunately, we already have bug in existing SMM 
exception handler. -- That is a good reason to remove duplication.

Again, it is not necessary to do it in this patch. I am totally OK to do it in 
another patch.

1.3) For PEI, I do not think we can use current way to allocate stack in data 
section, because it might be readonly in pre-mem phase. We must use some other 
way.

1.4) I believe this patch has a hidden assumption is that: 
InitializeCpuExceptionHandlers() won't be called by multiple APs.
If 2 or more APs call the it at same time, it might be broken because you use 
mNewStack for all the callers
Is that right?


Thank you
Yao Jiewen


> -Original Message-
> From: Wang, Jian J
> Sent: Thursday, November 23, 2017 2:06 PM
> To: Yao, Jiewen ; edk2-devel@lists.01.org
> Cc: Zeng, Star ; Dong, Eric ; 
> Kinney,
> Michael D 
> Subject: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch support
> 
> 
> 
> > -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: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > switch support
> >
> > 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.
> >
> Like what we discussed before, this series of patch is for Stack Guard feature
> which
> is only available for DXE (because Stack Guard needs paging to work). Stack
> switch
> is enabled for the sake of Stack Guard feature. So I think it's enough to
> implement
> it in DxeException.c. In addition, SMM has its own implementation of stack 
> guard
> and stack switch. It's not necessary to do it again.
> 
> I agree with you that we should merge those common code but I think we should
> do
> it in a separate patch series since it's not Stack Guard relevant. And I've 
> removed
> all architecture issues I can think of. Current stack switch initialization 
> should work
> for both PEI and SMM as well.
> 
> > 2) #define IA32_GDT_TYPE_TSS   0x9
> > This is generic, can we move to BaseLib.h?
> >
> >
> > Thank you
> > Yao Jiewen
> >
> >
> > > -Original Message-
> > > From: Wang, Jian J
> > > Sent: Wednesday, November 22, 2017 4:46 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Zeng, Star ; Dong, Eric ; 
> > > Yao,
> > > Jiewen ; Kinney, Michael D
> > > 
> > > Subject: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > switch
> > > support
> > >
> > > > 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
> > > >   phase of DXE core.
> > > >d. Remove the filter code used to exclude boot modes which doesn't
> > > support
> > > >   memory allocation because those memory can passed in by
> parameter
> > > now.
> > > >e. Remove the nasm macro to define exception handler one by one
> and
> > > add a
> > > >   function to return the start address of each handler.
> > >
> > > If Stack Guard is enabled and there's really a stack overflow happened 
> > > during
> > > boot, a Page Fault exception will be triggered. Because the stack is out 
> > > of
> > > usage, the exception handler, which shares the stack with normal UEFI 
> > > driver,
> > > cannot be executed and cannot dump the processor information.
> > >
> > > Without those information, it's very difficult for the BIOS developers 
> > > locate
> > > the root cause of stack overflow. And without a workable stack, the
> developer
> > > cannot event use single step to debug the UEFI driver with JTAG debugger.
> > >
> > > In order to make sure the exception handler to execute normally after 
> > > stack
> > > overflow. We need 

[edk2] [Patch][edk2-platforms] Toolchain

[lushifex]

Add toolchain for VS2015 build.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lushifex 
---
 .../PlatformSetupDxe/SetupInfoRecords.c| 30 +++
 .../SmBiosMiscDxe/MiscProcessorCacheFunction.c |  8 ++--
 .../VlvPlatformInitDxe/VlvPlatformInit.c   |  4 +-
 Vlv2TbltDevicePkg/bld_vlv.bat  | 45 +-
 4 files changed, 47 insertions(+), 40 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformSetupDxe/SetupInfoRecords.c 
b/Vlv2TbltDevicePkg/PlatformSetupDxe/SetupInfoRecords.c
index 8979b41..6a17643 100644
--- a/Vlv2TbltDevicePkg/PlatformSetupDxe/SetupInfoRecords.c
+++ b/Vlv2TbltDevicePkg/PlatformSetupDxe/SetupInfoRecords.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2004  - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2004  - 2017, Intel Corporation. All rights reserved.



   This program and the accompanying materials are licensed and made available 
under

   the terms and conditions of the BSD License that accompanies this 
distribution.  

@@ -1186,7 +1186,7 @@ UpdatePlatformInformation (
   EFI_STATUS   Status;
   UINT8CpuFlavor=0;
   EFI_PEI_HOB_POINTERS GuidHob;
-  EFI_PLATFORM_INFO_HOB*mPlatformInfo=NULL;
+  EFI_PLATFORM_INFO_HOB*PlatformInfo=NULL;
   UINTNNumHandles;
   EFI_HANDLE*HandleBuffer;
   UINTN Index;
@@ -1205,7 +1205,7 @@ UpdatePlatformInformation (
   GuidHob.Raw = GetHobList ();
   if (GuidHob.Raw != NULL) {
 if ((GuidHob.Raw = GetNextGuidHob (, GuidHob.Raw)) != 
NULL) {
-  mPlatformInfo = GET_GUID_HOB_DATA (GuidHob.Guid);
+  PlatformInfo = GET_GUID_HOB_DATA (GuidHob.Guid);
 }
   }
 
@@ -1274,41 +1274,41 @@ UpdatePlatformInformation (
   }
   HiiSetString(mHiiHandle,STRING_TOKEN(STR_CPU_FLAVOR_VALUE), Buffer, NULL);
 
-  if ( NULL != mPlatformInfo) {
+  if ( NULL != PlatformInfo) {
 //
 //BoardId
 //
-switch(mPlatformInfo->BoardId){
+switch(PlatformInfo->BoardId){
   case 0x2:
-UnicodeSPrint (Buffer, sizeof (Buffer), L"BAY LAKE RVP(%02x)", 
mPlatformInfo->BoardId);
+UnicodeSPrint (Buffer, sizeof (Buffer), L"BAY LAKE RVP(%02x)", 
PlatformInfo->BoardId);
 break;
 
   case 0x4:
-UnicodeSPrint (Buffer, sizeof (Buffer), L"BAY LAKE FFRD(%02x)", 
mPlatformInfo->BoardId);
+UnicodeSPrint (Buffer, sizeof (Buffer), L"BAY LAKE FFRD(%02x)", 
PlatformInfo->BoardId);
 break;
 
   case 0x5:
-UnicodeSPrint (Buffer, sizeof (Buffer), L"BAY ROCK RVP DDR3L (%02x)", 
mPlatformInfo->BoardId);
+UnicodeSPrint (Buffer, sizeof (Buffer), L"BAY ROCK RVP DDR3L (%02x)", 
PlatformInfo->BoardId);
 break;
 
   case 0x20:
-UnicodeSPrint (Buffer, sizeof (Buffer), L"BAYLEY BAY (%02x)", 
mPlatformInfo->BoardId);
+UnicodeSPrint (Buffer, sizeof (Buffer), L"BAYLEY BAY (%02x)", 
PlatformInfo->BoardId);
 break;
 
   case 0x30:
-UnicodeSPrint (Buffer, sizeof (Buffer), L"BAKER SPORT (%02x)", 
mPlatformInfo->BoardId);
+UnicodeSPrint (Buffer, sizeof (Buffer), L"BAKER SPORT (%02x)", 
PlatformInfo->BoardId);
 break;
 
   case 0x0:
-UnicodeSPrint (Buffer, sizeof (Buffer), L"ALPINE VALLEY (%x)", 
mPlatformInfo->BoardId);
+UnicodeSPrint (Buffer, sizeof (Buffer), L"ALPINE VALLEY (%x)", 
PlatformInfo->BoardId);
 break;
 
   case 0x3:
-UnicodeSPrint (Buffer, sizeof (Buffer), L"BAY LAKE FFD8 (%x)", 
mPlatformInfo->BoardId);
+UnicodeSPrint (Buffer, sizeof (Buffer), L"BAY LAKE FFD8 (%x)", 
PlatformInfo->BoardId);
 break;
 
   default:
-UnicodeSPrint (Buffer, sizeof (Buffer), L"Unknown BOARD (%02x)", 
mPlatformInfo->BoardId);
+UnicodeSPrint (Buffer, sizeof (Buffer), L"Unknown BOARD (%02x)", 
PlatformInfo->BoardId);
 break;
 }
 HiiSetString(mHiiHandle,STRING_TOKEN(STR_BOARD_ID_VALUE), Buffer, NULL);
@@ -1318,11 +1318,11 @@ UpdatePlatformInformation (
 // Get Board FAB ID Info from protocol, update into the NVS area.
 // bit0~bit3 are for Fab ID, 0x0F means unknow FAB.
 //
-if(mPlatformInfo->BoardRev == 0x0F) {
+if(PlatformInfo->BoardRev == 0x0F) {
   UnicodeSPrint (Buffer, sizeof (Buffer), L"%s", L"Unknown FAB");
   HiiSetString(mHiiHandle,STRING_TOKEN(STR_FAB_ID_VALUE), Buffer, NULL);
 } else {
-  UnicodeSPrint (Buffer, sizeof (Buffer), L"%2x", mPlatformInfo->BoardRev);
+  UnicodeSPrint (Buffer, sizeof (Buffer), L"%2x", PlatformInfo->BoardRev);
   HiiSetString(mHiiHandle,STRING_TOKEN(STR_FAB_ID_VALUE), Buffer, NULL);
 }
   }
diff --git a/Vlv2TbltDevicePkg/SmBiosMiscDxe/MiscProcessorCacheFunction.c 
b/Vlv2TbltDevicePkg/SmBiosMiscDxe/MiscProcessorCacheFunction.c
index b18a6aa..f38bfc4 100644
--- 

Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Wang, Jian J]

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, November 23, 2017 1:59 PM
> To: Yao, Jiewen ; Wang, Jian J ;
> edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Dong, Eric
> ; Zeng, Star 
> Subject: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch support
> 
> 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-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao,
> > Jiewen
> > Sent: Thursday, November 23, 2017 1:50 PM
> > To: Wang, Jian J ; edk2-devel@lists.01.org
> > Cc: Kinney, Michael D ; Dong, Eric
> > ; Zeng, Star 
> > Subject: Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add
> > stack switch support
> >
> > 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 IA32_GDT_TYPE_TSS   0x9
> > This is generic, can we move to BaseLib.h?
> >
> >
> > Thank you
> > Yao Jiewen
> >
> >
> > > -Original Message-
> > > From: Wang, Jian J
> > > Sent: Wednesday, November 22, 2017 4:46 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Zeng, Star ; Dong, Eric ;
> Yao,
> > > Jiewen ; Kinney, Michael D
> > > 
> > > Subject: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch
> > > support
> > >
> > > > 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
> > > >   phase of DXE core.
> > > >d. Remove the filter code used to exclude boot modes which doesn't
> > > support
> > > >   memory allocation because those memory can passed in by
> > parameter
> > > now.
> > > >e. Remove the nasm macro to define exception handler one by one and
> > > add a
> > > >   function to return the start address of each handler.
> > >
> > > If Stack Guard is enabled and there's really a stack overflow happened 
> > > during
> > > boot, a Page Fault exception will be triggered. Because the stack is out 
> > > of
> > > usage, the exception handler, which shares the stack with normal UEFI 
> > > driver,
> > > cannot be executed and cannot dump the processor information.
> > >
> > > Without those information, it's very difficult for the BIOS developers 
> > > locate
> > > the root cause of stack overflow. And without a workable stack, the
> developer
> > > cannot event use single step to debug the UEFI driver with JTAG debugger.
> > >
> > > In order to make sure the exception handler to execute normally after 
> > > stack
> > > overflow. We need separate stacks for exception handlers in case of
> unusable
> > > stack.
> > >
> > > IA processor allows to switch to a new stack during handling interrupt and
> > > exception. But X64 and IA32 provides different ways to make it. X64 
> > > provides
> > > interrupt stack table (IST) to allow maximum 7 different exceptions to 
> > > have
> > > new stack for its handler. IA32 doesn't have IST mechanism and can only 
> > > use
> > > task gate to do it since task switch allows to load a new stack through 
> > > its
> > > task-state segment (TSS).
> > >
> > > Cc: Star Zeng 
> > > Cc: Eric Dong 
> > > Cc: Jiewen Yao 
> > > Cc: Michael Kinney 
> > > Suggested-by: Ayellet Wolman 
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Jian J Wang 
> > > ---
> > >  .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  50 +++
> > >  .../DxeCpuExceptionHandlerLib.inf  |   6 +
> > >  .../Library/CpuExceptionHandlerLib/DxeException.c  |  53 ++-
> > >  .../Ia32/ArchExceptionHandler.c| 167 +
> > >  .../Ia32/ArchInterruptDefs.h   |   8 

Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Wang, Jian J]

> -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: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch support
> 
> 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.
> 
Like what we discussed before, this series of patch is for Stack Guard feature 
which
is only available for DXE (because Stack Guard needs paging to work). Stack 
switch
is enabled for the sake of Stack Guard feature. So I think it's enough to 
implement
it in DxeException.c. In addition, SMM has its own implementation of stack guard
and stack switch. It's not necessary to do it again.

I agree with you that we should merge those common code but I think we should do
it in a separate patch series since it's not Stack Guard relevant. And I've 
removed
all architecture issues I can think of. Current stack switch initialization 
should work
for both PEI and SMM as well.

> 2) #define IA32_GDT_TYPE_TSS   0x9
> This is generic, can we move to BaseLib.h?
> 
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Wednesday, November 22, 2017 4:46 PM
> > To: edk2-devel@lists.01.org
> > Cc: Zeng, Star ; Dong, Eric ; Yao,
> > Jiewen ; Kinney, Michael D
> > 
> > Subject: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch
> > support
> >
> > > 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
> > >   phase of DXE core.
> > >d. Remove the filter code used to exclude boot modes which doesn't
> > support
> > >   memory allocation because those memory can passed in by parameter
> > now.
> > >e. Remove the nasm macro to define exception handler one by one and
> > add a
> > >   function to return the start address of each handler.
> >
> > If Stack Guard is enabled and there's really a stack overflow happened 
> > during
> > boot, a Page Fault exception will be triggered. Because the stack is out of
> > usage, the exception handler, which shares the stack with normal UEFI 
> > driver,
> > cannot be executed and cannot dump the processor information.
> >
> > Without those information, it's very difficult for the BIOS developers 
> > locate
> > the root cause of stack overflow. And without a workable stack, the 
> > developer
> > cannot event use single step to debug the UEFI driver with JTAG debugger.
> >
> > In order to make sure the exception handler to execute normally after stack
> > overflow. We need separate stacks for exception handlers in case of unusable
> > stack.
> >
> > IA processor allows to switch to a new stack during handling interrupt and
> > exception. But X64 and IA32 provides different ways to make it. X64 provides
> > interrupt stack table (IST) to allow maximum 7 different exceptions to have
> > new stack for its handler. IA32 doesn't have IST mechanism and can only use
> > task gate to do it since task switch allows to load a new stack through its
> > task-state segment (TSS).
> >
> > Cc: Star Zeng 
> > Cc: Eric Dong 
> > Cc: Jiewen Yao 
> > Cc: Michael Kinney 
> > Suggested-by: Ayellet Wolman 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang 
> > ---
> >  .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  50 +++
> >  .../DxeCpuExceptionHandlerLib.inf  |   6 +
> >  .../Library/CpuExceptionHandlerLib/DxeException.c  |  53 ++-
> >  .../Ia32/ArchExceptionHandler.c| 167 +
> >  .../Ia32/ArchInterruptDefs.h   |   8 +
> >  .../Ia32/ExceptionTssEntryAsm.nasm | 398
> > +
> >  .../PeiCpuExceptionHandlerLib.inf  |   1 +
> >  .../SecPeiCpuExceptionHandlerLib.inf   |   1 +
> >  .../SmmCpuExceptionHandlerLib.inf  |   1 +
> >  .../X64/ArchExceptionHandler.c | 133 +++
> >  .../CpuExceptionHandlerLib/X64/ArchInterruptDefs.h |   3 +
> >  11 files changed, 820 insertions(+), 1 deletion(-)
> >  create mode 100644
> >
> 

Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Yao, Jiewen]

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-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao,
> Jiewen
> Sent: Thursday, November 23, 2017 1:50 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Dong, Eric
> ; Zeng, Star 
> Subject: Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add
> stack switch support
> 
> 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 IA32_GDT_TYPE_TSS   0x9
> This is generic, can we move to BaseLib.h?
> 
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Wednesday, November 22, 2017 4:46 PM
> > To: edk2-devel@lists.01.org
> > Cc: Zeng, Star ; Dong, Eric ; Yao,
> > Jiewen ; Kinney, Michael D
> > 
> > Subject: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch
> > support
> >
> > > 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
> > >   phase of DXE core.
> > >d. Remove the filter code used to exclude boot modes which doesn't
> > support
> > >   memory allocation because those memory can passed in by
> parameter
> > now.
> > >e. Remove the nasm macro to define exception handler one by one and
> > add a
> > >   function to return the start address of each handler.
> >
> > If Stack Guard is enabled and there's really a stack overflow happened 
> > during
> > boot, a Page Fault exception will be triggered. Because the stack is out of
> > usage, the exception handler, which shares the stack with normal UEFI 
> > driver,
> > cannot be executed and cannot dump the processor information.
> >
> > Without those information, it's very difficult for the BIOS developers 
> > locate
> > the root cause of stack overflow. And without a workable stack, the 
> > developer
> > cannot event use single step to debug the UEFI driver with JTAG debugger.
> >
> > In order to make sure the exception handler to execute normally after stack
> > overflow. We need separate stacks for exception handlers in case of unusable
> > stack.
> >
> > IA processor allows to switch to a new stack during handling interrupt and
> > exception. But X64 and IA32 provides different ways to make it. X64 provides
> > interrupt stack table (IST) to allow maximum 7 different exceptions to have
> > new stack for its handler. IA32 doesn't have IST mechanism and can only use
> > task gate to do it since task switch allows to load a new stack through its
> > task-state segment (TSS).
> >
> > Cc: Star Zeng 
> > Cc: Eric Dong 
> > Cc: Jiewen Yao 
> > Cc: Michael Kinney 
> > Suggested-by: Ayellet Wolman 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang 
> > ---
> >  .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  50 +++
> >  .../DxeCpuExceptionHandlerLib.inf  |   6 +
> >  .../Library/CpuExceptionHandlerLib/DxeException.c  |  53 ++-
> >  .../Ia32/ArchExceptionHandler.c| 167 +
> >  .../Ia32/ArchInterruptDefs.h   |   8 +
> >  .../Ia32/ExceptionTssEntryAsm.nasm | 398
> > +
> >  .../PeiCpuExceptionHandlerLib.inf  |   1 +
> >  .../SecPeiCpuExceptionHandlerLib.inf   |   1 +
> >  .../SmmCpuExceptionHandlerLib.inf  |   1 +
> >  .../X64/ArchExceptionHandler.c | 133 +++
> >  .../CpuExceptionHandlerLib/X64/ArchInterruptDefs.h |   3 +
> >  11 files changed, 820 insertions(+), 1 deletion(-)
> >  create mode 100644
> >
> UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionTssEntryAsm.nasm
> >
> > diff --git
> > a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
> > b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
> > index 740a58828b..30334105d2 100644
> > --- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
> > +++ 

Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Yao, Jiewen]

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 IA32_GDT_TYPE_TSS   0x9
This is generic, can we move to BaseLib.h?


Thank you
Yao Jiewen


> -Original Message-
> From: Wang, Jian J
> Sent: Wednesday, November 22, 2017 4:46 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Dong, Eric ; Yao,
> Jiewen ; Kinney, Michael D
> 
> Subject: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch
> support
> 
> > 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
> >   phase of DXE core.
> >d. Remove the filter code used to exclude boot modes which doesn't
> support
> >   memory allocation because those memory can passed in by parameter
> now.
> >e. Remove the nasm macro to define exception handler one by one and
> add a
> >   function to return the start address of each handler.
> 
> If Stack Guard is enabled and there's really a stack overflow happened during
> boot, a Page Fault exception will be triggered. Because the stack is out of
> usage, the exception handler, which shares the stack with normal UEFI driver,
> cannot be executed and cannot dump the processor information.
> 
> Without those information, it's very difficult for the BIOS developers locate
> the root cause of stack overflow. And without a workable stack, the developer
> cannot event use single step to debug the UEFI driver with JTAG debugger.
> 
> In order to make sure the exception handler to execute normally after stack
> overflow. We need separate stacks for exception handlers in case of unusable
> stack.
> 
> IA processor allows to switch to a new stack during handling interrupt and
> exception. But X64 and IA32 provides different ways to make it. X64 provides
> interrupt stack table (IST) to allow maximum 7 different exceptions to have
> new stack for its handler. IA32 doesn't have IST mechanism and can only use
> task gate to do it since task switch allows to load a new stack through its
> task-state segment (TSS).
> 
> Cc: Star Zeng 
> Cc: Eric Dong 
> Cc: Jiewen Yao 
> Cc: Michael Kinney 
> Suggested-by: Ayellet Wolman 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  50 +++
>  .../DxeCpuExceptionHandlerLib.inf  |   6 +
>  .../Library/CpuExceptionHandlerLib/DxeException.c  |  53 ++-
>  .../Ia32/ArchExceptionHandler.c| 167 +
>  .../Ia32/ArchInterruptDefs.h   |   8 +
>  .../Ia32/ExceptionTssEntryAsm.nasm | 398
> +
>  .../PeiCpuExceptionHandlerLib.inf  |   1 +
>  .../SecPeiCpuExceptionHandlerLib.inf   |   1 +
>  .../SmmCpuExceptionHandlerLib.inf  |   1 +
>  .../X64/ArchExceptionHandler.c | 133 +++
>  .../CpuExceptionHandlerLib/X64/ArchInterruptDefs.h |   3 +
>  11 files changed, 820 insertions(+), 1 deletion(-)
>  create mode 100644
> UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionTssEntryAsm.nasm
> 
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
> index 740a58828b..30334105d2 100644
> --- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
> +++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
> @@ -48,6 +48,32 @@
>  0xb21d9148, 0x9211, 0x4d8f, { 0xad, 0xd3, 0x66, 0xb1, 0x89, 0xc9, 0x2c, 
> 0x83 }
> \
>}
> 
> +#define CPU_STACK_SWITCH_EXCEPTION_NUMBER \
> +  FixedPcdGetSize (PcdCpuStackSwitchExceptionList)
> +
> +#define CPU_STACK_SWITCH_EXCEPTION_LIST \
> +  FixedPcdGetPtr (PcdCpuStackSwitchExceptionList)
> +
> +#define CPU_KNOWN_GOOD_STACK_SIZE \
> +  FixedPcdGet32 (PcdCpuKnownGoodStackSize)
> +
> +#define CPU_TSS_GDT_SIZE (SIZE_2KB + CPU_TSS_DESC_SIZE + CPU_TSS_SIZE)
> +
> +#define IA32_GDT_TYPE_TSS   0x9
> +#define IA32_GDT_ALIGNMENT  8
> +
> +typedef struct {
> +  UINTN StackTop;
> +  UINTN StackSize;
> +  UINT8 *Exceptions;
> +  UINTN ExceptionNumber;
> +  IA32_IDT_GATE_DESCRIPTOR  *IdtTable;
> +  IA32_SEGMENT_DESCRIPTOR   *GdtTable;
> +  UINTN 

Re: [edk2] [PATCH v2 0/8] Implement stack guard feature

[Yao, Jiewen]

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
> To: Yao, Jiewen ; edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH v2 0/8] Implement stack guard feature
> 
> 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 ; edk2-devel@lists.01.org
> > Subject: RE: [edk2] [PATCH v2 0/8] Implement stack guard feature
> >
> > 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
> > > Subject: [edk2] [PATCH v2 0/8] Implement stack guard feature
> > >
> > > 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 stack size.
> > >
> > > If this feature is enabled, DxeIpl will setup page tables and set page 
> > > where
> > > the stack bottom is at to be NON-PRESENT. If stack overflow occurs, Page
> > > Fault exception will be triggered.
> > >
> > > In order to make sure exception handler works normally even when the stack
> > > is corrupted, stack switching is implemented in exception library.
> > >
> > > Due to the mechanism behind Stack Guard, this feature is only avaiable for
> > > UEFI drivers (memory avaiable). That also means it doesn't support NT32
> > > emulated platform (paging not supported).
> > >
> > > Validation works include:
> > >   a. OVMF emulated platform: boot to shell (IA32/X64)
> > >   b. Intel real platform: boot to shell (IA32/X64)
> > >
> > > Jian J Wang (8):
> > >   MdeModulePkg/metafile: Add PCD PcdCpuStackGuard
> > >   MdeModulePkg/CpuExceptionHandlerLib.h: Add a new API
> > >   MdePkg/BaseLib: Add stack switch related definitions for IA32
> > >   MdeModulePkg/DxeIpl: Enable paging for Stack Guard
> > >   UefiCpuPkg/UefiCpuPkg.dec: Add two new PCDs for stack switch
> > >   UefiCpuPkg/MpLib: Add GDTR, IDTR and TR in saved AP data
> > >   UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support
> > >   UefiCpuPkg/CpuDxe: Initialize stack switch for MP
> > >
> > >  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   5 +-
> > >  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c|   4 +
> > >  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c |   1 +
> > >  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c   |  51 ++-
> > >  .../Include/Library/CpuExceptionHandlerLib.h   |  18 +
> > >  MdeModulePkg/MdeModulePkg.dec  |   7 +
> > >  MdeModulePkg/MdeModulePkg.uni  |   7 +
> > >  MdePkg/Include/Library/BaseLib.h   | 115 ++
> > >  MdePkg/Library/BaseLib/BaseLib.inf |   3 +
> > >  MdePkg/Library/BaseLib/Ia32/WriteTr.nasm   |  36 ++
> > >  MdePkg/Library/BaseLib/X64/WriteTr.nasm|  37 ++
> > >  UefiCpuPkg/CpuDxe/CpuDxe.inf   |   3 +
> > >  UefiCpuPkg/CpuDxe/CpuMp.c  | 168
> +
> > >  UefiCpuPkg/CpuDxe/CpuMp.h  |  12 +
> > >  .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  50 +++
> > >  .../DxeCpuExceptionHandlerLib.inf  |   6 +
> > >  .../Library/CpuExceptionHandlerLib/DxeException.c  |  53 ++-
> > >  .../Ia32/ArchExceptionHandler.c| 167 +
> > >  .../Ia32/ArchInterruptDefs.h   |   8 +
> > >  .../Ia32/ExceptionTssEntryAsm.nasm | 398
> > > +
> > >  .../PeiCpuExceptionHandlerLib.inf  |   1 +
> > >  .../SecPeiCpuExceptionHandlerLib.inf   |   1 +
> > >  .../SmmCpuExceptionHandlerLib.inf  |   1 +
> > >  .../X64/ArchExceptionHandler.c | 133 +++
> > >  .../CpuExceptionHandlerLib/X64/ArchInterruptDefs.h |   3 +
> > >  UefiCpuPkg/Library/MpInitLib/MpLib.c   |  17 +
> > >  UefiCpuPkg/Library/MpInitLib/MpLib.h   |   3 +
> > >  UefiCpuPkg/UefiCpuPkg.dec  |  12 +
> > >  28 files changed, 1304 insertions(+), 16 deletions(-)
> > >  create mode 100644 MdePkg/Library/BaseLib/Ia32/WriteTr.nasm
> > >  create mode 100644 MdePkg/Library/BaseLib/X64/WriteTr.nasm
> > >  

Re: [edk2] [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for MP

[Yao, Jiewen]

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: Kinney, Michael D ; Laszlo Ersek
> ; Dong, Eric 
> Subject: RE: [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for MP
> 
> 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;
> +  IA32_DESCRIPTOR   Idtr;
> +  IA32_DESCRIPTOR   Gdtr;
> +
>mExceptionHandlerData.ReservedVectors  =
> mReservedVectorsData;
>mExceptionHandlerData.ExternalInterruptHandler =
> mExternalInterruptHandlerTable;
>InitializeSpinLock ();
> -  return InitializeCpuExceptionHandlersWorker (VectorInfo,
> );
> +  Status = InitializeCpuExceptionHandlersWorker (VectorInfo,
> );
> +  if (!EFI_ERROR (Status) && PcdGetBool (PcdCpuStackGuard)) {
> +AsmReadIdtr ();
> +AsmReadGdtr ();
> +
> +StackSwitchData.StackTop = (UINTN)mNewStack;
> +StackSwitchData.StackSize = CPU_KNOWN_GOOD_STACK_SIZE;
> +StackSwitchData.Exceptions = CPU_STACK_SWITCH_EXCEPTION_LIST;
> +StackSwitchData.ExceptionNumber =
> CPU_STACK_SWITCH_EXCEPTION_NUMBER;
> +StackSwitchData.IdtTable = (IA32_IDT_GATE_DESCRIPTOR *)Idtr.Base;
> +StackSwitchData.GdtTable = (IA32_SEGMENT_DESCRIPTOR *)mNewGdt;
> +StackSwitchData.GdtSize = sizeof (mNewGdt);
> +StackSwitchData.TssDesc = (IA32_TSS_DESCRIPTOR *)(mNewGdt +
> Gdtr.Limit + 1);
> +StackSwitchData.Tss = (IA32_TASK_STATE_SEGMENT *)(mNewGdt +
> Gdtr.Limit + 1 +
> +
> CPU_TSS_DESC_SIZE);
> +Status = InitializeCpuExceptionStackSwitchHandlers (
> +   
> +   );
> +  }
> +  return Status;
>  }
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Wang,
> > Jian J
> > Sent: Thursday, November 23, 2017 1:04 PM
> > To: Yao, Jiewen ; edk2-devel@lists.01.org
> > Cc: Kinney, Michael D ; Laszlo Ersek
> > ; Dong, Eric 
> > Subject: Re: [edk2] [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack 
> > switch
> > for MP
> >
> > 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 
> > > Subject: RE: [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch 
> > > for MP
> > >
> > > Hi
> > > 1) Can we enable this feature in early DxeCore?
> > >
> > Yes. Intead of calling InitializeExceptionStackSwitchHandlers () directly in
> > DxeCore,
> > InitializeCpuExceptionHandlers() calls 
> > InitializeExceptionStackSwitchHandlers().
> >
> > I think it's reasonable to do this because
> InitializeExceptionStackSwitchHandlers()
> > is arch dependent. It'd be better not to call it in DxeCore. Another 
> > benefit is
> that
> > this can avoid backward compatibility issue introduced by new API, which 
> > hasn't
> > been implemented by cpu driver or lib of other archs.
> >
> > > 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 DxeCore.
> > >
> > > 2) In addition, InitializeCpuExceptionHandlers () has VectorInfoList as
> > parameter.
> > > Do we also need that for InitializeExceptionStackSwitchHandlers()?
> > >
> > I don't see the need. Do you have any use cases in mind?
> >
> > > Thank you
> > > Yao Jiewen
> > >
> > > > -Original Message-
> > > > From: Wang, Jian J
> > > > Sent: Wednesday, November 22, 2017 4:46 PM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Dong, Eric ; Laszlo Ersek ;
> > > Yao,
> > > > Jiewen ; Kinney, Michael D
> > > > 
> > > > Subject: [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for 
> > > > MP
> > > >
> > > > > 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 own configuration. This patch 

Re: [edk2] EDK2 build issues

[Gao, Liming]

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: af...@apple.com [mailto:af...@apple.com]
>Sent: Thursday, November 23, 2017 8:02 AM
>To: Desimone, Nathaniel L 
>Cc: Gao, Liming ; Aaron Durbin
>; edk2-devel@lists.01.org
>Subject: Re: [edk2] EDK2 build issues
>
>
>> 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 a few issues like that in BaseTools. We have a parallel
>makefile and we had to turn off parallelism when calling the BaseTools.
>
>In general the edk2 build system fights against "make -j " since the Python
>build command is trying to do the threading and invoking make in parallel.
>Given we ported EDK to parallel build, the Python parallel edk2 build is a lot
>slower than the EDK make parallel build, even when adjusting for the extra
>work the edk2 does.
>
>I even noticed a 1,000,000 calls to regex in Python during the ... phase of the
>build.
>
>I think the correct short term fix may be to put .NOTPARALLEL: in the
>BaseTools GNUmakefile given it is constructed in a way that it does not
>support parallelism.
>
>Thanks,
>
>Andrew Fish
>
>
>
>> https://bugzilla.tianocore.org/show_bug.cgi?id=786
>>
>> For the ARCH environment variable, we brainstormed two possible new
>names HOST_ARCH or BASETOOLS_ARCH. Should I file the ARCH variable
>request in Bugzilla as well?
>>
>> Thanks,
>>
>> Nate
>>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Gao, Liming
>> Sent: Monday, November 13, 2017 5:46 PM
>> To: Aaron Durbin 
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: [edk2] EDK2 build issues
>>
>> I add my comments.
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>>> Aaron Durbin
>>> Sent: Tuesday, November 14, 2017 1:38 AM
>>> To: Gao, Liming 
>>> Cc: edk2-devel@lists.01.org
>>> Subject: Re: [edk2] EDK2 build issues
>>>
>>> On Sun, Nov 12, 2017 at 7:15 PM, Gao, Liming 
>wrote:
 Yes. BaseTools needs some environments. Before build BaseTools, we
>need to call edkset.sh to setup them.

 1. BaseTools Soure tools are compiled in serial instead of parallel.
 And, VfrCompiler depends on Anltr tool. So, Anltr is required to be
>>> built first. I agree that this way takes some time to compile
>>> BaseTools source. I have one proposal to compile C source tools with
>multiple thread. I can share my draft patch.
>>>
>>> If the depedencies are correctly met in the makefiles then why are
>>> they built serially? It sounds like you understand the dependencies so
>>> why aren't those explicitly noted so one can build in parallel?
>>>
>> Seemly, VfrCompiler Makefile doesn't list those dependency clearly. Could
>you submit this issue in bugzillar (https://bugzilla.tianocore.org/)?
>> Besides, do you use make -j option to enable Parallel Execution? I want to
>know how to verify it.
>>
 2. BaseTools C source are compiled to the executable files. They run
 in host machine. Here ARCH is for the executable files those can
>>> run in host machine. edk2\BaseTools\Source\C\GNUmakefile auto detects
>ARCH based on 'uname -m' command.
>>>
>>> ARCH != host is my point. Why are those being conflated? Or are you
>>> saying edk2 tools define ARCH to be what the host is?
>>>
>> Yes. Edk2 BaseTools C source uses it as host arch. I agree ARCH name is too
>generic. In your environment, ARCH may be defined for the different purpose.
>>
 3. There are more GCC compiler distribution. We try to use the
 generic options in GCC tool chain. If you find the option doesn't
 work
>>> on your GCC compiler, please report it. And, we also notice
>>> tools_def.txt is too big to be hard to be maintain. We have one proposal to
>simplify it. I will send this RFC to edk2 community.

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> Of Aaron Durbin
> Sent: Saturday, November 11, 2017 6:27 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] EDK2 build issues
>
> Hello,
>
> Here are some observations I've encountered trying to utilize edk2
> for certain builds. Part of the problem seems to be with implicit
> assumptions in how edk2 is used. I'm trying to build things using
> edk2 from a clean enviroment on an automated builder. i.e. there
> isn't a workspace that exists on one persons 

Re: [edk2] [PATCH 3/5] MdeModulePkg/UefiBootManagerLib: report EDKII_OS_LOADER_DETAIL status code

[Ni, Ruiyu]

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 Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, November 23, 2017 7:59 AM
> To: edk2-devel-01 
> Cc: Ard Biesheuvel ; Justen, Jordan L
> ; Ni, Ruiyu ; Dong, Eric
> ; Zeng, Star 
> Subject: [PATCH 3/5] MdeModulePkg/UefiBootManagerLib: report
> EDKII_OS_LOADER_DETAIL status code
> 
> 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 -- the error result at the same
> locations, through EFI_DEBUG_CODE reporting. Use the
> PcdDebugCodeOsLoaderDetail status code value and the
> EDKII_OS_LOADER_DETAIL status code structure introduced earlier in this
> series.
> 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Ruiyu Ni 
> Cc: Eric Dong 
> Cc: Star Zeng 
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 
> ---
>  MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf |   2
> +
>  MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h   |  84
> ++
>  MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   |  51 +-
>  MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c   | 166
> 
>  4 files changed, 301 insertions(+), 2 deletions(-)
> 
> diff --git
> a/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
> b/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
> index ad4901db5713..633906fc6ca4 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
> +++
> b/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
> @@ -79,24 +79,25 @@ [Guids]
> 
>## SOMETIMES_PRODUCES ## Variable:L"BootCurrent" (The boot option of
> current boot)
>## SOMETIMES_CONSUMES ## Variable:L"BootXX" (Boot option variable)
>## SOMETIMES_CONSUMES ## Variable:L"BootOrder" (The boot option
> array)
>## SOMETIMES_CONSUMES ## Variable:L"DriverOrder" (The driver order
> list)
>## SOMETIMES_CONSUMES ## Variable:L"ConIn" (The device path of
> console in device)
>## SOMETIMES_CONSUMES ## Variable:L"ConOut" (The device path of
> console out device)
>## SOMETIMES_CONSUMES ## Variable:L"ErrOut" (The device path of
> error out device)
>gEfiGlobalVariableGuid
> 
>gPerformanceProtocolGuid  ## SOMETIMES_CONSUMES ##
> Variable:L"PerfDataMemAddr" (The ACPI address of performance data)
>gEdkiiStatusCodeDataTypeVariableGuid  ## SOMETIMES_CONSUMES
> ## GUID
> +  gEdkiiStatusCodeDataTypeOsLoaderDetailGuid##
> SOMETIMES_CONSUMES ## GUID
>gEfiDiskInfoAhciInterfaceGuid ## SOMETIMES_CONSUMES ##
> GUID
>gEfiDiskInfoIdeInterfaceGuid  ## SOMETIMES_CONSUMES ## GUID
>gEfiDiskInfoScsiInterfaceGuid ## SOMETIMES_CONSUMES ## GUID
>gEfiDiskInfoSdMmcInterfaceGuid## SOMETIMES_CONSUMES ##
> GUID
> 
>  [Protocols]
>gEfiPciRootBridgeIoProtocolGuid   ## CONSUMES
>gEfiSimpleFileSystemProtocolGuid  ## SOMETIMES_CONSUMES
>gEfiLoadFileProtocolGuid  ## SOMETIMES_CONSUMES
>gEfiSimpleTextOutProtocolGuid ## SOMETIMES_CONSUMES
>gEfiPciIoProtocolGuid ## SOMETIMES_CONSUMES
>gEfiLoadedImageProtocolGuid   ## CONSUMES
> @@ -112,16 +113,17 @@ [Protocols]
>gEfiUsbIoProtocolGuid ## SOMETIMES_CONSUMES
>gEfiNvmExpressPassThruProtocolGuid## SOMETIMES_CONSUMES
>gEfiDiskInfoProtocolGuid  ## SOMETIMES_CONSUMES
>gEfiDriverHealthProtocolGuid  ## SOMETIMES_CONSUMES
>gEfiFormBrowser2ProtocolGuid  ## SOMETIMES_CONSUMES
>gEfiRamDiskProtocolGuid   ## SOMETIMES_CONSUMES
>gEfiDeferredImageLoadProtocolGuid ## SOMETIMES_CONSUMES
> 
>  [Pcd]
> 
> gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationC
> hange  ## SOMETIMES_CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdProgressCodeOsLoaderLoad
> ## SOMETIMES_CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdProgressCodeOsLoaderStart
> ## SOMETIMES_CONSUMES
> +  

Re: [edk2] [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for MP

[Wang, Jian J]

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;
+  IA32_DESCRIPTOR   Idtr;
+  IA32_DESCRIPTOR   Gdtr;
+
   mExceptionHandlerData.ReservedVectors  = mReservedVectorsData;
   mExceptionHandlerData.ExternalInterruptHandler = 
mExternalInterruptHandlerTable;
   InitializeSpinLock ();
-  return InitializeCpuExceptionHandlersWorker (VectorInfo, 
);
+  Status = InitializeCpuExceptionHandlersWorker (VectorInfo, 
);
+  if (!EFI_ERROR (Status) && PcdGetBool (PcdCpuStackGuard)) {
+AsmReadIdtr ();
+AsmReadGdtr ();
+
+StackSwitchData.StackTop = (UINTN)mNewStack;
+StackSwitchData.StackSize = CPU_KNOWN_GOOD_STACK_SIZE;
+StackSwitchData.Exceptions = CPU_STACK_SWITCH_EXCEPTION_LIST;
+StackSwitchData.ExceptionNumber = CPU_STACK_SWITCH_EXCEPTION_NUMBER;
+StackSwitchData.IdtTable = (IA32_IDT_GATE_DESCRIPTOR *)Idtr.Base;
+StackSwitchData.GdtTable = (IA32_SEGMENT_DESCRIPTOR *)mNewGdt;
+StackSwitchData.GdtSize = sizeof (mNewGdt);
+StackSwitchData.TssDesc = (IA32_TSS_DESCRIPTOR *)(mNewGdt + Gdtr.Limit + 
1);
+StackSwitchData.Tss = (IA32_TASK_STATE_SEGMENT *)(mNewGdt + Gdtr.Limit + 1 
+
+  CPU_TSS_DESC_SIZE);
+Status = InitializeCpuExceptionStackSwitchHandlers (
+   
+   );
+  }
+  return Status;
 }

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang,
> Jian J
> Sent: Thursday, November 23, 2017 1:04 PM
> To: Yao, Jiewen ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Laszlo Ersek
> ; Dong, Eric 
> Subject: Re: [edk2] [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch
> for MP
> 
> 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 
> > Subject: RE: [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for 
> > MP
> >
> > Hi
> > 1) Can we enable this feature in early DxeCore?
> >
> Yes. Intead of calling InitializeExceptionStackSwitchHandlers () directly in
> DxeCore,
> InitializeCpuExceptionHandlers() calls 
> InitializeExceptionStackSwitchHandlers().
> 
> I think it's reasonable to do this because 
> InitializeExceptionStackSwitchHandlers()
> is arch dependent. It'd be better not to call it in DxeCore. Another benefit 
> is that
> this can avoid backward compatibility issue introduced by new API, which 
> hasn't
> been implemented by cpu driver or lib of other archs.
> 
> > 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 DxeCore.
> >
> > 2) In addition, InitializeCpuExceptionHandlers () has VectorInfoList as
> parameter.
> > Do we also need that for InitializeExceptionStackSwitchHandlers()?
> >
> I don't see the need. Do you have any use cases in mind?
> 
> > Thank you
> > Yao Jiewen
> >
> > > -Original Message-
> > > From: Wang, Jian J
> > > Sent: Wednesday, November 22, 2017 4:46 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Dong, Eric ; Laszlo Ersek ;
> > Yao,
> > > Jiewen ; Kinney, Michael D
> > > 
> > > Subject: [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for MP
> > >
> > > > 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 own configuration. This patch adds code to ask BSP and 
> > > AP
> > > to do exception handler initialization separately.
> > >
> > > Cc: Eric Dong 
> > > Cc: Laszlo Ersek 
> > > Cc: Jiewen Yao 
> > > Cc: Michael Kinney 
> > > Suggested-by: Ayellet Wolman 
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Jian J Wang 
> > > ---
> > >  UefiCpuPkg/CpuDxe/CpuDxe.inf |   3 +
> > >  UefiCpuPkg/CpuDxe/CpuMp.c| 168
> > > +++
> > >  UefiCpuPkg/CpuDxe/CpuMp.h|  12 
> > >  3 files changed, 183 

Re: [edk2] [PATCH v2 0/8] Implement stack guard feature

[Wang, Jian J]

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 ; edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH v2 0/8] Implement stack guard feature
> 
> 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
> > Subject: [edk2] [PATCH v2 0/8] Implement stack guard feature
> >
> > 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 stack size.
> >
> > If this feature is enabled, DxeIpl will setup page tables and set page where
> > the stack bottom is at to be NON-PRESENT. If stack overflow occurs, Page
> > Fault exception will be triggered.
> >
> > In order to make sure exception handler works normally even when the stack
> > is corrupted, stack switching is implemented in exception library.
> >
> > Due to the mechanism behind Stack Guard, this feature is only avaiable for
> > UEFI drivers (memory avaiable). That also means it doesn't support NT32
> > emulated platform (paging not supported).
> >
> > Validation works include:
> >   a. OVMF emulated platform: boot to shell (IA32/X64)
> >   b. Intel real platform: boot to shell (IA32/X64)
> >
> > Jian J Wang (8):
> >   MdeModulePkg/metafile: Add PCD PcdCpuStackGuard
> >   MdeModulePkg/CpuExceptionHandlerLib.h: Add a new API
> >   MdePkg/BaseLib: Add stack switch related definitions for IA32
> >   MdeModulePkg/DxeIpl: Enable paging for Stack Guard
> >   UefiCpuPkg/UefiCpuPkg.dec: Add two new PCDs for stack switch
> >   UefiCpuPkg/MpLib: Add GDTR, IDTR and TR in saved AP data
> >   UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support
> >   UefiCpuPkg/CpuDxe: Initialize stack switch for MP
> >
> >  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   5 +-
> >  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c|   4 +
> >  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c |   1 +
> >  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c   |  51 ++-
> >  .../Include/Library/CpuExceptionHandlerLib.h   |  18 +
> >  MdeModulePkg/MdeModulePkg.dec  |   7 +
> >  MdeModulePkg/MdeModulePkg.uni  |   7 +
> >  MdePkg/Include/Library/BaseLib.h   | 115 ++
> >  MdePkg/Library/BaseLib/BaseLib.inf |   3 +
> >  MdePkg/Library/BaseLib/Ia32/WriteTr.nasm   |  36 ++
> >  MdePkg/Library/BaseLib/X64/WriteTr.nasm|  37 ++
> >  UefiCpuPkg/CpuDxe/CpuDxe.inf   |   3 +
> >  UefiCpuPkg/CpuDxe/CpuMp.c  | 168 +
> >  UefiCpuPkg/CpuDxe/CpuMp.h  |  12 +
> >  .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  50 +++
> >  .../DxeCpuExceptionHandlerLib.inf  |   6 +
> >  .../Library/CpuExceptionHandlerLib/DxeException.c  |  53 ++-
> >  .../Ia32/ArchExceptionHandler.c| 167 +
> >  .../Ia32/ArchInterruptDefs.h   |   8 +
> >  .../Ia32/ExceptionTssEntryAsm.nasm | 398
> > +
> >  .../PeiCpuExceptionHandlerLib.inf  |   1 +
> >  .../SecPeiCpuExceptionHandlerLib.inf   |   1 +
> >  .../SmmCpuExceptionHandlerLib.inf  |   1 +
> >  .../X64/ArchExceptionHandler.c | 133 +++
> >  .../CpuExceptionHandlerLib/X64/ArchInterruptDefs.h |   3 +
> >  UefiCpuPkg/Library/MpInitLib/MpLib.c   |  17 +
> >  UefiCpuPkg/Library/MpInitLib/MpLib.h   |   3 +
> >  UefiCpuPkg/UefiCpuPkg.dec  |  12 +
> >  28 files changed, 1304 insertions(+), 16 deletions(-)
> >  create mode 100644 MdePkg/Library/BaseLib/Ia32/WriteTr.nasm
> >  create mode 100644 MdePkg/Library/BaseLib/X64/WriteTr.nasm
> >  create mode 100644
> >
> UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionTssEntryAsm.nasm
> >
> > --
> > 2.14.1.windows.1
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h: Add a new API

[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 ; edk2-devel@lists.01.org
> Cc: Dong, Eric ; Zeng, Star 
> Subject: RE: [edk2] [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h:
> Add a new API
> 
> 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
> 
> > -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
> > Cc: Yao, Jiewen ; Dong, Eric ;
> > Zeng, Star 
> > Subject: [edk2] [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h:
> Add
> > a new API
> >
> > > 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 resources reserved
> in
> > advance. This is necessary because the CpuExceptionHandlerLib will be linked
> > in different phases, in which there's no common way to reserve resources.
> >
> > EFI_STATUS
> > EFIAPI
> > InitializeCpuExceptionStackSwitchHandlers (
> >   IN VOID   *StackSwitchData  OPTIONAL
> >   );
> >
> > Cc: Star Zeng 
> > Cc: Eric Dong 
> > Cc: Jiewen Yao 
> > Suggested-by: Ayellet Wolman 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang 
> > ---
> >  MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h | 18
> > ++
> >  1 file changed, 18 insertions(+)
> >
> > diff --git a/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> > b/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> > index 6cd8230127..68de4850e1 100644
> > --- a/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> > +++ b/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> > @@ -41,6 +41,24 @@ InitializeCpuExceptionHandlers (
> >IN EFI_VECTOR_HANDOFF_INFO   *VectorInfo OPTIONAL
> >);
> >
> > +/**
> > +  Setup separate stack for given exceptions. StackSwitchData is optional 
> > and
> its
> > +  content depends one the specific arch of CPU.
> > +
> > +  @param[in] StackSwitchData  Pointer to data required for setuping up
> > +  stack switch.
> > +
> > +  @retval EFI_SUCCESS The exceptions have been successfully
> > +  initialized.
> > +  @retval EFI_INVALID_PARAMETER   StackSwitchData contains invalid
> > content.
> > +
> > +**/
> > +EFI_STATUS
> > +EFIAPI
> > +InitializeCpuExceptionStackSwitchHandlers (
> > +  IN VOID   *StackSwitchData  OPTIONAL
> > +  );
> > +
> >  /**
> >Initializes all CPU interrupt/exceptions entries and provides the default
> > interrupt/exception handlers.
> >
> > --
> > 2.14.1.windows.1
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for MP

[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 
> Subject: RE: [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for MP
> 
> Hi
> 1) Can we enable this feature in early DxeCore?
> 
Yes. Intead of calling InitializeExceptionStackSwitchHandlers () directly in 
DxeCore,
InitializeCpuExceptionHandlers() calls InitializeExceptionStackSwitchHandlers().

I think it's reasonable to do this because 
InitializeExceptionStackSwitchHandlers()
is arch dependent. It'd be better not to call it in DxeCore. Another benefit is 
that 
this can avoid backward compatibility issue introduced by new API, which hasn't 
been implemented by cpu driver or lib of other archs.

> 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 DxeCore.
> 
> 2) In addition, InitializeCpuExceptionHandlers () has VectorInfoList as 
> parameter.
> Do we also need that for InitializeExceptionStackSwitchHandlers()?
> 
I don't see the need. Do you have any use cases in mind?

> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Wednesday, November 22, 2017 4:46 PM
> > To: edk2-devel@lists.01.org
> > Cc: Dong, Eric ; Laszlo Ersek ;
> Yao,
> > Jiewen ; Kinney, Michael D
> > 
> > Subject: [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for MP
> >
> > > 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 own configuration. This patch adds code to ask BSP and AP
> > to do exception handler initialization separately.
> >
> > Cc: Eric Dong 
> > Cc: Laszlo Ersek 
> > Cc: Jiewen Yao 
> > Cc: Michael Kinney 
> > Suggested-by: Ayellet Wolman 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang 
> > ---
> >  UefiCpuPkg/CpuDxe/CpuDxe.inf |   3 +
> >  UefiCpuPkg/CpuDxe/CpuMp.c| 168
> > +++
> >  UefiCpuPkg/CpuDxe/CpuMp.h|  12 
> >  3 files changed, 183 insertions(+)
> >
> > diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.inf b/UefiCpuPkg/CpuDxe/CpuDxe.inf
> > index 3e8d196739..02f86b774c 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuDxe.inf
> > +++ b/UefiCpuPkg/CpuDxe/CpuDxe.inf
> > @@ -81,6 +81,9 @@
> >
> >  [Pcd]
> >
> > gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
> > ## CONSUMES
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard
> > ## CONSUMES
> > +  gUefiCpuPkgTokenSpaceGuid.PcdCpuStackSwitchExceptionList
> > ## CONSUMES
> > +  gUefiCpuPkgTokenSpaceGuid.PcdCpuKnownGoodStackSize
> > ## CONSUMES
> >
> >  [Depex]
> >TRUE
> > diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
> > index b3c0178d07..6b2ceacb39 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuMp.c
> > +++ b/UefiCpuPkg/CpuDxe/CpuMp.c
> > @@ -601,6 +601,169 @@ CollectBistDataFromHob (
> >}
> >  }
> >
> > +/**
> > +  Get GDT register content.
> > +
> > +  This function is mainly for AP purpose because AP may have different GDT
> > +  table than BSP.
> > +
> > +**/
> > +VOID
> > +EFIAPI
> > +GetGdtr (
> > +  IN OUT VOID *Buffer
> > +  )
> > +{
> > +  AsmReadGdtr ((IA32_DESCRIPTOR *)Buffer);
> > +}
> > +
> > +/**
> > +  Initializes CPU exceptions handlers for the sake of stack switch 
> > requirement.
> > +
> > +  This function is a wrapper of InitializeCpuExceptionStackSwitchHandlers.
> > +  It's mainly for AP purpose because of EFI_AP_PROCEDURE API requirement.
> > +
> > +**/
> > +VOID
> > +EFIAPI
> > +InitializeExceptionStackSwitchHandlers (
> > +  IN OUT VOID *Buffer
> > +  )
> > +{
> > +  EXCEPTION_STACK_SWITCH_DATA *EssData;
> > +  IA32_DESCRIPTOR Idtr;
> > +  EFI_STATUS  Status;
> > +
> > +  EssData = Buffer;
> > +  //
> > +  // We don't plan to replace IDT table with a new one, and we don't assume
> > +  // the AP's IDT is the same as BSP's IDT either.
> > +  //
> > +  AsmReadIdtr ();
> > +  EssData->IdtTable = (IA32_IDT_GATE_DESCRIPTOR *)Idtr.Base;
> > +  Status = InitializeCpuExceptionStackSwitchHandlers (EssData);
> > +  ASSERT_EFI_ERROR (Status);
> > +}
> > +
> > +/**
> > +  Initializes MP exceptions handlers for the sake of stack switch 
> > requirement.
> > +
> > +  This 

Re: [edk2] SCT Test crashes After HTTPS boot success.

[Wu, Jiaxin]

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 to the above sentence that all of 
the TlsSB/TlsProtocol/TlsConfigProtocol must exist, if not, the failure happen.

For other cases, we will review them, then feedback to you.

Thanks,
Jiaxin




From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Wednesday, November 22, 2017 6:25 PM
To: Wu, Jiaxin ; 'edk2-devel@lists.01.org' 

Cc: Fu, Siyuan ; Ye, Ting ; Jin, Eric 

Subject: RE: SCT Test crashes After HTTPS boot success.

Hi Jiaxin,

Thank you very much for your detailed explanation.

After talk with SCT expert (Jin, Eric 
>) , we agree the Spec may need 
to be updated since it can mislead the caller.
Sorry, I didn't get the point here, whether we're going to update SCT spec to 
resolve this TLS failure?

And regards other failures

? The platform have SCSI module, PXE_BC protocols and one of UNDI/SNP/MNP are 
present, But still I'm getting SCT failures related to this.

? Also there are some failures in HiiTest

Could you please provide your comments/Suggestions on other failures too.

Thank You.
Karunakar

From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Wednesday, November 22, 2017 2:13 PM
To: Karunakar P; 'edk2-devel@lists.01.org'
Cc: Fu, Siyuan; Ye, Ting; Jin, Eric
Subject: RE: SCT Test crashes After HTTPS boot success.

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 and
EFI_TLS_CONFIGURATION_PROTOCOL are required.

So, the SCT will check the EFI_TLS_SERVICE_BINDING_PROTOCOL, EFI_TLS_PROTOCOL 
and EFI_TLS_CONFIGURATION_PROTOCOL, but it didn't find the EFI_TLS_PROTOCOL and 
EFI_TLS_CONFIGURATION_PROTOCOL because no available TLS instance is created by 
default since it's no driver dependency. Even you tried the HTTPS, the TLS 
instance will be destroyed after finishing the HTTPS boot process, that's the 
reason why it still fail after HTTPS boot.
  Status = gtBS->LocateProtocol (
   ,
   NULL,
   (VOID **) 
   );
  if (!EFI_ERROR (Status)) {
ValueB = TRUE;
  } else {
ValueB = FALSE;
  }

After talk with SCT expert (Jin, Eric 
>) , we agree the Spec may need 
to be updated since it can mislead the caller.

Thanks,
Jiaxin


From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Tuesday, November 21, 2017 7:55 PM
To: Wu, Jiaxin >; 
'edk2-devel@lists.01.org' 
>
Cc: Fu, Siyuan >; Ye, Ting 
>
Subject: RE: SCT Test crashes After HTTPS boot success.


Hi Jiaxin,

I've done SCT Test After HTTPS Boot success(Release Mode), I'm facing the below 
failures


1.   GenericTest\EFICompliantTest - EFI Compliant - PXE_BC protocols and 
one of UNDI/SNP/MNP must be implemented if a platform supports to boot from a 
network device.

2.   GenericTest\EFICompliantTest - UEFI-Compliant - 
EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL must be implemented if a platform includes 
an NVM Express controller.

3.   GenericTest\EFICompliantTest - UEFI-Compliant - EFI_BLOCK_IO_PROTOCOL 
must be existed if the platform supports booting from a block-oriented NVM 
Express controller. EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL may be required.

4.   GenericTest\EFICompliantTest - EFI Compliant - SCSI_PASS_THRU protocol 
must be implemented if a platform includes an I/O system that uses SCSI command 
packets.

5.   GenericTest\EFICompliantTest - UEFI-Compliant EFI_SCSI IO_PROTOCOL, 
EFI_Block IO_PROTOCOL and EFI_EXT_SCSI_PASS_THRU_PROTOCOL must be implemented 
if a platform supports booting from a SCSI peripheral device.

6.   GenericTest\EFICompliantTest - EFI Compliant - DEBUG_SUPPORT and 
DEBUG_PORT protocols must be implemented if a platform supports debugging 
capabilities.

7.   GenericTest\EFICompliantTest - UEFI-Compliant - 
EFI_ATA_PASS_THRU_PROTOCOL must be implemented if a platform includes an I/O 
subsystem that utilizes ATA command packets.

8.   GenericTest\EFICompliantTest - UEFI-Compliant - EFI_TLS_PROTOCOL, 
EFI_TLS_SERVICE_BINDING_PROTOCOL, EFI_TLS_CONFIGURATION_PROTOCOL must be 
existed if the platform supports TLS feature.

9.   GenericTest\EFICompliantTest - UEFI-Compliant - 

Re: [edk2] [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for MP

[Yao, Jiewen]

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 DxeCore.

2) In addition, InitializeCpuExceptionHandlers () has VectorInfoList as 
parameter.
Do we also need that for InitializeExceptionStackSwitchHandlers()?

Thank you
Yao Jiewen

> -Original Message-
> From: Wang, Jian J
> Sent: Wednesday, November 22, 2017 4:46 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric ; Laszlo Ersek ; Yao,
> Jiewen ; Kinney, Michael D
> 
> Subject: [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for MP
> 
> > 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 own configuration. This patch adds code to ask BSP and AP
> to do exception handler initialization separately.
> 
> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> Cc: Jiewen Yao 
> Cc: Michael Kinney 
> Suggested-by: Ayellet Wolman 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  UefiCpuPkg/CpuDxe/CpuDxe.inf |   3 +
>  UefiCpuPkg/CpuDxe/CpuMp.c| 168
> +++
>  UefiCpuPkg/CpuDxe/CpuMp.h|  12 
>  3 files changed, 183 insertions(+)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.inf b/UefiCpuPkg/CpuDxe/CpuDxe.inf
> index 3e8d196739..02f86b774c 100644
> --- a/UefiCpuPkg/CpuDxe/CpuDxe.inf
> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.inf
> @@ -81,6 +81,9 @@
> 
>  [Pcd]
> 
> gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
> ## CONSUMES
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard
> ## CONSUMES
> +  gUefiCpuPkgTokenSpaceGuid.PcdCpuStackSwitchExceptionList
> ## CONSUMES
> +  gUefiCpuPkgTokenSpaceGuid.PcdCpuKnownGoodStackSize
> ## CONSUMES
> 
>  [Depex]
>TRUE
> diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
> index b3c0178d07..6b2ceacb39 100644
> --- a/UefiCpuPkg/CpuDxe/CpuMp.c
> +++ b/UefiCpuPkg/CpuDxe/CpuMp.c
> @@ -601,6 +601,169 @@ CollectBistDataFromHob (
>}
>  }
> 
> +/**
> +  Get GDT register content.
> +
> +  This function is mainly for AP purpose because AP may have different GDT
> +  table than BSP.
> +
> +**/
> +VOID
> +EFIAPI
> +GetGdtr (
> +  IN OUT VOID *Buffer
> +  )
> +{
> +  AsmReadGdtr ((IA32_DESCRIPTOR *)Buffer);
> +}
> +
> +/**
> +  Initializes CPU exceptions handlers for the sake of stack switch 
> requirement.
> +
> +  This function is a wrapper of InitializeCpuExceptionStackSwitchHandlers.
> +  It's mainly for AP purpose because of EFI_AP_PROCEDURE API requirement.
> +
> +**/
> +VOID
> +EFIAPI
> +InitializeExceptionStackSwitchHandlers (
> +  IN OUT VOID *Buffer
> +  )
> +{
> +  EXCEPTION_STACK_SWITCH_DATA *EssData;
> +  IA32_DESCRIPTOR Idtr;
> +  EFI_STATUS  Status;
> +
> +  EssData = Buffer;
> +  //
> +  // We don't plan to replace IDT table with a new one, and we don't assume
> +  // the AP's IDT is the same as BSP's IDT either.
> +  //
> +  AsmReadIdtr ();
> +  EssData->IdtTable = (IA32_IDT_GATE_DESCRIPTOR *)Idtr.Base;
> +  Status = InitializeCpuExceptionStackSwitchHandlers (EssData);
> +  ASSERT_EFI_ERROR (Status);
> +}
> +
> +/**
> +  Initializes MP exceptions handlers for the sake of stack switch 
> requirement.
> +
> +  This function will allocate required resources for stack switch and pass
> +  them through EXCEPTION_STACK_SWITCH_DATA to each logic processor.
> +
> +**/
> +VOID
> +InitializeMpExceptionStackSwitchHandlers (
> +  VOID
> +  )
> +{
> +  UINTN   Index;
> +  UINTN   Bsp;
> +  UINTN   ExceptionNumber;
> +  UINTN   NewGdtSize;
> +  UINTN   NewStackSize;
> +  IA32_DESCRIPTOR Gdtr;
> +  EXCEPTION_STACK_SWITCH_DATA EssData;
> +  UINT8   *GdtBuffer;
> +  UINT8   *StackTop;
> +
> +  if (!PcdGetBool (PcdCpuStackGuard)) {
> +return;
> +  }
> +
> +  ExceptionNumber = FixedPcdGetSize (PcdCpuStackSwitchExceptionList);
> +  NewStackSize = FixedPcdGet32 (PcdCpuKnownGoodStackSize) *
> ExceptionNumber;
> +
> +  StackTop = AllocateRuntimeZeroPool (NewStackSize *
> mNumberOfProcessors);
> +  ASSERT (StackTop != NULL);
> +  StackTop += NewStackSize  * mNumberOfProcessors;
> +
> +  EssData.Exceptions = FixedPcdGetPtr (PcdCpuStackSwitchExceptionList);
> +  

Re: [edk2] [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h: Add a new API

[Yao, Jiewen]

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

> -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
> Cc: Yao, Jiewen ; Dong, Eric ;
> Zeng, Star 
> Subject: [edk2] [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h: Add
> a new API
> 
> > 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 resources reserved in
> advance. This is necessary because the CpuExceptionHandlerLib will be linked
> in different phases, in which there's no common way to reserve resources.
> 
> EFI_STATUS
> EFIAPI
> InitializeCpuExceptionStackSwitchHandlers (
>   IN VOID   *StackSwitchData  OPTIONAL
>   );
> 
> Cc: Star Zeng 
> Cc: Eric Dong 
> Cc: Jiewen Yao 
> Suggested-by: Ayellet Wolman 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h | 18
> ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> b/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> index 6cd8230127..68de4850e1 100644
> --- a/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> +++ b/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> @@ -41,6 +41,24 @@ InitializeCpuExceptionHandlers (
>IN EFI_VECTOR_HANDOFF_INFO   *VectorInfo OPTIONAL
>);
> 
> +/**
> +  Setup separate stack for given exceptions. StackSwitchData is optional and 
> its
> +  content depends one the specific arch of CPU.
> +
> +  @param[in] StackSwitchData  Pointer to data required for setuping up
> +  stack switch.
> +
> +  @retval EFI_SUCCESS The exceptions have been successfully
> +  initialized.
> +  @retval EFI_INVALID_PARAMETER   StackSwitchData contains invalid
> content.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +InitializeCpuExceptionStackSwitchHandlers (
> +  IN VOID   *StackSwitchData  OPTIONAL
> +  );
> +
>  /**
>Initializes all CPU interrupt/exceptions entries and provides the default
> interrupt/exception handlers.
> 
> --
> 2.14.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/8] Implement stack guard feature

[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
> Subject: [edk2] [PATCH v2 0/8] Implement stack guard feature
> 
> 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 stack size.
> 
> If this feature is enabled, DxeIpl will setup page tables and set page where
> the stack bottom is at to be NON-PRESENT. If stack overflow occurs, Page
> Fault exception will be triggered.
> 
> In order to make sure exception handler works normally even when the stack
> is corrupted, stack switching is implemented in exception library.
> 
> Due to the mechanism behind Stack Guard, this feature is only avaiable for
> UEFI drivers (memory avaiable). That also means it doesn't support NT32
> emulated platform (paging not supported).
> 
> Validation works include:
>   a. OVMF emulated platform: boot to shell (IA32/X64)
>   b. Intel real platform: boot to shell (IA32/X64)
> 
> Jian J Wang (8):
>   MdeModulePkg/metafile: Add PCD PcdCpuStackGuard
>   MdeModulePkg/CpuExceptionHandlerLib.h: Add a new API
>   MdePkg/BaseLib: Add stack switch related definitions for IA32
>   MdeModulePkg/DxeIpl: Enable paging for Stack Guard
>   UefiCpuPkg/UefiCpuPkg.dec: Add two new PCDs for stack switch
>   UefiCpuPkg/MpLib: Add GDTR, IDTR and TR in saved AP data
>   UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support
>   UefiCpuPkg/CpuDxe: Initialize stack switch for MP
> 
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   5 +-
>  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c|   4 +
>  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c |   1 +
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c   |  51 ++-
>  .../Include/Library/CpuExceptionHandlerLib.h   |  18 +
>  MdeModulePkg/MdeModulePkg.dec  |   7 +
>  MdeModulePkg/MdeModulePkg.uni  |   7 +
>  MdePkg/Include/Library/BaseLib.h   | 115 ++
>  MdePkg/Library/BaseLib/BaseLib.inf |   3 +
>  MdePkg/Library/BaseLib/Ia32/WriteTr.nasm   |  36 ++
>  MdePkg/Library/BaseLib/X64/WriteTr.nasm|  37 ++
>  UefiCpuPkg/CpuDxe/CpuDxe.inf   |   3 +
>  UefiCpuPkg/CpuDxe/CpuMp.c  | 168 +
>  UefiCpuPkg/CpuDxe/CpuMp.h  |  12 +
>  .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  50 +++
>  .../DxeCpuExceptionHandlerLib.inf  |   6 +
>  .../Library/CpuExceptionHandlerLib/DxeException.c  |  53 ++-
>  .../Ia32/ArchExceptionHandler.c| 167 +
>  .../Ia32/ArchInterruptDefs.h   |   8 +
>  .../Ia32/ExceptionTssEntryAsm.nasm | 398
> +
>  .../PeiCpuExceptionHandlerLib.inf  |   1 +
>  .../SecPeiCpuExceptionHandlerLib.inf   |   1 +
>  .../SmmCpuExceptionHandlerLib.inf  |   1 +
>  .../X64/ArchExceptionHandler.c | 133 +++
>  .../CpuExceptionHandlerLib/X64/ArchInterruptDefs.h |   3 +
>  UefiCpuPkg/Library/MpInitLib/MpLib.c   |  17 +
>  UefiCpuPkg/Library/MpInitLib/MpLib.h   |   3 +
>  UefiCpuPkg/UefiCpuPkg.dec  |  12 +
>  28 files changed, 1304 insertions(+), 16 deletions(-)
>  create mode 100644 MdePkg/Library/BaseLib/Ia32/WriteTr.nasm
>  create mode 100644 MdePkg/Library/BaseLib/X64/WriteTr.nasm
>  create mode 100644
> UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionTssEntryAsm.nasm
> 
> --
> 2.14.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/5] MdeModulePkg/BdsDxe: fall back to a Boot Manager Menu loop before hanging

[Ni, Ruiyu]

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 AM
> To: edk2-devel-01 
> Cc: Ard Biesheuvel ; Justen, Jordan L
> ; Ni, Ruiyu ; Dong, Eric
> ; Zeng, Star 
> Subject: [PATCH 1/5] MdeModulePkg/BdsDxe: fall back to a Boot Manager
> Menu loop before hanging
> 
> 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() with:
> 
>DEBUG ((EFI_D_ERROR, "[Bds] Unable to boot!\n"));
>CpuDeadLoop ();
> 
> while the user sits at the TianoCore logo page, wondering what's going on.
> Print an informative message to the console, wait for a keypress, and then
> return to the Boot Manager Menu forever.
> 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Ruiyu Ni 
> Cc: Eric Dong 
> Cc: Star Zeng 
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=513
> Suggested-by: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 
> ---
>  MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 60 ++-
> -
>  1 file changed, 56 insertions(+), 4 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> index dccc49090219..2b24755ac368 100644
> --- a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> +++ b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> @@ -676,24 +676,73 @@ BdsAllocateMemoryForPerformanceData (
>  //
>  // Mark L"PerfDataMemAddr" variable to read-only if the Variable Lock
> protocol exists
>  // Still lock it even the variable cannot be saved to prevent it's set 
> by 3rd
> party code.
>  //
>  Status = gBS->LocateProtocol (, NULL,
> (VOID **) );
>  if (!EFI_ERROR (Status)) {
>Status = VariableLock->RequestToLock (VariableLock,
> L"PerfDataMemAddr", );
>ASSERT_EFI_ERROR (Status);
>  }
>}
>  }
> 
> +/**
> +  Enter an infinite loop of calling the Boot Manager Menu.
> +
> +  This is a last resort alternative to BdsEntry() giving up for good.
> + This  function never returns.
> +
> +  @param[in] BootManagerMenu  The
> EFI_BOOT_MANAGER_LOAD_OPTION located and/or
> +  created by the 
> EfiBootManagerGetBootManagerMenu()
> +  call in BdsEntry().
> +**/
> +VOID
> +BdsBootManagerMenuLoop (
> +  IN EFI_BOOT_MANAGER_LOAD_OPTION *BootManagerMenu
> +  )
> +{
> +  EFI_INPUT_KEY Key;
> +
> +  //
> +  // Normally BdsDxe does not print anything to the system console, but
> + this is  // a last resort -- the end-user will likely not see any
> + DEBUG messages  // logged in this situation.
> +  //
> +  // AsciiPrint() will NULL-check gST->ConOut internally. We check
> + gST->ConIn  // here to see if it makes sense to request and wait for a
> keypress.
> +  //
> +  if (gST->ConIn != NULL) {
> +AsciiPrint (
> +  "%a: No bootable option or device was found.\n"
> +  "%a: Press any key to enter the Boot Manager Menu.\n",
> +  gEfiCallerBaseName,
> +  gEfiCallerBaseName
> +  );
> +BdsWaitForSingleEvent (gST->ConIn->WaitForKey, 0);
> +
> +//
> +// Drain any queued keys.
> +//
> +while (!EFI_ERROR (gST->ConIn->ReadKeyStroke (gST->ConIn, ))) {
> +  //
> +  // just throw away Key
> +  //
> +}
> +  }
> +
> +  for (;;) {
> +EfiBootManagerBoot (BootManagerMenu);
> +  }
> +}
> +
>  /**
> 
>Service routine for BdsInstance->Entry(). Devices are connected, the
>consoles are initialized, and the boot options are tried.
> 
>@param This Protocol Instance structure.
> 
>  **/
>  VOID
>  EFIAPI
>  BdsEntry (
>IN EFI_BDS_ARCH_PROTOCOL  *This
> @@ -1079,34 +1128,37 @@ BdsEntry (
>  }
> 
>  do {
>//
>// Retry to boot if any of the boot succeeds
>//
>LoadOptions = EfiBootManagerGetLoadOptions (,
> LoadOptionTypeBoot);
>BootSuccess = BootBootOptions (LoadOptions, LoadOptionCount,
> (BootManagerMenuStatus != EFI_NOT_FOUND) ?  :
> NULL);
>EfiBootManagerFreeLoadOptions (LoadOptions, LoadOptionCount);
>  } while (BootSuccess);
>}
> 
> -  if (BootManagerMenuStatus != EFI_NOT_FOUND) {
> -EfiBootManagerFreeLoadOption ();
> -  }
> -
>if (!BootSuccess) {
>  

[edk2] [PATCH] IntelFsp2WrapperPkg: Support UPD allocation outside FspWrapper

[Chasel, Chiu]

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 
---
 .../FspmWrapperPeim/FspmWrapperPeim.c  | 25 ---
 .../FspmWrapperPeim/FspmWrapperPeim.inf|  3 +-
 .../FspsWrapperPeim/FspsWrapperPeim.c  | 84 +++---
 .../FspsWrapperPeim/FspsWrapperPeim.inf|  3 +-
 IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec| 13 +++-
 5 files changed, 76 insertions(+), 52 deletions(-)

diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c 
b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
index f1d1cd6421..7b7c5f5d86 100644
--- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
@@ -3,7 +3,7 @@
   register TemporaryRamDonePpi to call TempRamExit API, and register 
MemoryDiscoveredPpi
   notify to call FspSiliconInit API.
 
-  Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -63,20 +63,29 @@ PeiFspMemoryInit (
   DEBUG ((DEBUG_INFO, "PeiFspMemoryInit enter\n"));
 
   FspHobListPtr = NULL;
+  FspmUpdDataPtr = NULL;
 
-  //
-  // Copy default FSP-M UPD data from Flash
-  //
   FspmHeaderPtr = (FSP_INFO_HEADER *)FspFindFspHeader (PcdGet32 
(PcdFspmBaseAddress));
   DEBUG ((DEBUG_INFO, "FspmHeaderPtr - 0x%x\n", FspmHeaderPtr));
   if (FspmHeaderPtr == NULL) {
 return EFI_DEVICE_ERROR;
   }
 
-  FspmUpdDataPtr = (FSPM_UPD_COMMON *)AllocateZeroPool 
((UINTN)FspmHeaderPtr->CfgRegionSize);
-  ASSERT (FspmUpdDataPtr != NULL);
-  SourceData = (UINTN *)((UINTN)FspmHeaderPtr->ImageBase + 
(UINTN)FspmHeaderPtr->CfgRegionOffset);
-  CopyMem (FspmUpdDataPtr, SourceData, (UINTN)FspmHeaderPtr->CfgRegionSize);
+  if (PcdGet32 (PcdFspmUpdDataAddress) == 0 && (FspmHeaderPtr->CfgRegionSize 
!= 0) && (FspmHeaderPtr->CfgRegionOffset != 0)) {
+//
+// Copy default FSP-M UPD data from Flash
+//
+FspmUpdDataPtr = (FSPM_UPD_COMMON *)AllocateZeroPool 
((UINTN)FspmHeaderPtr->CfgRegionSize);
+ASSERT (FspmUpdDataPtr != NULL);
+SourceData = (UINTN *)((UINTN)FspmHeaderPtr->ImageBase + 
(UINTN)FspmHeaderPtr->CfgRegionOffset);
+CopyMem (FspmUpdDataPtr, SourceData, (UINTN)FspmHeaderPtr->CfgRegionSize);
+  } else {
+//
+// External UPD is ready, get the buffer from PCD pointer.
+//
+FspmUpdDataPtr = (FSPM_UPD_COMMON *)PcdGet32 (PcdFspmUpdDataAddress);
+ASSERT (FspmUpdDataPtr != NULL);
+  }
 
   DEBUG ((DEBUG_INFO, "UpdateFspmUpdData enter\n"));
   UpdateFspmUpdData ((VOID *)FspmUpdDataPtr);
diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf 
b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
index 2b3d240d08..542356b582 100644
--- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
+++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
@@ -59,7 +59,8 @@
   IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec
 
 [Pcd]
-  gIntelFsp2WrapperTokenSpaceGuid.PcdFspmBaseAddress  ## CONSUMES
+  gIntelFsp2WrapperTokenSpaceGuid.PcdFspmBaseAddress ## CONSUMES
+  gIntelFsp2WrapperTokenSpaceGuid.PcdFspmUpdDataAddress  ## CONSUMES
 
 [Sources]
   FspmWrapperPeim.c
diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c 
b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
index ddc19c7e8f..70dac7a414 100644
--- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
@@ -3,7 +3,7 @@
   register TemporaryRamDonePpi to call TempRamExit API, and register 
MemoryDiscoveredPpi
   notify to call FspSiliconInit API.
 
-  Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -44,14 +44,14 @@ extern EFI_PEI_NOTIFY_DESCRIPTOR mS3EndOfPeiNotifyDesc;
 extern EFI_GUID  gFspHobGuid;
 
 /**
-This function handles S3 resume task at the end of PEI
+  This function handles S3 resume task at the end of PEI
 
-@param[in] PeiServicesPointer to PEI Services Table.
-@param[in] NotifyDesc Pointer to the descriptor for the Notification event 
that
-caused this function to execute.
-@param[in] PpiPointer to the PPI data associated with this 
function.
+  @param[in] PeiServicesPointer to PEI 

Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-DMA at ExitBootServices()

[Ni, Ruiyu]

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 ;
> edk2-devel-01 
> Cc: Ard Biesheuvel ; Dong, Eric
> ; Dann Frazier ; Zeng, Star
> 
> Subject: RE: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only
> BM-DMA at ExitBootServices()
> 
> 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  de...@lists.01.org>
> Cc: Ard Biesheuvel ; Dong, Eric
> ; Zeng, Star ; Dann Frazier
> 
> Subject: RE: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only
> BM-DMA at ExitBootServices()
> 
> 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
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Laszlo Ersek
> > Sent: Saturday, October 28, 2017 12:10 AM
> > To: edk2-devel-01 
> > Cc: Ard Biesheuvel ; Dong, Eric
> > ; Zeng, Star ; Dann Frazier
> > 
> > Subject: Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable
> > only BM-DMA at ExitBootServices()
> >
> > On 10/26/17 17:48, Laszlo Ersek wrote:
> > > Clearing I/O port decoding in the PCI command register at
> > > ExitBootServices() breaks IDE boot in Windows, on QEMU's "pc"
> > > (i440fx) machine type. (AHCI boot on "q35" is unaffected.) Windows
> > > seems repeatedly stuck, apparently waiting for a timeout of sorts.
> > >
> > > This is arguably a Windows bug; a native OS driver should not expect
> > > the firmware to leave the PCI command register in any particular state.
> > >
> > > Strictly speaking, we only need to disable BM-DMA at
> > > ExitBootServices(), in order to abort pending transfers to/from RAM,
> > > which is soon to be owned by the OS. BM-DMA is also the only bit
> > > that's explicitly named by the UEFI Driver Writers' Guide, for
> > > clearing at
> > ExitBootServices().
> > >
> > > I've verified that clearing only BM-DMA fixes the isse (boot time)
> > > on i440fx, and does not regress q35/AHCI.
> > >
> > > Cc: Aleksei Kovura 
> > > Cc: Ard Biesheuvel 
> > > Cc: Dann Frazier 
> > > Cc: Eric Dong 
> > > Cc: Star Zeng 
> > > Reported-by: Aleksei Kovura 
> > > Reported-by: Dann Frazier 
> > > Reported-by: https://launchpad.net/~cjkrupp
> > > Bisected-by: Dann Frazier 
> > > Bisected-by: https://launchpad.net/~cjkrupp
> > > Suggested-by: Ard Biesheuvel 
> > > Suggested-by: Star Zeng 
> > > Ref: https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1725560
> > > Fixes: 6fb8ddd36bde45614b0a069528cdc97077835a74
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Laszlo Ersek 
> > > ---
> > >
> > > Notes:
> > > Repo:   https://github.com/lersek/edk2.git
> > > Branch: ata_disable_only_bmdma
> > >
> > >  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h | 3 +--
> > > MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c | 5 ++---
> > >  2 files changed, 3 insertions(+), 5 deletions(-)
> > >
> > > diff --git
> > > a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
> > > b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
> > > index 8d6eac706c0b..92c5bf2001cd 100644
> > > --- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
> > > +++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
> > > @@ -123,8 +123,7 @@ typedef struct {
> > >LIST_ENTRYNonBlockingTaskList;
> > >
> > >//
> > > -  // For disabling the device (especially Bus Master DMA) at
> > > -  // ExitBootServices().
> > > +  // For disabling Bus Master DMA on the device at ExitBootServices().
> > >//
> > >EFI_EVENT ExitBootEvent;
> > >  } ATA_ATAPI_PASS_THRU_INSTANCE;
> > > diff --git
> > > a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
> > > b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
> > > index 

[edk2] [PATCH v8 0/2] Fix multiple entries of RT_CODE in memory map

[Jian J Wang]

> 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 mismatch all the time to avoid
>a logic hole
> b. Add warning message if failed to update capability
> c. Add local variable to hold new attributes to make code cleaner

> v3:
> a. Add comment to explain more on updating memory capabilities
> b. Fix logic hole in updating attributes
> c. Instead of checking illegal memory space address and size, use return
>status of gDS->SetMemorySpaceCapabilities() to skip memory block which
>cannot be updated with new capabilities.

> v2
> a. Fix an issue which will cause setting capability failure if size is smaller
>than a page.

More than one entry of RT_CODE memory might cause boot problem for some
old OSs. This patch will fix this issue to keep OS compatibility as much
as possible.

More detailed information, please refer to
https://bugzilla.tianocore.org/show_bug.cgi?id=753

Laszlo did a thorough test on OVMF emulated platform. The details can be found
at https://bugzilla.tianocore.org/show_bug.cgi?id=753#c10

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
Tested-by: Laszlo Ersek 

Jian J Wang (2):
  UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map
  MdeModulePkg/DxeCore: Filter out all paging capabilities

 MdeModulePkg/Core/Dxe/Mem/Page.c | 20 +
 UefiCpuPkg/CpuDxe/CpuPageTable.c | 94 +++-
 2 files changed, 93 insertions(+), 21 deletions(-)

-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v8 1/2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Jian J Wang]

> 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. Add local variable to hold new attributes to make code cleaner

> v3:
> a. Add comment to explain more on updating memory capabilities
> b. Fix logic hole in updating attributes
> c. Instead of checking illegal memory space address and size, use return
>status of gDS->SetMemorySpaceCapabilities() to skip memory block which
>cannot be updated with new capabilities.

> v2
> a. Fix an issue which will cause setting capability failure if size is smaller
>than a page.

More than one entry of RT_CODE memory might cause boot problem for some
old OSs. This patch will fix this issue to keep OS compatibility as much
as possible.

More detailed information, please refer to
https://bugzilla.tianocore.org/show_bug.cgi?id=753

Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Star Zeng 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
Tested-by: Laszlo Ersek 
Reviewed-by: Star Zeng 
Reviewed-by: Laszlo Ersek 
---
 UefiCpuPkg/CpuDxe/CpuPageTable.c | 94 +++-
 1 file changed, 73 insertions(+), 21 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c b/UefiCpuPkg/CpuDxe/CpuPageTable.c
index 76f44f9bd1..9658ed74c5 100644
--- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
+++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
@@ -769,6 +769,20 @@ AssignMemoryPageAttributes (
   return Status;
 }
 
+/**
+ Check if Execute Disable feature is enabled or not.
+**/
+BOOLEAN
+IsExecuteDisableEnabled (
+  VOID
+  )
+{
+  MSR_CORE_IA32_EFER_REGISTERMsrEfer;
+
+  MsrEfer.Uint64 = AsmReadMsr64 (MSR_IA32_EFER);
+  return (MsrEfer.Bits.NXE == 1);
+}
+
 /**
   Update GCD memory space attributes according to current page table setup.
 **/
@@ -790,7 +804,7 @@ RefreshGcdMemoryAttributesFromPaging (
   UINT64  PageStartAddress;
   UINT64  Attributes;
   UINT64  Capabilities;
-  BOOLEAN DoUpdate;
+  UINT64  NewAttributes;
   UINTN   Index;
 
   //
@@ -802,17 +816,50 @@ RefreshGcdMemoryAttributesFromPaging (
 
   GetCurrentPagingContext ();
 
-  DoUpdate  = FALSE;
-  Capabilities  = 0;
-  Attributes= 0;
-  BaseAddress   = 0;
-  PageLength= 0;
+  Attributes  = 0;
+  NewAttributes   = 0;
+  BaseAddress = 0;
+  PageLength  = 0;
+
+  if (IsExecuteDisableEnabled ()) {
+Capabilities = EFI_MEMORY_RO | EFI_MEMORY_RP | EFI_MEMORY_XP;
+  } else {
+Capabilities = EFI_MEMORY_RO | EFI_MEMORY_RP;
+  }
 
   for (Index = 0; Index < NumberOfDescriptors; Index++) {
 if (MemorySpaceMap[Index].GcdMemoryType == EfiGcdMemoryTypeNonExistent) {
   continue;
 }
 
+//
+// Sync the actual paging related capabilities back to GCD service first.
+// As a side effect (good one), this can also help to avoid unnecessary
+// memory map entries due to the different capabilities of the same type
+// memory, such as multiple RT_CODE and RT_DATA entries in memory map,
+// which could cause boot failure of some old Linux distro (before v4.3).
+//
+Status = gDS->SetMemorySpaceCapabilities (
+MemorySpaceMap[Index].BaseAddress,
+MemorySpaceMap[Index].Length,
+MemorySpaceMap[Index].Capabilities | Capabilities
+);
+if (EFI_ERROR (Status)) {
+  //
+  // If we cannot udpate the capabilities, we cannot update its
+  // attributes either. So just simply skip current block of memory.
+  //
+  DEBUG ((
+DEBUG_WARN,
+"Failed to update capability: [%lu] %016lx - %016lx (%016lx -> 
%016lx)\r\n",
+(UINT64)Index, MemorySpaceMap[Index].BaseAddress,
+MemorySpaceMap[Index].BaseAddress + MemorySpaceMap[Index].Length - 1,
+MemorySpaceMap[Index].Capabilities,
+MemorySpaceMap[Index].Capabilities | Capabilities
+));
+  continue;
+}
+
 if (MemorySpaceMap[Index].BaseAddress >= (BaseAddress + PageLength)) {
   //
   // Current memory space starts at a new page. Resetting PageLength will
@@ -826,7 +873,9 @@ RefreshGcdMemoryAttributesFromPaging (
   PageLength -= (MemorySpaceMap[Index].BaseAddress - BaseAddress);
 }
 
-// Sync real page attributes to GCD
+//
+// Sync actual page attributes to GCD
+//
 BaseAddress   = MemorySpaceMap[Index].BaseAddress;
 MemorySpaceLength = 

[edk2] [PATCH v8 2/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

[Jian J Wang]

> 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.
But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
value from Capabilities in GCD memory map. This might cause
boot problems. Clearing all paging related capabilities can
workaround it. The code added in this patch is supposed to
be removed once the usage of EFI_MEMORY_DESCRIPTOR.Attribute
is clarified in UEFI spec and adopted by both EDK-II Core and
all supported OSs.

Cc: Jiewen Yao 
Cc: Star Zeng 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
Tested-by: Laszlo Ersek 
Reviewed-by: Star Zeng 
Reviewed-by: Laszlo Ersek 
---
 MdeModulePkg/Core/Dxe/Mem/Page.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index 2034b64cd7..962ae90d3d 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -1687,6 +1687,7 @@ CoreGetMemoryMap (
   EFI_GCD_MAP_ENTRY MergeGcdMapEntry;
   EFI_MEMORY_TYPE   Type;
   EFI_MEMORY_DESCRIPTOR *MemoryMapStart;
+  EFI_MEMORY_DESCRIPTOR *MemoryMapEnd;
 
   //
   // Make sure the parameters are valid
@@ -1896,6 +1897,25 @@ CoreGetMemoryMap (
   //
   BufferSize = ((UINT8 *)MemoryMap - (UINT8 *)MemoryMapStart);
 
+  //
+  // Note: Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really
+  //   set attributes and change memory paging attribute accordingly.
+  //   But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
+  //   value from Capabilities in GCD memory map. This might cause
+  //   boot problems. Clearing all paging related capabilities can
+  //   workaround it. Following code is supposed to be removed once
+  //   the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified in
+  //   UEFI spec and adopted by both EDK-II Core and all supported
+  //   OSs.
+  //
+  MemoryMapEnd = MemoryMap;
+  MemoryMap = MemoryMapStart;
+  while (MemoryMap < MemoryMapEnd) {
+MemoryMap->Attribute &= ~(UINT64)(EFI_MEMORY_RP | EFI_MEMORY_RO |
+  EFI_MEMORY_XP);
+MemoryMap = NEXT_MEMORY_DESCRIPTOR (MemoryMap, Size);
+  }
+
   Status = EFI_SUCCESS;
 
 Done:
-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch][edk2-platforms] Minor BIOS ID.

[lushifex]

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 
b/Platform/BroxtonPlatformPkg/BiosId.env
index 851c2d3..656f130 100644
--- a/Platform/BroxtonPlatformPkg/BiosId.env
+++ b/Platform/BroxtonPlatformPkg/BiosId.env
@@ -31,5 +31,5 @@ BOARD_ID  = APLKRVP
 BOARD_REV = 3
 BUILD_TYPE= D
 VERSION_MAJOR = 0067
-VERSION_MINOR = 05
+VERSION_MINOR = 06
 BOARD_EXT = X64
-- 
2.7.0.windows.1


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/Core: Fix potential array overflow

[Wu, Hao A]

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
> 
> 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: Star Zeng 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  MdeModulePkg/Core/Dxe/Mem/HeapGuard.c   | 4 +++-
>  MdeModulePkg/Core/PiSmmCore/HeapGuard.c | 8 ++--
>  2 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> index 30a73fc04d..3a829854af 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> @@ -1110,7 +1110,9 @@ DumpGuardedMemoryBitmap (
>CHAR8 *Ruler1;
>CHAR8 *Ruler2;
> 
> -  if (mGuardedMemoryMap == 0) {
> +  if (mGuardedMemoryMap == 0 ||
> +  mMapLevel == 0 ||
> +  mMapLevel > GUARDED_HEAP_MAP_TABLE_DEPTH) {
>  return;
>}
> 
> diff --git a/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> b/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> index 7dbbf79dc0..1d5fb8cdb5 100644
> --- a/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> +++ b/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> @@ -1170,7 +1170,9 @@ SetAllGuardPages (
>UINTN Index;
>BOOLEAN   OnGuarding;
> 
> -  if (mGuardedMemoryMap == 0) {
> +  if (mGuardedMemoryMap == 0 ||
> +  mMapLevel == 0 ||
> +  mMapLevel > GUARDED_HEAP_MAP_TABLE_DEPTH) {
>  return;
>}
> 
> @@ -1329,7 +1331,9 @@ DumpGuardedMemoryBitmap (
>CHAR8 *Ruler1;
>CHAR8 *Ruler2;
> 
> -  if (mGuardedMemoryMap == 0) {
> +  if (mGuardedMemoryMap == 0 ||
> +  mMapLevel == 0 ||
> +  mMapLevel > GUARDED_HEAP_MAP_TABLE_DEPTH) {
>  return;
>}
> 
> --
> 2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/Core: Add missing header files into inf

[Bi, Dandan]

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 ; Zeng, 
Star 
Subject: [edk2] [PATCH] MdeModulePkg/Core: Add missing header files into inf

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 Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/Dxe/DxeMain.inf | 1 +
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf | 1 +
 2 files changed, 2 insertions(+)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf 
b/MdeModulePkg/Core/Dxe/DxeMain.inf
index f2155fcab1..7334780326 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.inf
+++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -57,6 +57,7 @@
   Mem/Imem.h
   Mem/MemoryProfileRecord.c
   Mem/HeapGuard.c
+  Mem/HeapGuard.h
   FwVolBlock/FwVolBlock.c
   FwVolBlock/FwVolBlock.h
   FwVol/FwVolWrite.c
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
index 1583641887..01d706d0e3 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
@@ -41,6 +41,7 @@
   MemoryAttributesTable.c
   SmiHandlerProfile.c
   HeapGuard.c
+  HeapGuard.h
 
 [Packages]
   MdePkg/MdePkg.dec
--
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] IntelSiliconPkg IntelVTdDxe: Do not SetupVtd again

[Yao, Jiewen]

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] IntelSiliconPkg IntelVTdDxe: Do not SetupVtd again
> 
> 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 +++--
>  IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmarAcpiTable.c | 7 ---
>  3 files changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.c
> b/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.c
> index 6052a0aebe45..37b3b19bce90 100644
> --- a/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.c
> +++ b/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.c
> @@ -412,6 +412,9 @@ AcpiNotificationFunc (
> 
>Status = GetDmarAcpiTable ();
>if (EFI_ERROR (Status)) {
> +if (Status == EFI_ALREADY_STARTED) {
> +  gBS->CloseEvent (Event);
> +}
>  return;
>}
>SetupVtd ();
> diff --git a/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.h
> b/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.h
> index 0886647ea673..519a5ab00450 100644
> --- a/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.h
> +++ b/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.h
> @@ -302,8 +302,9 @@ FindVtdIndexByPciDevice (
>  /**
>Get the DMAR ACPI table.
> 
> -  @retval EFI_SUCCESSThe DMAR ACPI table is got.
> -  @retval EFI_NOT_FOUND  The DMAR ACPI table is not found.
> +  @retval EFI_SUCCESS   The DMAR ACPI table is got.
> +  @retval EFI_ALREADY_STARTED   The DMAR ACPI table has been got
> previously.
> +  @retval EFI_NOT_FOUND The DMAR ACPI table is not found.
>  **/
>  EFI_STATUS
>  GetDmarAcpiTable (
> diff --git a/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmarAcpiTable.c
> b/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmarAcpiTable.c
> index 81dec109675b..ce350bafbe3f 100644
> --- a/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmarAcpiTable.c
> +++ b/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmarAcpiTable.c
> @@ -978,8 +978,9 @@ FindAcpiPtr (
>  /**
>Get the DMAR ACPI table.
> 
> -  @retval EFI_SUCCESSThe DMAR ACPI table is got.
> -  @retval EFI_NOT_FOUND  The DMAR ACPI table is not found.
> +  @retval EFI_SUCCESS   The DMAR ACPI table is got.
> +  @retval EFI_ALREADY_STARTED   The DMAR ACPI table has been got
> previously.
> +  @retval EFI_NOT_FOUND The DMAR ACPI table is not found.
>  **/
>  EFI_STATUS
>  GetDmarAcpiTable (
> @@ -990,7 +991,7 @@ GetDmarAcpiTable (
>EFI_STATUSStatus;
> 
>if (mAcpiDmarTable != NULL) {
> -return EFI_SUCCESS;
> +return EFI_ALREADY_STARTED;
>}
> 
>AcpiTable = NULL;
> --
> 2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] MdeModulePkg/Core: Add missing header files into inf

[Jian J Wang]

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 Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/Dxe/DxeMain.inf | 1 +
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf | 1 +
 2 files changed, 2 insertions(+)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf 
b/MdeModulePkg/Core/Dxe/DxeMain.inf
index f2155fcab1..7334780326 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.inf
+++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -57,6 +57,7 @@
   Mem/Imem.h
   Mem/MemoryProfileRecord.c
   Mem/HeapGuard.c
+  Mem/HeapGuard.h
   FwVolBlock/FwVolBlock.c
   FwVolBlock/FwVolBlock.h
   FwVol/FwVolWrite.c
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
index 1583641887..01d706d0e3 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
@@ -41,6 +41,7 @@
   MemoryAttributesTable.c
   SmiHandlerProfile.c
   HeapGuard.c
+  HeapGuard.h
 
 [Packages]
   MdePkg/MdePkg.dec
-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] MdeModulePkg: Free NET_BUF data after it is sent out to avoid memory leak

[Wu, Jiaxin]

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 incorrect since the Packet will be retransmit later.

Please take a look.

Thanks,
Jiaxin


> -Original Message-
> From: Wang, Fan
> Sent: Wednesday, November 22, 2017 2:56 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin ; Ye, Ting ; Fu,
> Siyuan ; Wang, Fan 
> Subject: [Patch] MdeModulePkg: Free NET_BUF data after it is sent out to
> avoid memory leak
> 
> When build a DHCP message in function DhcpSendMessage() or
> DhcpRetransmit(),
> a new NET_BUF is created by the library of NetbufFromExt, but it's not freed
> after it is sent out. This patch is to fix this memory leak issue.
> 
> Cc: Jiaxin Wu 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wang Fan 
> ---
>  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> index 3898223..d90dc34 100644
> --- a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> +++ b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> @@ -1397,23 +1397,22 @@ DhcpSendMessage (
>  EndPoint.LocalAddr.Addr[0]  = DhcpSb->ClientAddr;
>  UdpIo   = DhcpSb->LeaseIoPort;
>}
> 
>ASSERT (UdpIo != NULL);
> -  NET_GET_REF (Wrap);
> -
> +
>Status = UdpIoSendDatagram (
>   UdpIo,
>   Wrap,
>   ,
>   NULL,
>   DhcpOnPacketSent,
>   DhcpSb
>   );
> 
>if (EFI_ERROR (Status)) {
> -NET_PUT_REF (Wrap);
> +NetbufFree (Wrap);
>  return EFI_ACCESS_DENIED;
>}
> 
>return EFI_SUCCESS;
>  }
> @@ -1475,22 +1474,21 @@ DhcpRetransmit (
>  UdpIo   = DhcpSb->LeaseIoPort;
>}
> 
>ASSERT (UdpIo != NULL);
> 
> -  NET_GET_REF (Wrap);
>Status = UdpIoSendDatagram (
>   UdpIo,
>   Wrap,
>   ,
>   NULL,
>   DhcpOnPacketSent,
>   DhcpSb
>   );
> 
>if (EFI_ERROR (Status)) {
> -NET_PUT_REF (Wrap);
> +NetbufFree (Wrap);
>  return EFI_ACCESS_DENIED;
>}
> 
>return EFI_SUCCESS;
>  }
> --
> 1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] IntelSiliconPkg IntelVTdDxe: Do not SetupVtd again

[Star Zeng]

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 +++--
 IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmarAcpiTable.c | 7 ---
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.c 
b/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.c
index 6052a0aebe45..37b3b19bce90 100644
--- a/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.c
+++ b/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.c
@@ -412,6 +412,9 @@ AcpiNotificationFunc (
 
   Status = GetDmarAcpiTable ();
   if (EFI_ERROR (Status)) {
+if (Status == EFI_ALREADY_STARTED) {
+  gBS->CloseEvent (Event);
+}
 return;
   }
   SetupVtd ();
diff --git a/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.h 
b/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.h
index 0886647ea673..519a5ab00450 100644
--- a/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.h
+++ b/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.h
@@ -302,8 +302,9 @@ FindVtdIndexByPciDevice (
 /**
   Get the DMAR ACPI table.
 
-  @retval EFI_SUCCESSThe DMAR ACPI table is got.
-  @retval EFI_NOT_FOUND  The DMAR ACPI table is not found.
+  @retval EFI_SUCCESS   The DMAR ACPI table is got.
+  @retval EFI_ALREADY_STARTED   The DMAR ACPI table has been got previously.
+  @retval EFI_NOT_FOUND The DMAR ACPI table is not found.
 **/
 EFI_STATUS
 GetDmarAcpiTable (
diff --git a/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmarAcpiTable.c 
b/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmarAcpiTable.c
index 81dec109675b..ce350bafbe3f 100644
--- a/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmarAcpiTable.c
+++ b/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmarAcpiTable.c
@@ -978,8 +978,9 @@ FindAcpiPtr (
 /**
   Get the DMAR ACPI table.
 
-  @retval EFI_SUCCESSThe DMAR ACPI table is got.
-  @retval EFI_NOT_FOUND  The DMAR ACPI table is not found.
+  @retval EFI_SUCCESS   The DMAR ACPI table is got.
+  @retval EFI_ALREADY_STARTED   The DMAR ACPI table has been got previously.
+  @retval EFI_NOT_FOUND The DMAR ACPI table is not found.
 **/
 EFI_STATUS
 GetDmarAcpiTable (
@@ -990,7 +991,7 @@ GetDmarAcpiTable (
   EFI_STATUSStatus;
 
   if (mAcpiDmarTable != NULL) {
-return EFI_SUCCESS;
+return EFI_ALREADY_STARTED;
   }
 
   AcpiTable = NULL;
-- 
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg UhciPei: Also check TempPtr against NULL to return error

[Wu, Hao A]

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 NULL
> to return error
> 
> 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 a/MdeModulePkg/Bus/Pci/UhciPei/UhcPeim.c
> b/MdeModulePkg/Bus/Pci/UhciPei/UhcPeim.c
> index b7d60db0c94e..482c404c0eae 100644
> --- a/MdeModulePkg/Bus/Pci/UhciPei/UhcPeim.c
> +++ b/MdeModulePkg/Bus/Pci/UhciPei/UhcPeim.c
> @@ -2863,8 +2863,8 @@ CreateMemoryBlock (
>   ,
>   
>   );
> -  if (EFI_ERROR (Status)) {
> -return Status;
> +  if (EFI_ERROR (Status) || (TempPtr == NULL)) {
> +return EFI_OUT_OF_RESOURCES;
>}
> 
>Ptr = TempPtr;
> --
> 2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] MdeModulePkg/Core: Fix potential array overflow

[Jian J Wang]

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: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/Dxe/Mem/HeapGuard.c   | 4 +++-
 MdeModulePkg/Core/PiSmmCore/HeapGuard.c | 8 ++--
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c 
b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
index 30a73fc04d..3a829854af 100644
--- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
+++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
@@ -1110,7 +1110,9 @@ DumpGuardedMemoryBitmap (
   CHAR8 *Ruler1;
   CHAR8 *Ruler2;
 
-  if (mGuardedMemoryMap == 0) {
+  if (mGuardedMemoryMap == 0 ||
+  mMapLevel == 0 ||
+  mMapLevel > GUARDED_HEAP_MAP_TABLE_DEPTH) {
 return;
   }
 
diff --git a/MdeModulePkg/Core/PiSmmCore/HeapGuard.c 
b/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
index 7dbbf79dc0..1d5fb8cdb5 100644
--- a/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
+++ b/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
@@ -1170,7 +1170,9 @@ SetAllGuardPages (
   UINTN Index;
   BOOLEAN   OnGuarding;
 
-  if (mGuardedMemoryMap == 0) {
+  if (mGuardedMemoryMap == 0 ||
+  mMapLevel == 0 ||
+  mMapLevel > GUARDED_HEAP_MAP_TABLE_DEPTH) {
 return;
   }
 
@@ -1329,7 +1331,9 @@ DumpGuardedMemoryBitmap (
   CHAR8 *Ruler1;
   CHAR8 *Ruler2;
 
-  if (mGuardedMemoryMap == 0) {
+  if (mGuardedMemoryMap == 0 ||
+  mMapLevel == 0 ||
+  mMapLevel > GUARDED_HEAP_MAP_TABLE_DEPTH) {
 return;
   }
 
-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] MdeModulePkg UhciPei: Also check TempPtr against NULL to return error

[Star Zeng]

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 a/MdeModulePkg/Bus/Pci/UhciPei/UhcPeim.c 
b/MdeModulePkg/Bus/Pci/UhciPei/UhcPeim.c
index b7d60db0c94e..482c404c0eae 100644
--- a/MdeModulePkg/Bus/Pci/UhciPei/UhcPeim.c
+++ b/MdeModulePkg/Bus/Pci/UhciPei/UhcPeim.c
@@ -2863,8 +2863,8 @@ CreateMemoryBlock (
  ,
  
  );
-  if (EFI_ERROR (Status)) {
-return Status;
+  if (EFI_ERROR (Status) || (TempPtr == NULL)) {
+return EFI_OUT_OF_RESOURCES;
   }
 
   Ptr = TempPtr;
-- 
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EDK2 build issues

[Andrew Fish]

> 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 a few issues like that in BaseTools. We have a parallel 
makefile and we had to turn off parallelism when calling the BaseTools. 

In general the edk2 build system fights against "make -j " since the Python 
build command is trying to do the threading and invoking make in parallel. 
Given we ported EDK to parallel build, the Python parallel edk2 build is a lot 
slower than the EDK make parallel build, even when adjusting for the extra work 
the edk2 does. 

I even noticed a 1,000,000 calls to regex in Python during the ... phase of the 
build. 

I think the correct short term fix may be to put .NOTPARALLEL: in the BaseTools 
GNUmakefile given it is constructed in a way that it does not support 
parallelism. 

Thanks,

Andrew Fish



> https://bugzilla.tianocore.org/show_bug.cgi?id=786
> 
> For the ARCH environment variable, we brainstormed two possible new names 
> HOST_ARCH or BASETOOLS_ARCH. Should I file the ARCH variable request in 
> Bugzilla as well?
> 
> Thanks,
> 
> Nate
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao, 
> Liming
> Sent: Monday, November 13, 2017 5:46 PM
> To: Aaron Durbin 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] EDK2 build issues
> 
> I add my comments. 
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Aaron Durbin
>> Sent: Tuesday, November 14, 2017 1:38 AM
>> To: Gao, Liming 
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: [edk2] EDK2 build issues
>> 
>> On Sun, Nov 12, 2017 at 7:15 PM, Gao, Liming  wrote:
>>> Yes. BaseTools needs some environments. Before build BaseTools, we need to 
>>> call edkset.sh to setup them.
>>> 
>>> 1. BaseTools Soure tools are compiled in serial instead of parallel. 
>>> And, VfrCompiler depends on Anltr tool. So, Anltr is required to be
>> built first. I agree that this way takes some time to compile 
>> BaseTools source. I have one proposal to compile C source tools with 
>> multiple thread. I can share my draft patch.
>> 
>> If the depedencies are correctly met in the makefiles then why are 
>> they built serially? It sounds like you understand the dependencies so 
>> why aren't those explicitly noted so one can build in parallel?
>> 
> Seemly, VfrCompiler Makefile doesn't list those dependency clearly. Could you 
> submit this issue in bugzillar (https://bugzilla.tianocore.org/)?
> Besides, do you use make -j option to enable Parallel Execution? I want to 
> know how to verify it. 
> 
>>> 2. BaseTools C source are compiled to the executable files. They run 
>>> in host machine. Here ARCH is for the executable files those can
>> run in host machine. edk2\BaseTools\Source\C\GNUmakefile auto detects ARCH 
>> based on 'uname -m' command.
>> 
>> ARCH != host is my point. Why are those being conflated? Or are you 
>> saying edk2 tools define ARCH to be what the host is?
>> 
> Yes. Edk2 BaseTools C source uses it as host arch. I agree ARCH name is too 
> generic. In your environment, ARCH may be defined for the different purpose. 
> 
>>> 3. There are more GCC compiler distribution. We try to use the 
>>> generic options in GCC tool chain. If you find the option doesn't 
>>> work
>> on your GCC compiler, please report it. And, we also notice 
>> tools_def.txt is too big to be hard to be maintain. We have one proposal to 
>> simplify it. I will send this RFC to edk2 community.
>>> 
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
 Of Aaron Durbin
 Sent: Saturday, November 11, 2017 6:27 AM
 To: edk2-devel@lists.01.org
 Subject: [edk2] EDK2 build issues
 
 Hello,
 
 Here are some observations I've encountered trying to utilize edk2 
 for certain builds. Part of the problem seems to be with implicit 
 assumptions in how edk2 is used. I'm trying to build things using 
 edk2 from a clean enviroment on an automated builder. i.e. there 
 isn't a workspace that exists on one persons computer for the 
 lifetime of development.
 
 1. BaseTools can't build in parallel. The tests are racey which 
 result in test failures. Because of this one has to build these in 
 serial instead of in parallel.
 
 ===
 ===
 FAIL: testHelp (TianoCompress.Tests)
 
 --
 Traceback (most recent call last):
 File 
 "/build/zoombini/tmp/portage/sys-boot/fsp-cnl-/work/fsp-cnl-
 

[edk2] [PATCH 4/5] OvmfPkg/PlatformBootManagerLib: print EDKII_OS_LOADER_DETAIL to ConOut

[Laszlo Ersek]

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 (earlier) console messages about boot option
generation and boot option filtering / reordering.

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: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
We can port this later to ArmVirtPkg. For that, first we'll have to
replace commit 59541d41633c ("ArmVirtPkg: remove status code support",
2017-07-05) with a port of commit a6d594c5fabd ("OvmfPkg: use StatusCode
Router and Handler from MdeModulePkg", 2016-08-03).

 OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |   4 +
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h  |  15 +
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c  |   8 +
 OvmfPkg/Library/PlatformBootManagerLib/StatusCodeHandler.c| 298 

 4 files changed, 325 insertions(+)

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 27789b7377bc..36901fc39d95 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -21,24 +21,25 @@ [Defines]
   LIBRARY_CLASS  = PlatformBootManagerLib|DXE_DRIVER
 
 #
 # The following information is for reference only and not required by the 
build tools.
 #
 #  VALID_ARCHITECTURES   = IA32 X64 IPF EBC
 #
 
 [Sources]
   BdsPlatform.c
   PlatformData.c
   QemuKernel.c
+  StatusCodeHandler.c
   BdsPlatform.h
 
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
   IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
   SourceLevelDebugPkg/SourceLevelDebugPkg.dec
   OvmfPkg/OvmfPkg.dec
 
 [LibraryClasses]
   BaseLib
   MemoryAllocationLib
@@ -54,28 +55,31 @@ [LibraryClasses]
   QemuFwCfgLib
   QemuFwCfgS3Lib
   LoadLinuxLib
   QemuBootOrderLib
   UefiLib
 
 [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile
+  gEfiMdeModulePkgTokenSpaceGuid.PcdDebugCodeOsLoaderDetail
 
 [Pcd.IA32, Pcd.X64]
   gEfiMdePkgTokenSpaceGuid.PcdFSBClock
 
 [Protocols]
   gEfiDecompressProtocolGuid
   gEfiPciRootBridgeIoProtocolGuid
   gEfiS3SaveStateProtocolGuid   # PROTOCOL SOMETIMES_CONSUMED
   gEfiDxeSmmReadyToLockProtocolGuid # PROTOCOL SOMETIMES_PRODUCED
   gEfiLoadedImageProtocolGuid   # PROTOCOL SOMETIMES_PRODUCED
   gEfiFirmwareVolume2ProtocolGuid   # PROTOCOL SOMETIMES_CONSUMED
+  gEfiRscHandlerProtocolGuid# PROTOCOL SOMETIMES_CONSUMED
 
 [Guids]
   gEfiXenInfoGuid
   gEfiEndOfDxeEventGroupGuid
   gRootBridgesConnectedEventGroupGuid
+  gEdkiiStatusCodeDataTypeOsLoaderDetailGuid
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
index 97ffbb514825..493cfee85f54 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
@@ -183,13 +183,28 @@ PlatformInitializeConsole (
 
 /**
   Loads and boots UEFI Linux via the FwCfg interface.
 
   @retvalEFI_NOT_FOUND - The Linux kernel was not found
 
 **/
 EFI_STATUS
 TryRunningQemuKernel (
   VOID
   );
 
+/**
+  Register a status code handler for printing EDKII_OS_LOADER_DETAIL reports to
+  the console.
+
+  @retval EFI_SUCCESS  The status code handler has been successfully
+   registered.
+
+  @return  Error codes propagated from boot services and from
+   EFI_RSC_HANDLER_PROTOCOL.
+**/
+EFI_STATUS
+RegisterStatusCodeHandler (
+  VOID
+  );
+
 #endif // _PLATFORM_SPECIFIC_BDS_PLATFORM_H_
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 025252e72b39..429f2926d2af 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -1454,35 +1454,43 @@ Routine Description:
   BootLogoEnableLogo ();
 
   //
   // Perform some platform specific connect sequence
   //
   PlatformBdsConnectSequence ();
 
   //
   // Process QEMU's -kernel command line option
   //
   

[edk2] [PATCH 1/5] MdeModulePkg/BdsDxe: fall back to a Boot Manager Menu loop before hanging

[Laszlo Ersek]

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() with:

   DEBUG ((EFI_D_ERROR, "[Bds] Unable to boot!\n"));
   CpuDeadLoop ();

while the user sits at the TianoCore logo page, wondering what's going on.
Print an informative message to the console, wait for a keypress, and then
return to the Boot Manager Menu forever.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Ruiyu Ni 
Cc: Eric Dong 
Cc: Star Zeng 
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=513
Suggested-by: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 60 ++--
 1 file changed, 56 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c 
b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
index dccc49090219..2b24755ac368 100644
--- a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
+++ b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
@@ -676,24 +676,73 @@ BdsAllocateMemoryForPerformanceData (
 //
 // Mark L"PerfDataMemAddr" variable to read-only if the Variable Lock 
protocol exists
 // Still lock it even the variable cannot be saved to prevent it's set by 
3rd party code.
 //
 Status = gBS->LocateProtocol (, NULL, (VOID 
**) );
 if (!EFI_ERROR (Status)) {
   Status = VariableLock->RequestToLock (VariableLock, L"PerfDataMemAddr", 
);
   ASSERT_EFI_ERROR (Status);
 }
   }
 }
 
+/**
+  Enter an infinite loop of calling the Boot Manager Menu.
+
+  This is a last resort alternative to BdsEntry() giving up for good. This
+  function never returns.
+
+  @param[in] BootManagerMenu  The EFI_BOOT_MANAGER_LOAD_OPTION located and/or
+  created by the EfiBootManagerGetBootManagerMenu()
+  call in BdsEntry().
+**/
+VOID
+BdsBootManagerMenuLoop (
+  IN EFI_BOOT_MANAGER_LOAD_OPTION *BootManagerMenu
+  )
+{
+  EFI_INPUT_KEY Key;
+
+  //
+  // Normally BdsDxe does not print anything to the system console, but this is
+  // a last resort -- the end-user will likely not see any DEBUG messages
+  // logged in this situation.
+  //
+  // AsciiPrint() will NULL-check gST->ConOut internally. We check gST->ConIn
+  // here to see if it makes sense to request and wait for a keypress.
+  //
+  if (gST->ConIn != NULL) {
+AsciiPrint (
+  "%a: No bootable option or device was found.\n"
+  "%a: Press any key to enter the Boot Manager Menu.\n",
+  gEfiCallerBaseName,
+  gEfiCallerBaseName
+  );
+BdsWaitForSingleEvent (gST->ConIn->WaitForKey, 0);
+
+//
+// Drain any queued keys.
+//
+while (!EFI_ERROR (gST->ConIn->ReadKeyStroke (gST->ConIn, ))) {
+  //
+  // just throw away Key
+  //
+}
+  }
+
+  for (;;) {
+EfiBootManagerBoot (BootManagerMenu);
+  }
+}
+
 /**
 
   Service routine for BdsInstance->Entry(). Devices are connected, the
   consoles are initialized, and the boot options are tried.
 
   @param This Protocol Instance structure.
 
 **/
 VOID
 EFIAPI
 BdsEntry (
   IN EFI_BDS_ARCH_PROTOCOL  *This
@@ -1079,34 +1128,37 @@ BdsEntry (
 }
 
 do {
   //
   // Retry to boot if any of the boot succeeds
   //
   LoadOptions = EfiBootManagerGetLoadOptions (, 
LoadOptionTypeBoot);
   BootSuccess = BootBootOptions (LoadOptions, LoadOptionCount, 
(BootManagerMenuStatus != EFI_NOT_FOUND) ?  : NULL);
   EfiBootManagerFreeLoadOptions (LoadOptions, LoadOptionCount);
 } while (BootSuccess);
   }
 
-  if (BootManagerMenuStatus != EFI_NOT_FOUND) {
-EfiBootManagerFreeLoadOption ();
-  }
-
   if (!BootSuccess) {
 LoadOptions = EfiBootManagerGetLoadOptions (, 
LoadOptionTypePlatformRecovery);
 ProcessLoadOptions (LoadOptions, LoadOptionCount);
 EfiBootManagerFreeLoadOptions (LoadOptions, LoadOptionCount);
   }
 
+  //
+  // If BootManagerMenu is available, fall back to it indefinitely.
+  //
+  if (BootManagerMenuStatus != EFI_NOT_FOUND) {
+BdsBootManagerMenuLoop ();
+  }
+
   DEBUG ((EFI_D_ERROR, "[Bds] Unable to boot!\n"));
   CpuDeadLoop ();
 }
 
 /**
   Set the variable and report the error through status code upon failure.
 
   @param  VariableName   A Null-terminated string that is the name of 
the vendor's variable.
  Each VariableName is unique for each 
VendorGuid. VariableName must
  contain 1 or more characters. If VariableName 
is an empty string,
  then EFI_INVALID_PARAMETER is returned.
   

[edk2] [PATCH 3/5] MdeModulePkg/UefiBootManagerLib: report EDKII_OS_LOADER_DETAIL status code

[Laszlo Ersek]

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 -- the error result at the
same locations, through EFI_DEBUG_CODE reporting. Use the
PcdDebugCodeOsLoaderDetail status code value and the
EDKII_OS_LOADER_DETAIL status code structure introduced earlier in this
series.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Ruiyu Ni 
Cc: Eric Dong 
Cc: Star Zeng 
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---
 MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf |   2 +
 MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h   |  84 ++
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   |  51 +-
 MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c   | 166 

 4 files changed, 301 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf 
b/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
index ad4901db5713..633906fc6ca4 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
+++ b/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
@@ -79,24 +79,25 @@ [Guids]
 
   ## SOMETIMES_PRODUCES ## Variable:L"BootCurrent" (The boot option of current 
boot)
   ## SOMETIMES_CONSUMES ## Variable:L"BootXX" (Boot option variable)
   ## SOMETIMES_CONSUMES ## Variable:L"BootOrder" (The boot option array)
   ## SOMETIMES_CONSUMES ## Variable:L"DriverOrder" (The driver order list)
   ## SOMETIMES_CONSUMES ## Variable:L"ConIn" (The device path of console in 
device)
   ## SOMETIMES_CONSUMES ## Variable:L"ConOut" (The device path of console out 
device)
   ## SOMETIMES_CONSUMES ## Variable:L"ErrOut" (The device path of error out 
device)
   gEfiGlobalVariableGuid
 
   gPerformanceProtocolGuid  ## SOMETIMES_CONSUMES ## 
Variable:L"PerfDataMemAddr" (The ACPI address of performance data)
   gEdkiiStatusCodeDataTypeVariableGuid  ## SOMETIMES_CONSUMES ## GUID
+  gEdkiiStatusCodeDataTypeOsLoaderDetailGuid## SOMETIMES_CONSUMES ## GUID
   gEfiDiskInfoAhciInterfaceGuid ## SOMETIMES_CONSUMES ## GUID
   gEfiDiskInfoIdeInterfaceGuid  ## SOMETIMES_CONSUMES ## GUID
   gEfiDiskInfoScsiInterfaceGuid ## SOMETIMES_CONSUMES ## GUID
   gEfiDiskInfoSdMmcInterfaceGuid## SOMETIMES_CONSUMES ## GUID
 
 [Protocols]
   gEfiPciRootBridgeIoProtocolGuid   ## CONSUMES
   gEfiSimpleFileSystemProtocolGuid  ## SOMETIMES_CONSUMES
   gEfiLoadFileProtocolGuid  ## SOMETIMES_CONSUMES
   gEfiSimpleTextOutProtocolGuid ## SOMETIMES_CONSUMES
   gEfiPciIoProtocolGuid ## SOMETIMES_CONSUMES
   gEfiLoadedImageProtocolGuid   ## CONSUMES
@@ -112,16 +113,17 @@ [Protocols]
   gEfiUsbIoProtocolGuid ## SOMETIMES_CONSUMES
   gEfiNvmExpressPassThruProtocolGuid## SOMETIMES_CONSUMES
   gEfiDiskInfoProtocolGuid  ## SOMETIMES_CONSUMES
   gEfiDriverHealthProtocolGuid  ## SOMETIMES_CONSUMES
   gEfiFormBrowser2ProtocolGuid  ## SOMETIMES_CONSUMES
   gEfiRamDiskProtocolGuid   ## SOMETIMES_CONSUMES
   gEfiDeferredImageLoadProtocolGuid ## SOMETIMES_CONSUMES
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange  ## 
SOMETIMES_CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdProgressCodeOsLoaderLoad## 
SOMETIMES_CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdProgressCodeOsLoaderStart   ## 
SOMETIMES_CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdDebugCodeOsLoaderDetail ## 
SOMETIMES_CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdErrorCodeSetVariable## 
SOMETIMES_CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdDriverHealthConfigureForm   ## 
SOMETIMES_CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxRepairCount  ## 
CONSUMES
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h 
b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
index 0224bd34a9ed..ddcb0347aef6 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
+++ b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
@@ -44,24 +44,25 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
 #include 
 #include 
 

[edk2] [PATCH 5/5] OvmfPkg: disable EFI_DEBUG_CODE reporting in RELEASE builds

[Laszlo Ersek]

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: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 7 +++
 OvmfPkg/OvmfPkgIa32X64.dsc | 7 +++
 OvmfPkg/OvmfPkgX64.dsc | 7 +++
 3 files changed, 21 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 7ccb61147f27..c5bd9aa4dc6c 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -420,25 +420,32 @@ [PcdsFixedAtBuild]
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800
   gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
 !endif
 !if $(FD_SIZE_IN_KB) == 4096
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x8400
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x8400
   gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x4
 !endif
 
   gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0
 
+  # REPORT_STATUS_CODE_PROPERTY_PROGRESS_CODE_ENABLED 0x01
+  # REPORT_STATUS_CODE_PROPERTY_ERROR_CODE_ENABLED0x02
+  # REPORT_STATUS_CODE_PROPERTY_DEBUG_CODE_ENABLED0x04
+!if $(TARGET) == RELEASE
+  gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x03
+!else
   gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07
+!endif
 
   # DEBUG_INIT  0x0001  // Initialization
   # DEBUG_WARN  0x0002  // Warnings
   # DEBUG_LOAD  0x0004  // Load events
   # DEBUG_FS0x0008  // EFI File system
   # DEBUG_POOL  0x0010  // Alloc & Free (pool)
   # DEBUG_PAGE  0x0020  // Alloc & Free (page)
   # DEBUG_INFO  0x0040  // Informational debug messages
   # DEBUG_DISPATCH  0x0080  // PEI/DXE/SMM Dispatchers
   # DEBUG_VARIABLE  0x0100  // Variable
   # DEBUG_BM0x0400  // Boot Manager
   # DEBUG_BLKIO 0x1000  // BlkIo Driver
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 237ec71b5ec0..6e39896b318f 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -425,25 +425,32 @@ [PcdsFixedAtBuild]
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800
   gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
 !endif
 !if $(FD_SIZE_IN_KB) == 4096
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x8400
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x8400
   gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x4
 !endif
 
   gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0
 
+  # REPORT_STATUS_CODE_PROPERTY_PROGRESS_CODE_ENABLED 0x01
+  # REPORT_STATUS_CODE_PROPERTY_ERROR_CODE_ENABLED0x02
+  # REPORT_STATUS_CODE_PROPERTY_DEBUG_CODE_ENABLED0x04
+!if $(TARGET) == RELEASE
+  gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x03
+!else
   gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07
+!endif
 
   # DEBUG_INIT  0x0001  // Initialization
   # DEBUG_WARN  0x0002  // Warnings
   # DEBUG_LOAD  0x0004  // Load events
   # DEBUG_FS0x0008  // EFI File system
   # DEBUG_POOL  0x0010  // Alloc & Free (pool)
   # DEBUG_PAGE  0x0020  // Alloc & Free (page)
   # DEBUG_INFO  0x0040  // Informational debug messages
   # DEBUG_DISPATCH  0x0080  // PEI/DXE/SMM Dispatchers
   # DEBUG_VARIABLE  0x0100  // Variable
   # DEBUG_BM0x0400  // Boot Manager
   # DEBUG_BLKIO 0x1000  // BlkIo Driver
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index a5047fa38e61..2e2d4d584429 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -425,25 +425,32 @@ [PcdsFixedAtBuild]
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800
   gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
 !endif
 !if $(FD_SIZE_IN_KB) == 4096
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x8400
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x8400
   gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x4
 !endif
 
   gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0
 
+  # REPORT_STATUS_CODE_PROPERTY_PROGRESS_CODE_ENABLED 0x01
+  # REPORT_STATUS_CODE_PROPERTY_ERROR_CODE_ENABLED0x02
+  # REPORT_STATUS_CODE_PROPERTY_DEBUG_CODE_ENABLED0x04
+!if $(TARGET) == RELEASE
+  gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x03
+!else
   gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07
+!endif
 
   # DEBUG_INIT  0x0001  // Initialization
   # DEBUG_WARN  0x0002  // Warnings
   # DEBUG_LOAD  0x0004  // Load events
   # DEBUG_FS0x0008  // EFI File 

[edk2] [PATCH 0/5] MdeModulePkg, OvmfPkg: more easily visible boot progress reporting

[Laszlo Ersek]

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 booting to the system console.

(Please read  as
well about our use case.)

Patch #1 makes the

   DEBUG ((EFI_D_ERROR, "[Bds] Unable to boot!\n"));
   CpuDeadLoop ();

part in BdsDxe more friendly, by printing a similar message to the
console, and entering the boot manager menu after a keypress. This was
suggested by Ray earlier; please refer to
.

Patches #2 through #4 introduce a new, structured, status code for the
reporting and routing/handling infrastructure. UefiBootManagerLib should
not write directly to the console -- it already only logs DEBUGs and
reports status codes --, but we should emit more detailed information in
status codes than we currently do. OVMF's PlatformBds is modified to
catch these status codes and print them to the console. Other platforms
are not affected (beyond any catch-all handlers picking up the new
status codes, if EFI_DEBUG_CODE reporting is enabled).

Patch #5 makes sure that RELEASE builds of OVMF are also not affected,
by clearing EFI_DEBUG_CODE reporting in those builds.

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Eric Dong 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Ruiyu Ni 
Cc: Star Zeng 

Thanks
Laszlo

Laszlo Ersek (5):
  MdeModulePkg/BdsDxe: fall back to a Boot Manager Menu loop before
hanging
  MdeModulePkg: introduce the EDKII_OS_LOADER_DETAIL status code payload
  MdeModulePkg/UefiBootManagerLib: report EDKII_OS_LOADER_DETAIL status
code
  OvmfPkg/PlatformBootManagerLib: print EDKII_OS_LOADER_DETAIL to ConOut
  OvmfPkg: disable EFI_DEBUG_CODE reporting in RELEASE builds

 MdeModulePkg/MdeModulePkg.dec |   9 +
 MdeModulePkg/MdeModulePkg.uni |   7 +
 OvmfPkg/OvmfPkgIa32.dsc   |   7 +
 OvmfPkg/OvmfPkgIa32X64.dsc|   7 +
 OvmfPkg/OvmfPkgX64.dsc|   7 +
 MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf|   2 +
 OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |   4 +
 MdeModulePkg/Include/Guid/StatusCodeDataTypeOsLoaderDetail.h  | 109 +++
 MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h  |  84 ++
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h  |  15 +
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c  |  51 +++-
 MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c  | 166 
+++
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c  |  60 +++-
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c  |   8 +
 OvmfPkg/Library/PlatformBootManagerLib/StatusCodeHandler.c| 298 

 15 files changed, 828 insertions(+), 6 deletions(-)
 create mode 100644 MdeModulePkg/Include/Guid/StatusCodeDataTypeOsLoaderDetail.h
 create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/StatusCodeHandler.c

-- 
2.14.1.3.gb7cf6e02401b

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 2/5] MdeModulePkg: introduce the EDKII_OS_LOADER_DETAIL status code payload

[Laszlo Ersek]

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 information is reported via DEBUG messages and progress/status
codes.

Individual platforms can customize how they handle the status codes
reported. However, the codes currently reported about LoadImage() and
StartImage() invocations are simple constants. Even if a platform displays
them on some end-user accessible device -- because end-users are generally
clueless of debug log capturing --, the information contained is
insufficient for even rudimentary bug reporting.

Introduce:

- a new, common debug code that is similar to:

  - PcdProgressCodeOsLoaderLoad (LoadImage() preparation),
  - EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR (LoadImage() error),
  - PcdProgressCodeOsLoaderStart(StartImage() preparation),
  - EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED (StartImage() error),

  under which more details will be possible to convey about the same set
  of events;

- a new status code payload structure (somewhat similar to
  EDKII_SET_VARIABLE_STATUS from
  "Include/Guid/StatusCodeDataTypeVariable.h"), for defining the wire
  format of said details.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Ruiyu Ni 
Cc: Eric Dong 
Cc: Star Zeng 
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---
 MdeModulePkg/MdeModulePkg.dec|   9 ++
 MdeModulePkg/MdeModulePkg.uni|   7 ++
 MdeModulePkg/Include/Guid/StatusCodeDataTypeOsLoaderDetail.h | 109 

 3 files changed, 125 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 856d67aceb21..6ba95dedc20d 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -383,24 +383,27 @@ [Guids]
   gEdkiiNonDiscoverableAmbaDeviceGuid = { 0x94440339, 0xCC93, 0x4506, {0xB4, 
0xC6, 0xEE, 0x8D, 0x0F, 0x4C, 0xA1, 0x91 } }
   gEdkiiNonDiscoverableEhciDeviceGuid = { 0xEAEE5615, 0x0CFD, 0x45FC, {0x87, 
0x69, 0xA0, 0xD8, 0x56, 0x95, 0xAF, 0x85 } }
   gEdkiiNonDiscoverableNvmeDeviceGuid = { 0xC5F25542, 0x2A79, 0x4A26, {0x81, 
0xBB, 0x4E, 0xA6, 0x32, 0x33, 0xB3, 0x09 } }
   gEdkiiNonDiscoverableOhciDeviceGuid = { 0xB20005B0, 0xBB2D, 0x496F, {0x86, 
0x9C, 0x23, 0x0B, 0x44, 0x79, 0xE7, 0xD1 } }
   gEdkiiNonDiscoverableSdhciDeviceGuid = { 0x1DD1D619, 0xF9B8, 0x463E, {0x86, 
0x81, 0xD1, 0xDC, 0x7C, 0x07, 0xB7, 0x2C } }
   gEdkiiNonDiscoverableUfsDeviceGuid = { 0x2EA77912, 0x80A8, 0x4947, {0xBE, 
0x69, 0xCD, 0xD0, 0x0A, 0xFB, 0xE5, 0x56 } }
   gEdkiiNonDiscoverableUhciDeviceGuid = { 0xA8CDA0A2, 0x4F37, 0x4A1B, {0x8E, 
0x10, 0x8E, 0xF3, 0xCC, 0x3B, 0xF3, 0xA8 } }
   gEdkiiNonDiscoverableXhciDeviceGuid = { 0xB1BE0BC5, 0x6C28, 0x442D, {0xAA, 
0x37, 0x15, 0x1B, 0x42, 0x57, 0xBD, 0x78 } }
 
   ## Include/Guid/PlatformHasAcpi.h
   gEdkiiPlatformHasAcpiGuid = { 0xf0966b41, 0xc23f, 0x41b9, { 0x96, 0x04, 
0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } }
 
+  ## Include/Guid/StatusCodeDataTypeOsLoaderDetail.h
+  gEdkiiStatusCodeDataTypeOsLoaderDetailGuid = { 0xBE4904DC, 0x7EC4, 0x4167, { 
0x90, 0x52, 0x38, 0x4D, 0x0B, 0x81, 0x30, 0x0B } }
+
 [Ppis]
   ## Include/Ppi/AtaController.h
   gPeiAtaControllerPpiGuid   = { 0xa45e60d1, 0xc719, 0x44aa, { 0xb0, 0x7a, 
0xaa, 0x77, 0x7f, 0x85, 0x90, 0x6d }}
 
   ## Include/Ppi/UsbHostController.h
   gPeiUsbHostControllerPpiGuid   = { 0x652B38A9, 0x77F4, 0x453F, { 0x89, 0xD5, 
0xE7, 0xBD, 0xC3, 0x52, 0xFC, 0x53 }}
 
   ## Include/Ppi/Usb2HostController.h
   gPeiUsb2HostControllerPpiGuid  = { 0xfedd6305, 0xe2d7, 0x4ed5, { 0x9f, 0xaa, 
0xda, 0x8, 0xe, 0x33, 0x6c, 0x22   }}
 
   ## Include/Ppi/UsbController.h
   gPeiUsbControllerPpiGuid   = { 0x3BC1F6DE, 0x693E, 0x4547, { 0xA3, 0x00, 
0x21, 0x82, 0x3C, 0xA4, 0x20, 0xB2 }}
@@ -846,24 +849,30 @@ [PcdsFixedAtBuild]
   ## Progress Code for OS Loader LoadImage start.
   #  PROGRESS_CODE_OS_LOADER_LOAD   = (EFI_SOFTWARE_DXE_BS_DRIVER | 
(EFI_OEM_SPECIFIC | 0x)) = 0x03058000
   # @Prompt Progress Code for OS Loader LoadImage start.
   # @ValidList  0x8003 | 0x03058000
   
gEfiMdeModulePkgTokenSpaceGuid.PcdProgressCodeOsLoaderLoad|0x03058000|UINT32|0x30001030
 
   ## Progress Code for OS Loader StartImage start.
   #  PROGRESS_CODE_OS_LOADER_START  = (EFI_SOFTWARE_DXE_BS_DRIVER | 
(EFI_OEM_SPECIFIC | 0x0001)) = 0x03058001
   # @Prompt Progress Code for OS Loader StartImage start.
   # @ValidList  0x8003 | 0x03058001
   
gEfiMdeModulePkgTokenSpaceGuid.PcdProgressCodeOsLoaderStart|0x03058001|UINT32|0x30001031
 
+  ## Debug Code for OS Loader 

Re: [edk2] EDK2 build issues

[Desimone, Nathaniel L]

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] EDK2 build issues

Nate:
  OK. Please submit the tracker on ARCH request. 

Thanks
Liming
> -Original Message-
> From: Desimone, Nathaniel L
> Sent: Friday, November 17, 2017 5:38 AM
> To: Gao, Liming ; Aaron Durbin 
> 
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] EDK2 build issues
> 
> 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:
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=786
> 
> For the ARCH environment variable, we brainstormed two possible new 
> names HOST_ARCH or BASETOOLS_ARCH. Should I file the ARCH variable request in 
> Bugzilla as well?
> 
> Thanks,
> 
> Nate
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Gao, Liming
> Sent: Monday, November 13, 2017 5:46 PM
> To: Aaron Durbin 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] EDK2 build issues
> 
> I add my comments.
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Aaron Durbin
> > Sent: Tuesday, November 14, 2017 1:38 AM
> > To: Gao, Liming 
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] EDK2 build issues
> >
> > On Sun, Nov 12, 2017 at 7:15 PM, Gao, Liming  wrote:
> > > Yes. BaseTools needs some environments. Before build BaseTools, we need 
> > > to call edkset.sh to setup them.
> > >
> > > 1. BaseTools Soure tools are compiled in serial instead of parallel.
> > > And, VfrCompiler depends on Anltr tool. So, Anltr is required to 
> > > be
> > built first. I agree that this way takes some time to compile 
> > BaseTools source. I have one proposal to compile C source tools with 
> > multiple thread. I can share my draft patch.
> >
> > If the depedencies are correctly met in the makefiles then why are 
> > they built serially? It sounds like you understand the dependencies 
> > so why aren't those explicitly noted so one can build in parallel?
> >
> Seemly, VfrCompiler Makefile doesn't list those dependency clearly. 
> Could you submit this issue in bugzillar (https://bugzilla.tianocore.org/)?
> Besides, do you use make -j option to enable Parallel Execution? I want to 
> know how to verify it.
> 
> > > 2. BaseTools C source are compiled to the executable files. They 
> > > run in host machine. Here ARCH is for the executable files those 
> > > can
> > run in host machine. edk2\BaseTools\Source\C\GNUmakefile auto detects ARCH 
> > based on 'uname -m' command.
> >
> > ARCH != host is my point. Why are those being conflated? Or are you 
> > saying edk2 tools define ARCH to be what the host is?
> >
> Yes. Edk2 BaseTools C source uses it as host arch. I agree ARCH name 
> is too generic. In your environment, ARCH may be defined for the different 
> purpose.
> 
> > > 3. There are more GCC compiler distribution. We try to use the 
> > > generic options in GCC tool chain. If you find the option doesn't 
> > > work
> > on your GCC compiler, please report it. And, we also notice 
> > tools_def.txt is too big to be hard to be maintain. We have one proposal to 
> > simplify it. I will send this RFC to edk2 community.
> > >
> > >>-Original Message-
> > >>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On 
> > >>Behalf Of Aaron Durbin
> > >>Sent: Saturday, November 11, 2017 6:27 AM
> > >>To: edk2-devel@lists.01.org
> > >>Subject: [edk2] EDK2 build issues
> > >>
> > >>Hello,
> > >>
> > >>Here are some observations I've encountered trying to utilize edk2 
> > >>for certain builds. Part of the problem seems to be with implicit 
> > >>assumptions in how edk2 is used. I'm trying to build things using
> > >>edk2 from a clean enviroment on an automated builder. i.e. there 
> > >>isn't a workspace that exists on one persons computer for the 
> > >>lifetime of development.
> > >>
> > >>1. BaseTools can't build in parallel. The tests are racey which 
> > >>result in test failures. Because of this one has to build these in 
> > >>serial instead of in parallel.
> > >>
> > >>===
> > >>===
> > >>FAIL: testHelp (TianoCompress.Tests)
> > >>--
> > >>--
> > >>--
> > >>Traceback (most recent call last):
> > >>  File
> > >>"/build/zoombini/tmp/portage/sys-boot/fsp-cnl-/work/fsp-cnl-
> > >>/Edk2/BaseTools/Tests/TianoCompress.py",
> > >>line 34, in testHelp
> > >>self.assertTrue(result == 0)
> > >>AssertionError: False is not true
> > >>
> > 

Re: [edk2] [RFC] ACPI table HID/CID allocation

[Daniel Thompson]

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 + compatible, for things like
I2C
slaves that are external to the SoC



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 because I don't understand why there
is no HID available.



PRP0001 + compatible was invented to avoid the need to allocate a _HID
for each and every component in existence that can already be
identified by a DT compatible string (and little else except, e.g., a
I2C slave address) and is not deeply engrained in the SoC in terms of
clock tree, power states etc. So while internal/external may not be
the most accurate distinction, it is still a useful one IMHO.


Hmnnn it sounds like jedec,spi-nor meets this test.

There is only one property in the DT bindings that describes the device 
itself (fast read support) rather than its "bus address" (chip select, 
frequency). Further, that single property is obsolete, at least for 
Linux; the kernel driver now contains a quirks tables to look up by 
device ID whether fast read is supported and will use that on non-DT 
systems (and also to censor broken DT systems ;-) ).



Daniel.

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] ACPI table HID/CID allocation

[Ard Biesheuvel]

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
>>> I2C
>>> slaves that are external to the SoC
>>
>>
>> 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 because I don't understand why there
> is no HID available.
>

PRP0001 + compatible was invented to avoid the need to allocate a _HID
for each and every component in existence that can already be
identified by a DT compatible string (and little else except, e.g., a
I2C slave address) and is not deeply engrained in the SoC in terms of
clock tree, power states etc. So while internal/external may not be
the most accurate distinction, it is still a useful one IMHO.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] ACPI table HID/CID allocation

[Andrew Fish]

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
 
.
 Anyone can make a request. 

PNP ID Registry: http://www.uefi.org/pnp_id_list 

ACPI ID Registry: http://www.uefi.org/acpi_id_list 


Thanks,

Andrew Fish

> On Nov 22, 2017, at 5:39 AM, Udit Kumar  wrote:
> 
> 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 because I don't understand why there is no HID
>> available.
> 
> This is more a choice/rule between allocating HID or using PRP0001.
> HID could be assigned to external devices, and getting them reviewed 
> by maintainers. 
> 
>> Large OEMs and board manufacturers usually have their own vendor IDs and
>> sometimes have to use these to describe hardware (IIRC the SMC LAN9xxx on
>> the ARM Juno uses an ARM HID).
> 
> Thanks,  for this example. 
> This is good example for me, where HID allocation is not limited to Vendor 
> devices.
> 
> 
>> Admittedly the part you are describing follows a JEDEC standard so it would 
>> be
>> nice to have more widely agreed bindings... however making SPI NOR FLASH
>> available as raw MTD device to the OS is sufficiently unusual in ACPI systems
>> that there may not be any prior art to follow.
> 
> Please take this as an example. ( Main point was to use HID or PRP0001)
> Could be possible, if such device is exposed then this may not be used at all.
> Thanks for help. 
> 
> Thanks
> Udit 
> 
>> 
>> Daniel.
>> 
>> 
>>> 
>>> As you pointed out, are external devices to SOC such exception to use
>>> PRP0001 + compatible be it i2c slave or SPI slave ?
>>> 
>>> 
>>> Regards
>>> Udit
>>> 
 -Original Message-
 From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
 Sent: Tuesday, November 21, 2017 7:34 PM
 To: Udit Kumar 
 Cc: Leif Lindholm ;
 edk2-devel@lists.01.org; Varun Sethi ; Daniel
 Thompson ; Graeme Gregory
 
 Subject: Re: [RFC] ACPI table HID/CID allocation
 
 On 21 November 2017 at 13:24, Udit Kumar  wrote:
> Thanks Ard,
> 
> My intend of this email to know, what is right way to define HID and
> CID in ACPI firmware i.e
> 
> Device(XYZ) {
> Name(_HID, "NXP0001")
> Name(_CID, "PRP0001")
>   Device(Slave1) {
> Name(_CID, "PRP0001")
>  }
> }
> is ok or
> 
> 
> Device(XYZ) {
> Name(_HID, "NXP0001")
> Name(_CID, " NXP0001")
>   Device(Slave1) {
> Name(_CID, " NXP0002")
>  }
> }
> Seems good
> 
 
 I don't think it makes a lot of sense to use the same value for _HID
 and _CID, so you can just drop the latter.
>>> 
>>> Sure,
>>> 
> For sure, AML methods (as needed _ON/OFF/RST/STA etc) /_DSD will to
> be
 coded in table using either of.
> 
> Please see more in line
> 
> Regards
> Udit
> 
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Tuesday, November 21, 2017 5:59 PM
>> To: Udit Kumar 
>> Cc: Leif Lindholm ;
>> edk2-devel@lists.01.org; Varun Sethi ; Daniel
>> Thompson ; Graeme Gregory
>> 
>> Subject: Re: [RFC] ACPI table HID/CID allocation
>> 
>> On 21 November 2017 at 11:32, Udit Kumar 
>> wrote:
>>> 
 On 21 November 2017 at 09:59, Udit Kumar 
 wrote:
> Thanks Ard.
> Below table was for example. I am not converting whole DT to
> ACPI tables :) My idea is to reduce Linux patches for probing as
>> possible.
> Also keeping firmware and OS separately then Let firmware expose
> both way (HID and PRP1) and Linux to decide binding
 
 No.
 
 You are still assuming ACPI and DT device drivers bind at the
 same level, and they don't.
>>> 
>>> No, my above comments was just limited to binding.
>> 
>> Yes, but if you leave it to the OS to decide which binding it uses,
>> you will have to support all of them into eternity. And the more

Re: [edk2] [PATCH v2 10/14] ArmVirtPkg/ArmVirtXen: add ArmVirtMemInfoLib implementation

[Julien Grall]

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 ArmVirtMemInfoLib implementation.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Cc: Julien Grall 


I have tested the series on both Arm32 and Arm64 guests:

Tested-by: Julien Grall 

[...]


+VOID
+EFIAPI
+ArmVirtGetMemoryMap (
+  OUT ARM_MEMORY_REGION_DESCRIPTOR   **VirtualMemoryMap
+  )
+{
+  ASSERT (VirtualMemoryMap != NULL);
+
+  //
+  // Map the entire physical memory space as cached. The only device
+  // we care about is the GIC, which will be stage 2 mapped as a device
+  // by the hypervisor, overriding the cached mapping we install here.
+  //


I was about to complain about the fact you rely on the hypervisor 
setting correct stage-2 memory attribute. But I see this is a copy of 
the current code :).


We did relax the attribute for MMIO in the case of the Hardware Domain. 
I will keep the UEFI implementation in mind if we ever decide to relax 
for guests too.




+  mVirtualMemoryTable[0].PhysicalBase = 0x0;
+  mVirtualMemoryTable[0].VirtualBase  = 0x0;
+  mVirtualMemoryTable[0].Length   = ArmGetPhysAddrTop ();
+  mVirtualMemoryTable[0].Attributes   = ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
+
+  mVirtualMemoryTable[1].PhysicalBase = 0x0;
+  mVirtualMemoryTable[1].VirtualBase  = 0x0;
+  mVirtualMemoryTable[1].Length   = 0x0;
+  mVirtualMemoryTable[1].Attributes   = 0x0;
+
+  *VirtualMemoryMap = mVirtualMemoryTable;
+}


Cheers,

--
Julien Grall
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 0/4] Add VS2017 tool chain for evaluation

[Pete Batard]

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 to build source code with Visual Studio 2017 on 32bit or
64bit Windows OS. After this tool chain is evaluated, ASL, ARM and ARM64
support can be provided.
And, to avoid more duplicated informations be introduced, the proposal to
simplify tools_def.template will be provided.


Liming Gao (4):
  MdePkg: Disable VS warning 4701 & 4703 for VS2017
  BaseTools: Add VS2017 tool chain in BaseTools tools_def.template
  BaseTools: Update VS batch file to auto detect VS2017
  Nt32Pkg: Add VS2017 support in SecMain

 BaseTools/Conf/tools_def.template   | 126 
 BaseTools/get_vsvars.bat|   8 ++
 BaseTools/set_vsprefix_envs.bat |  33 -
 MdePkg/Include/Ia32/ProcessorBind.h |   4 +-
 MdePkg/Include/X64/ProcessorBind.h  |   4 +-
 Nt32Pkg/Sec/SecMain.inf |   2 +
 6 files changed, 172 insertions(+), 5 deletions(-)

-- 
2.9.3.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 4/4] Nt32Pkg: Add VS2017 support in SecMain

[Pete Batard]

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 f2e1520b6dac..51f844c8526b 100644
--- a/Nt32Pkg/Sec/SecMain.inf
+++ b/Nt32Pkg/Sec/SecMain.inf
@@ -71,6 +71,7 @@ [BuildOptions]
   MSFT:*_*_IA32_DLINK_FLAGS == /out:"$(BIN_DIR)\SecMain.exe" /base:0x1000 
/pdb:"$(BIN_DIR)\SecMain.pdb" /LIBPATH:"$(VCINSTALLDIR)\Lib" 
/LIBPATH:"$(VCINSTALLDIR)\PlatformSdk\Lib" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86" /NOLOGO 
/SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG 
/MACHINE:I386 /LTCG Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib 
Advapi32.lib
   MSFT:*_VS2015_IA32_DLINK_FLAGS == /out:"$(BIN_DIR)\SecMain.exe" 
/base:0x1000 /pdb:"$(BIN_DIR)\SecMain.pdb" /LIBPATH:"$(VCINSTALLDIR)\Lib" 
/LIBPATH:"$(VCINSTALLDIR)\PlatformSdk\Lib" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86" /NOLOGO 
/SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG 
/MACHINE:I386 /LTCG Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib 
User32.lib Winmm.lib Advapi32.lib
   MSFT:*_VS2015x86_IA32_DLINK_FLAGS == /out:"$(BIN_DIR)\SecMain.exe" 
/base:0x1000 /pdb:"$(BIN_DIR)\SecMain.pdb" /LIBPATH:"$(VCINSTALLDIR)\Lib" 
/LIBPATH:"$(VCINSTALLDIR)\PlatformSdk\Lib" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86" /NOLOGO 
/SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG 
/MACHINE:I386 /LTCG Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib 
User32.lib Winmm.lib Advapi32.lib
+  MSFT:*_VS2017_IA32_DLINK_FLAGS == /out:"$(BIN_DIR)\SecMain.exe" 
/base:0x1000 /pdb:"$(BIN_DIR)\SecMain.pdb" 
/LIBPATH:"%VCToolsInstallDir%lib\x86" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86" /NOLOGO 
/SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG 
/MACHINE:I386 /LTCG Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib 
User32.lib Winmm.lib Advapi32.lib
   MSFT:*_*_IA32_CC_FLAGS == /nologo /W4 /WX /Gy /c /D UNICODE /Od /FIAutoGen.h 
/EHs-c- /GF /Gs8192 /Zi /Gm /D _CRT_SECURE_NO_WARNINGS /D 
_CRT_SECURE_NO_DEPRECATE
   MSFT:*_*_IA32_PP_FLAGS == /nologo /E /TC /FIAutoGen.h
   MSFT:*_*_IA32_ASM_FLAGS == /nologo /W3 /WX /c /coff /Cx /Zd /W0 /Zi
@@ -79,6 +80,7 @@ [BuildOptions]
   MSFT:*_*_X64_DLINK_FLAGS == /out:"$(BIN_DIR)\SecMain.exe" /base:0x1000 
/pdb:"$(BIN_DIR)\SecMain.pdb" /LIBPATH:"$(VCINSTALLDIR)\Lib\AMD64" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64" /NOLOGO 
/SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG 
/MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib 
Advapi32.lib
   MSFT:*_VS2015_X64_DLINK_FLAGS == /out:"$(BIN_DIR)\SecMain.exe" 
/base:0x1000 /pdb:"$(BIN_DIR)\SecMain.pdb" 
/LIBPATH:"$(VCINSTALLDIR)\Lib\AMD64" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64" /NOLOGO 
/SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG 
/MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib 
Gdi32.lib User32.lib Winmm.lib Advapi32.lib
   MSFT:*_VS2015x86_X64_DLINK_FLAGS == /out:"$(BIN_DIR)\SecMain.exe" 
/base:0x1000 /pdb:"$(BIN_DIR)\SecMain.pdb" 
/LIBPATH:"$(VCINSTALLDIR)\Lib\AMD64" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64" /NOLOGO 
/SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG 
/MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib 
Gdi32.lib User32.lib Winmm.lib Advapi32.lib
+  MSFT:*_VS2017_X64_DLINK_FLAGS == /out:"$(BIN_DIR)\SecMain.exe" 
/base:0x1000 /pdb:"$(BIN_DIR)\SecMain.pdb" 
/LIBPATH:"%VCToolsInstallDir%lib\x64" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64" /NOLOGO 
/SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG 
/MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib 
Gdi32.lib User32.lib Winmm.lib Advapi32.lib
   MSFT:*_*_X64_CC_FLAGS == /nologo /W4 /WX /Gy /c /D UNICODE /Od /FIAutoGen.h 
/EHs-c- /GF /Gs8192 /Zi /Gm /D _CRT_SECURE_NO_WARNINGS /D 
_CRT_SECURE_NO_DEPRECATE
   MSFT:*_*_X64_PP_FLAGS == /nologo /E /TC /FIAutoGen.h
   MSFT:*_*_X64_ASM_FLAGS == /nologo /W3 /WX /c /Cx /Zd /W0 /Zi
-- 
2.9.3.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 2/4] BaseTools: Add VS2017 tool chain in BaseTools tools_def.template

[Pete Batard]

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 
---
 BaseTools/Conf/tools_def.template | 126 
 1 file changed, 126 insertions(+)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index aebd7d558633..5526c5bda761 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -74,6 +74,12 @@ DEFINE VS2015x86_BIN= ENV(VS2015_PREFIX)Vc\bin
 DEFINE VS2015x86_DLL= ENV(VS2015_PREFIX)Common7\IDE;DEF(VS2015x86_BIN)
 DEFINE VS2015x86_BINX64 = DEF(VS2015x86_BIN)\x86_amd64
 
+DEFINE VS2017_BIN = ENV(VS2017_PREFIX)bin
+DEFINE VS2017_HOST= x86
+DEFINE VS2017_BIN_HOST= 
DEF(VS2017_BIN)\HostDEF(VS2017_HOST)\DEF(VS2017_HOST)
+DEFINE VS2017_BIN_IA32= DEF(VS2017_BIN)\HostDEF(VS2017_HOST)\x86
+DEFINE VS2017_BIN_X64 = DEF(VS2017_BIN)\HostDEF(VS2017_HOST)\x64
+
 DEFINE WINSDK_BIN   = ENV(WINSDK_PREFIX)
 DEFINE WINSDKx86_BIN= ENV(WINSDKx86_PREFIX)
 
@@ -93,6 +99,9 @@ DEFINE WINSDK8x86_BIN= ENV(WINSDK8x86_PREFIX)x64
 DEFINE WINSDK81_BIN   = ENV(WINSDK81_PREFIX)x86\
 DEFINE WINSDK81x86_BIN= ENV(WINSDK81x86_PREFIX)x64
 
+# Microsoft Visual Studio 2017 Professional Edition
+DEFINE WINSDK10_BIN   = ENV(WINSDK10_PREFIX)DEF(VS2017_HOST)
+
 # These defines are needed for certain Microsoft Visual Studio tools that
 # are used by other toolchains.  An example is that ICC on Windows normally
 # uses Microsoft's nmake.exe.
@@ -318,6 +327,14 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 # Required to build platforms or ACPI tables:
 #   Intel(r) ACPI Compiler (iasl.exe) from
 #   https://acpica.org/downloads
+#   VS2017  -win32-  Requires:
+# Microsoft Visual Studio 2017 version 15.2 or 
later
+#Optional:
+# Required to build EBC drivers:
+#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
+# Required to build platforms or ACPI tables:
+#   Intel(r) ACPI Compiler (iasl.exe) from
+#   https://acpica.org/downloads
 #   DDK3790 -win32-  Requires:
 # Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
 #Optional:
@@ -4062,6 +4079,115 @@ NOOPT_VS2015x86xASL_X64_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT
 
 
 

+#   VS2017   - Microsoft Visual Studio 2017 with Intel ASL
+#   ASL  - Intel ACPI Source Language Compiler (iasl.exe)
+
+#   VS2017   - Microsoft Visual Studio 2017 professional Edition with 
Intel ASL
+*_VS2017_*_*_FAMILY= MSFT
+*_VS2017_*_*_DLL   = DEF(VS2017_BIN_HOST)
+
+*_VS2017_*_MAKE_PATH   = DEF(VS2017_BIN_HOST)\nmake.exe
+*_VS2017_*_MAKE_FLAG   = /nologo
+*_VS2017_*_RC_PATH = DEF(WINSDK10_BIN)\rc.exe
+
+*_VS2017_*_MAKE_FLAGS  = /nologo
+*_VS2017_*_SLINK_FLAGS = /NOLOGO /LTCG
+*_VS2017_*_APP_FLAGS   = /nologo /E /TC
+*_VS2017_*_PP_FLAGS= /nologo /E /TC /FIAutoGen.h
+*_VS2017_*_VFRPP_FLAGS = /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h
+*_VS2017_*_DLINK2_FLAGS= /WHOLEARCHIVE
+*_VS2017_*_ASM16_PATH  = DEF(VS2017_BIN_IA32)\ml.exe
+
+##
+# ASL definitions
+##
+*_VS2017_*_ASL_PATH= DEF(WIN_IASL_BIN)
+*_VS2017_*_ASL_FLAGS   = DEF(DEFAULT_WIN_ASL_FLAGS)
+*_VS2017_*_ASL_OUTFLAGS= DEF(DEFAULT_WIN_ASL_OUTFLAGS)
+*_VS2017_*_ASLCC_FLAGS = DEF(MSFT_ASLCC_FLAGS)
+*_VS2017_*_ASLPP_FLAGS = DEF(MSFT_ASLPP_FLAGS)
+*_VS2017_*_ASLDLINK_FLAGS  = DEF(MSFT_ASLDLINK_FLAGS)
+
+##
+# IA32 definitions
+##
+*_VS2017_IA32_CC_PATH  = DEF(VS2017_BIN_IA32)\cl.exe
+*_VS2017_IA32_VFRPP_PATH   = DEF(VS2017_BIN_IA32)\cl.exe
+*_VS2017_IA32_ASLCC_PATH   = DEF(VS2017_BIN_IA32)\cl.exe
+*_VS2017_IA32_ASLPP_PATH   = DEF(VS2017_BIN_IA32)\cl.exe
+*_VS2017_IA32_SLINK_PATH   = DEF(VS2017_BIN_IA32)\lib.exe
+*_VS2017_IA32_DLINK_PATH   = DEF(VS2017_BIN_IA32)\link.exe
+*_VS2017_IA32_ASLDLINK_PATH= DEF(VS2017_BIN_IA32)\link.exe
+*_VS2017_IA32_APP_PATH = DEF(VS2017_BIN_IA32)\cl.exe
+*_VS2017_IA32_PP_PATH  = DEF(VS2017_BIN_IA32)\cl.exe
+*_VS2017_IA32_ASM_PATH = DEF(VS2017_BIN_IA32)\ml.exe
+
+  *_VS2017_IA32_MAKE_FLAGS  = /nologo
+  DEBUG_VS2017_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 /Gs32768 
/D UNICODE /O1b2 /GL 

[edk2] [PATCH v3 3/4] BaseTools: Update VS batch file to auto detect VS2017

[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 Batard 
---
 BaseTools/get_vsvars.bat|  8 +
 BaseTools/set_vsprefix_envs.bat | 33 +++-
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/BaseTools/get_vsvars.bat b/BaseTools/get_vsvars.bat
index 7649e1dccf47..ba3e54d588cf 100644
--- a/BaseTools/get_vsvars.bat
+++ b/BaseTools/get_vsvars.bat
@@ -16,6 +16,12 @@
 @echo off
 goto  :main
 
+:set_vsvars
+for /f "usebackq tokens=1* delims=: " %%i in (`%*`) do (
+  if /i "%%i"=="installationPath" call "%%j\VC\Auxiliary\Build\vcvars32.bat"
+)
+goto :EOF
+
 :read_vsvars
 @rem Do nothing if already found, otherwise call vsvars32.bat if there
 if defined VCINSTALLDIR goto :EOF
@@ -33,6 +39,8 @@ REM   (Or invoke the relevant vsvars32 file beforehand).
 
 :main
 if defined VCINSTALLDIR goto :done
+  if exist "%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" 
 call :set_vsvars "%ProgramFiles(x86)%\Microsoft Visual 
Studio\Installer\vswhere.exe"
+  if exist "%ProgramFiles%\Microsoft Visual Studio\Installer\vswhere.exe"  
 call :set_vsvars "%ProgramFiles%\Microsoft Visual Studio\Installer\vswhere.exe"
   if defined VS140COMNTOOLS  call :read_vsvars  "%VS140COMNTOOLS%"
   if defined VS120COMNTOOLS  call :read_vsvars  "%VS120COMNTOOLS%"
   if defined VS110COMNTOOLS  call :read_vsvars  "%VS110COMNTOOLS%"
diff --git a/BaseTools/set_vsprefix_envs.bat b/BaseTools/set_vsprefix_envs.bat
index b05b1d222083..ed83222a24c8 100644
--- a/BaseTools/set_vsprefix_envs.bat
+++ b/BaseTools/set_vsprefix_envs.bat
@@ -3,7 +3,7 @@
 @REM   however it may be executed directly from the BaseTools project folder
 @REM   if the file is not executed within a WORKSPACE\BaseTools folder.
 @REM
-@REM Copyright (c) 2016, Intel Corporation. All rights reserved.
+@REM Copyright (c) 2016-2017, Intel Corporation. All rights reserved.
 @REM
 @REM This program and the accompanying materials are licensed and made 
available
 @REM under the terms and conditions of the BSD License which accompanies this
@@ -90,6 +90,37 @@ if defined VS140COMNTOOLS (
   )
 )
 
+@REM set VS2017
+if not defined VS150COMNTOOLS (
+  if exist "%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" 
(
+for /f "usebackq tokens=1* delims=: " %%i in 
(`"%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe"`) do (
+  if /i "%%i"=="installationPath" call 
"%%j\VC\Auxiliary\Build\vcvars32.bat"
+)
+  ) else if exist "%ProgramFiles%\Microsoft Visual 
Studio\Installer\vswhere.exe" (
+for /f "usebackq tokens=1* delims=: " %%i in (`"%ProgramFiles%\Microsoft 
Visual Studio\Installer\vswhere.exe"`) do (
+  if /i "%%i"=="installationPath" call 
"%%j\VC\Auxiliary\Build\vcvars32.bat"
+)
+  ) else (
+goto SetWinDDK
+  )
+)
+
+if defined VCToolsInstallDir (
+  if not defined VS2017_PREFIX (
+set "VS2017_PREFIX=%VCToolsInstallDir%"
+  )
+)
+if not defined WINSDK10_PREFIX (
+  if defined WindowsSdkVerBinPath (
+set "WINSDK10_PREFIX=%WindowsSdkVerBinPath%"
+  ) else if exist "%ProgramFiles(x86)%\Windows Kits\10\bin" (
+set "WINSDK10_PREFIX=%ProgramFiles(x86)%\Windows Kits\10\bin\"
+  ) else if exist "%ProgramFiles%\Windows Kits\10\bin" (
+set "WINSDK10_PREFIX=%ProgramFiles%\Windows Kits\10\bin\"
+  )
+)
+
+:SetWinDDK
 if not defined WINDDK3790_PREFIX (
   set WINDDK3790_PREFIX=C:\WINDDK\3790.1830\bin\
 )
-- 
2.9.3.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 1/4] MdePkg: Disable VS warning 4701 & 4703 for VS2017

[Pete Batard]

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 --git a/MdePkg/Include/Ia32/ProcessorBind.h 
b/MdePkg/Include/Ia32/ProcessorBind.h
index 8ba2348261a2..aeecf3fa9feb 100644
--- a/MdePkg/Include/Ia32/ProcessorBind.h
+++ b/MdePkg/Include/Ia32/ProcessorBind.h
@@ -1,7 +1,7 @@
 /** @file
   Processor or Compiler specific defines and types for IA-32 architecture.
 
-Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials are licensed and made available 
under 
 the terms and conditions of the BSD License that accompanies this 
distribution.  
 The full text of the license may be found at
@@ -93,7 +93,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 //
 #pragma warning ( disable : 4206 )
 
-#if _MSC_VER == 1800 || _MSC_VER == 1900
+#if _MSC_VER == 1800 || _MSC_VER == 1900 || _MSC_VER >= 1910
 
 //
 // Disable these warnings for VS2013.
diff --git a/MdePkg/Include/X64/ProcessorBind.h 
b/MdePkg/Include/X64/ProcessorBind.h
index 72cc85151cba..e637d8649f57 100644
--- a/MdePkg/Include/X64/ProcessorBind.h
+++ b/MdePkg/Include/X64/ProcessorBind.h
@@ -1,7 +1,7 @@
 /** @file
   Processor or Compiler specific defines and types x64 (Intel 64, AMD64).
 
-  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
   This program and the accompanying materials  
   are licensed and made available under the terms and conditions of the BSD 
License 
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -107,7 +107,7 @@
 //
 #pragma warning ( disable : 4206 )
 
-#if _MSC_VER == 1800 || _MSC_VER == 1900
+#if _MSC_VER == 1800 || _MSC_VER == 1900 || _MSC_VER >= 1910
 
 //
 // Disable these warnings for VS2013.
-- 
2.9.3.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 2/4] BaseTools: Add VS2017 tool chain in BaseTools tools_def.template

[Gao, Liming]

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 [mailto:p...@akeo.ie]
> Sent: Tuesday, November 21, 2017 2:41 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: Re: [PATCH v2 2/4] BaseTools: Add VS2017 tool chain in BaseTools 
> tools_def.template
> 
> Hi Liming,
> 
> On 2017.11.20 08:46, Gao, Liming wrote:
> >Here, I suggest to mention VS version 15.2 or above, because vswhere.exe 
> > depends on this version.
> >After later, you may also update this version to 15.4 for ARM and 
> > AARCH64 support.
> 
> I assume you mean replacing the "Microsoft Visual Studio 2017
> Professional or Community Edition" from the comment with something like
> "Microsoft Visual Studio 2017 version 15.2 or later", right?
> 
> If so, I will do that and submit a v3.
> 
> Do you think the possibility of adding vswhere.exe to
> BaseTools\Bin\Win32 is also worth exploring? For one thing this would
> solve the issue of locating 15.2 VS 2017 (as well as nonstandard
> installations that may have removed the installer directory), and the
> executable is both Open Source (MIT) and redistributable.
> 
> The other possibility of course is to let pre 15.2 VS2017 fail the
> detection process, and expect users to get a hint that they need an
> updated version from the comments in tools_def...
> 
> Regards,
> 
> /Pete
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] ACPI table HID/CID allocation

[Udit Kumar]

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 because I don't understand why there is no HID
> available.

This is more a choice/rule between allocating HID or using PRP0001.
HID could be assigned to external devices, and getting them reviewed 
by maintainers. 

> Large OEMs and board manufacturers usually have their own vendor IDs and
> sometimes have to use these to describe hardware (IIRC the SMC LAN9xxx on
> the ARM Juno uses an ARM HID).

Thanks,  for this example. 
This is good example for me, where HID allocation is not limited to Vendor 
devices.

 
> Admittedly the part you are describing follows a JEDEC standard so it would be
> nice to have more widely agreed bindings... however making SPI NOR FLASH
> available as raw MTD device to the OS is sufficiently unusual in ACPI systems
> that there may not be any prior art to follow.

Please take this as an example. ( Main point was to use HID or PRP0001)
Could be possible, if such device is exposed then this may not be used at all.
Thanks for help. 

Thanks
Udit 

> 
> Daniel.
> 
> 
> >
> > As you pointed out, are external devices to SOC such exception to use
> > PRP0001 + compatible be it i2c slave or SPI slave ?
> >
> >
> > Regards
> > Udit
> >
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: Tuesday, November 21, 2017 7:34 PM
> >> To: Udit Kumar 
> >> Cc: Leif Lindholm ;
> >> edk2-devel@lists.01.org; Varun Sethi ; Daniel
> >> Thompson ; Graeme Gregory
> >> 
> >> Subject: Re: [RFC] ACPI table HID/CID allocation
> >>
> >> On 21 November 2017 at 13:24, Udit Kumar  wrote:
> >>> Thanks Ard,
> >>>
> >>> My intend of this email to know, what is right way to define HID and
> >>> CID in ACPI firmware i.e
> >>>
> >>> Device(XYZ) {
> >>>  Name(_HID, "NXP0001")
> >>>  Name(_CID, "PRP0001")
> >>>Device(Slave1) {
> >>>  Name(_CID, "PRP0001")
> >>>   }
> >>> }
> >>> is ok or
> >>>
> >>>
> >>> Device(XYZ) {
> >>>  Name(_HID, "NXP0001")
> >>>  Name(_CID, " NXP0001")
> >>>Device(Slave1) {
> >>>  Name(_CID, " NXP0002")
> >>>   }
> >>> }
> >>> Seems good
> >>>
> >>
> >> I don't think it makes a lot of sense to use the same value for _HID
> >> and _CID, so you can just drop the latter.
> >
> > Sure,
> >
> >>> For sure, AML methods (as needed _ON/OFF/RST/STA etc) /_DSD will to
> >>> be
> >> coded in table using either of.
> >>>
> >>> Please see more in line
> >>>
> >>> Regards
> >>> Udit
> >>>
>  -Original Message-
>  From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>  Sent: Tuesday, November 21, 2017 5:59 PM
>  To: Udit Kumar 
>  Cc: Leif Lindholm ;
>  edk2-devel@lists.01.org; Varun Sethi ; Daniel
>  Thompson ; Graeme Gregory
>  
>  Subject: Re: [RFC] ACPI table HID/CID allocation
> 
>  On 21 November 2017 at 11:32, Udit Kumar 
> wrote:
> >
> >> On 21 November 2017 at 09:59, Udit Kumar 
> >> wrote:
> >>> Thanks Ard.
> >>> Below table was for example. I am not converting whole DT to
> >>> ACPI tables :) My idea is to reduce Linux patches for probing as
> possible.
> >>> Also keeping firmware and OS separately then Let firmware expose
> >>> both way (HID and PRP1) and Linux to decide binding
> >>
> >> No.
> >>
> >> You are still assuming ACPI and DT device drivers bind at the
> >> same level, and they don't.
> >
> > No, my above comments was just limited to binding.
> 
>  Yes, but if you leave it to the OS to decide which binding it uses,
>  you will have to support all of them into eternity. And the more
>  detailed binding you need to support may limit you in the available
>  choices when it comes to making hardware changes, something ACPI
>  allows
> >> you to do.
> >>>
> >>> Thanks,
> >>> Is this ok to say , we can provide max same properties in driver as
> >>> of DT (with _DSD) , But prefer to use AML methods.
> >>> With note, clocking regulators are out of scope here.
> >>>
> >>
> >> Yes. _DSD may be used to describe device specific data that goes
> >> beyond what ACPI can express natively. Using _DSD to describe clocks
> >> and regulators is an absolute no-go. Putting things like "status" or
> >> "dma-coherent" in _DSD properties is absolutely 

Re: [edk2] [RFC] ACPI table HID/CID allocation

[Daniel Thompson]

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), 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 because I don't 
understand why there is no HID available.


Large OEMs and board manufacturers usually have their own vendor IDs and 
sometimes have to use these to describe hardware (IIRC the SMC LAN9xxx 
on the ARM Juno uses an ARM HID).


Admittedly the part you are describing follows a JEDEC standard so it 
would be nice to have more widely agreed bindings... however making SPI 
NOR FLASH available as raw MTD device to the OS is sufficiently unusual 
in ACPI systems that there may not be any prior art to follow.



Daniel.




As you pointed out, are external devices to SOC such exception to use PRP0001 + 
compatible be it
i2c slave or SPI slave ?


Regards
Udit


-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Tuesday, November 21, 2017 7:34 PM
To: Udit Kumar 
Cc: Leif Lindholm ; edk2-devel@lists.01.org; Varun
Sethi ; Daniel Thompson ;
Graeme Gregory 
Subject: Re: [RFC] ACPI table HID/CID allocation

On 21 November 2017 at 13:24, Udit Kumar  wrote:

Thanks Ard,

My intend of this email to know, what is right way to define HID and
CID in ACPI firmware i.e

Device(XYZ) {
 Name(_HID, "NXP0001")
 Name(_CID, "PRP0001")
   Device(Slave1) {
 Name(_CID, "PRP0001")
  }
}
is ok or


Device(XYZ) {
 Name(_HID, "NXP0001")
 Name(_CID, " NXP0001")
   Device(Slave1) {
 Name(_CID, " NXP0002")
  }
}
Seems good



I don't think it makes a lot of sense to use the same value for _HID and _CID, 
so
you can just drop the latter.


Sure,
  

For sure, AML methods (as needed _ON/OFF/RST/STA etc) /_DSD will to be

coded in table using either of.


Please see more in line

Regards
Udit


-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Tuesday, November 21, 2017 5:59 PM
To: Udit Kumar 
Cc: Leif Lindholm ;
edk2-devel@lists.01.org; Varun Sethi ; Daniel
Thompson ; Graeme Gregory

Subject: Re: [RFC] ACPI table HID/CID allocation

On 21 November 2017 at 11:32, Udit Kumar  wrote:



On 21 November 2017 at 09:59, Udit Kumar 

wrote:

Thanks Ard.
Below table was for example. I am not converting whole DT to
ACPI tables :) My idea is to reduce Linux patches for probing as possible.
Also keeping firmware and OS separately then Let firmware expose
both way (HID and PRP1) and Linux to decide binding


No.

You are still assuming ACPI and DT device drivers bind at the same
level, and they don't.


No, my above comments was just limited to binding.


Yes, but if you leave it to the OS to decide which binding it uses,
you will have to support all of them into eternity. And the more
detailed binding you need to support may limit you in the available
choices when it comes to making hardware changes, something ACPI allows

you to do.


Thanks,
Is this ok to say , we can provide max same properties in driver as of
DT (with _DSD) , But prefer to use AML methods.
With note, clocking regulators are out of scope here.



Yes. _DSD may be used to describe device specific data that goes beyond what
ACPI can express natively. Using _DSD to describe clocks and regulators is an
absolute no-go. Putting things like "status" or "dma-coherent" in _DSD
properties is absolutely unacceptable as well.
But even things like initialization data that the driver programs into the 
device a
single time really do not belong in _DSD. Instead, it should be the firmware 
that
initializes the device, and presents it to the OS in its initialized state.



Agreed, I never meant something to add in DSD which was prohibited in ACPI 
spces.




Right, here device driver should know that device is present in
system, I see probe function (device-driver binding) is way to know this.
Then driver can execute AML methods exposed by firmware.



Yes, declaring the presence of the device is the main purpose of
describing it both in ACPI and in DT.


An ACPI device has AML methods to manage power state and perform
other device related low-level tasks. The device driver has no
knowledge of the hardware beyond what it needs to invoke those

Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-DMA at ExitBootServices()

[Zeng, Star]

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: Ard Biesheuvel ; Dong, Eric 
; Zeng, Star ; Dann Frazier 

Subject: RE: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-DMA 
at ExitBootServices()

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

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Laszlo Ersek
> Sent: Saturday, October 28, 2017 12:10 AM
> To: edk2-devel-01 
> Cc: Ard Biesheuvel ; Dong, Eric 
> ; Zeng, Star ; Dann Frazier 
> 
> Subject: Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable 
> only BM-DMA at ExitBootServices()
> 
> On 10/26/17 17:48, Laszlo Ersek wrote:
> > Clearing I/O port decoding in the PCI command register at
> > ExitBootServices() breaks IDE boot in Windows, on QEMU's "pc" 
> > (i440fx) machine type. (AHCI boot on "q35" is unaffected.) Windows 
> > seems repeatedly stuck, apparently waiting for a timeout of sorts.
> >
> > This is arguably a Windows bug; a native OS driver should not expect 
> > the firmware to leave the PCI command register in any particular state.
> >
> > Strictly speaking, we only need to disable BM-DMA at 
> > ExitBootServices(), in order to abort pending transfers to/from RAM, 
> > which is soon to be owned by the OS. BM-DMA is also the only bit 
> > that's explicitly named by the UEFI Driver Writers' Guide, for 
> > clearing at
> ExitBootServices().
> >
> > I've verified that clearing only BM-DMA fixes the isse (boot time) 
> > on i440fx, and does not regress q35/AHCI.
> >
> > Cc: Aleksei Kovura 
> > Cc: Ard Biesheuvel 
> > Cc: Dann Frazier 
> > Cc: Eric Dong 
> > Cc: Star Zeng 
> > Reported-by: Aleksei Kovura 
> > Reported-by: Dann Frazier 
> > Reported-by: https://launchpad.net/~cjkrupp
> > Bisected-by: Dann Frazier 
> > Bisected-by: https://launchpad.net/~cjkrupp
> > Suggested-by: Ard Biesheuvel 
> > Suggested-by: Star Zeng 
> > Ref: https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1725560
> > Fixes: 6fb8ddd36bde45614b0a069528cdc97077835a74
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Laszlo Ersek 
> > ---
> >
> > Notes:
> > Repo:   https://github.com/lersek/edk2.git
> > Branch: ata_disable_only_bmdma
> >
> >  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h | 3 +-- 
> > MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c | 5 ++---
> >  2 files changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git 
> > a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
> > b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
> > index 8d6eac706c0b..92c5bf2001cd 100644
> > --- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
> > +++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
> > @@ -123,8 +123,7 @@ typedef struct {
> >LIST_ENTRYNonBlockingTaskList;
> >
> >//
> > -  // For disabling the device (especially Bus Master DMA) at
> > -  // ExitBootServices().
> > +  // For disabling Bus Master DMA on the device at ExitBootServices().
> >//
> >EFI_EVENT ExitBootEvent;
> >  } ATA_ATAPI_PASS_THRU_INSTANCE;
> > diff --git 
> > a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
> > b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
> > index 09064dda18b7..e10e0d4e65f6 100644
> > --- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
> > +++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
> > @@ -480,8 +480,7 @@ InitializeAtaAtapiPassThru (  }
> >
> >  /**
> > -  Disable the device (especially Bus Master DMA) when exiting the 
> > boot
> > -  services.
> > +  Disable Bus Master DMA on the device when exiting the boot services.
> >
> >@param[in] EventEvent for which this notification function is being
> >called.
> > @@ -506,7 +505,7 @@ AtaPassThruExitBootServices (
> >PciIo->Attributes (
> > PciIo,
> > EfiPciIoAttributeOperationDisable,
> > -   Instance->EnabledPciAttributes,
> > +   Instance->EnabledPciAttributes & 
> > + 

[edk2] [PATCH v2 14/14] ArmVirtPkg: remove ArmPlatformLib implementations

[Ard Biesheuvel]

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   
|   1 -
 ArmVirtPkg/ArmVirtXen.dsc  
|   1 -
 
ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/AARCH64/RelocatableVirtHelper.S
   | 141 -
 ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/ARM/RelocatableVirtHelper.S   
| 123 ---
 
ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/ArmQemuRelocatablePlatformLib.inf
 |  64 
 ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/FdtParser.c   
|  90 ---
 ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/QemuVirtMem.c 
| 106 -
 ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/RelocatableVirt.c 
|  70 -
 ArmVirtPkg/Library/ArmVirtPlatformLib/AARCH64/VirtHelper.S 
|  70 -
 ArmVirtPkg/Library/ArmVirtPlatformLib/ARM/VirtHelper.S 
|  57 ---
 ArmVirtPkg/Library/ArmVirtPlatformLib/ARM/VirtHelper.asm   
|  71 -
 ArmVirtPkg/Library/ArmVirtPlatformLib/ArmVirtPlatformLib.inf   
|  64 
 ArmVirtPkg/Library/ArmVirtPlatformLib/Virt.c   
| 160 
 ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c
| 102 -
 
ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/AARCH64/RelocatableVirtHelper.S 
   | 140 -
 ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/ARM/RelocatableVirtHelper.S
| 123 ---
 
ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/ArmXenRelocatablePlatformLib.inf
   |  63 
 ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/FdtParser.c
|  89 ---
 ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/RelocatableVirt.c  
|  70 -
 ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/XenVirtMem.c   
|  82 --
 20 files changed, 1687 deletions(-)

diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index f50d30388cf2..cc2c5a50c925 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -48,7 +48,6 @@ [LibraryClasses.common]
   QemuFwCfgLib|ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf
 
-  
ArmPlatformLib|ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/ArmQemuRelocatablePlatformLib.inf
   
ArmVirtMemInfoLib|ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
 
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index 3df684d13cb0..11e073287a84 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -43,7 +43,6 @@ [LibraryClasses]
   VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
   
VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
 
-  
ArmPlatformLib|ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/ArmXenRelocatablePlatformLib.inf
   ArmVirtMemInfoLib|ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
 
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
diff --git 
a/ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/AARCH64/RelocatableVirtHelper.S
 
b/ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/AARCH64/RelocatableVirtHelper.S
deleted file mode 100644
index ec6955cf0af8..
--- 
a/ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/AARCH64/RelocatableVirtHelper.S
+++ /dev/null
@@ -1,141 +0,0 @@
-#
-#  Copyright (c) 2011-2013, ARM Limited. All rights reserved.
-#  Copyright (c) 2016, Linaro Limited. All rights reserved.
-#
-#  This program and the accompanying materials
-#  are licensed and made available under the terms and conditions of the BSD 
License
-#  which accompanies this distribution.  The full text of the license may be 
found at
-#  http://opensource.org/licenses/bsd-license.php
-#
-#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
-#
-#
-
-#include 
-#include 
-
-// VOID
-// ArmPlatformPeiBootAction (
-//   VOID   *DeviceTreeBaseAddress,   // passed by loader in x0
-//   VOID   *ImageBase// passed by FDF trampoline in x1
-//   );
-ASM_FUNC(ArmPlatformPeiBootAction)
-  //
-  // If we are booting from RAM using the Linux kernel boot protocol, x0 will
-  // point to the DTB image in memory. Otherwise, use the default value defined
-  // by the platform.
-  //
-  cbnz  x0, 0f
-  ldr   x0, PcdGet64 (PcdDeviceTreeInitialBaseAddress)
-

[edk2] [PATCH v2 12/14] ArmVirtPkg: create QemuVirtMemInfoLib version for ArmVirtQemu

[Ard Biesheuvel]

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 called.

On ArmVirtQemu, we currently abuse the implied ordering guarantees
provided by ArmPlatformLib, by implementing this as follows:

  ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf [ArmVirtPkg/ArmVirtQemu.dsc]
InitializeMemory()
[ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c]
  ArmPlatformInitializeSystemMemory() 
[ArmVirtPkg/Library/ArmVirtPlatformLib/Virt.c]
//
// set PcdSystemMemorySize from the DT
//
  MemoryPeim()
[ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c]
InitMmu() 
[ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c]
  ArmPlatformGetVirtualMemoryMap()
[ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c]
//
// consume PcdSystemMemorySize
//

Given that we are trying to get rid of ArmPlatformLib, or at least remove
some of these API functions that are never used for their original purpose
by any platforms, we need to move the PCD assignment elsewhere.

So create a PEIM-only version of QemuVirtMemInfoLib especially for
ArmVirtQemu, and add the PCD assignment code to its constructor.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/ArmVirtQemu.dsc   |   3 
+
 ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf  |  58 
+++
 ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLibConstructor.c | 106 

 3 files changed, 167 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index d14a0dd0d1d9..519c2ae2e939 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -67,6 +67,9 @@ [LibraryClasses.common]
   HttpLib|MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.inf
 !endif
 
+[LibraryClasses.common.PEIM]
+  
ArmVirtMemInfoLib|ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
+
 [LibraryClasses.common.UEFI_DRIVER]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf 
b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
new file mode 100644
index ..e574a47443d0
--- /dev/null
+++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
@@ -0,0 +1,58 @@
+#/* @file
+#
+#  Copyright (c) 2011-2015, ARM Limited. All rights reserved.
+#  Copyright (c) 2014-2017, Linaro Limited. All rights reserved.
+#
+#  This program and the accompanying materials are licensed and made available
+#  under the terms and conditions of the BSD License which accompanies this
+#  distribution.  The full text of the license may be found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#*/
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = QemuVirtMemInfoLib
+  FILE_GUID  = 0c4d10cf-d949-49b4-bd13-47a4ae22efce
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = ArmVirtMemInfoLib|PEIM
+  CONSTRUCTOR= QemuVirtMemInfoPeiLibConstructor
+
+[Sources]
+  QemuVirtMemInfoLib.c
+  QemuVirtMemInfoPeiLibConstructor.c
+
+[Sources.ARM]
+  Arm/PhysAddrTop.S
+
+[Sources.AARCH64]
+  AArch64/PhysAddrTop.S
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  ArmVirtPkg/ArmVirtPkg.dec
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  ArmLib
+  BaseMemoryLib
+  DebugLib
+  FdtLib
+  PcdLib
+  MemoryAllocationLib
+
+[Pcd]
+  gArmTokenSpaceGuid.PcdFdBaseAddress
+  gArmTokenSpaceGuid.PcdSystemMemoryBase
+  gArmTokenSpaceGuid.PcdSystemMemorySize
+
+[FixedPcd]
+  gArmTokenSpaceGuid.PcdFdSize
+  gArmVirtTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress
+  gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
diff --git 
a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLibConstructor.c 
b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLibConstructor.c
new file mode 100644
index ..ef8ac6e018d1
--- /dev/null
+++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLibConstructor.c
@@ -0,0 +1,106 @@
+/** @file
+
+  Copyright (c) 2014-2017, Linaro Limited. All rights reserved.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License 

[edk2] [PATCH v2 13/14] ArmVirtPkg/ArmVirtMemoryInitPeiLib: move to ArmVirtMemInfoLib

[Ard Biesheuvel]

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 | 2 +-
 ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c   | 4 ++--
 ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf | 3 ++-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 519c2ae2e939..f09226671827 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -48,7 +48,7 @@ [LibraryClasses.common]
   QemuFwCfgLib|ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf
 
-  ArmPlatformLib|ArmVirtPkg/Library/ArmVirtPlatformLib/ArmVirtPlatformLib.inf
+  
ArmPlatformLib|ArmPlatformPkg/Library/ArmPlatformLibNull/ArmPlatformLibNull.inf
 
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
   NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
diff --git 
a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c 
b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c
index 6f3e54b7afcb..05afd1282422 100644
--- a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c
+++ b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c
@@ -16,7 +16,7 @@
 #include 
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -39,7 +39,7 @@ InitMmu (
   RETURN_STATUS Status;
 
   // Get Virtual Memory Map from the Platform Library
-  ArmPlatformGetVirtualMemoryMap ();
+  ArmVirtGetMemoryMap ();
 
   //Note: Because we called PeiServicesInstallPeiMemory() before to call 
InitMmu() the MMU Page Table resides in
   //  DRAM (even at the top of DRAM as it is the first permanent memory 
allocation)
diff --git 
a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf 
b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf
index 028d6fb5ac28..54879d590a8a 100644
--- a/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf
+++ b/ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf
@@ -29,13 +29,14 @@ [Packages]
   EmbeddedPkg/EmbeddedPkg.dec
   ArmPkg/ArmPkg.dec
   ArmPlatformPkg/ArmPlatformPkg.dec
+  ArmVirtPkg/ArmVirtPkg.dec
 
 [LibraryClasses]
   DebugLib
   HobLib
   ArmLib
   ArmMmuLib
-  ArmPlatformLib
+  ArmVirtMemInfoLib
   CacheMaintenanceLib
 
 [Guids]
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 07/14] ArmVirtPkg/PrePi: remove bogus IntelFrameworkModulePkg.dec dependency

[Ard Biesheuvel]

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 | 1 -
 1 file changed, 1 deletion(-)

diff --git a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf 
b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
index ae9a088c7256..58290d2d1b76 100755
--- a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
+++ b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
@@ -40,7 +40,6 @@ [Packages]
   ArmPkg/ArmPkg.dec
   ArmPlatformPkg/ArmPlatformPkg.dec
   ArmVirtPkg/ArmVirtPkg.dec
-  IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
 
 [LibraryClasses]
   BaseLib
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 03/14] ArmVirtPkg/PrePi: remove bogus primary core check

[Ard Biesheuvel]

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 ArmPlatformLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
---
 ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S | 7 ---
 ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S | 7 ---
 2 files changed, 14 deletions(-)

diff --git a/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S 
b/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S
index cc8b47e69026..7a9c0c3787cc 100644
--- a/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S
+++ b/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S
@@ -128,13 +128,6 @@ _GetStackBase:
   MOV32 (x3, FixedPcdGet32(PcdCPUCoreSecondaryStackSize))
   blASM_PFX(ArmPlatformStackSet)
 
-  // Is it the Primary Core ?
-  mov   x0, x10
-  blASM_PFX(ArmPlatformIsPrimaryCore)
-  cmp   x0, #1
-  bne   _PrepareArguments
-
-_PrepareArguments:
   mov   x0, x20
   mov   x1, x21
   mov   x2, x22
diff --git a/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S 
b/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S
index 59028d0a553e..eebf660acdb2 100644
--- a/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S
+++ b/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S
@@ -136,13 +136,6 @@ _GetStackBase:
   MOV32 (r3, FixedPcdGet32(PcdCPUCoreSecondaryStackSize))
   blASM_PFX(ArmPlatformStackSet)
 
-  // Is it the Primary Core ?
-  mov   r0, r10
-  blASM_PFX(ArmPlatformIsPrimaryCore)
-  cmp   r0, #1
-  bne   _PrepareArguments
-
-_PrepareArguments:
   mov   r0, r10
   mov   r1, r11
   mov   r2, r9
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 05/14] ArmVirtPkg/PrePi: remove dependency on ArmPlatformLib

[Ard Biesheuvel]

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 
---
 ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf | 1 -
 ArmVirtPkg/PrePi/PrePi.c| 6 ++
 ArmVirtPkg/PrePi/PrePi.h| 1 -
 3 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf 
b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
index 789a896857aa..e816e9583da8 100755
--- a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
+++ b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
@@ -54,7 +54,6 @@ [LibraryClasses]
   LzmaDecompressLib
   PeCoffGetEntryPointLib
   PrePiLib
-  ArmPlatformLib
   ArmPlatformStackLib
   MemoryAllocationLib
   HobLib
diff --git a/ArmVirtPkg/PrePi/PrePi.c b/ArmVirtPkg/PrePi/PrePi.c
index c4fa979c43ef..fce4ab9428a5 100755
--- a/ArmVirtPkg/PrePi/PrePi.c
+++ b/ArmVirtPkg/PrePi/PrePi.c
@@ -13,6 +13,7 @@
 **/
 
 #include 
+#include 
 
 #include 
 #include 
@@ -85,7 +86,7 @@ PrePiMain (
   BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize));
 
   // Set the Boot Mode
-  SetBootMode (ArmPlatformGetBootMode ());
+  SetBootMode (BOOT_WITH_FULL_CONFIGURATION);
 
   // Initialize Platform HOBs (CpuHob and FvHob)
   Status = PlatformPeim ();
@@ -123,9 +124,6 @@ CEntryPoint (
 {
   UINT64   StartTimeStamp;
 
-  // Initialize the platform specific controllers
-  ArmPlatformInitialize (MpId);
-
   if (PerformanceMeasurementEnabled ()) {
 // Initialize the Timer Library to setup the Timer HW controller
 TimerConstructor ();
diff --git a/ArmVirtPkg/PrePi/PrePi.h b/ArmVirtPkg/PrePi/PrePi.h
index 153f06b9c7fb..14c9bf92c115 100644
--- a/ArmVirtPkg/PrePi/PrePi.h
+++ b/ArmVirtPkg/PrePi/PrePi.h
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #define SerialPrint(txt)  SerialPortWrite (txt, AsciiStrLen(txt)+1);
 
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 08/14] ArmVirtPkg/ArmVirtPlatformLib: remove support for uncached mappings

[Ard Biesheuvel]

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 
Reviewed-by: Laszlo Ersek 
---
 ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c 
b/ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c
index d10548f86dfc..4368d05f76ef 100644
--- a/ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c
+++ b/ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c
@@ -22,10 +22,6 @@
 // Number of Virtual Memory Map Descriptors
 #define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS  5
 
-// DDR attributes
-#define DDR_ATTRIBUTES_CACHEDARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK
-#define DDR_ATTRIBUTES_UNCACHED  
ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED
-
 EFI_PHYSICAL_ADDRESS
 ArmGetPhysAddrTop (
   VOID
@@ -48,7 +44,6 @@ ArmPlatformGetVirtualMemoryMap (
   IN ARM_MEMORY_REGION_DESCRIPTOR** VirtualMemoryMap
   )
 {
-  ARM_MEMORY_REGION_ATTRIBUTES  CacheAttributes;
   ARM_MEMORY_REGION_DESCRIPTOR  *VirtualMemoryTable;
 
   ASSERT (VirtualMemoryMap != NULL);
@@ -65,17 +60,11 @@ ArmPlatformGetVirtualMemoryMap (
 return;
   }
 
-  if (FeaturePcdGet (PcdCacheEnable) == TRUE) {
-CacheAttributes = DDR_ATTRIBUTES_CACHED;
-  } else {
-CacheAttributes = DDR_ATTRIBUTES_UNCACHED;
-  }
-
   // System DRAM
   VirtualMemoryTable[0].PhysicalBase = PcdGet64 (PcdSystemMemoryBase);
   VirtualMemoryTable[0].VirtualBase  = VirtualMemoryTable[0].PhysicalBase;
   VirtualMemoryTable[0].Length   = PcdGet64 (PcdSystemMemorySize);
-  VirtualMemoryTable[0].Attributes   = CacheAttributes;
+  VirtualMemoryTable[0].Attributes   = ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
 
   DEBUG ((EFI_D_INFO, "%a: Dumping System DRAM Memory Map:\n"
   "\tPhysicalBase: 0x%lX\n"
@@ -104,7 +93,7 @@ ArmPlatformGetVirtualMemoryMap (
   VirtualMemoryTable[3].PhysicalBase = FixedPcdGet64 (PcdFdBaseAddress);
   VirtualMemoryTable[3].VirtualBase  = VirtualMemoryTable[3].PhysicalBase;
   VirtualMemoryTable[3].Length   = FixedPcdGet32 (PcdFdSize);
-  VirtualMemoryTable[3].Attributes   = CacheAttributes;
+  VirtualMemoryTable[3].Attributes   = ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
 
   // End of Table
   ZeroMem ([4], sizeof (ARM_MEMORY_REGION_DESCRIPTOR));
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 10/14] ArmVirtPkg/ArmVirtXen: add ArmVirtMemInfoLib implementation

[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 Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Cc: Julien Grall 
---
 ArmVirtPkg/ArmVirtXen.dsc  |  1 +
 ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S | 39 
 ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S | 24 
 ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c   | 63 

 ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf | 41 +
 5 files changed, 168 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index 7a443483d1ac..3df684d13cb0 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -44,6 +44,7 @@ [LibraryClasses]
   
VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
 
   
ArmPlatformLib|ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/ArmXenRelocatablePlatformLib.inf
+  ArmVirtMemInfoLib|ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
 
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
 
diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S 
b/ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S
new file mode 100644
index ..a1f6a194d59b
--- /dev/null
+++ b/ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S
@@ -0,0 +1,39 @@
+#
+#  Copyright (c) 2011-2013, ARM Limited. All rights reserved.
+#  Copyright (c) 2016-2017, Linaro Limited. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#
+
+#include 
+
+//EFI_PHYSICAL_ADDRESS
+//GetPhysAddrTop (
+//  VOID
+//  );
+ASM_FUNC(ArmGetPhysAddrTop)
+  mrs   x0, id_aa64mmfr0_el1
+  adr   x1, .LPARanges
+  and   x0, x0, #7
+  ldrb  w1, [x1, x0]
+  mov   x0, #1
+  lsl   x0, x0, x1
+  ret
+
+//
+// Bits 0..2 of the AA64MFR0_EL1 system register encode the size of the
+// physical address space support on this CPU:
+// 0 == 32 bits, 1 == 36 bits, etc etc
+// 6 and 7 are reserved
+//
+.LPARanges:
+  .byte 32, 36, 40, 42, 44, 48, -1, -1
+
+ASM_FUNCTION_REMOVE_IF_UNREFERENCED
diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S 
b/ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S
new file mode 100644
index ..9cd81529fb3d
--- /dev/null
+++ b/ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S
@@ -0,0 +1,24 @@
+#
+#  Copyright (c) 2011-2013, ARM Limited. All rights reserved.
+#  Copyright (c) 2014-2017, Linaro Limited. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#
+
+#include 
+
+//EFI_PHYSICAL_ADDRESS
+//GetPhysAddrTop (
+//  VOID
+//  );
+ASM_FUNC(ArmGetPhysAddrTop)
+  mov   r0, #0x
+  mov   r1, #0x1
+  bxlr
diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c 
b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
new file mode 100644
index ..88ff3167cbfd
--- /dev/null
+++ b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
@@ -0,0 +1,63 @@
+/** @file
+
+  Copyright (c) 2014-2017, Linaro Limited. All rights reserved.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution.  The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include 
+
+STATIC ARM_MEMORY_REGION_DESCRIPTOR  mVirtualMemoryTable[2];
+
+EFI_PHYSICAL_ADDRESS
+ArmGetPhysAddrTop (
+  VOID
+  );
+
+/**
+  Return the Virtual Memory Map of your platform
+
+  This Virtual Memory Map is used by MemoryInitPei Module to initialize the MMU
+  on your platform.
+
+  @param[out]   VirtualMemoryMapArray of 

[edk2] [PATCH v2 04/14] ArmVirtPkg/PrePi: move DRAM discovery code into PrePi

[Ard Biesheuvel]

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 them (and not with any other platforms)
so we can eliminate another dependency on the messy ArmPlatformLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
---
 ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S | 77 -
 ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S | 71 +++
 ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf |  2 +
 ArmVirtPkg/PrePi/FdtParser.c| 90 
 4 files changed, 238 insertions(+), 2 deletions(-)

diff --git a/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S 
b/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S
index 7a9c0c3787cc..3296aedfe9aa 100644
--- a/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S
+++ b/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S
@@ -49,8 +49,7 @@ ASM_FUNC(_ModuleEntryPoint)
   b .Lreloc_loop
 .Lreloc_done:
 
-  // Do early platform specific actions
-  blASM_PFX(ArmPlatformPeiBootAction)
+  blASM_PFX(DiscoverDramFromDt)
 
   // Get ID of this CPU in Multicore system
   blASM_PFX(ArmReadMpidr)
@@ -140,3 +139,77 @@ _GetStackBase:
 
 _NeverReturn:
   b _NeverReturn
+
+// VOID
+// DiscoverDramFromDt (
+//   VOID   *DeviceTreeBaseAddress,   // passed by loader in x0
+//   VOID   *ImageBase// passed by FDF trampoline in x1
+//   );
+ASM_PFX(DiscoverDramFromDt):
+  //
+  // If we are booting from RAM using the Linux kernel boot protocol, x0 will
+  // point to the DTB image in memory. Otherwise, use the default value defined
+  // by the platform.
+  //
+  cbnz  x0, 0f
+  ldr   x0, PcdGet64 (PcdDeviceTreeInitialBaseAddress)
+
+0:mov   x29, x30// preserve LR
+  mov   x28, x0 // preserve DTB pointer
+  mov   x27, x1 // preserve base of image pointer
+
+  //
+  // The base of the runtime image has been preserved in x1. Check whether
+  // the expected magic number can be found in the header.
+  //
+  ldr   w8, .LArm64LinuxMagic
+  ldr   w9, [x1, #0x38]
+  cmp   w8, w9
+  bne   .Lout
+
+  //
+  //
+  // OK, so far so good. We have confirmed that we likely have a DTB and are
+  // booting via the arm64 Linux boot protocol. Update the base-of-image PCD
+  // to the actual relocated value, and add the shift of PcdFdBaseAddress to
+  // PcdFvBaseAddress as well
+  //
+  adr   x8, PcdGet64 (PcdFdBaseAddress)
+  adr   x9, PcdGet64 (PcdFvBaseAddress)
+  ldr   x6, [x8]
+  ldr   x7, [x9]
+  sub   x7, x7, x6
+  add   x7, x7, x1
+  str   x1, [x8]
+  str   x7, [x9]
+
+  //
+  // Discover the memory size and offset from the DTB, and record in the
+  // respective PCDs. This will also return false if a corrupt DTB is
+  // encountered. Since we are calling a C function, use the window at the
+  // beginning of the FD image as a temp stack.
+  //
+  adr   x1, PcdGet64 (PcdSystemMemoryBase)
+  adr   x2, PcdGet64 (PcdSystemMemorySize)
+  mov   sp, x7
+  blFindMemnode
+  cbz   x0, .Lout
+
+  //
+  // Copy the DTB to the slack space right after the 64 byte arm64/Linux style
+  // image header at the base of this image (defined in the FDF), and record 
the
+  // pointer in PcdDeviceTreeInitialBaseAddress.
+  //
+  adr   x8, PcdGet64 (PcdDeviceTreeInitialBaseAddress)
+  add   x27, x27, #0x40
+  str   x27, [x8]
+
+  mov   x0, x27
+  mov   x1, x28
+  blCopyFdt
+
+.Lout:
+  retx29
+
+.LArm64LinuxMagic:
+  .byte   0x41, 0x52, 0x4d, 0x64
diff --git a/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S 
b/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S
index eebf660acdb2..a918c191432e 100644
--- a/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S
+++ b/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S
@@ -148,3 +148,74 @@ _GetStackBase:
 
 _NeverReturn:
   b _NeverReturn
+
+ASM_PFX(ArmPlatformPeiBootAction):
+  //
+  // If we are booting from RAM using the Linux kernel boot protocol, r0 will
+  // point to the DTB image in memory. Otherwise, use the default value defined
+  // by the platform.
+  //
+  teq   r0, #0
+  bne   0f
+  LDRL  (r0, PcdGet64 (PcdDeviceTreeInitialBaseAddress))
+
+0:mov   r11, r14// preserve LR
+  mov   r10, r0 // preserve DTB pointer
+  mov   r9, r1  // preserve base of image pointer
+
+  //
+  // The base of the runtime image has been preserved in r1. Check whether
+  // the expected magic number can be found in the header.
+  //
+  ldr   r8, .LArm32LinuxMagic
+  ldr   r7, [r1, #0x24]
+  cmp   r7, r8
+  bne   .Lout
+
+  //
+  //
+  // OK, so far so good. We have confirmed that we likely have a DTB and are
+  // booting via the ARM Linux boot protocol. Update the base-of-image PCD
+  // to the actual relocated value, and add the shift of 

[edk2] [PATCH v2 01/14] ArmVirtPkg/PrePi: run all library constructors by hand

[Ard Biesheuvel]

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 
Reviewed-by: Laszlo Ersek 
---
 ArmVirtPkg/PrePi/PrePi.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/ArmVirtPkg/PrePi/PrePi.c b/ArmVirtPkg/PrePi/PrePi.c
index c69cff249e80..3679087aec4d 100755
--- a/ArmVirtPkg/PrePi/PrePi.c
+++ b/ArmVirtPkg/PrePi/PrePi.c
@@ -29,15 +29,9 @@
 #include "PrePi.h"
 #include "LzmaDecompress.h"
 
-EFI_STATUS
-EFIAPI
-ExtractGuidedSectionLibConstructor (
-  VOID
-  );
-
-EFI_STATUS
+VOID
 EFIAPI
-LzmaDecompressLibConstructor (
+ProcessLibraryConstructorList (
   VOID
   );
 
@@ -125,8 +119,7 @@ PrePiMain (
   PERF_START (NULL, "PEI", NULL, StartTimeStamp);
 
   // SEC phase needs to run library constructors by hand.
-  ExtractGuidedSectionLibConstructor ();
-  LzmaDecompressLibConstructor ();
+  ProcessLibraryConstructorList ();
 
   // Build HOBs to pass up our version of stuff the DXE Core needs to save 
space
   BuildPeCoffLoaderHob ();
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 02/14] ArmVirtPkg/PrePi: remove unused GetPlatformPpi() function

[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 
 ArmVirtPkg/PrePi/PrePi.h |  6 -
 2 files changed, 30 deletions(-)

diff --git a/ArmVirtPkg/PrePi/PrePi.c b/ArmVirtPkg/PrePi/PrePi.c
index 3679087aec4d..c4fa979c43ef 100755
--- a/ArmVirtPkg/PrePi/PrePi.c
+++ b/ArmVirtPkg/PrePi/PrePi.c
@@ -35,30 +35,6 @@ ProcessLibraryConstructorList (
   VOID
   );
 
-EFI_STATUS
-GetPlatformPpi (
-  IN  EFI_GUID  *PpiGuid,
-  OUT VOID  **Ppi
-  )
-{
-  UINTN   PpiListSize;
-  UINTN   PpiListCount;
-  EFI_PEI_PPI_DESCRIPTOR  *PpiList;
-  UINTN   Index;
-
-  PpiListSize = 0;
-  ArmPlatformGetPlatformPpiList (, );
-  PpiListCount = PpiListSize / sizeof(EFI_PEI_PPI_DESCRIPTOR);
-  for (Index = 0; Index < PpiListCount; Index++, PpiList++) {
-if (CompareGuid (PpiList->Guid, PpiGuid) == TRUE) {
-  *Ppi = PpiList->Ppi;
-  return EFI_SUCCESS;
-}
-  }
-
-  return EFI_NOT_FOUND;
-}
-
 VOID
 PrePiMain (
   IN  UINTN UefiMemoryBase,
diff --git a/ArmVirtPkg/PrePi/PrePi.h b/ArmVirtPkg/PrePi/PrePi.h
index d3189c0b8a6f..153f06b9c7fb 100644
--- a/ArmVirtPkg/PrePi/PrePi.h
+++ b/ArmVirtPkg/PrePi/PrePi.h
@@ -61,12 +61,6 @@ BuildMemoryTypeInformationHob (
   VOID
   );
 
-EFI_STATUS
-GetPlatformPpi (
-  IN  EFI_GUID  *PpiGuid,
-  OUT VOID  **Ppi
-  );
-
 // Initialize the Architecture specific controllers
 VOID
 ArchInitialize (
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 11/14] ArmVirtPkg/ArmVirtQemu: add ArmVirtMemInfoLib implementation

[Ard Biesheuvel]

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
- use a temp variable to hold the top of the physical address space
- use AllocatePool () instead of AllocatePages (), given that we use
  160 bytes only, and the memory is never freed.

In a future patch, we will add this library to the ordinary ArmVirtQemu
platform as well.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/ArmVirtQemuKernel.dsc |   1 +
 ArmVirtPkg/Library/QemuVirtMemInfoLib/AArch64/PhysAddrTop.S  |  39 
 ArmVirtPkg/Library/QemuVirtMemInfoLib/Arm/PhysAddrTop.S  |  24 +
 ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c   | 100 

 ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf |  54 +++
 5 files changed, 218 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index 7e5d584344b4..f50d30388cf2 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -49,6 +49,7 @@ [LibraryClasses.common]
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf
 
   
ArmPlatformLib|ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/ArmQemuRelocatablePlatformLib.inf
+  
ArmVirtMemInfoLib|ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
 
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
   NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/AArch64/PhysAddrTop.S 
b/ArmVirtPkg/Library/QemuVirtMemInfoLib/AArch64/PhysAddrTop.S
new file mode 100644
index ..a1f6a194d59b
--- /dev/null
+++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/AArch64/PhysAddrTop.S
@@ -0,0 +1,39 @@
+#
+#  Copyright (c) 2011-2013, ARM Limited. All rights reserved.
+#  Copyright (c) 2016-2017, Linaro Limited. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#
+
+#include 
+
+//EFI_PHYSICAL_ADDRESS
+//GetPhysAddrTop (
+//  VOID
+//  );
+ASM_FUNC(ArmGetPhysAddrTop)
+  mrs   x0, id_aa64mmfr0_el1
+  adr   x1, .LPARanges
+  and   x0, x0, #7
+  ldrb  w1, [x1, x0]
+  mov   x0, #1
+  lsl   x0, x0, x1
+  ret
+
+//
+// Bits 0..2 of the AA64MFR0_EL1 system register encode the size of the
+// physical address space support on this CPU:
+// 0 == 32 bits, 1 == 36 bits, etc etc
+// 6 and 7 are reserved
+//
+.LPARanges:
+  .byte 32, 36, 40, 42, 44, 48, -1, -1
+
+ASM_FUNCTION_REMOVE_IF_UNREFERENCED
diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/Arm/PhysAddrTop.S 
b/ArmVirtPkg/Library/QemuVirtMemInfoLib/Arm/PhysAddrTop.S
new file mode 100644
index ..9cd81529fb3d
--- /dev/null
+++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/Arm/PhysAddrTop.S
@@ -0,0 +1,24 @@
+#
+#  Copyright (c) 2011-2013, ARM Limited. All rights reserved.
+#  Copyright (c) 2014-2017, Linaro Limited. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#
+
+#include 
+
+//EFI_PHYSICAL_ADDRESS
+//GetPhysAddrTop (
+//  VOID
+//  );
+ASM_FUNC(ArmGetPhysAddrTop)
+  mov   r0, #0x
+  mov   r1, #0x1
+  bxlr
diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c 
b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
new file mode 100644
index ..ea70f2c33b77
--- /dev/null
+++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
@@ -0,0 +1,100 @@
+/** @file
+
+  Copyright (c) 2014-2017, Linaro Limited. All rights reserved.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution.  The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 

[edk2] [PATCH v2 09/14] ArmVirtPkg: introduce ArmVirtMemInfoLib library class

[Ard Biesheuvel]

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 functionality from ArmPlatformLib later, or, in the case of
ArmVirtXen and ArmVirtQemuKernel, drop ArmPlatformLib altogether.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/ArmVirtPkg.dec  |  3 ++
 ArmVirtPkg/Include/Library/ArmVirtMemInfoLib.h | 41 
 2 files changed, 44 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
index a8603e1b80e5..8f656fd2739d 100644
--- a/ArmVirtPkg/ArmVirtPkg.dec
+++ b/ArmVirtPkg/ArmVirtPkg.dec
@@ -30,6 +30,9 @@ [Defines]
 [Includes.common]
   Include# Root include for the package
 
+[LibraryClasses]
+  ArmVirtMemInfoLib|Include/Library/ArmVirtMemInfoLib.h
+
 [Guids.common]
   gArmVirtTokenSpaceGuid = { 0x0B6F5CA7, 0x4F53, 0x445A, { 0xB7, 0x6E, 0x2E, 
0x36, 0x5B, 0x80, 0x63, 0x66 } }
   gEarlyPL011BaseAddressGuid   = { 0xB199DEA9, 0xFD5C, 0x4A84, { 0x80, 
0x82, 0x2F, 0x41, 0x70, 0x78, 0x03, 0x05 } }
diff --git a/ArmVirtPkg/Include/Library/ArmVirtMemInfoLib.h 
b/ArmVirtPkg/Include/Library/ArmVirtMemInfoLib.h
new file mode 100644
index ..bdf1c513bc6d
--- /dev/null
+++ b/ArmVirtPkg/Include/Library/ArmVirtMemInfoLib.h
@@ -0,0 +1,41 @@
+/** @file
+
+  Copyright (c) 2011-2013, ARM Limited. All rights reserved.
+  Copyright (c) 2017, Linaro, Ltd. All rights reserved.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution.  The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef _ARM_VIRT_MEMINFO_LIB_H_
+#define _ARM_VIRT_MEMINFO_LIB_H_
+
+#include 
+#include 
+
+/**
+  Return the Virtual Memory Map of your platform
+
+  This Virtual Memory Map is used by MemoryInitPei Module to initialize the MMU
+  on your platform.
+
+  @param[out]   VirtualMemoryMapArray of ARM_MEMORY_REGION_DESCRIPTOR
+describing a Physical-to-Virtual Memory
+mapping. This array must be ended by a
+zero-filled entry. The allocated memory
+will not be freed.
+
+**/
+VOID
+EFIAPI
+ArmVirtGetMemoryMap (
+  OUT ARM_MEMORY_REGION_DESCRIPTOR**VirtualMemoryMap
+  );
+
+#endif
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 06/14] ArmVirtPkg/PrePi: remove ArmPlatformStackLib dependency

[Ard Biesheuvel]

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 
Acked-by: Laszlo Ersek 
---
 ArmVirtPkg/ArmVirt.dsc.inc  |  1 -
 ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S | 14 ++
 ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S | 14 ++
 ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf |  1 -
 4 files changed, 4 insertions(+), 26 deletions(-)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index 50eb8675d1c0..5d7edff104b5 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -93,7 +93,6 @@ [LibraryClasses.common]
   ArmDisassemblerLib|ArmPkg/Library/ArmDisassemblerLib/ArmDisassemblerLib.inf
   ArmGicLib|ArmPkg/Drivers/ArmGic/ArmGicLib.inf
   ArmGicArchLib|ArmVirtPkg/Library/ArmVirtGicArchLib/ArmVirtGicArchLib.inf
-  
ArmPlatformStackLib|ArmPlatformPkg/Library/ArmPlatformStackLib/ArmPlatformStackLib.inf
   ArmSmcLib|ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
   ArmHvcLib|ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf
   
ArmGenericTimerCounterLib|ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.inf
diff --git a/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S 
b/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S
index 3296aedfe9aa..891cf1fcab40 100644
--- a/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S
+++ b/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S
@@ -111,22 +111,12 @@ _GetBaseUefiMemory:
 
 _GetStackBase:
   // r1 = The top of the Mpcore Stacks
+  mov   sp, x1
+
   // Stack for the primary core = PrimaryCoreStack
   MOV32 (x2, FixedPcdGet32(PcdCPUCorePrimaryStackSize))
   sub   x22, x1, x2
 
-  // Stack for the secondary core = Number of Cores - 1
-  MOV32 (x1, (FixedPcdGet32(PcdCoreCount) - 1) * 
FixedPcdGet32(PcdCPUCoreSecondaryStackSize))
-  sub   x22, x22, x1
-
-  // x22 = The base of the MpCore Stacks (primary stack & secondary stacks)
-  mov   x0, x22
-  mov   x1, x20
-  //ArmPlatformStackSet(StackBase, MpId, PrimaryStackSize, SecondaryStackSize)
-  MOV32 (x2, FixedPcdGet32(PcdCPUCorePrimaryStackSize))
-  MOV32 (x3, FixedPcdGet32(PcdCPUCoreSecondaryStackSize))
-  blASM_PFX(ArmPlatformStackSet)
-
   mov   x0, x20
   mov   x1, x21
   mov   x2, x22
diff --git a/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S 
b/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S
index a918c191432e..ced08593e9de 100644
--- a/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S
+++ b/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S
@@ -120,22 +120,12 @@ _GetBaseUefiMemory:
 
 _GetStackBase:
   // r1 = The top of the Mpcore Stacks
+  mov   sp, r1
+
   // Stack for the primary core = PrimaryCoreStack
   MOV32 (r2, FixedPcdGet32(PcdCPUCorePrimaryStackSize))
   sub   r9, r1, r2
 
-  // Stack for the secondary core = Number of Cores - 1
-  MOV32 (r1, (FixedPcdGet32(PcdCoreCount) - 1) * 
FixedPcdGet32(PcdCPUCoreSecondaryStackSize))
-  sub   r9, r9, r1
-
-  // r9 = The base of the MpCore Stacks (primary stack & secondary stacks)
-  mov   r0, r9
-  mov   r1, r10
-  //ArmPlatformStackSet(StackBase, MpId, PrimaryStackSize, SecondaryStackSize)
-  MOV32 (r2, FixedPcdGet32(PcdCPUCorePrimaryStackSize))
-  MOV32 (r3, FixedPcdGet32(PcdCPUCoreSecondaryStackSize))
-  blASM_PFX(ArmPlatformStackSet)
-
   mov   r0, r10
   mov   r1, r11
   mov   r2, r9
diff --git a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf 
b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
index e816e9583da8..ae9a088c7256 100755
--- a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
+++ b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
@@ -54,7 +54,6 @@ [LibraryClasses]
   LzmaDecompressLib
   PeCoffGetEntryPointLib
   PrePiLib
-  ArmPlatformStackLib
   MemoryAllocationLib
   HobLib
   PrePiHobListPointerLib
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 00/14] ArmVirtPkg: get rid of ArmPlatformLib

[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 secure world, and booted all cores into SEC.
Also, the fact that both PrePi and PrePeiCore use ArmPlatformLib makes it
difficult to use PEI phase features such as PPI depexes. It would be better
if we could get rid of it completely, or at least not require each platform
to implement it in its entirety.

So as a first step towards phasing out ArmPlatformLib to the extent possible,
let's remove it from ArmVirtPkg. For ArmVirtXen and ArmVirtQemuKernel, we can
get rid of it completely. For ArmVirtQemu, we can't, but we can still remove
our own implementation by switching to the NULL implementation from
ArmPlatformPkg (which does require a minimal tweak in patch #1). Further
reductions of the scope of ArmPlatformLib will be reflected in that library
without the need for further changes to ArmVirtPkg.

v2: drop ArmPlatformPkg prereq patch, it is merged now
use constructor instead of PEIM depex ordering to ensure ArmVirtQemu's
PcdSystemMemorySize PCD is set before being consumed
add acks from Laszlo

Ard Biesheuvel (14):
  ArmVirtPkg/PrePi: run all library constructors by hand
  ArmVirtPkg/PrePi: remove unused GetPlatformPpi() function
  ArmVirtPkg/PrePi: remove bogus primary core check
  ArmVirtPkg/PrePi: move DRAM discovery code into PrePi
  ArmVirtPkg/PrePi: remove dependency on ArmPlatformLib
  ArmVirtPkg/PrePi: remove ArmPlatformStackLib dependency
  ArmVirtPkg/PrePi: remove bogus IntelFrameworkModulePkg.dec dependency
  ArmVirtPkg/ArmVirtPlatformLib: remove support for uncached mappings
  ArmVirtPkg: introduce ArmVirtMemInfoLib library class
  ArmVirtPkg/ArmVirtXen: add ArmVirtMemInfoLib implementation
  ArmVirtPkg/ArmVirtQemu: add ArmVirtMemInfoLib implementation
  ArmVirtPkg: create QemuVirtMemInfoLib version for ArmVirtQemu
  ArmVirtPkg/ArmVirtMemoryInitPeiLib: move to ArmVirtMemInfoLib
  ArmVirtPkg: remove ArmPlatformLib implementations

 ArmVirtPkg/ArmVirt.dsc.inc 
 |   1 -
 ArmVirtPkg/ArmVirtPkg.dec  
 |   3 +
 ArmVirtPkg/ArmVirtQemu.dsc 
 |   5 +-
 ArmVirtPkg/ArmVirtQemuKernel.dsc   
 |   2 +-
 ArmVirtPkg/ArmVirtXen.dsc  
 |   2 +-
 ArmVirtPkg/Include/Library/ArmVirtMemInfoLib.h 
 |  41 ++
 
ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/AARCH64/RelocatableVirtHelper.S
| 141 
 ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/ARM/RelocatableVirtHelper.S   
 | 123 -
 
ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/ArmQemuRelocatablePlatformLib.inf
  |  64 -
 ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/RelocatableVirt.c 
 |  70 --
 ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c   
 |   4 +-
 ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.inf 
 |   3 +-
 ArmVirtPkg/Library/ArmVirtPlatformLib/ARM/VirtHelper.S 
 |  57 
 ArmVirtPkg/Library/ArmVirtPlatformLib/ARM/VirtHelper.asm   
 |  71 --
 ArmVirtPkg/Library/ArmVirtPlatformLib/ArmVirtPlatformLib.inf   
 |  64 -
 ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c
 | 113 
 
ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/AARCH64/RelocatableVirtHelper.S 
| 140 ---
 ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/ARM/RelocatableVirtHelper.S
 | 123 -
 
ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/ArmXenRelocatablePlatformLib.inf
|  63 -
 ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/FdtParser.c
 |  89 
 ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/RelocatableVirt.c  
 |  70 --
 ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/XenVirtMem.c   
 |  82 
 

Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-DMA at ExitBootServices()

[Ni, Ruiyu]

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

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Saturday, October 28, 2017 12:10 AM
> To: edk2-devel-01 
> Cc: Ard Biesheuvel ; Dong, Eric
> ; Zeng, Star ; Dann Frazier
> 
> Subject: Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only
> BM-DMA at ExitBootServices()
> 
> On 10/26/17 17:48, Laszlo Ersek wrote:
> > Clearing I/O port decoding in the PCI command register at
> > ExitBootServices() breaks IDE boot in Windows, on QEMU's "pc" (i440fx)
> > machine type. (AHCI boot on "q35" is unaffected.) Windows seems
> > repeatedly stuck, apparently waiting for a timeout of sorts.
> >
> > This is arguably a Windows bug; a native OS driver should not expect
> > the firmware to leave the PCI command register in any particular state.
> >
> > Strictly speaking, we only need to disable BM-DMA at
> > ExitBootServices(), in order to abort pending transfers to/from RAM,
> > which is soon to be owned by the OS. BM-DMA is also the only bit
> > that's explicitly named by the UEFI Driver Writers' Guide, for clearing at
> ExitBootServices().
> >
> > I've verified that clearing only BM-DMA fixes the isse (boot time) on
> > i440fx, and does not regress q35/AHCI.
> >
> > Cc: Aleksei Kovura 
> > Cc: Ard Biesheuvel 
> > Cc: Dann Frazier 
> > Cc: Eric Dong 
> > Cc: Star Zeng 
> > Reported-by: Aleksei Kovura 
> > Reported-by: Dann Frazier 
> > Reported-by: https://launchpad.net/~cjkrupp
> > Bisected-by: Dann Frazier 
> > Bisected-by: https://launchpad.net/~cjkrupp
> > Suggested-by: Ard Biesheuvel 
> > Suggested-by: Star Zeng 
> > Ref: https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1725560
> > Fixes: 6fb8ddd36bde45614b0a069528cdc97077835a74
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Laszlo Ersek 
> > ---
> >
> > Notes:
> > Repo:   https://github.com/lersek/edk2.git
> > Branch: ata_disable_only_bmdma
> >
> >  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h | 3 +--
> > MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c | 5 ++---
> >  2 files changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
> > b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
> > index 8d6eac706c0b..92c5bf2001cd 100644
> > --- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
> > +++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
> > @@ -123,8 +123,7 @@ typedef struct {
> >LIST_ENTRYNonBlockingTaskList;
> >
> >//
> > -  // For disabling the device (especially Bus Master DMA) at
> > -  // ExitBootServices().
> > +  // For disabling Bus Master DMA on the device at ExitBootServices().
> >//
> >EFI_EVENT ExitBootEvent;
> >  } ATA_ATAPI_PASS_THRU_INSTANCE;
> > diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
> > b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
> > index 09064dda18b7..e10e0d4e65f6 100644
> > --- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
> > +++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
> > @@ -480,8 +480,7 @@ InitializeAtaAtapiPassThru (  }
> >
> >  /**
> > -  Disable the device (especially Bus Master DMA) when exiting the
> > boot
> > -  services.
> > +  Disable Bus Master DMA on the device when exiting the boot services.
> >
> >@param[in] EventEvent for which this notification function is being
> >called.
> > @@ -506,7 +505,7 @@ AtaPassThruExitBootServices (
> >PciIo->Attributes (
> > PciIo,
> > EfiPciIoAttributeOperationDisable,
> > -   Instance->EnabledPciAttributes,
> > +   Instance->EnabledPciAttributes &
> > + EFI_PCI_IO_ATTRIBUTE_BUS_MASTER,
> > NULL
> > );
> >  }
> >
> 
> Thanks Everyone for the feedback; I fixed the typo pointed out by Star and
> pushed the patch as commit 76fd5a660d70.
> 
> Cheers
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 8/9] Compilation : Add the fdf, dsc and dec files.

[Meenakshi Aggarwal]

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 +
 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf | 281 +
 Platform/NXP/NxpQoriqLs.dec  | 248 +++
 Platform/NXP/NxpQoriqLs.dsc  | 453 +++
 Silicon/NXP/LS1043A/LS1043A.dec  |  22 ++
 Silicon/NXP/LS1043A/LS1043A.dsc  |  82 +
 7 files changed, 1192 insertions(+)
 create mode 100644 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dec
 create mode 100644 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
 create mode 100644 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
 create mode 100644 Platform/NXP/NxpQoriqLs.dec
 create mode 100644 Platform/NXP/NxpQoriqLs.dsc
 create mode 100644 Silicon/NXP/LS1043A/LS1043A.dec
 create mode 100644 Silicon/NXP/LS1043A/LS1043A.dsc

diff --git a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dec 
b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dec
new file mode 100644
index 000..1b639e2
--- /dev/null
+++ b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dec
@@ -0,0 +1,29 @@
+#  LS1043aRdbPkg.dec
+#  LS1043a board package.
+#
+#  Copyright 2017 NXP
+#
+#  This program and the accompanying materials are licensed and made available 
under
+#  the terms and conditions of the BSD License which accompanies this 
distribution.
+#  The full text of the license may be found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+
+[Defines]
+  PACKAGE_NAME   = LS1043aRdbPkg
+  PACKAGE_GUID   = 6eba6648-d853-4eb3-9761-528b82d5ab04
+
+
+#
+# Include Section - list of Include Paths that are provided by this package.
+#   Comments are used for Keywords and Module Types.
+#
+# Supported Module Types:
+#  BASE SEC PEI_CORE PEIM DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER 
DXE_SMM_DRIVER DXE_SAL_DRIVER UEFI_DRIVER UEFI_APPLICATION
+#
+
+[Includes.common]
+  Include# Root include for the package
diff --git a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc 
b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
new file mode 100644
index 000..1951e82
--- /dev/null
+++ b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
@@ -0,0 +1,77 @@
+#  LS1043aRdbPkg.dsc
+#
+#  LS1043ARDB Board package.
+#
+#  Copyright 2017 NXP
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution. The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+[Defines]
+  #
+  # Defines for default states.  These can be changed on the command line.
+  # -D FLAG=VALUE
+  #
+  PLATFORM_NAME  = LS1043aRdbPkg
+  PLATFORM_GUID  = 60169ec4-d2b4-44f8-825e-f8684fd42e4f
+  OUTPUT_DIRECTORY   = Build/LS1043aRdbPkg
+  FLASH_DEFINITION   = 
edk2-platforms/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
+
+!include ../NxpQoriqLs.dsc
+!include ../../../Silicon/NXP/LS1043A/LS1043A.dsc
+
+[LibraryClasses.common]
+  
ArmPlatformLib|edk2-platforms/Platform/NXP/LS1043aRdbPkg/Library/PlatformLib/ArmPlatformLib.inf
+  
ResetSystemLib|ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
+  
SerialPortLib|edk2-platforms/Platform/NXP/Library/DUartPortLib/DUartPortLib.inf
+  BeIoLib|edk2-platforms/Platform/NXP/Library/BeIoLib/BeIoLib.inf
+  SocLib|edk2-platforms/Silicon/NXP/Chassis/LS1043aSocLib.inf
+  
RealTimeClockLib|edk2-platforms/Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.inf
+
+[PcdsFixedAtBuild.common]
+  gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"LS1043a RDB board"
+
+  #
+  # Board Specific Pcds
+  #
+  gNxpQoriqLsTokenSpaceGuid.PcdSerdes2Enabled|FALSE
+  gNxpQoriqLsTokenSpaceGuid.PcdPlatformFreqDiv|0x1
+
+  #
+  # Big Endian IPs
+  #
+  gNxpQoriqLsTokenSpaceGuid.PcdGurBigEndian|TRUE
+  gNxpQoriqLsTokenSpaceGuid.PcdWdogBigEndian|TRUE
+
+  #
+  # I2C controller Pcds
+  #
+  gNxpQoriqLsTokenSpaceGuid.PcdI2cBus|0
+
+  #
+  # RTC Pcds
+  #
+  

[edk2] [PATCH v2 9/9] Build : Add build script and environment script

[Meenakshi Aggarwal]

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 
 Platform/NXP/Readme.md |  15 +++
 Platform/NXP/build.sh  | 103 +
 3 files changed, 195 insertions(+)
 create mode 100755 Platform/NXP/Env.cshrc
 create mode 100644 Platform/NXP/Readme.md
 create mode 100755 Platform/NXP/build.sh

diff --git a/Platform/NXP/Env.cshrc b/Platform/NXP/Env.cshrc
new file mode 100755
index 000..31abb04
--- /dev/null
+++ b/Platform/NXP/Env.cshrc
@@ -0,0 +1,77 @@
+#  @file.
+#
+#  Copyright 2017 NXP
+#
+#  This program and the accompanying materials are licensed and made available 
under
+#  the terms and conditions of the BSD License which accompanies this 
distribution.
+#  The full text of the license may be found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#
+
+unset GCC_UTILITY GCC_VERSION MajorVersion MinorVersion
+
+if [ X"$CROSS_COMPILE_64" != X"" ]; then
+  ARM64_PREFIX="$CROSS_COMPILE_64"
+elif [ X"$CROSS_COMPILE" != X"" ]; then
+  ARM64_PREFIX="$CROSS_COMPILE"
+else
+  ARM64_PREFIX="aarch64-linux-gnu-"
+fi
+
+GCC_UTILITY="${ARM64_PREFIX}gcc"
+CheckGcc=`which $GCC_UTILITY >/dev/null 2>&1`
+if [ "$?" -eq 0 ];then
+  GCC_VERSION=`$GCC_UTILITY -v 2>&1 | tail -n 1 | awk '{print $3}'`
+  MajorVersion=`echo $GCC_VERSION | cut -d . -f 1`
+  MinorVersion=`echo $GCC_VERSION | cut -d . -f 2`
+  GCC_ARCH_PREFIX=
+  NOTSUPPORTED=0
+
+  case $MajorVersion in
+4)
+  case $MinorVersion in
+9)
+  GCC_ARCH_PREFIX="GCC49_AARCH64_PREFIX"
+;;
+*)
+  NOTSUPPORTED=1
+;;
+  esac
+;;
+5)
+  case $MinorVersion in
+  4)
+GCC_ARCH_PREFIX="GCC5_AARCH64_PREFIX"
+  ;;
+  *)
+GCC_ARCH_PREFIX="GCC5_AARCH64_PREFIX"
+echo "Warning: ${GCC_UTILITY} version ($MajorVersion.$MinorVersion) 
has not been tested, please use at own risk."
+  ;;
+  esac
+;;
+*)
+  NOTSUPPORTED=1
+;;
+  esac
+
+  [ "$NOTSUPPORTED" -eq 1 ] && {
+  echo "Error: ${GCC_UTILITY} version ($MajorVersion.$MinorVersion) not 
supported ."
+  unset GCC_UTILITY GCC_VERSION MajorVersion MinorVersion
+  }
+
+  [ -n "$GCC_ARCH_PREFIX" ] && {
+export GCC_ARCH_PREFIX="$GCC_ARCH_PREFIX"
+export "$GCC_ARCH_PREFIX=$ARM64_PREFIX"
+  }
+
+  unset ARCH
+else
+echo "Error: ${GCC_UTILITY} not found. Please check PATH variable."
+unset GCC_UTILITY GCC_VERSION MajorVersion MinorVersion
+fi
+
+export PACKAGES_PATH=$PWD/../../../edk2-platforms
diff --git a/Platform/NXP/Readme.md b/Platform/NXP/Readme.md
new file mode 100644
index 000..2c36f43
--- /dev/null
+++ b/Platform/NXP/Readme.md
@@ -0,0 +1,15 @@
+Support for all NXP boards is available in this directory.
+
+# How to build
+
+build script source environment file Env.cshrc
+
+user need to run only build command.
+
+1. Build desired board
+   ./build.sh(optional)
+
+   board-name  : LS1043 / LS1046 / LS2088
+   build-candidate : DEBUG / RELEASE
+
+Currently, support for LS1043 is provided.
diff --git a/Platform/NXP/build.sh b/Platform/NXP/build.sh
new file mode 100755
index 000..e465ebf
--- /dev/null
+++ b/Platform/NXP/build.sh
@@ -0,0 +1,103 @@
+#!/bin/bash
+
+# UEFI build script for NXP LS SoCs
+#
+# Copyright 2017 NXP
+#
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD 
License
+# which accompanies this distribution.  The full text of the license may be 
found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+#
+
+# source environment file
+source Env.cshrc
+
+# Global Defaults
+ARCH=AARCH64
+TARGET_TOOLS=`echo $GCC_ARCH_PREFIX | cut -d _ -f 1`
+BASE_DIR=../../..
+
+[ -z "$TARGET_TOOLS" ] && {
+  echo "TARGET_TOOLS not found. Please run \"source Env.cshrc\" ."
+  exit 1
+}
+
+print_usage_banner()
+{
+echo ""
+echo "This shell script expects:"
+echo "Arg 1 (mandatory): Board Type (can be LS1043 / LS1046 / LS2088)."
+echo "Arg 2 (mandatory): Build candidate (can be RELEASE or DEBUG). By
+  default we build the RELEASE candidate."
+echo "Arg 3 (optional): clean - To do a 'make clean' operation."
+}
+
+# Check for total num of input arguments
+if [[ "$#" -gt 3 ]]; then
+  echo "Illegal number of parameters"
+  print_usage_banner
+  exit
+fi
+
+# Check for third parameter to be clean only
+if [[ "$3" && $3 != "clean" ]]; then
+  echo "Error ! Either clean or emplty"
+  

[edk2] [PATCH v2 6/9] Silicon/Maxim : Add support for DS1307 RTC library

[Meenakshi Aggarwal]

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 +
 .../Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.dec|  26 ++
 .../Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.inf|  45 +++
 4 files changed, 457 insertions(+)
 create mode 100644 Silicon/Maxim/Library/Ds1307RtcLib/Ds1307Rtc.h
 create mode 100644 Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.c
 create mode 100644 Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.dec
 create mode 100644 Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.inf

diff --git a/Silicon/Maxim/Library/Ds1307RtcLib/Ds1307Rtc.h 
b/Silicon/Maxim/Library/Ds1307RtcLib/Ds1307Rtc.h
new file mode 100644
index 000..96271f8
--- /dev/null
+++ b/Silicon/Maxim/Library/Ds1307RtcLib/Ds1307Rtc.h
@@ -0,0 +1,59 @@
+/** Ds1307Rtc.h
+*
+*  Copyright 2017 NXP
+*
+*  This program and the accompanying materials
+*  are licensed and made available under the terms and conditions of the BSD 
License
+*  which accompanies this distribution.  The full text of the license may be 
found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+
+#ifndef __DS1307RTC_H__
+#define __DS1307RTC_H__
+
+/*
+ * RTC time register
+ */
+#define DS1307_SEC_REG_ADDR0x00
+#define DS1307_MIN_REG_ADDR0x01
+#define DS1307_HR_REG_ADDR 0x02
+#define DS1307_DAY_REG_ADDR0x03
+#define DS1307_DATE_REG_ADDR   0x04
+#define DS1307_MON_REG_ADDR0x05
+#define DS1307_YR_REG_ADDR 0x06
+
+#define DS1307_SEC_BIT_CH  0x80  /* Clock Halt (in Register 0)   */
+
+/*
+ * RTC control register
+ */
+#define DS1307_CTL_REG_ADDR0x07
+
+#define START_YEAR 1970
+#define END_YEAR   2070
+
+/*
+ * TIME MASKS
+ */
+#define MASK_SEC   0x7F
+#define MASK_MIN   0x7F
+#define MASK_HOUR  0x3F
+#define MASK_DAY   0x3F
+#define MASK_MONTH 0x1F
+
+/*
+ * I2C FLAGS
+ */
+#define I2C_REG_ADDRESS0x2
+
+typedef struct {
+  UINTN   OperationCount;
+  EFI_I2C_OPERATION   SetAddressOp;
+  EFI_I2C_OPERATION   GetSetDateTimeOp;
+} RTC_I2C_REQUEST;
+
+#endif // __DS1307RTC_H__
diff --git a/Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.c 
b/Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.c
new file mode 100644
index 000..e362f2b
--- /dev/null
+++ b/Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.c
@@ -0,0 +1,327 @@
+/** Ds1307RtcLib.c
+  Implement EFI RealTimeClock via RTC Lib for DS1307 RTC.
+
+  Based on RTC implementation available in
+  EmbeddedPkg/Library/TemplateRealTimeClockLib/RealTimeClockLib.c
+
+  Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
+  Copyright 2017 NXP
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "Ds1307Rtc.h"
+
+STATIC VOID   *mDriverEventRegistration;
+STATIC EFI_I2C_MASTER_PROTOCOL*mI2cMaster;
+
+/**
+  Read RTC register.
+
+  @param  RtcRegAddr   Register offset of RTC to be read.
+
+  @retval  Register Value read
+
+**/
+
+STATIC
+UINT8
+RtcRead (
+  IN  UINT8RtcRegAddr
+  )
+{
+  RTC_I2C_REQUEST  Req;
+  EFI_STATUS   Status;
+  UINT8Val;
+
+  Val = 0;
+
+  Req.OperationCount = 2;
+
+  Req.SetAddressOp.Flags = 0;
+  Req.SetAddressOp.LengthInBytes = sizeof (RtcRegAddr);
+  Req.SetAddressOp.Buffer = 
+
+  Req.GetSetDateTimeOp.Flags = I2C_FLAG_READ;
+  Req.GetSetDateTimeOp.LengthInBytes = sizeof (Val);
+  Req.GetSetDateTimeOp.Buffer = 
+
+  Status = mI2cMaster->StartRequest (mI2cMaster, FixedPcdGet8 
(PcdI2cSlaveAddress),
+ (VOID *),
+ NULL,  NULL);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "RTC read error at Addr:0x%x\n", RtcRegAddr));
+  }
+
+  return Val;
+}
+
+/**
+  Write RTC register.
+
+  @param  RtcRegAddr   Register offset of RTC to write.
+  @param  Val  Value to be written
+
+**/
+
+STATIC
+VOID
+RtcWrite (
+  IN  UINT8RtcRegAddr,
+  IN  UINT8Val
+  )
+{
+  

[edk2] [PATCH v2 7/9] Platform/NXP: Add support for ArmPlatformLib

[Meenakshi Aggarwal]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal 
---
 .../Library/PlatformLib/ArmPlatformLib.c   | 105 
 .../Library/PlatformLib/ArmPlatformLib.inf |  70 
 .../Library/PlatformLib/NxpQoriqLsHelper.S |  38 +
 .../Library/PlatformLib/NxpQoriqLsMem.c| 184 +
 4 files changed, 397 insertions(+)
 create mode 100644 
Platform/NXP/LS1043aRdbPkg/Library/PlatformLib/ArmPlatformLib.c
 create mode 100644 
Platform/NXP/LS1043aRdbPkg/Library/PlatformLib/ArmPlatformLib.inf
 create mode 100644 
Platform/NXP/LS1043aRdbPkg/Library/PlatformLib/NxpQoriqLsHelper.S
 create mode 100644 
Platform/NXP/LS1043aRdbPkg/Library/PlatformLib/NxpQoriqLsMem.c

diff --git a/Platform/NXP/LS1043aRdbPkg/Library/PlatformLib/ArmPlatformLib.c 
b/Platform/NXP/LS1043aRdbPkg/Library/PlatformLib/ArmPlatformLib.c
new file mode 100644
index 000..ab4815d
--- /dev/null
+++ b/Platform/NXP/LS1043aRdbPkg/Library/PlatformLib/ArmPlatformLib.c
@@ -0,0 +1,105 @@
+/** ArmPlatformLib.c
+*
+*  Contains board initialization functions.
+*
+*  Based on BeagleBoardPkg/Library/BeagleBoardLib/BeagleBoard.c
+*
+*  Copyright (c) 2011-2012, ARM Limited. All rights reserved.
+*  Copyright (c) 2016, Freescale Semiconductor, Inc. All rights reserved.
+*  Copyright 2017 NXP
+*
+*  This program and the accompanying materials
+*  are licensed and made available under the terms and conditions of the BSD 
License
+*  which accompanies this distribution.  The full text of the license may be 
found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+
+#include 
+#include 
+
+extern VOID SocInit (VOID);
+
+/**
+  Return the current Boot Mode
+
+  This function returns the boot reason on the platform
+
+**/
+EFI_BOOT_MODE
+ArmPlatformGetBootMode (
+  VOID
+  )
+{
+  return BOOT_WITH_FULL_CONFIGURATION;
+}
+
+/**
+ Placeholder for Platform Initialization
+**/
+EFI_STATUS
+ArmPlatformInitialize (
+  IN  UINTN   MpId
+  )
+{
+ SocInit ();
+
+ return EFI_SUCCESS;
+}
+
+ARM_CORE_INFO LS1043aMpCoreInfoCTA53x4[] = {
+  {
+// Cluster 0, Core 0
+0x0, 0x0,
+
+// MP Core MailBox Set/Get/Clear Addresses and Clear Value
+(EFI_PHYSICAL_ADDRESS)0,
+(EFI_PHYSICAL_ADDRESS)0,
+(EFI_PHYSICAL_ADDRESS)0,
+(UINT64)0x
+  },
+};
+
+EFI_STATUS
+PrePeiCoreGetMpCoreInfo (
+  OUT UINTN   *CoreCount,
+  OUT ARM_CORE_INFO   **ArmCoreTable
+  )
+{
+  *CoreCount= sizeof (LS1043aMpCoreInfoCTA53x4) / sizeof (ARM_CORE_INFO);
+  *ArmCoreTable = LS1043aMpCoreInfoCTA53x4;
+
+  return EFI_SUCCESS;
+}
+
+ARM_MP_CORE_INFO_PPI mMpCoreInfoPpi = { PrePeiCoreGetMpCoreInfo };
+
+EFI_PEI_PPI_DESCRIPTOR  gPlatformPpiTable[] = {
+  {
+EFI_PEI_PPI_DESCRIPTOR_PPI,
+,
+
+  }
+};
+
+VOID
+ArmPlatformGetPlatformPpiList (
+  OUT UINTN   *PpiListSize,
+  OUT EFI_PEI_PPI_DESCRIPTOR  **PpiList
+  )
+{
+  *PpiListSize = sizeof (gPlatformPpiTable);
+  *PpiList = gPlatformPpiTable;
+}
+
+
+UINTN
+ArmPlatformGetCorePosition (
+  IN UINTN MpId
+  )
+{
+  return 1;
+}
diff --git a/Platform/NXP/LS1043aRdbPkg/Library/PlatformLib/ArmPlatformLib.inf 
b/Platform/NXP/LS1043aRdbPkg/Library/PlatformLib/ArmPlatformLib.inf
new file mode 100644
index 000..f8fdee9
--- /dev/null
+++ b/Platform/NXP/LS1043aRdbPkg/Library/PlatformLib/ArmPlatformLib.inf
@@ -0,0 +1,70 @@
+#  @file
+#
+#  Copyright (c) 2016, Freescale Semiconductor, Inc. All rights reserved.
+#  Copyright 2017 NXP
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = PlatformLib
+  FILE_GUID  = 736343a0-1d96-11e0--0002a5d5c51b
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = ArmPlatformLib
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  ArmPlatformPkg/ArmPlatformPkg.dec
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdePkg/MdePkg.dec
+  Platform/NXP/NxpQoriqLs.dec
+
+[LibraryClasses]
+  ArmLib
+  SocLib
+
+[Sources.common]
+  NxpQoriqLsHelper.S| GCC
+  NxpQoriqLsMem.c
+  ArmPlatformLib.c
+
+[Ppis]
+  gArmMpCoreInfoPpiGuid
+
+[FeaturePcd]
+  gEmbeddedTokenSpaceGuid.PcdCacheEnable
+
+[FixedPcd]
+  gArmTokenSpaceGuid.PcdArmPrimaryCore
+  gNxpQoriqLsTokenSpaceGuid.PcdCcsrBaseAddr
+  gNxpQoriqLsTokenSpaceGuid.PcdCcsrSize
+  

[edk2] [PATCH v2 5/9] Platform/NXP: Add support for I2c driver

[Meenakshi Aggarwal]

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 +
 Platform/NXP/Drivers/I2cDxe/I2cDxe.h   |  64 +++
 Platform/NXP/Drivers/I2cDxe/I2cDxe.inf |  57 +++
 3 files changed, 849 insertions(+)
 create mode 100644 Platform/NXP/Drivers/I2cDxe/I2cDxe.c
 create mode 100644 Platform/NXP/Drivers/I2cDxe/I2cDxe.h
 create mode 100644 Platform/NXP/Drivers/I2cDxe/I2cDxe.inf

diff --git a/Platform/NXP/Drivers/I2cDxe/I2cDxe.c 
b/Platform/NXP/Drivers/I2cDxe/I2cDxe.c
new file mode 100644
index 000..1f43f9a
--- /dev/null
+++ b/Platform/NXP/Drivers/I2cDxe/I2cDxe.c
@@ -0,0 +1,728 @@
+/** I2cDxe.c
+  I2c driver APIs for read, write, initialize, set speed and reset
+
+  Copyright NXP 2017
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution. The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "I2cDxe.h"
+
+STATIC CONST EFI_PHYSICAL_ADDRESS I2cAddrArr[FixedPcdGet32 
(PcdNumI2cController)] = {
+  FixedPcdGet64 (PcdI2c0BaseAddr),
+  FixedPcdGet64 (PcdI2c1BaseAddr),
+  FixedPcdGet64 (PcdI2c2BaseAddr),
+  FixedPcdGet64 (PcdI2c3BaseAddr)
+};
+
+STATIC CONST UINT16 ClkDiv[60][2] = {
+  { 20,  0x00 }, { 22, 0x01 },  { 24, 0x02 },  { 26, 0x03 },
+  { 28,  0x04 }, { 30,  0x05 }, { 32,  0x09 }, { 34, 0x06 },
+  { 36,  0x0A }, { 40, 0x07 },  { 44, 0x0C },  { 48, 0x0D },
+  { 52,  0x43 }, { 56,  0x0E }, { 60, 0x45 },  { 64, 0x12 },
+  { 68,  0x0F }, { 72,  0x13 }, { 80,  0x14 }, { 88,  0x15 },
+  { 96,  0x19 }, { 104, 0x16 }, { 112, 0x1A }, { 128, 0x17 },
+  { 136, 0x4F }, { 144, 0x1C }, { 160, 0x1D }, { 176, 0x55 },
+  { 192, 0x1E }, { 208, 0x56 }, { 224, 0x22 }, { 228, 0x24 },
+  { 240, 0x1F }, { 256, 0x23 }, { 288, 0x5C }, { 320, 0x25 },
+  { 384, 0x26 }, { 448, 0x2A }, { 480, 0x27 }, { 512, 0x2B },
+  { 576, 0x2C }, { 640, 0x2D }, { 768, 0x31 }, { 896, 0x32 },
+  { 960, 0x2F }, { 1024, 0x33 }, { 1152, 0x34 },{ 1280, 0x35 },
+  { 1536, 0x36 }, { 1792, 0x3A }, { 1920, 0x37 }, { 2048, 0x3B },
+  { 2304, 0x3C }, { 2560, 0x3D }, { 3072, 0x3E }, { 3584, 0x7A },
+  { 3840, 0x3F }, { 4096, 0x7B }, { 5120, 0x7D }, { 6144, 0x7E },
+};
+
+/**
+  Calculate and set proper clock divider
+
+  @param  Rate   clock rate
+
+  @retval ClkDiv Value used to get frequency divider value
+
+**/
+STATIC
+UINT8
+GetClk (
+  IN  UINT32 Rate
+  )
+{
+  UINTN  ClkRate;
+  UINT32 Div;
+  UINT8  ClkDivx;
+
+  ClkRate = CalculateI2cClockRate ();
+
+  Div = (ClkRate + Rate - 1) / Rate;
+
+  if (Div < ClkDiv[0][0]) {
+ClkDivx = 0;
+  } else if (Div > ClkDiv[ARRAY_SIZE (ClkDiv) - 1][0]){
+ClkDivx = ARRAY_SIZE (ClkDiv) - 1;
+  } else {
+for (ClkDivx = 0; ClkDiv[ClkDivx][0] < Div; ClkDivx++);
+  }
+
+  return ClkDivx;
+}
+
+/**
+  Function used to check if i2c is in mentioned state or not
+
+  @param   I2cRegsPointer to I2C registers
+  @param   State  i2c state need to be checked
+
+  @retval  EFI_NOT_READY  Arbitration was lost
+  @retval  EFI_TIMEOUTTimeout occured
+  @retval  CurrState  Value of state register
+
+**/
+STATIC
+EFI_STATUS
+WaitForI2cState (
+  IN  I2C_REGS*I2cRegs,
+  IN  UINT32  State
+  )
+{
+  UINT8   CurrState;
+  UINT64  Cnt;
+
+  for (Cnt = 0; Cnt < 5; Cnt++) {
+MemoryFence ();
+CurrState = MmioRead8 ((UINTN)>I2cSr);
+if (CurrState & I2C_SR_IAL) {
+   MmioWrite8 ((UINTN)>I2cSr, CurrState | I2C_SR_IAL);
+return EFI_NOT_READY;
+}
+
+if ((CurrState & (State >> 8)) == (UINT8)State) {
+  return CurrState;
+}
+  }
+
+  return EFI_TIMEOUT;
+}
+
+/**
+  Function to transfer byte on i2c
+
+  @param   I2cRegsPointer to i2c registers
+  @param   Byte   Byte to be transferred on i2c bus
+
+  @retval  EFI_NOT_READY  Arbitration was lost
+  @retval  EFI_TIMEOUTTimeout occured
+  @retval  EFI_NOT_FOUND  ACK was not recieved
+  @retval  EFI_SUCCESSData transfer was succesful
+
+**/
+STATIC
+EFI_STATUS
+TransferByte (
+  IN  I2C_REGS*I2cRegs,
+  IN  UINT8   Byte
+  )
+{
+  EFI_STATUS  Ret;
+
+  MmioWrite8 ((UINTN)>I2cSr, I2C_SR_IIF_CLEAR);
+  MmioWrite8 ((UINTN)>I2cDr, Byte);
+
+  Ret = WaitForI2cState (I2cRegs, IIF);
+  if ((Ret == EFI_TIMEOUT) || (Ret == EFI_NOT_READY)) {
+return Ret;
+  }
+
+  if (Ret & I2C_SR_RX_NO_AK) {
+return EFI_NOT_FOUND;
+  }
+
+  return EFI_SUCCESS;
+}

[edk2] [PATCH v2 4/9] Platform/NXP : Add support for DUART library

[Meenakshi Aggarwal]

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 +
 Platform/NXP/Library/DUartPortLib/DUartPortLib.inf |  39 +++
 3 files changed, 498 insertions(+)
 create mode 100644 Platform/NXP/Library/DUartPortLib/DUart.h
 create mode 100644 Platform/NXP/Library/DUartPortLib/DUartPortLib.c
 create mode 100644 Platform/NXP/Library/DUartPortLib/DUartPortLib.inf

diff --git a/Platform/NXP/Library/DUartPortLib/DUart.h 
b/Platform/NXP/Library/DUartPortLib/DUart.h
new file mode 100644
index 000..907790b
--- /dev/null
+++ b/Platform/NXP/Library/DUartPortLib/DUart.h
@@ -0,0 +1,128 @@
+/** DUart.h
+*  Header defining the DUART constants (Base addresses, sizes, flags)
+*
+*  Based on Serial I/O Port library headers available in PL011Uart.h
+*
+*  Copyright (c) 2011-2012, ARM Limited. All rights reserved.
+*  Copyright (c) 2016, Freescale Semiconductor, Inc. All rights reserved.
+*  Copyright 2017 NXP
+*
+*  This program and the accompanying materials
+*  are licensed and made available under the terms and conditions of the BSD 
License
+*  which accompanies this distribution.  The full text of the license may be 
found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+
+#ifndef __DUART_H__
+#define __DUART_H__
+
+// FIFO Control Register
+#define DUART_FCR_FIFO_EN  0x01 /* Fifo enable */
+#define DUART_FCR_CLEAR_RCVR   0x02 /* Clear the RCVR FIFO */
+#define DUART_FCR_CLEAR_XMIT   0x04 /* Clear the XMIT FIFO */
+#define DUART_FCR_DMA_SELECT   0x08 /* For DMA applications */
+#define DUART_FCR_TRIGGER_MASK 0xC0 /* Mask for the FIFO trigger range */
+#define DUART_FCR_TRIGGER_10x00 /* Mask for trigger set at 1 */
+#define DUART_FCR_TRIGGER_40x40 /* Mask for trigger set at 4 */
+#define DUART_FCR_TRIGGER_80x80 /* Mask for trigger set at 8 */
+#define DUART_FCR_TRIGGER_14   0xC0 /* Mask for trigger set at 14 */
+#define DUART_FCR_RXSR 0x02 /* Receiver soft reset */
+#define DUART_FCR_TXSR 0x04 /* Transmitter soft reset */
+
+// Modem Control Register
+#define DUART_MCR_DTR  0x01 /* Reserved  */
+#define DUART_MCR_RTS  0x02 /* RTS   */
+#define DUART_MCR_OUT1 0x04 /* Reserved */
+#define DUART_MCR_OUT2 0x08 /* Reserved */
+#define DUART_MCR_LOOP 0x10 /* Enable loopback test mode */
+#define DUART_MCR_AFE  0x20 /* AFE (Auto Flow Control) */
+#define DUART_MCR_DMA_EN   0x04
+#define DUART_MCR_TX_DFR   0x08
+
+// Line Control Register
+/*
+* Note: if the word length is 5 bits (DUART_LCR_WLEN5), then setting
+* DUART_LCR_STOP will select 1.5 stop bits, not 2 stop bits.
+*/
+#define DUART_LCR_WLS_MSK  0x03 /* character length select mask */
+#define DUART_LCR_WLS_50x00 /* 5 bit character length */
+#define DUART_LCR_WLS_60x01 /* 6 bit character length */
+#define DUART_LCR_WLS_70x02 /* 7 bit character length */
+#define DUART_LCR_WLS_80x03 /* 8 bit character length */
+#define DUART_LCR_STB  0x04 /* # stop Bits, off=1, on=1.5 or 2) */
+#define DUART_LCR_PEN  0x08 /* Parity eneble */
+#define DUART_LCR_EPS  0x10 /* Even Parity Select */
+#define DUART_LCR_STKP 0x20 /* Stick Parity */
+#define DUART_LCR_SBRK 0x40 /* Set Break */
+#define DUART_LCR_BKSE 0x80 /* Bank select enable */
+#define DUART_LCR_DLAB 0x80 /* Divisor latch access bit */
+
+// Line Status Register
+#define DUART_LSR_DR   0x01 /* Data ready */
+#define DUART_LSR_OE   0x02 /* Overrun */
+#define DUART_LSR_PE   0x04 /* Parity error */
+#define DUART_LSR_FE   0x08 /* Framing error */
+#define DUART_LSR_BI   0x10 /* Break */
+#define DUART_LSR_THRE 0x20 /* Xmit holding register empty */
+#define DUART_LSR_TEMT 0x40 /* Xmitter empty */
+#define DUART_LSR_ERR  0x80 /* Error */
+
+// Modem Status Register
+#define DUART_MSR_DCTS 0x01 /* Delta CTS */
+#define DUART_MSR_DDSR 0x02 /* Reserved */
+#define DUART_MSR_TERI 0x04 /* Reserved */
+#define DUART_MSR_DDCD 0x08 /* Reserved */
+#define DUART_MSR_CTS  0x10 /* Clear to Send */
+#define DUART_MSR_DSR  0x20 /* Reserved */
+#define DUART_MSR_RI   0x40 /* Reserved */
+#define DUART_MSR_DCD  0x80 /* Reserved */
+
+// Interrupt Identification Register
+#define DUART_IIR_NO_INT   0x01 /* No interrupts pending */
+#define DUART_IIR_ID   

[edk2] [PATCH v2 1/9] Platform/NXP: Add support for Big Endian Mmio APIs

[Meenakshi Aggarwal]

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 
---
 Platform/NXP/Include/Library/BeIoLib.h   | 332 +
 Platform/NXP/Library/BeIoLib/BeIoLib.c   | 400 +++
 Platform/NXP/Library/BeIoLib/BeIoLib.inf |  31 +++
 3 files changed, 763 insertions(+)
 create mode 100644 Platform/NXP/Include/Library/BeIoLib.h
 create mode 100644 Platform/NXP/Library/BeIoLib/BeIoLib.c
 create mode 100644 Platform/NXP/Library/BeIoLib/BeIoLib.inf

diff --git a/Platform/NXP/Include/Library/BeIoLib.h 
b/Platform/NXP/Include/Library/BeIoLib.h
new file mode 100644
index 000..a58883a
--- /dev/null
+++ b/Platform/NXP/Include/Library/BeIoLib.h
@@ -0,0 +1,332 @@
+/** BeIoLib.h
+ *
+ *  Copyright 2017 NXP
+ *
+ *  This program and the accompanying materials
+ *  are licensed and made available under the terms and conditions of the BSD 
License
+ *  which accompanies this distribution.  The full text of the license may be 
found at
+ *  http://opensource.org/licenses/bsd-license.php
+ *
+ *  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ *  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+ *
+ **/
+
+#ifndef __BE_IOLIB_H__
+#define __BE_IOLIB_H__
+
+#include 
+
+/**
+  MmioRead8 for Big-Endian modules.
+
+  @param  Address The MMIO register to read.
+
+  @return The value read.
+
+**/
+UINT8
+EFIAPI
+BeMmioRead8 (
+  IN  UINTN Address
+  );
+
+/**
+  MmioRead16 for Big-Endian modules.
+
+  @param  Address The MMIO register to read.
+
+  @return The value read.
+
+**/
+UINT16
+EFIAPI
+BeMmioRead16 (
+  IN  UINTN Address
+  );
+
+/**
+  MmioRead32 for Big-Endian modules.
+
+  @param  Address The MMIO register to read.
+
+  @return The value read.
+
+**/
+UINT32
+EFIAPI
+BeMmioRead32 (
+  IN  UINTN Address
+  );
+
+/**
+  MmioRead64 for Big-Endian modules.
+
+  @param  Address The MMIO register to read.
+
+  @return The value read.
+
+**/
+UINT64
+EFIAPI
+BeMmioRead64 (
+  IN  UINTN Address
+  );
+
+/**
+  MmioWrite8 for Big-Endian modules.
+
+  @param  Address The MMIO register to write.
+  @param  Value   The value to write to the MMIO register.
+
+**/
+UINT8
+EFIAPI
+BeMmioWrite8 (
+  IN  UINTN Address,
+  IN  UINT8 Value
+  );
+
+/**
+  MmioWrite16 for Big-Endian modules.
+
+  @param  Address The MMIO register to write.
+  @param  Value   The value to write to the MMIO register.
+
+**/
+UINT16
+EFIAPI
+BeMmioWrite16 (
+  IN  UINTN Address,
+  IN  UINT16Value
+  );
+
+/**
+  MmioWrite32 for Big-Endian modules.
+
+  @param  Address The MMIO register to write.
+  @param  Value   The value to write to the MMIO register.
+
+**/
+UINT32
+EFIAPI
+BeMmioWrite32 (
+  IN  UINTN Address,
+  IN  UINT32Value
+  );
+
+/**
+  MmioWrite64 for Big-Endian modules.
+
+  @param  Address The MMIO register to write.
+  @param  Value   The value to write to the MMIO register.
+
+**/
+UINT64
+EFIAPI
+BeMmioWrite64 (
+  IN  UINTN Address,
+  IN  UINT64Value
+  );
+
+/**
+  MmioAndThenOr8 for Big-Endian modules.
+
+  @param  Address The MMIO register to write.
+  @param  AndData The value to AND with the read value from the MMIO register.
+  @param  OrData  The value to OR with the result of the AND operation.
+
+  @return The value written back to the MMIO register.
+
+**/
+UINT8
+EFIAPI
+BeMmioAndThenOr8 (
+  IN  UINTN Address,
+  IN  UINT8 AndData,
+  IN  UINT8 OrData
+  );
+
+/**
+  MmioAndThenOr16 for Big-Endian modules.
+
+  @param  Address The MMIO register to write.
+  @param  AndData The value to AND with the read value from the MMIO register.
+  @param  OrData  The value to OR with the result of the AND operation.
+
+  @return The value written back to the MMIO register.
+
+**/
+UINT16
+EFIAPI
+BeMmioAndThenOr16 (
+  IN  UINTN Address,
+  IN  UINT16AndData,
+  IN  UINT16OrData
+  );
+
+/**
+  MmioAndThenOr32 for Big-Endian modules.
+
+  @param  Address The MMIO register to write.
+  @param  AndData The value to AND with the read value from the MMIO register.
+  @param  OrData  The value to OR with the result of the AND operation.
+
+  @return The value written back to the MMIO register.
+
+**/
+UINT32
+EFIAPI
+BeMmioAndThenOr32 (
+  IN  UINTN Address,
+  IN  UINT32AndData,
+  IN  UINT32OrData
+  );
+
+/**
+  MmioAndThenOr64 for Big-Endian modules.
+
+  @param  Address The MMIO register to write.
+  @param  AndData The value to AND with the read value from the MMIO register.
+  @param  OrData  The value to OR with the result of the AND operation.
+
+  @return The value written back to the MMIO register.
+
+**/
+UINT64
+EFIAPI
+BeMmioAndThenOr64 (
+  IN  UINTN Address,
+  IN  UINT64AndData,
+ 

[edk2] [PATCH v2 3/9] SocLib : Add support for initialization of peripherals

[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 +
 Silicon/NXP/Chassis/Chassis.c | 413 ++
 Silicon/NXP/Chassis/Chassis.h | 144 +++
 Silicon/NXP/Chassis/Chassis2/Chassis2.dec |  19 ++
 Silicon/NXP/Chassis/Chassis2/SerDes.h |  69 +
 Silicon/NXP/Chassis/Chassis2/Soc.c| 145 +++
 Silicon/NXP/Chassis/Chassis2/Soc.h| 376 +++
 Silicon/NXP/Chassis/LS1043aSocLib.inf |  47 
 Silicon/NXP/Chassis/SerDes.c  | 254 ++
 Silicon/NXP/LS1043A/Include/SocSerDes.h   |  55 
 10 files changed, 1701 insertions(+)
 create mode 100644 Platform/NXP/Include/Bitops.h
 create mode 100644 Silicon/NXP/Chassis/Chassis.c
 create mode 100644 Silicon/NXP/Chassis/Chassis.h
 create mode 100644 Silicon/NXP/Chassis/Chassis2/Chassis2.dec
 create mode 100644 Silicon/NXP/Chassis/Chassis2/SerDes.h
 create mode 100644 Silicon/NXP/Chassis/Chassis2/Soc.c
 create mode 100644 Silicon/NXP/Chassis/Chassis2/Soc.h
 create mode 100644 Silicon/NXP/Chassis/LS1043aSocLib.inf
 create mode 100644 Silicon/NXP/Chassis/SerDes.c
 create mode 100644 Silicon/NXP/LS1043A/Include/SocSerDes.h

diff --git a/Platform/NXP/Include/Bitops.h b/Platform/NXP/Include/Bitops.h
new file mode 100644
index 000..beddb4e
--- /dev/null
+++ b/Platform/NXP/Include/Bitops.h
@@ -0,0 +1,179 @@
+/** Bitops.h
+  Header defining the general bitwise operations
+
+  Copyright 2017 NXP
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __BITOPS_H__
+#define __BITOPS_H__
+
+#include 
+
+#define MASK_LOWER_16  0x
+#define MASK_UPPER_16  0x
+#define MASK_LOWER_8   0xFF00
+#define MASK_UPPER_8   0x00FF
+
+/*
+ * Returns the bit mask for a bit index from 0 to 31
+ */
+#define BIT(_BitIndex) (0x1u << (_BitIndex))
+
+/**
+ * Upper32Bits - return bits 32-63 of a number
+ * @N: the number we're accessing
+ *
+ * A basic shift-right of a 64- or 32-bit quantity.  Use this to suppress
+ * the "right shift count >= width of type" warning when that quantity is
+ * 32-bits.
+ */
+#define Upper32Bits(N) ((UINT32)(((N) >> 16) >> 16))
+
+/**
+ * Lower32Bits - return bits 0-31 of a number
+ * @N: the number we're accessing
+ */
+#define Lower32Bits(N) ((UINT32)(N))
+
+
+/*
+ * Stores a value for a given bit field in 32-bit '_Container'
+ */
+
+#define SET_BIT_FIELD32(_Container, _BitShift, _BitWidth, _Value) \
+  __SET_BIT_FIELD32(_Container,   \
+  __GEN_BIT_FIELD_MASK32(_BitShift, _BitWidth),   \
+  _BitShift,  \
+  _Value)
+
+#define __SET_BIT_FIELD32(_Container, _BitMask, _BitShift, _Value)  \
+  do {  \
+(_Container) &= ~(_BitMask);\
+if ((_Value) != 0) {\
+  ASSERT(((UINT32)(_Value) << (_BitShift)) <= (_BitMask));  \
+  (_Container) |=   \
+  ((UINT32)(_Value) << (_BitShift)) & (_BitMask);   \
+}   \
+  } while (0)
+
+/*
+ * Extracts the value for a given bit field in 32-bit _Container
+ */
+
+#define GET_BIT_FIELD32(_Container, _BitShift, _BitWidth) \
+  __GET_BIT_FIELD32(_Container,   \
+  __GEN_BIT_FIELD_MASK32(_BitShift, _BitWidth),   \
+  _BitShift)
+
+#define __GET_BIT_FIELD32(_Container, _BitMask, _BitShift)  \
+  (((UINT32)(_Container) & (_BitMask)) >> (_BitShift))
+
+#define __GEN_BIT_FIELD_MASK32(_BitShift, _BitWidth)\
+  ((_BitWidth) < 32 ?   \
+   (((UINT32)1 << (_BitWidth)) - 1) << (_BitShift) :\
+   ~(UINT32)0)
+
+/*
+ *Stores a value for a given bit field in 64-bit '_Container'
+ */
+#define SET_BIT_FIELD64(_Container, _BitShift, _BitWidth, _Value) \
+  __SET_BIT_FIELD64(_Container,   \
+  __GEN_BIT_FIELD_MASK64(_BitShift, _BitWidth),   \
+  _BitShift,  \
+  _Value)
+
+#define __SET_BIT_FIELD64(_Container, _BitMask, _BitShift, _Value)  \
+  do {   

[edk2] [PATCH v2 2/9] Platform/NXP : Add support for Watchdog driver

[Meenakshi Aggarwal]

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 +++
 Platform/NXP/Drivers/WatchDog/WatchDogDxe.inf |  47 +++
 3 files changed, 505 insertions(+)
 create mode 100644 Platform/NXP/Drivers/WatchDog/WatchDog.c
 create mode 100644 Platform/NXP/Drivers/WatchDog/WatchDog.h
 create mode 100644 Platform/NXP/Drivers/WatchDog/WatchDogDxe.inf

diff --git a/Platform/NXP/Drivers/WatchDog/WatchDog.c 
b/Platform/NXP/Drivers/WatchDog/WatchDog.c
new file mode 100644
index 000..956e455
--- /dev/null
+++ b/Platform/NXP/Drivers/WatchDog/WatchDog.c
@@ -0,0 +1,421 @@
+/** WatchDog.c
+*
+*  Based on Watchdog driver implemenation available in
+*  ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805Watchdog.c
+*
+*  Copyright (c) 2011-2013, ARM Limited. All rights reserved.
+*  Copyright 2017 NXP
+*
+*  This program and the accompanying materials
+*  are licensed and made available under the terms and conditions of the BSD 
License
+*  which accompanies this distribution.  The full text of the license may be 
found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "WatchDog.h"
+
+STATIC EFI_EVENT  EfiExitBootServicesEvent;
+
+STATIC
+UINT16
+EFIAPI
+WdogRead (
+  IN  UINTN Address
+  )
+{
+  if (FixedPcdGetBool (PcdWdogBigEndian)) {
+return BeMmioRead16 (Address);
+  } else {
+return MmioRead16(Address);
+  }
+}
+
+STATIC
+UINT16
+EFIAPI
+WdogWrite (
+  IN  UINTN Address,
+  IN  UINT16Value
+  )
+{
+  if (FixedPcdGetBool (PcdWdogBigEndian)) {
+return BeMmioWrite16 (Address, Value);
+  } else {
+return MmioWrite16 (Address, Value);
+  }
+}
+
+STATIC
+UINT16
+EFIAPI
+WdogAndThenOr (
+  IN  UINTN Address,
+  IN  UINT16And,
+  IN  UINT16Or
+  )
+{
+  if (FixedPcdGetBool (PcdWdogBigEndian)) {
+return BeMmioAndThenOr16 (Address, And, Or);
+  } else {
+return MmioAndThenOr16 (Address, And, Or);
+  }
+}
+
+STATIC
+UINT16
+EFIAPI
+WdogOr (
+  IN  UINTN Address,
+  IN  UINT16Or
+  )
+{
+  if (FixedPcdGetBool (PcdWdogBigEndian)) {
+return BeMmioOr16 (Address, Or);
+  } else {
+return MmioOr16 (Address, Or);
+  }
+}
+
+STATIC
+VOID
+WdogPing (
+  VOID
+  )
+{
+  //
+  // To reload a timeout value to the counter the proper service sequence 
begins by
+  // writing 0x_ followed by 0x_ to the Watchdog Service Register 
(WDOG_WSR).
+  // This service sequence will reload the counter with the timeout value 
WT[7:0] of
+  // Watchdog Control Register (WDOG_WCR).
+  //
+
+  WdogWrite (PcdGet64 (PcdWdog1BaseAddr) + WDOG_WSR_OFFSET,
+ WDOG_SERVICE_SEQ1);
+  WdogWrite (PcdGet64 (PcdWdog1BaseAddr) + WDOG_WSR_OFFSET,
+ WDOG_SERVICE_SEQ2);
+}
+
+/**
+  Stop the Wdog watchdog timer from counting down.
+**/
+STATIC
+VOID
+WdogStop (
+  VOID
+  )
+{
+  // Watchdog cannot be disabled by software once started.
+  // At best, we can keep reload counter with maximum value
+
+  WdogAndThenOr (PcdGet64 (PcdWdog1BaseAddr) + WDOG_WCR_OFFSET,
+ (UINT16)(~WDOG_WCR_WT),
+ (WD_COUNT (WT_MAX_TIME) & WD_COUNT_MASK));
+  WdogPing ();
+}
+
+/**
+  Starts the Wdog counting down by feeding Service register with
+  desired pattern.
+  The count down will start from the value stored in the Load register,
+  not from the value where it was previously stopped.
+**/
+STATIC
+VOID
+WdogStart (
+  VOID
+  )
+{
+  //Reload the timeout value
+  WdogPing ();
+}
+
+/**
+On exiting boot services we must make sure the Wdog Watchdog Timer
+is stopped.
+**/
+STATIC
+VOID
+EFIAPI
+ExitBootServicesEvent (
+  IN EFI_EVENT  Event,
+  IN VOID   *Context
+  )
+{
+  WdogStop ();
+}
+
+/**
+  This function registers the handler NotifyFunction so it is called every time
+  the watchdog timer expires.  It also passes the amount of time since the last
+  handler call to the NotifyFunction.
+  If NotifyFunction is not NULL and a handler is not already registered,
+  then the new handler is registered and EFI_SUCCESS is returned.
+  If NotifyFunction is NULL, and a handler is already registered,
+  then that handler is unregistered.
+  If an attempt is made to register a handler when a handler is already 
registered,
+  then EFI_ALREADY_STARTED is returned.
+  If an attempt is made to unregister a handler when a handler is not 
registered,
+  then EFI_INVALID_PARAMETER is returned.
+
+  @param  This The EFI_TIMER_ARCH_PROTOCOL instance.
+  @param  NotifyFunction   The function to call when a timer interrupt fires. 
This
+  

Re: [edk2] [PATCH v7 0/2] Fix multiple entries of RT_CODE in memory map

[Wang, Jian J]

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 
> Cc: edk2-devel@lists.01.org; Yao, Jiewen 
> Subject: Re: [edk2] [PATCH v7 0/2] Fix multiple entries of RT_CODE in memory
> map
> 
> 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
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> > Sent: Tuesday, November 21, 2017 9:38 PM
> > To: Wang, Jian J 
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] [PATCH v7 0/2] Fix multiple entries of RT_CODE in memory
> map
> >
> > Jian,
> >
> > On 11/21/17 07:17, Jian J Wang wrote:
> >>> v7:
> >>>   Merge memory map after filtering paging attributes
> >>
> >> More than one entry of RT_CODE memory might cause boot problem for
> >> some old OSs. This patch will fix this issue to keep OS compatibility
> >> as much as possible.
> >>
> >> Jian J Wang (2):
> >>   MdeModulePkg/DxeCore: Filter out all paging capabilities
> >>   UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map
> >>
> >>  MdeModulePkg/Core/Dxe/DxeMain.h  | 18 ++
> >>  MdeModulePkg/Core/Dxe/Mem/Page.c | 21 +++
> >>  MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c |  1 -
> >>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 94 +--
> -
> >>  4 files changed, 112 insertions(+), 22 deletions(-)
> >>
> >
> > I don't have capacity to retest and re-review the series.
> >
> > Considering the following two options, I like none of them:
> >
> > (1) Version 7 is merged with my feedback tags from v6. I don't like this 
> > because
> I didn't review or test version 7.
> >
> > (2) Version 7 is merged without my feedback tags. I don't like this because 
> > I've
> put a lot of BZ writeup, and patch review and testing effort for this series, 
> and
> I'd like the commit log to reflect that.
> >
> >
> > Instead, I would like to request the following, for v8:
> >
> > Please submit a series that consists of three patches:
> >
> > - patch v8 1/3: identical to v6 1/2, except for the code comment update,
> > - patch v8 2/3: identical to v6 2/2,
> > - patch v8 3/3: please implement the merging of the memory map as a
> separate patch.
> >
> > Patches v8 1/3 and 2/3 should include *both* my Tested-by *and* my
> Reviewed-by tags, from v6.
> >
> > Patch v8 3/3 should be reviewed / tested separately by others. I don't 
> > think I
> can find the capacity for that at the moment.
> >
> > This approach will correctly reflect all the work done thus far, and it will
> provide the desired result for the code as well.
> >
> > Thanks
> > Laszlo
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> >

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v7 0/2] Fix multiple entries of RT_CODE in memory map

[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 doesn't need a re-test in another email. But I 
understand
it if you insist re-test is necessary. Star and Jiewen have given a proposal, 
similar to yours
but putting the "merge" into a new patch instead of in this series. I think 
it's feasible. Let me
know your opinion.

Again, thanks for all your valuable comments and test efforts on this series 
and all others.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, November 21, 2017 9:38 PM
> To: Wang, Jian J 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH v7 0/2] Fix multiple entries of RT_CODE in memory
> map
> 
> Jian,
> 
> On 11/21/17 07:17, Jian J Wang wrote:
> >> v7:
> >>   Merge memory map after filtering paging attributes
> >
> > More than one entry of RT_CODE memory might cause boot problem for
> some
> > old OSs. This patch will fix this issue to keep OS compatibility as much
> > as possible.
> >
> > Jian J Wang (2):
> >   MdeModulePkg/DxeCore: Filter out all paging capabilities
> >   UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map
> >
> >  MdeModulePkg/Core/Dxe/DxeMain.h  | 18 ++
> >  MdeModulePkg/Core/Dxe/Mem/Page.c | 21 +++
> >  MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c |  1 -
> >  UefiCpuPkg/CpuDxe/CpuPageTable.c | 94 +
> ---
> >  4 files changed, 112 insertions(+), 22 deletions(-)
> >
> 
> I don't have capacity to retest and re-review the series.
> 
> Considering the following two options, I like none of them:
> 
> (1) Version 7 is merged with my feedback tags from v6. I don't like this
> because I didn't review or test version 7.
> 
> (2) Version 7 is merged without my feedback tags. I don't like this
> because I've put a lot of BZ writeup, and patch review and testing
> effort for this series, and I'd like the commit log to reflect that.
> 
> 
> Instead, I would like to request the following, for v8:
> 
> Please submit a series that consists of three patches:
> 
> - patch v8 1/3: identical to v6 1/2, except for the code comment update,
> - patch v8 2/3: identical to v6 2/2,
> - patch v8 3/3: please implement the merging of the memory map as a
> separate patch.
> 
> Patches v8 1/3 and 2/3 should include *both* my Tested-by *and* my
> Reviewed-by tags, from v6.
> 
> Patch v8 3/3 should be reviewed / tested separately by others. I don't
> think I can find the capacity for that at the moment.
> 
> This approach will correctly reflect all the work done thus far, and it
> will provide the desired result for the code as well.
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v7 0/2] Fix multiple entries of RT_CODE in memory map

[Laszlo Ersek]

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
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
> Ersek
> Sent: Tuesday, November 21, 2017 9:38 PM
> To: Wang, Jian J 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH v7 0/2] Fix multiple entries of RT_CODE in memory 
> map
> 
> Jian,
> 
> On 11/21/17 07:17, Jian J Wang wrote:
>>> v7:
>>>   Merge memory map after filtering paging attributes
>>
>> More than one entry of RT_CODE memory might cause boot problem for 
>> some old OSs. This patch will fix this issue to keep OS compatibility 
>> as much as possible.
>>
>> Jian J Wang (2):
>>   MdeModulePkg/DxeCore: Filter out all paging capabilities
>>   UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map
>>
>>  MdeModulePkg/Core/Dxe/DxeMain.h  | 18 ++
>>  MdeModulePkg/Core/Dxe/Mem/Page.c | 21 +++
>>  MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c |  1 -
>>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 94 
>> +---
>>  4 files changed, 112 insertions(+), 22 deletions(-)
>>
> 
> I don't have capacity to retest and re-review the series.
> 
> Considering the following two options, I like none of them:
> 
> (1) Version 7 is merged with my feedback tags from v6. I don't like this 
> because I didn't review or test version 7.
> 
> (2) Version 7 is merged without my feedback tags. I don't like this because 
> I've put a lot of BZ writeup, and patch review and testing effort for this 
> series, and I'd like the commit log to reflect that.
> 
> 
> Instead, I would like to request the following, for v8:
> 
> Please submit a series that consists of three patches:
> 
> - patch v8 1/3: identical to v6 1/2, except for the code comment update,
> - patch v8 2/3: identical to v6 2/2,
> - patch v8 3/3: please implement the merging of the memory map as a separate 
> patch.
> 
> Patches v8 1/3 and 2/3 should include *both* my Tested-by *and* my 
> Reviewed-by tags, from v6.
> 
> Patch v8 3/3 should be reviewed / tested separately by others. I don't think 
> I can find the capacity for that at the moment.
> 
> This approach will correctly reflect all the work done thus far, and it will 
> provide the desired result for the code as well.
> 
> Thanks
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Jian J Wang]

> 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
>   phase of DXE core.
>d. Remove the filter code used to exclude boot modes which doesn't support
>   memory allocation because those memory can passed in by parameter now.
>e. Remove the nasm macro to define exception handler one by one and add a
>   function to return the start address of each handler.

If Stack Guard is enabled and there's really a stack overflow happened during
boot, a Page Fault exception will be triggered. Because the stack is out of
usage, the exception handler, which shares the stack with normal UEFI driver,
cannot be executed and cannot dump the processor information.

Without those information, it's very difficult for the BIOS developers locate
the root cause of stack overflow. And without a workable stack, the developer
cannot event use single step to debug the UEFI driver with JTAG debugger.

In order to make sure the exception handler to execute normally after stack
overflow. We need separate stacks for exception handlers in case of unusable
stack.

IA processor allows to switch to a new stack during handling interrupt and
exception. But X64 and IA32 provides different ways to make it. X64 provides
interrupt stack table (IST) to allow maximum 7 different exceptions to have
new stack for its handler. IA32 doesn't have IST mechanism and can only use
task gate to do it since task switch allows to load a new stack through its
task-state segment (TSS).

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  50 +++
 .../DxeCpuExceptionHandlerLib.inf  |   6 +
 .../Library/CpuExceptionHandlerLib/DxeException.c  |  53 ++-
 .../Ia32/ArchExceptionHandler.c| 167 +
 .../Ia32/ArchInterruptDefs.h   |   8 +
 .../Ia32/ExceptionTssEntryAsm.nasm | 398 +
 .../PeiCpuExceptionHandlerLib.inf  |   1 +
 .../SecPeiCpuExceptionHandlerLib.inf   |   1 +
 .../SmmCpuExceptionHandlerLib.inf  |   1 +
 .../X64/ArchExceptionHandler.c | 133 +++
 .../CpuExceptionHandlerLib/X64/ArchInterruptDefs.h |   3 +
 11 files changed, 820 insertions(+), 1 deletion(-)
 create mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionTssEntryAsm.nasm

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
index 740a58828b..30334105d2 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
@@ -48,6 +48,32 @@
 0xb21d9148, 0x9211, 0x4d8f, { 0xad, 0xd3, 0x66, 0xb1, 0x89, 0xc9, 0x2c, 
0x83 } \
   }
 
+#define CPU_STACK_SWITCH_EXCEPTION_NUMBER \
+  FixedPcdGetSize (PcdCpuStackSwitchExceptionList)
+
+#define CPU_STACK_SWITCH_EXCEPTION_LIST \
+  FixedPcdGetPtr (PcdCpuStackSwitchExceptionList)
+
+#define CPU_KNOWN_GOOD_STACK_SIZE \
+  FixedPcdGet32 (PcdCpuKnownGoodStackSize)
+
+#define CPU_TSS_GDT_SIZE (SIZE_2KB + CPU_TSS_DESC_SIZE + CPU_TSS_SIZE)
+
+#define IA32_GDT_TYPE_TSS   0x9
+#define IA32_GDT_ALIGNMENT  8
+
+typedef struct {
+  UINTN StackTop;
+  UINTN StackSize;
+  UINT8 *Exceptions;
+  UINTN ExceptionNumber;
+  IA32_IDT_GATE_DESCRIPTOR  *IdtTable;
+  IA32_SEGMENT_DESCRIPTOR   *GdtTable;
+  UINTN GdtSize;
+  IA32_TSS_DESCRIPTOR   *TssDesc;
+  IA32_TASK_STATE_SEGMENT   *Tss;
+} EXCEPTION_STACK_SWITCH_DATA;
+
 //
 // Record exception handler information
 //
@@ -288,5 +314,29 @@ CommonExceptionHandlerWorker (
   IN EXCEPTION_HANDLER_DATA  *ExceptionHandlerData
   );
 
+/**
+  Setup separate stack for specific exceptions.
+
+  @param[in] IdtTableIDT table base.
+**/
+EFI_STATUS
+EFIAPI
+ArchSetupExcpetionStack (
+  IN EXCEPTION_STACK_SWITCH_DATA  *StackSwitchData
+  );
+
+/**
+  Return address map of exception handler template so that C code can generate
+  exception tables. The template is only for exceptions using task gate instead
+  of interrupt gate.
+
+  @param AddressMap  Pointer to a buffer where the address map is returned.
+**/
+VOID
+EFIAPI
+AsmGetTssTemplateMap (
+  OUT EXCEPTION_HANDLER_TEMPLATE_MAP  *AddressMap
+  );
+
 #endif
 
diff --git 

[edk2] [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for MP

[Jian J Wang]

> 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 own configuration. This patch adds code to ask BSP and AP
to do exception handler initialization separately.

Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 UefiCpuPkg/CpuDxe/CpuDxe.inf |   3 +
 UefiCpuPkg/CpuDxe/CpuMp.c| 168 +++
 UefiCpuPkg/CpuDxe/CpuMp.h|  12 
 3 files changed, 183 insertions(+)

diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.inf b/UefiCpuPkg/CpuDxe/CpuDxe.inf
index 3e8d196739..02f86b774c 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.inf
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.inf
@@ -81,6 +81,9 @@
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard   ## 
CONSUMES
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuStackSwitchExceptionList  ## 
CONSUMES
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuKnownGoodStackSize## 
CONSUMES
 
 [Depex]
   TRUE
diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
index b3c0178d07..6b2ceacb39 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -601,6 +601,169 @@ CollectBistDataFromHob (
   }
 }
 
+/**
+  Get GDT register content.
+
+  This function is mainly for AP purpose because AP may have different GDT
+  table than BSP.
+
+**/
+VOID
+EFIAPI
+GetGdtr (
+  IN OUT VOID *Buffer
+  )
+{
+  AsmReadGdtr ((IA32_DESCRIPTOR *)Buffer);
+}
+
+/**
+  Initializes CPU exceptions handlers for the sake of stack switch requirement.
+
+  This function is a wrapper of InitializeCpuExceptionStackSwitchHandlers.
+  It's mainly for AP purpose because of EFI_AP_PROCEDURE API requirement.
+
+**/
+VOID
+EFIAPI
+InitializeExceptionStackSwitchHandlers (
+  IN OUT VOID *Buffer
+  )
+{
+  EXCEPTION_STACK_SWITCH_DATA *EssData;
+  IA32_DESCRIPTOR Idtr;
+  EFI_STATUS  Status;
+
+  EssData = Buffer;
+  //
+  // We don't plan to replace IDT table with a new one, and we don't assume
+  // the AP's IDT is the same as BSP's IDT either.
+  //
+  AsmReadIdtr ();
+  EssData->IdtTable = (IA32_IDT_GATE_DESCRIPTOR *)Idtr.Base;
+  Status = InitializeCpuExceptionStackSwitchHandlers (EssData);
+  ASSERT_EFI_ERROR (Status);
+}
+
+/**
+  Initializes MP exceptions handlers for the sake of stack switch requirement.
+
+  This function will allocate required resources for stack switch and pass
+  them through EXCEPTION_STACK_SWITCH_DATA to each logic processor.
+
+**/
+VOID
+InitializeMpExceptionStackSwitchHandlers (
+  VOID
+  )
+{
+  UINTN   Index;
+  UINTN   Bsp;
+  UINTN   ExceptionNumber;
+  UINTN   NewGdtSize;
+  UINTN   NewStackSize;
+  IA32_DESCRIPTOR Gdtr;
+  EXCEPTION_STACK_SWITCH_DATA EssData;
+  UINT8   *GdtBuffer;
+  UINT8   *StackTop;
+
+  if (!PcdGetBool (PcdCpuStackGuard)) {
+return;
+  }
+
+  ExceptionNumber = FixedPcdGetSize (PcdCpuStackSwitchExceptionList);
+  NewStackSize = FixedPcdGet32 (PcdCpuKnownGoodStackSize) * ExceptionNumber;
+
+  StackTop = AllocateRuntimeZeroPool (NewStackSize * mNumberOfProcessors);
+  ASSERT (StackTop != NULL);
+  StackTop += NewStackSize  * mNumberOfProcessors;
+
+  EssData.Exceptions = FixedPcdGetPtr (PcdCpuStackSwitchExceptionList);
+  EssData.ExceptionNumber = ExceptionNumber;
+  EssData.StackSize = FixedPcdGet32 (PcdCpuKnownGoodStackSize);
+
+  MpInitLibWhoAmI ();
+  for (Index = 0; Index < mNumberOfProcessors; ++Index) {
+//
+// To support stack switch, we need to re-construct GDT but not IDT.
+//
+if (Index == Bsp) {
+  GetGdtr ();
+} else {
+  //
+  // AP might have different size of GDT from BSP.
+  //
+  MpInitLibStartupThisAP (GetGdtr, Index, NULL, 0, (VOID *), NULL);
+}
+
+//
+// X64 needs only one TSS of current task working for all exceptions
+// because of its IST feature. IA32 needs one TSS for each exception
+// in addition to current task. Since AP is not supposed to allocate
+// memory, we have to do it in BSP. To simplify the code, we allocate
+// memory for IA32 case to cover both IA32 and X64 exception stack
+// switch.
+//
+// Layout of memory to allocate for each processor:
+//
+//|Alignment |  (just in case)
+  

[edk2] [PATCH v2 3/8] MdePkg/BaseLib: Add stack switch related definitions for IA32

[Jian J Wang]

> 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 stack switch.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Jiewen Yao 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdePkg/Include/Library/BaseLib.h | 115 +++
 MdePkg/Library/BaseLib/BaseLib.inf   |   3 +
 MdePkg/Library/BaseLib/Ia32/WriteTr.nasm |  36 ++
 MdePkg/Library/BaseLib/X64/WriteTr.nasm  |  37 ++
 4 files changed, 191 insertions(+)
 create mode 100644 MdePkg/Library/BaseLib/Ia32/WriteTr.nasm
 create mode 100644 MdePkg/Library/BaseLib/X64/WriteTr.nasm

diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index d33c3b6b38..371109ad8f 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -6663,6 +6663,70 @@ typedef union {
   UINT64  Uint64;
 } IA32_IDT_GATE_DESCRIPTOR;
 
+#pragma pack (1)
+//
+// IA32 Task-State Segment Definition
+//
+typedef struct {
+  UINT16PreviousTaskLink;
+  UINT16Reserved_2;
+  UINT32ESP0;
+  UINT16SS0;
+  UINT16Reserved_10;
+  UINT32ESP1;
+  UINT16SS1;
+  UINT16Reserved_18;
+  UINT32ESP2;
+  UINT16SS2;
+  UINT16Reserved_26;
+  UINT32CR3;
+  UINT32EIP;
+  UINT32EFLAGS;
+  UINT32EAX;
+  UINT32ECX;
+  UINT32EDX;
+  UINT32EBX;
+  UINT32ESP;
+  UINT32EBP;
+  UINT32ESI;
+  UINT32EDI;
+  UINT16ES;
+  UINT16Reserved_74;
+  UINT16CS;
+  UINT16Reserved_78;
+  UINT16SS;
+  UINT16Reserved_82;
+  UINT16DS;
+  UINT16Reserved_86;
+  UINT16FS;
+  UINT16Reserved_90;
+  UINT16GS;
+  UINT16Reserved_94;
+  UINT16LDTSegmentSelector;
+  UINT16Reserved_98;
+  UINT16T;
+  UINT16IOMapBaseAddress;
+} IA32_TASK_STATE_SEGMENT;
+
+typedef union {
+  struct {
+UINT32  LimitLow:16;///< Segment Limit 15..00
+UINT32  BaseLow:16; ///< Base Address  15..00
+UINT32  BaseMid:8;  ///< Base Address  23..16
+UINT32  Type:4; ///< Type (1 0 B 1)
+UINT32  Reserved_43:1;  ///< 0
+UINT32  DPL:2;  ///< Descriptor Privilege Level
+UINT32  P:1;///< Segment Present
+UINT32  LimitHigh:4;///< Segment Limit 19..16
+UINT32  AVL:1;  ///< Available for use by system software
+UINT32  Reserved_52:2;  ///< 0 0
+UINT32  G:1;///< Granularity
+UINT32  BaseHigh:8; ///< Base Address 31..24
+  } Bits;
+  UINT64  Uint64;
+} IA32_TSS_DESCRIPTOR;
+#pragma pack ()
+
 #endif
 
 #if defined (MDE_CPU_X64)
@@ -6685,6 +6749,46 @@ typedef union {
   } Uint128;   
 } IA32_IDT_GATE_DESCRIPTOR;
 
+#pragma pack (1)
+//
+// IA32 Task-State Segment Definition
+//
+typedef struct {
+  UINT32Reserved_0;
+  UINT64RSP0;
+  UINT64RSP1;
+  UINT64RSP2;
+  UINT64Reserved_28;
+  UINT64IST[7];
+  UINT64Reserved_92;
+  UINT16Reserved_100;
+  UINT16IOMapBaseAddress;
+} IA32_TASK_STATE_SEGMENT;
+
+typedef union {
+  struct {
+UINT32  LimitLow:16;///< Segment Limit 15..00
+UINT32  BaseLow:16; ///< Base Address  15..00
+UINT32  BaseMidl:8; ///< Base Address  23..16
+UINT32  Type:4; ///< Type (1 0 B 1)
+UINT32  Reserved_43:1;  ///< 0
+UINT32  DPL:2;  ///< Descriptor Privilege Level
+UINT32  P:1;///< Segment Present
+UINT32  LimitHigh:4;///< Segment Limit 19..16
+UINT32  AVL:1;  ///< Available for use by system software
+UINT32  Reserved_52:2;  ///< 0 0
+UINT32  G:1;///< Granularity
+UINT32  BaseMidh:8; ///< Base Address  31..24
+UINT32  BaseHigh:32;///< Base Address  63..32
+UINT32  Reserved_96:32; ///< Reserved
+  } Bits;
+  struct {
+UINT64  Uint64;
+UINT64  Uint64_1;
+  } Uint128;
+} IA32_TSS_DESCRIPTOR;
+#pragma pack ()
+
 #endif
 
 ///
@@ -8950,6 +9054,17 @@ AsmRdRand64  (
   OUT UINT64*Rand
   );
 
+/**
+  Load given selector into TR register
+
+  @param[in] Selector Task segment selector
+**/
+VOID
+EFIAPI
+AsmWriteTr (
+  IN UINT16 Selector
+  );
+
 #endif
 #endif
 
diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
b/MdePkg/Library/BaseLib/BaseLib.inf
index 320ac457ea..fbfb0063b7 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -67,6 +67,8 @@
   BaseLibInternals.h
 
 [Sources.Ia32]
+  Ia32/WriteTr.nasm
+
   Ia32/Wbinvd.c | MSFT 
   Ia32/WriteMm7.c | MSFT 
   Ia32/WriteMm6.c | MSFT 
@@ -447,6 +449,7 @@
   X64/EnableCache.asm
   X64/DisableCache.nasm
   

[edk2] [PATCH v2 6/8] UefiCpuPkg/MpLib: Add GDTR, IDTR and TR in saved AP data

[Jian J Wang]

> 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 into structure CPU_VOLATILE_REGISTERS and save/restore methods. This will
make sure that any changes to GDT, IDT and task gate for an AP will be kept
from overwritten by BSP settings.

Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Jiewen Yao 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 UefiCpuPkg/Library/MpInitLib/MpLib.c | 17 +
 UefiCpuPkg/Library/MpInitLib/MpLib.h |  3 +++
 2 files changed, 20 insertions(+)

diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
b/UefiCpuPkg/Library/MpInitLib/MpLib.c
index 61b14c9843..0c2058a7b0 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -195,6 +195,10 @@ SaveVolatileRegisters (
 VolatileRegisters->Dr6 = AsmReadDr6 ();
 VolatileRegisters->Dr7 = AsmReadDr7 ();
   }
+
+  AsmReadGdtr (>Gdtr);
+  AsmReadIdtr (>Idtr);
+  VolatileRegisters->Tr = AsmReadTr ();
 }
 
 /**
@@ -211,6 +215,7 @@ RestoreVolatileRegisters (
   )
 {
   CPUID_VERSION_INFO_EDXVersionInfoEdx;
+  IA32_TSS_DESCRIPTOR   *Tss;
 
   AsmWriteCr0 (VolatileRegisters->Cr0);
   AsmWriteCr3 (VolatileRegisters->Cr3);
@@ -231,6 +236,18 @@ RestoreVolatileRegisters (
   AsmWriteDr7 (VolatileRegisters->Dr7);
 }
   }
+
+  AsmWriteGdtr (>Gdtr);
+  AsmWriteIdtr (>Idtr);
+  if (VolatileRegisters->Tr != 0 &&
+  VolatileRegisters->Tr < VolatileRegisters->Gdtr.Limit) {
+Tss = (IA32_TSS_DESCRIPTOR *)(VolatileRegisters->Gdtr.Base +
+  VolatileRegisters->Tr);
+if (Tss->Bits.P == 1) {
+  Tss->Bits.Type &= 0xD;  // 1101 - Clear busy bit just in case
+  AsmWriteTr (VolatileRegisters->Tr);
+}
+  }
 }
 
 /**
diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h 
b/UefiCpuPkg/Library/MpInitLib/MpLib.h
index d13d5c06f5..685e96cbac 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
@@ -102,6 +102,9 @@ typedef struct {
   UINTN  Dr3;
   UINTN  Dr6;
   UINTN  Dr7;
+  IA32_DESCRIPTORGdtr;
+  IA32_DESCRIPTORIdtr;
+  UINT16 Tr;
 } CPU_VOLATILE_REGISTERS;
 
 //
-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 0/8] Implement stack guard feature

[Jian J Wang]

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 stack size.

If this feature is enabled, DxeIpl will setup page tables and set page where
the stack bottom is at to be NON-PRESENT. If stack overflow occurs, Page
Fault exception will be triggered.

In order to make sure exception handler works normally even when the stack
is corrupted, stack switching is implemented in exception library.

Due to the mechanism behind Stack Guard, this feature is only avaiable for
UEFI drivers (memory avaiable). That also means it doesn't support NT32 
emulated platform (paging not supported).

Validation works include:
  a. OVMF emulated platform: boot to shell (IA32/X64)
  b. Intel real platform: boot to shell (IA32/X64)

Jian J Wang (8):
  MdeModulePkg/metafile: Add PCD PcdCpuStackGuard
  MdeModulePkg/CpuExceptionHandlerLib.h: Add a new API
  MdePkg/BaseLib: Add stack switch related definitions for IA32
  MdeModulePkg/DxeIpl: Enable paging for Stack Guard
  UefiCpuPkg/UefiCpuPkg.dec: Add two new PCDs for stack switch
  UefiCpuPkg/MpLib: Add GDTR, IDTR and TR in saved AP data
  UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support
  UefiCpuPkg/CpuDxe: Initialize stack switch for MP

 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   5 +-
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c|   4 +
 MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c |   1 +
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c   |  51 ++-
 .../Include/Library/CpuExceptionHandlerLib.h   |  18 +
 MdeModulePkg/MdeModulePkg.dec  |   7 +
 MdeModulePkg/MdeModulePkg.uni  |   7 +
 MdePkg/Include/Library/BaseLib.h   | 115 ++
 MdePkg/Library/BaseLib/BaseLib.inf |   3 +
 MdePkg/Library/BaseLib/Ia32/WriteTr.nasm   |  36 ++
 MdePkg/Library/BaseLib/X64/WriteTr.nasm|  37 ++
 UefiCpuPkg/CpuDxe/CpuDxe.inf   |   3 +
 UefiCpuPkg/CpuDxe/CpuMp.c  | 168 +
 UefiCpuPkg/CpuDxe/CpuMp.h  |  12 +
 .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  50 +++
 .../DxeCpuExceptionHandlerLib.inf  |   6 +
 .../Library/CpuExceptionHandlerLib/DxeException.c  |  53 ++-
 .../Ia32/ArchExceptionHandler.c| 167 +
 .../Ia32/ArchInterruptDefs.h   |   8 +
 .../Ia32/ExceptionTssEntryAsm.nasm | 398 +
 .../PeiCpuExceptionHandlerLib.inf  |   1 +
 .../SecPeiCpuExceptionHandlerLib.inf   |   1 +
 .../SmmCpuExceptionHandlerLib.inf  |   1 +
 .../X64/ArchExceptionHandler.c | 133 +++
 .../CpuExceptionHandlerLib/X64/ArchInterruptDefs.h |   3 +
 UefiCpuPkg/Library/MpInitLib/MpLib.c   |  17 +
 UefiCpuPkg/Library/MpInitLib/MpLib.h   |   3 +
 UefiCpuPkg/UefiCpuPkg.dec  |  12 +
 28 files changed, 1304 insertions(+), 16 deletions(-)
 create mode 100644 MdePkg/Library/BaseLib/Ia32/WriteTr.nasm
 create mode 100644 MdePkg/Library/BaseLib/X64/WriteTr.nasm
 create mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionTssEntryAsm.nasm

-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 1/8] MdeModulePkg/metafile: Add PCD PcdCpuStackGuard

[Jian J Wang]

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
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/MdeModulePkg.dec | 7 +++
 MdeModulePkg/MdeModulePkg.uni | 7 +++
 2 files changed, 14 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 856d67aceb..b3831a21ad 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -949,6 +949,13 @@
   # @Prompt The Heap Guard feature mask
   gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask|0x0|UINT8|0x30001054
 
+  ## Indicates if UEFI Stack Guard will be enabled.
+  #  If enabled, stack overflow in UEFI can be caught, preventing chaotic 
consequences.
+  #   TRUE  - UEFI Stack Guard will be enabled.
+  #   FALSE - UEFI Stack Guard will be disabled.
+  # @Prompt Enable UEFI Stack Guard.
+  gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard|FALSE|BOOLEAN|0x30001055
+
 [PcdsFixedAtBuild, PcdsPatchableInModule]
   ## Dynamic type PCD can be registered callback function for Pcd setting 
action.
   #  PcdMaxPeiPcdCallBackNumberPerPcdEntry indicates the maximum number of 
callback function
diff --git a/MdeModulePkg/MdeModulePkg.uni b/MdeModulePkg/MdeModulePkg.uni
index 588905a9a1..43dd5103be 100644
--- a/MdeModulePkg/MdeModulePkg.uni
+++ b/MdeModulePkg/MdeModulePkg.uni
@@ -1204,3 +1204,10 @@

 "  0 - The returned pool is adjacent to the bottom guard 
page.\n"

 "  1 - The returned pool is adjacent to the top guard 
page."
 
+#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdCpuStackGuard_PROMPT  #language 
en-US "Enable UEFI Stack Guard"
+
+#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdCpuStackGuard_HELP#language 
en-US "Indicates if UEFI Stack Guard will be enabled.\n"
+   
 "  If enabled, stack overflow in UEFI can be caught, preventing chaotic 
consequences.\n"
+   
 "   TRUE  - UEFI Stack Guard will be enabled.\n"
+   
 "   FALSE - UEFI Stack Guard will be disabled."
+
-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h: Add a new API

[Jian J Wang]

> 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 resources reserved in
advance. This is necessary because the CpuExceptionHandlerLib will be linked
in different phases, in which there's no common way to reserve resources.

EFI_STATUS
EFIAPI
InitializeCpuExceptionStackSwitchHandlers (
  IN VOID   *StackSwitchData  OPTIONAL
  );

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Jiewen Yao 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h 
b/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
index 6cd8230127..68de4850e1 100644
--- a/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
+++ b/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
@@ -41,6 +41,24 @@ InitializeCpuExceptionHandlers (
   IN EFI_VECTOR_HANDOFF_INFO   *VectorInfo OPTIONAL
   );
 
+/**
+  Setup separate stack for given exceptions. StackSwitchData is optional and 
its
+  content depends one the specific arch of CPU.
+
+  @param[in] StackSwitchData  Pointer to data required for setuping up
+  stack switch.
+
+  @retval EFI_SUCCESS The exceptions have been successfully
+  initialized.
+  @retval EFI_INVALID_PARAMETER   StackSwitchData contains invalid content.
+
+**/
+EFI_STATUS
+EFIAPI
+InitializeCpuExceptionStackSwitchHandlers (
+  IN VOID   *StackSwitchData  OPTIONAL
+  );
+
 /**
   Initializes all CPU interrupt/exceptions entries and provides the default 
interrupt/exception handlers.
   
-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 5/8] UefiCpuPkg/UefiCpuPkg.dec: Add two new PCDs for stack switch

[Jian J Wang]

> 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
  gUefiCpuPkgTokenSpaceGuid.PcdCpuKnownGoodStackSize

PcdCpuStackSwitchExceptionList is used to specify which exception will
have separate stack for its handler. For Stack Guard feature, #PF must
be specified at least.

PcdCpuKnownGoodStackSize is used to specify the size of good stack for an
exception handler. Cpu driver or other drivers should use this PCD to reserve
stack memory for exceptions specified above PCD.

Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Jiewen Yao 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 UefiCpuPkg/UefiCpuPkg.dec | 12 
 1 file changed, 12 insertions(+)

diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index 3bd8740c98..b87e20fb38 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -144,6 +144,18 @@
   # @Prompt Lock SMM Feature Control MSR.
   
gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmFeatureControlMsrLock|TRUE|BOOLEAN|0x3213210B
 
+[PcdsFixedAtBuild]
+  ## List of exception vectors which need switching stack.
+  #  This PCD will only take into effect if PcdCpuStackGuard is enabled.
+  #  By default exception #DD(8), #PF(14) are supported.
+  # @Prompt Specify exception vectors which need switching stack.
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuStackSwitchExceptionList|{0x08, 
0x0E}|VOID*|0x30002000
+
+  ## Size of good stack for an exception.
+  #  This PCD will only take into effect if PcdCpuStackGuard is enabled.
+  # @Prompt Specify size of good stack of exception which need switching stack.
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuKnownGoodStackSize|2048|UINT32|0x30002001
+
 [PcdsFixedAtBuild, PcdsPatchableInModule]
   ## This value is the CPU Local APIC base address, which aligns the address 
on a 4-KByte boundary.
   # @Prompt Configure base address of CPU Local APIC
-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 4/8] MdeModulePkg/DxeIpl: Enable paging for Stack Guard

[Jian J Wang]

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 and memory access cross into the last page
of it, #PF exception will be triggered.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Jiewen Yao 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |  5 ++-
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  |  4 ++
 MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c   |  1 +
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 51 ++--
 4 files changed, 46 insertions(+), 15 deletions(-)

diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf 
b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
index a1b8748432..ba1d9c6b05 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
@@ -49,7 +49,7 @@
 [Sources.X64]
   X64/VirtualMemory.h
   X64/VirtualMemory.c
-  X64/DxeLoadFunc.c
+  X64/DxeLoadFunc.c
 
 [Sources.IPF]
   Ipf/DxeLoadFunc.c
@@ -117,6 +117,7 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask   ## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard   ## 
CONSUMES
 
 [Pcd.IA32,Pcd.X64,Pcd.ARM,Pcd.AARCH64]
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack   ## 
SOMETIMES_CONSUMES
@@ -132,7 +133,7 @@
 #
 # [Hob]
 # MEMORY_ALLOCATION ## SOMETIMES_PRODUCES # 
MEMORY_ALLOCATION_MODULE for DxeCore
-# MEMORY_ALLOCATION ## SOMETIMES_PRODUCES # New Stack HoB   
+# MEMORY_ALLOCATION ## SOMETIMES_PRODUCES # New Stack HoB
 # MEMORY_ALLOCATION ## SOMETIMES_PRODUCES # Old Stack HOB
 #
 # [Hob.IPF]
diff --git a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c 
b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
index 5649265367..441096ad0f 100644
--- a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
+++ b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
@@ -235,6 +235,10 @@ ToBuildPageTable (
 return TRUE;
   }
 
+  if (PcdGetBool (PcdCpuStackGuard)) {
+return TRUE;
+  }
+
   if (PcdGetBool (PcdSetNxForStack) && IsExecuteDisableBitAvailable ()) {
 return TRUE;
   }
diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c 
b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
index f613221b81..b75a4489bf 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
@@ -95,6 +95,7 @@ HandOffToDxeCore (
 // for the DxeIpl and the DxeCore are both X64.
 //
 ASSERT (PcdGetBool (PcdSetNxForStack) == FALSE);
+ASSERT (PcdGetBool (PcdCpuStackGuard) == FALSE);
   }
   
   //
diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
index 29b6205e88..a2466b7766 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
@@ -117,6 +117,39 @@ EnableExecuteDisableBit (
   AsmWriteMsr64 (0xC080, MsrRegisters);
 }
 
+/**
+  The function will check if page table entry should be splitted to smaller
+  granularity.
+
+  @retval TRUE  Page table should be created.
+  @retval FALSE Page table should not be created.
+**/
+BOOLEAN
+ToSplitPageTable (
+  IN EFI_PHYSICAL_ADDRESS   Address,
+  IN UINTN  Size,
+  IN EFI_PHYSICAL_ADDRESS   StackBase,
+  IN UINTN  StackSize
+  )
+{
+  if (IsNullDetectionEnabled () && Address == 0) {
+return TRUE;
+  }
+
+  if (PcdGetBool (PcdCpuStackGuard)) {
+if (StackBase >= Address && StackBase < (Address + Size)) {
+  return TRUE;
+}
+  }
+
+  if (PcdGetBool (PcdSetNxForStack)) {
+if ((Address < StackBase + StackSize) && ((Address + Size) > StackBase)) {
+  return TRUE;
+}
+  }
+
+  return FALSE;
+}
 /**
   Split 2M page to 4K.
 
@@ -160,7 +193,8 @@ Split2MPageTo4K (
 PageTableEntry->Uint64 = (UINT64) PhysicalAddress4K | AddressEncMask;
 PageTableEntry->Bits.ReadWrite = 1;
 
-if (IsNullDetectionEnabled () && PhysicalAddress4K == 0) {
+if ((IsNullDetectionEnabled () && PhysicalAddress4K == 0) ||
+(PcdGetBool (PcdCpuStackGuard) && PhysicalAddress4K == StackBase)) {
   PageTableEntry->Bits.Present = 0;
 } else {
   PageTableEntry->Bits.Present = 1;
@@ -214,10 +248,7 @@ Split1GPageTo2M (
 
   PhysicalAddress2M = PhysicalAddress;
   for (IndexOfPageDirectoryEntries = 0; 

Re: [edk2] [PATCH 13/15] ArmVirtPkg: implement ArmVirtMemInfo PPI, PEIM and library

[Laszlo Ersek]

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 .c file between two infs in the same directory?
>> 
>> Hm, I think I missed the impact on ArmVirtQemuKernel. In the
>> current set, its DSC file is only modified in patch 12. (I missed
>> that too.) Are any changes necessary for ArmVirtQemuKernel that are
>> not contained in this set?
>> 
>> Either way, what you propose above seems to be the standard
>> approach to me: use two INF files, keep the bulk of the code in one
>> (shared) C file, and add the constructor to another (non-shared) C
>> file (i.e., referenced by only one of the INF files). Should the
>> constructor need shared utility functions from the shared C file,
>> add an internal header for those.
>> 
> 
> Would you object to having a single .c file, but only declare the 
> constructor in one of the two .INFs? The code will be pruned anyway, 
> due to our use of -ffunction-sections
> 

I would frown, but not object. :)

Please add a comment above the constructor function about the non-shared
use.

Thanks,
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] SCT Test crashes After HTTPS boot success.

[Wu, Jiaxin]

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 and
EFI_TLS_CONFIGURATION_PROTOCOL are required.

So, the SCT will check the EFI_TLS_SERVICE_BINDING_PROTOCOL, EFI_TLS_PROTOCOL 
and EFI_TLS_CONFIGURATION_PROTOCOL, but it didn't find the EFI_TLS_PROTOCOL and 
EFI_TLS_CONFIGURATION_PROTOCOL because no available TLS instance is created by 
default since it's no driver dependency. Even you tried the HTTPS, the TLS 
instance will be destroyed after finishing the HTTPS boot process, that's the 
reason why it still fail after HTTPS boot.
  Status = gtBS->LocateProtocol (
   ,
   NULL,
   (VOID **) 
   );
  if (!EFI_ERROR (Status)) {
ValueB = TRUE;
  } else {
ValueB = FALSE;
  }

After talk with SCT expert (Jin, Eric ) , we agree the Spec 
may need to be updated since it can mislead the caller.

Thanks,
Jiaxin


From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Tuesday, November 21, 2017 7:55 PM
To: Wu, Jiaxin ; 'edk2-devel@lists.01.org' 

Cc: Fu, Siyuan ; Ye, Ting 
Subject: RE: SCT Test crashes After HTTPS boot success.


Hi Jiaxin,

I've done SCT Test After HTTPS Boot success(Release Mode), I'm facing the below 
failures


1.   GenericTest\EFICompliantTest - EFI Compliant - PXE_BC protocols and 
one of UNDI/SNP/MNP must be implemented if a platform supports to boot from a 
network device.

2.   GenericTest\EFICompliantTest - UEFI-Compliant - 
EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL must be implemented if a platform includes 
an NVM Express controller.

3.   GenericTest\EFICompliantTest - UEFI-Compliant - EFI_BLOCK_IO_PROTOCOL 
must be existed if the platform supports booting from a block-oriented NVM 
Express controller. EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL may be required.

4.   GenericTest\EFICompliantTest - EFI Compliant - SCSI_PASS_THRU protocol 
must be implemented if a platform includes an I/O system that uses SCSI command 
packets.

5.   GenericTest\EFICompliantTest - UEFI-Compliant EFI_SCSI IO_PROTOCOL, 
EFI_Block IO_PROTOCOL and EFI_EXT_SCSI_PASS_THRU_PROTOCOL must be implemented 
if a platform supports booting from a SCSI peripheral device.

6.   GenericTest\EFICompliantTest - EFI Compliant - DEBUG_SUPPORT and 
DEBUG_PORT protocols must be implemented if a platform supports debugging 
capabilities.

7.   GenericTest\EFICompliantTest - UEFI-Compliant - 
EFI_ATA_PASS_THRU_PROTOCOL must be implemented if a platform includes an I/O 
subsystem that utilizes ATA command packets.

8.   GenericTest\EFICompliantTest - UEFI-Compliant - EFI_TLS_PROTOCOL, 
EFI_TLS_SERVICE_BINDING_PROTOCOL, EFI_TLS_CONFIGURATION_PROTOCOL must be 
existed if the platform supports TLS feature.

9.   GenericTest\EFICompliantTest - UEFI-Compliant - EFI_EAP_PROTOCOL, 
EFI_EAP_CONFIGURATION_PROTOCOL, EFI_EAP_MANAGEMENT2_PROTOCOL must be existed if 
the platform includes the ability to perform a wireless boot from a network 
device with EAP feature, and if this platform provides

10.   GenericTest\EFICompliantTest - UEFI-Compliant - 
EFI_BLUETOOTH_HC_PROTOCOL, EFI_BLUETOOTH_IO_PROTOCOL, 
EFI_BLUETOOTH_CONFIG_PROTOCOL must be existed if the platform supports classic 
Bluetooth.

I've attached the Test Report for reference.
Could you please provide your comments/suggestions on the failures?

Thanks,
Karunakar

From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Friday, November 17, 2017 12:05 PM
To: Karunakar P; 'edk2-devel@lists.01.org'
Cc: Fu, Siyuan; Ye, Ting
Subject: RE: SCT Test crashes After HTTPS boot success.

I will try to reproduce the issue with EDK2 trunk code, then feedback to you. 
Thanks the report.

Jiaxin

From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Friday, November 17, 2017 2:32 PM
To: Wu, Jiaxin >; 
'edk2-devel@lists.01.org' 
>
Cc: Fu, Siyuan >; Ye, Ting 
>
Subject: RE: SCT Test crashes After HTTPS boot success.

Hi Jiaxin,

Below are the detailed steps for SCT test

[Steps to reproduce]
.
  5. Run SCT test

a.  Execute the following commands to run SCT test on SUT
 sct -r

  sct -u
   b.  In Test Case Management page, Enable GenericTest
   c.  Press F9 to run the selected test case

[Observation]
synchronous exception occurred in SCT ,Attached the Log for reference.

Thanks,
Karunakar

From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Friday, November 17, 2017 6:01 AM
To: Karunakar P; 'edk2-devel@lists.01.org'
Cc: Fu, Siyuan; Ye, Ting

Re: [edk2] [PATCH 1/2] MdeModulePkg/PciBus: Revert "disable all BME when entering RT"

[Yao, Jiewen]

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
> Sent: Wednesday, November 22, 2017 4:15 PM
> To: Ni, Ruiyu ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Michael Turner
> 
> Subject: Re: [edk2] [PATCH 1/2] MdeModulePkg/PciBus: Revert "disable all BME
> when entering RT"
> 
> 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, Jiewen 
> > Subject: [PATCH 1/2] MdeModulePkg/PciBus: Revert "disable all BME when
> > entering RT"
> >
> > This reverts commit 050763db0730a0bb46235cec87e3716632dc532c.
> >   "MdeModulePkg/PciBus: Disable BME of all devices when entering RT"
> >
> > We met some compatibility issues when doing Windows S4 resume.
> > Reverting the BME disabling patches to fix the S4 resume issue.
> >
> > Signed-off-by: Ruiyu Ni 
> > Signed-off-by: Michael Turner 
> > Cc: Michael D Kinney 
> > Cc: Jiewen Yao 
> > ---
> >  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h   |  2 -
> >  MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf  |  3 -
> >  MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c | 86
> ---
> >  3 files changed, 91 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> > b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> > index 79b5b71082..55eb3a5a80 100644
> > --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> > +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
> > @@ -18,8 +18,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND,
> > EITHER EXPRESS OR IMPLIED.
> >
> >  #include 
> >
> > -#include 
> > -
> >  #include 
> >  #include 
> >  #include 
> > diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
> > b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
> > index d5b8fab3ca..97608bfcf2 100644
> > --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
> > +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
> > @@ -80,9 +80,6 @@ [LibraryClasses]
> >DebugLib
> >PeCoffLib
> >
> > -[Guids]
> > -  gEfiEventExitBootServicesGuid   ##
> > SOMETIMES_CONSUMES ## Event
> > -
> >  [Protocols]
> >gEfiPciHotPlugRequestProtocolGuid   ##
> > SOMETIMES_PRODUCES
> >gEfiPciIoProtocolGuid   ## BY_START
> > diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> > b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> > index 004f2a3b5b..97bb971a59 100644
> > --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> > +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> > @@ -20,72 +20,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> > KIND, EITHER EXPRESS OR IMPLIED.
> >  //
> >  LIST_ENTRY  mPciDevicePool;
> >
> > -/**
> > - Disable Bus Master Enable bit in all devices in the list.
> > -
> > - @param Devices  A device list.
> > -**/
> > -VOID
> > -DisableBmeOnTree (
> > -  IN LIST_ENTRY  *Devices
> > -  )
> > -{
> > -  LIST_ENTRY  *Link;
> > -  PCI_IO_DEVICE   *PciIoDevice;
> > -  UINT16   Command;
> > -
> > -  for ( Link = GetFirstNode (Devices)
> > -  ; !IsNull (Devices, Link)
> > -  ; Link = GetNextNode (Devices, Link)
> > -  ) {
> > -PciIoDevice = PCI_IO_DEVICE_FROM_LINK (Link);
> > -//
> > -// Turn off all children's Bus Master, if any
> > -//
> > -DisableBmeOnTree (>ChildList);
> > -
> > -//
> > -// If this is a device that supports BME, disable BME on this device.
> > -//
> > -if ((PciIoDevice->Supports & EFI_PCI_IO_ATTRIBUTE_BUS_MASTER) != 0)
> {
> > -  PCI_READ_COMMAND_REGISTER(PciIoDevice, );
> > -  if ((Command & EFI_PCI_COMMAND_BUS_MASTER) != 0) {
> > -Command &= ~EFI_PCI_COMMAND_BUS_MASTER;
> > -PCI_SET_COMMAND_REGISTER (PciIoDevice, Command);
> > -DEBUG ((
> > -  DEBUG_INFO,"  %02x   %02x  %02x %04x\n",
> > -  PciIoDevice->BusNumber, PciIoDevice->DeviceNumber,
> > PciIoDevice->FunctionNumber,
> > -  Command
> > -  ));
> > -  }
> > -}
> > -  }
> > -}
> > -
> > -/**
> > -  Exit Boot Services Event notification handler.
> > -
> > -  Disable Bus Master on any that were enabled during BDS.
> > -
> > -  @param[in]  Event Event whose notification function is being
> invoked.
> > -  @param[in]  Context   Pointer to the notification function's context.
> > -
> > -**/
> > -VOID
> > -EFIAPI
> > -OnExitBootServices (
> > -  IN  EFI_EVENT  

Re: [edk2] [PATCH 2/2] MdeModulePkg/PciBus: Revert "Enable BM on P2P bridges on demand"

[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, Jiewen 
> Subject: [PATCH 2/2] MdeModulePkg/PciBus: Revert "Enable BM on P2P bridges
> on demand"
> 
> This reverts commit 5db417ed2522367290c365831f9d6628d31c346c.
>  "MdeModulePkg/PciBusDxe: Enable Bus Master on P2P bridges on demand"
> 
> We met some compatibility issues when doing Windows S4 resume.
> Reverting the BME disabling patches to fix the S4 resume issue.
> 
> Signed-off-by: Ruiyu Ni 
> Signed-off-by: Michael Turner 
> Cc: Michael D Kinney 
> Cc: Jiewen Yao 
> ---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c | 16
> +++-
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c | 18
> +++---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c|  8 
>  3 files changed, 10 insertions(+), 32 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> index 97bb971a59..e76c8f0046 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> @@ -1,7 +1,7 @@
>  /** @file
>Supporting functions implementaion for PCI devices management.
> 
> -Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD
> License
>  which accompanies this distribution.  The full text of the license may be 
> found
> at
> @@ -711,12 +711,7 @@ StartPciDevicesOnBridge (
>   0,
>   
>   );
> -//
> -// By default every bridge's IO and MMIO spaces are enabled.
> -// Bridge's Bus Master will be enabled when any device behind it
> requests
> -// to enable Bus Master.
> -//
> -Supports &= (UINT64) (EFI_PCI_IO_ATTRIBUTE_IO |
> EFI_PCI_IO_ATTRIBUTE_MEMORY);
> +Supports &= (UINT64)EFI_PCI_DEVICE_ENABLE;
>  PciIoDevice->PciIo.Attributes (
>   &(PciIoDevice->PciIo),
>   EfiPciIoAttributeOperationEnable,
> @@ -768,12 +763,7 @@ StartPciDevicesOnBridge (
>   0,
>   
>   );
> -//
> -// By default every bridge's IO and MMIO spaces are enabled.
> -// Bridge's Bus Master will be enabled when any device behind it
> requests
> -// to enable Bus Master.
> -//
> -Supports &= (UINT64) (EFI_PCI_IO_ATTRIBUTE_IO |
> EFI_PCI_IO_ATTRIBUTE_MEMORY);
> +Supports &= (UINT64)EFI_PCI_DEVICE_ENABLE;
>  PciIoDevice->PciIo.Attributes (
>   &(PciIoDevice->PciIo),
>   EfiPciIoAttributeOperationEnable,
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> index f73756a31e..81171c82d9 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> @@ -1218,12 +1218,11 @@ DetermineDeviceAttribute (
>return Status;
>  }
>  //
> -// Assume the PCI Root Bridge supports DAC and Bus Master.
> +// Assume the PCI Root Bridge supports DAC
>  //
>  PciIoDevice->Supports |=
> (UINT64)(EFI_PCI_IO_ATTRIBUTE_EMBEDDED_DEVICE |
>EFI_PCI_IO_ATTRIBUTE_EMBEDDED_ROM |
> -
> EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE |
> -  EFI_PCI_IO_ATTRIBUTE_BUS_MASTER);
> +
> EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE);
> 
>} else {
> 
> @@ -1234,16 +1233,9 @@ DetermineDeviceAttribute (
>  //
>  Command = EFI_PCI_COMMAND_IO_SPACE |
>EFI_PCI_COMMAND_MEMORY_SPACE |
> +  EFI_PCI_COMMAND_BUS_MASTER   |
>EFI_PCI_COMMAND_VGA_PALETTE_SNOOP;
> 
> -//
> -// Per PCI-to-PCI Bridge Architecture all PCI-to-PCI bridges are Bus 
> Master
> capable.
> -// So only test the Bus Master capability for PCI devices.
> -//
> -if (!IS_PCI_BRIDGE(>Pci)) {
> -  Command |= EFI_PCI_COMMAND_BUS_MASTER;
> -}
> -
>  BridgeControl = EFI_PCI_BRIDGE_CONTROL_ISA |
> EFI_PCI_BRIDGE_CONTROL_VGA | EFI_PCI_BRIDGE_CONTROL_VGA_16;
> 
>  //
> @@ -1253,11 +1245,7 @@ DetermineDeviceAttribute (
> 
>  //
>  // Set the supported attributes for specified PCI device
> -// Per PCI-to-PCI Bridge Architecture all