Re: [edk2] [Patch 1/2] BaseTools VfrCompiler: In order to keep consistent, add an optional "; " for condition op-code.

2015-10-14 Thread Leif Lindholm
On Wed, Oct 14, 2015 at 04:29:27PM +0800, Eric Dong wrote:
> In current implementation, the "endif" opcode for suppressif has an end ";" 
> for the statement opcode, but not for the option opcode. This is not a user 
> friendly grammar. So this patch fixed this issue. Add an optional ";" end for 
> option opcode to keep consistent with existed code. The same case also 
> existed for grayoutif/disableif/inconsistentif/nosubmitif/warningif.

Can we have line breaks inserted in the commit message as appropriate
to conform with BaseTools/Contributions.txt?

Regards,

Leif

> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Eric Dong 
> ---
>  BaseTools/Source/C/VfrCompile/VfrSyntax.g | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/BaseTools/Source/C/VfrCompile/VfrSyntax.g 
> b/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> index ad839b2..d74fec8 100644
> --- a/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> +++ b/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> @@ -3256,39 +3256,39 @@ vfrStatementInconsistentIf :
><< CIfrInconsistentIf IIObj; >>
>L:InconsistentIf << 
> IIObj.SetLineNo(L->getLine()); >>
>Prompt "=" "STRING_TOKEN" "\(" S:Number "\)" "," << IIObj.SetError 
> (_STOSID(S->getText(), S->getLine())); >>
>{ FLAGS "=" flagsField ( "\|" flagsField )* "," }
>vfrStatementExpression[0]
> -  E:EndIf  << CRT_END_OP (E); >>
> +  E:EndIf {";"}<< CRT_END_OP (E); >>
>;
>  
>  vfrStatementNoSubmitIf :
><< CIfrNoSubmitIf NSIObj; >>
>L:NoSubmitIf << 
> NSIObj.SetLineNo(L->getLine()); >>
>Prompt "=" "STRING_TOKEN" "\(" S:Number "\)" "," << NSIObj.SetError 
> (_STOSID(S->getText(), S->getLine())); >>
>{ FLAGS "=" flagsField ( "\|" flagsField )* "," }
>vfrStatementExpression[0]
> -  E:EndIf  << CRT_END_OP (E); >>
> +  E:EndIf {";"}<< CRT_END_OP (E); >>
>;
>  
>  vfrStatementWarningIf :
><< CIfrWarningIf WIObj; >>
>L:WarningIf  << 
> WIObj.SetLineNo(L->getLine()); >>
>Prompt "=" "STRING_TOKEN" "\(" S:Number "\)" "," << WIObj.SetWarning 
> (_STOSID(S->getText(), S->getLine())); >>
>{Timeout "=" T:Number ","<< WIObj.SetTimeOut 
> (_STOU8(T->getText(), T->getLine())); >>}
>vfrStatementExpression[0]
> -  E:EndIf  << CRT_END_OP (E); >>
> +  E:EndIf {";"}<< CRT_END_OP (E); >>
>;
>  
>  vfrStatementDisableIfQuest :
><< 
>  CIfrDisableIf DIObj; 
>>>
>L:DisableIf  << 
> DIObj.SetLineNo(L->getLine()); >>
>vfrStatementExpression[0] ";"
>vfrStatementQuestionOptionList
> -  E:EndIf  << CRT_END_OP (E); >>
> +  E:EndIf {";"}<< CRT_END_OP (E); >>
>;
>  
>  vfrStatementRefresh :
><< CIfrRefresh RObj; >>
>L:Refresh<< 
> RObj.SetLineNo(L->getLine()); >>
> @@ -3314,20 +3314,20 @@ vfrStatementSuppressIfQuest :
><< CIfrSuppressIf SIObj; >>
>L:SuppressIf << 
> SIObj.SetLineNo(L->getLine()); >>
>{ FLAGS "=" flagsField ( "\|" flagsField )* "," }
>vfrStatementExpression[0] ";"
>vfrStatementQuestionOptionList
> -  E:EndIf  << CRT_END_OP (E); >>
> +  E:EndIf {";"}<< CRT_END_OP (E); >>
>;
>  
>  vfrStatementGrayOutIfQuest :
><< CIfrGrayOutIf GOIObj; >>
>L:GrayOutIf  << 
> GOIObj.SetLineNo(L->getLine()); >>
>{ FLAGS "=" flagsField ( "\|" flagsField )* "," }
>vfrStatementExpression[0] ";"
>vfrStatementQuestionOptionList
> -  E:EndIf  << CRT_END_OP (E); >>
> +  E:EndIf {";"}<< CRT_END_OP (E); >>
>;
>  
>  vfrStatementOptions :
>vfrStatementOneOfOption
>;
> -- 
> 1.9.5.msysgit.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] ShellPkg: Use safe string functions to refine Tftp.c code.

2015-10-14 Thread Carsey, Jaben
Reviewed-by: Jaben Carsey 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Qiu Shumin
> Sent: Tuesday, October 13, 2015 10:00 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Qiu, Shumin
> 
> Subject: [edk2] [PATCH] ShellPkg: Use safe string functions to refine Tftp.c
> code.
> Importance: High
> 
> Cc: Jaben Carsey 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qiu Shumin 
> ---
>  ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> index 4bb21aa..02099fe 100644
> --- a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> +++ b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> @@ -955,6 +955,7 @@ CheckPacket (
>UINTN Index;
>UINTN LastStep;
>UINTN Step;
> +  EFI_STATUSStatus;
> 
>if ((NTOHS (Packet->OpCode)) != EFI_MTFTP4_OPCODE_DATA) {
>  return EFI_SUCCESS;
> @@ -984,7 +985,10 @@ CheckPacket (
> 
>ShellPrintEx (-1, -1, L"%s", mTftpProgressDelete);
> 
> -  StrCpy (Progress, mTftpProgressFrame);
> +  Status = StrCpyS (Progress, TFTP_PROGRESS_MESSAGE_SIZE,
> mTftpProgressFrame);
> +  if (EFI_ERROR(Status)) {
> +return Status;
> +  }
>for (Index = 1; Index < Step; Index++) {
>  Progress[Index] = L'=';
>}
> --
> 1.9.5.msysgit.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 2/2] MdeModulePkg DriverSampleDxe: Add optional "; " to keep consistent with existed vfr op-code.

2015-10-14 Thread Leif Lindholm
On Wed, Oct 14, 2015 at 04:29:28PM +0800, Eric Dong wrote:
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Eric Dong 

Hi Eric,

There appears to be no commit message here.
I guess the addition of this optional ';' is simply to update this
example to use the improved syntax added by 1/2 - to encourage people
to start using it.
So can you just mention that?

Regards,

Leif

> ---
>  MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr 
> b/MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr
> index bd28797..c48b06a 100644
> --- a/MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr
> +++ b/MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr
> @@ -213,11 +213,11 @@ formset
>  option text = STRING_TOKEN(STR_BOOT_OPTION2), value = 2, 
> flags = 0;
>  option text = STRING_TOKEN(STR_BOOT_OPTION1), value = 1, 
> flags = 0;
>  option text = STRING_TOKEN(STR_BOOT_OPTION3), value = 3, 
> flags = 0;
>suppressif ideqval MyIfrNVData.BootOrderLarge == 0;
>  option text = STRING_TOKEN(STR_BOOT_OPTION4), value = 4, 
> flags = 0;
> -  endif
> +  endif;
>endlist;
>  
>//
>// label should be paired with each other
>//
> @@ -261,11 +261,11 @@ formset
>flags   = RESET_REQUIRED,
>option text = STRING_TOKEN(STR_ONE_OF_TEXT1), value = 0, flags = 0;
>option text = STRING_TOKEN(STR_ONE_OF_TEXT2), value = 1, flags = 
> DEFAULT;
>warningif prompt = STRING_TOKEN(STR_WARNING_POPUP), timeout = 5,
>  ideqval MyIfrNVData.TestLateCheck == 0
> -  endif
> +  endif;
>  
>  endoneof;
>  
>  oneof varid  = MyIfrNVData.TestLateCheck2,
>prompt  = STRING_TOKEN(STR_TEST_OPCODE2),
> @@ -274,11 +274,11 @@ formset
>option text = STRING_TOKEN(STR_ONE_OF_TEXT1), value = 0, flags = 
> DEFAULT;
>option text = STRING_TOKEN(STR_ONE_OF_TEXT2), value = 1, flags = 0;
>  
>inconsistentif prompt = STRING_TOKEN(STR_ERROR_POPUP),
>  ideqid MyIfrNVData.TestLateCheck == MyIfrNVData.TestLateCheck2
> -  endif
> +  endif;
>  
>  endoneof;
>  
>  oneof varid  = MyIfrNVData.QuestionAboutTreeHugging,
>prompt  = STRING_TOKEN(STR_ONE_OF_PROMPT_KEYWORD),
> @@ -299,11 +299,11 @@ formset
>key  = 0x1236,
>minsize  = 6,
>maxsize  = 40,
>inconsistentif prompt = 
> STRING_TOKEN(STR_STRING_CHECK_ERROR_POPUP),
>  pushthis != stringref(STRING_TOKEN(STR_STRING_CHECK))
> -  endif
> +  endif;
>  endstring;
>  
>  //
>  // Define a numeric (EFI_IFR_NUMERIC)
>  //
> @@ -332,11 +332,11 @@ formset
>ideqval MyIfrNVData.HowOldAreYouInYearsManual == 99
>OR
>ideqid  MyIfrNVData.HowOldAreYouInYearsManual == 
> MyEfiVar.Field8
>OR
>ideqvallist MyIfrNVData.HowOldAreYouInYearsManual == 1 3 5 7
> -endif
> +endif;
>  
>  endnumeric;
>  
>  numeric varid   = MyEfiVar.Field8,// Reference of 
> EFI variable storage
>  questionid  = 0x,
> @@ -537,20 +537,20 @@ formset
>  
>  inconsistentif prompt = STRING_TOKEN(STR_ERROR_POPUP),
>ideqval Date.Day == 31
>AND
>ideqvallist Date.Month == 2 4 6 9 11
> -endif
> +endif;
>  
>  //
>  // If the day is 30 AND month is 2
>  //
>  inconsistentif prompt = STRING_TOKEN(STR_ERROR_POPUP),
>ideqval Date.Day == 30
>AND
>ideqval Date.Month == 2
> -endif
> +endif;
>  
>  //
>  // If the day is 29 AND month is 2 AND it year is NOT a leapyear
>  //
>  inconsistentif prompt = STRING_TOKEN(STR_ERROR_POPUP),
> @@ -558,11 +558,11 @@ formset
>AND
>ideqval Date.Month == 2
>AND
>NOT
>ideqvallist Date.Year == 2004 2008 20012 20016 2020 2024 2028 2032 
> 2036
> -endif
> +endif;
>  
>enddate;
>  
>text
>  help   = STRING_TOKEN(STR_SAVE_CURRENT_AND_EXIT),
> -- 
> 1.9.5.msysgit.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] worth openning gEfiSimpleTextIinputProtocol ?

2015-10-14 Thread Carsey, Jaben
There may be multiple text in protocols.  How will you know which one to open?  
ConIn may also be redirecting from a Unicode file, an asci file, or an 
environment variable if you run under the shell.

Tl;dr No, don't do it.

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Miller, Carl H
> Sent: Tuesday, October 13, 2015 1:35 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] worth openning gEfiSimpleTextIinputProtocol ?
> 
> hello, was wondering if it makes sense to open the
> gEfiSimpleTextIinputProtocol rather than just using gST->ConIn pointer 
> 
> thanks
> ___
> 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] [grub PATCH] efinet: disable MNP background polling

2015-10-14 Thread Andrei Borzenkov

14.10.2015 11:00, Ye, Ting пишет:

Could you please describe the details how does GRUB use UEFI network protocols?



When efinet driver is loaded it enumerates handles with SNP; these 
handles represent network cards for grub. If driver is part of initial 
core.img (default for network boot image) it additionally queries loaded 
image handle for PXE for DhcpAck using EFI_PXE_BASE_CODE_PROTOCOL and is 
using it for autoconfiguration. Before the first send/receive request on 
network card SNP on associated handle is opened exclusively and SNP 
Transmit/Receive are used.



I see the thread says that EXCLUSIVE open SNP causes PXE boot fail.

If you read below description about 'EXCLUSIVE' in UEFI specification, you will 
find when GRUB exclusive opens SNP protocol, the UEFI will remove any drivers 
that opened SNP with BY_DRIVER by calling the driver's Stop() function. In UEFI 
network stack, MNP driver will open SNP 'BY_DRIVER'. So if GRUB/iPXE exclusive 
opens SNP, MNP will uninstall itself and the whole UEFI network stack is 
disconnected except SNP and UNDI. Hence, the UEFI PXE no longer work.



EXCLUSIVE   Used by applications to gain exclusive access to a 
protocol interface.
If any drivers have the protocol interface opened with 
an attribute of BY_DRIVER,
then an attempt will be made to remove them by calling 
the driver's Stop() function.



If GRUB would like to call SNP protocol only, it should use EXCLUSIVE open to 
gain the exclusive access and disconnect UEFI network stack since MNP. Then the 
MNP background polling is also disabled.


It does it already.


If GRUB still needs UEFI PXE capability, it should utilize PXE base code 
protocol to continue the process, rather than calling SNP, as SNP is already 
consumed by UEFI network stack.



It does not use PXE after initial autoconfiguration as described above 
nor does it need it. All data transmission is performed using SNP only.



Thanks,
Ye Ting


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrei 
Borzenkov
Sent: Wednesday, October 14, 2015 2:58 PM
To: Ye, Ting; Laszlo Ersek; daniel.ki...@oracle.com; grub-de...@gnu.org
Cc: edk2-devel-01; Mark Salter; g...@suse.com; seth.goldb...@oracle.com; 
konrad.w...@oracle.com
Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling

14.10.2015 09:15, Ye, Ting пишет:

May I know the details what problems it causes in some cases?



One is being discussed in this thread:

http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00013.html
http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00068.html

Another was reported recently:

http://lists.gnu.org/archive/html/help-grub/2015-09/msg00033.html
http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00071.html



Thanks,
Ye Ting

-Original Message-
From: Andrei Borzenkov [mailto:arvidj...@gmail.com]
Sent: Wednesday, October 14, 2015 1:58 PM
To: Ye, Ting; Laszlo Ersek; daniel.ki...@oracle.com; grub-de...@gnu.org
Cc: konrad.w...@oracle.com; edk2-devel-01; g...@suse.com; 
seth.goldb...@oracle.com; Mark Salter
Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling

14.10.2015 08:19, Ye, Ting пишет:

Hi all,

If I understand the issue correctly, I don't quite agree that UEFI spec is 
imprecise about SNP constraints described as following.
The "constraint" described here is that the grub should use attribute 
"EXCLUSIVE" to open SNP protocol to gain exclusive access. This usage is clearly 
described in page 184, chapter 6.3 EFI_BOOT_SERVICES.OpenProtocol().

EXCLUSIVE   Used by applications to gain exclusive access to a 
protocol interface.
If any drivers have the protocol interface opened with 
an attribute of BY_DRIVER,
then an attempt will be made to remove them by calling 
the driver's Stop() function.

The grub code should not assume that the SNP is not occupied by other drivers, 
instead, it should use EXCLUSIVE to open SNP protocol, or to be more precise, 
use OpenProtocolInformation() to check whether SNP is already opened by other 
driver, then decide whether need to use EXCLUSIVE to disconnect the other 
drivers. This is the typical usage for all UEFI protocol, not particular 
constraints to SNP protocol.



That is exactly what grub currently does - it opens SNP exclusively.
Apparently it is causing problems in some cases.



___
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] KVM: MTRR: fix memory type handling if MTRR is completely disabled

2015-10-14 Thread Janusz
W dniu 14.10.2015 o 10:32, Xiao Guangrong pisze:
>
>
> On 10/14/2015 04:24 PM, Xiao Guangrong wrote:
>>
>>
>> On 10/14/2015 03:37 PM, Janusz wrote:
>>> I was able to run my virtual machine with this, but had very high cpu
>>> usage when something happen in it like booting system. once, my virtual
>>> machine hang and I couln't even get my mouse / keyboard back from qemu.
>>> When I did vga passthrough, I didn't get any video output, and cpu
>>> usage
>>> was also high. Tried it on 4.3
>>
>> Which tree are you using? Is it kvm tree?
>> Could you please work on queue brancn on current kvm tree based on
>> top commit 73917739334c6509: KVM: x86: fix SMI to halted VCPU.
>>
>> Hmm... interesting, this diff works on my box...
>
> Forgot to say that i built my test env following the instructions on
> kvm-wiki:
> http://www.linux-kvm.org/page/OVMF
>
> My test script is attached, and i will try to build the env like yours
> as much
> as possible...
I cloned git://git.kernel.org/pub/scm/virt/kvm/kvm.git 73917739334c6509
commit, but this is breaking my system...
Slim is not able to start i3, xdm is not killing X when I stop xdm, qemu
is not able to start when I don't use option -nographic
log from qemu on that kernel version:
xcb_connection_has_error() returned true
No protocol specified
Could not initialize SDL(No available video device) - exiting

On main kernel branch I don't have those problems.

I tried to run with -nographic, and tried pc-i440fx-2.1 but the same
problem as before, high cpu usage and no graphic on my GPU.
I don't know if that will help by this is my log from option -global
isa-debugcon.iobase=0x402 -debugcon file:fedora.ovmf.log:
https://bpaste.net/show/36c54dba68c2

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


Re: [edk2] [grub PATCH] efinet: disable MNP background polling

2015-10-14 Thread Ye, Ting
May I know the details what problems it causes in some cases? 

Thanks,
Ye Ting

-Original Message-
From: Andrei Borzenkov [mailto:arvidj...@gmail.com] 
Sent: Wednesday, October 14, 2015 1:58 PM
To: Ye, Ting; Laszlo Ersek; daniel.ki...@oracle.com; grub-de...@gnu.org
Cc: konrad.w...@oracle.com; edk2-devel-01; g...@suse.com; 
seth.goldb...@oracle.com; Mark Salter
Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling

14.10.2015 08:19, Ye, Ting пишет:
> Hi all,
>
> If I understand the issue correctly, I don't quite agree that UEFI spec is 
> imprecise about SNP constraints described as following.
> The "constraint" described here is that the grub should use attribute 
> "EXCLUSIVE" to open SNP protocol to gain exclusive access. This usage is 
> clearly described in page 184, chapter 6.3 EFI_BOOT_SERVICES.OpenProtocol().
>
> EXCLUSIVE Used by applications to gain exclusive access to a 
> protocol interface.
>   If any drivers have the protocol interface opened with 
> an attribute of BY_DRIVER,
>   then an attempt will be made to remove them by calling 
> the driver's Stop() function.
>
> The grub code should not assume that the SNP is not occupied by other 
> drivers, instead, it should use EXCLUSIVE to open SNP protocol, or to be more 
> precise, use OpenProtocolInformation() to check whether SNP is already opened 
> by other driver, then decide whether need to use EXCLUSIVE to disconnect the 
> other drivers. This is the typical usage for all UEFI protocol, not 
> particular constraints to SNP protocol.
>

That is exactly what grub currently does - it opens SNP exclusively. 
Apparently it is causing problems in some cases.

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


Re: [edk2] [grub PATCH] efinet: disable MNP background polling

2015-10-14 Thread Andrei Borzenkov

14.10.2015 04:01, Yinghai Lu пишет:

On Tue, Oct 13, 2015 at 3:11 PM, Daniel Kiper  wrote:

On Thu, Oct 01, 2015 at 08:53:44PM +0300, Andrei Borzenkov wrote:

Hatayama-san, would you consider implementing MNP-based driver for GRUB?
Having at least proof of concept available for testing would be good.


Are we sure that we want to migrate to MNP? As I saw others (e.g. PXELINUX,
iPXE) use SNP and it work for them.

If yes then I can post my unfinished rebase work for Solaris GRUB2 MNP patches.
I did that for our internal needs, however, I did not finish it because usptream
GRUB2 solved our problems. Well, patches are very raw, based on very old GRUB2
(Apr 2012) and do not build. However, maybe they could be a good starting point
for further work.


I ported that on top of grub2 upstream this January. It is based on
upstream of 2015-01-28.
so need to revert 4fe8e6d f348aee c52ae40 49426e9 cf2b4a3 from current upstream.



Do you also observe problems with current upstream?


We (x86 system group) have used it internally for a while. It solved
all the uefi pxe booting
problems that we met with grub2, like 1g intel supper slow, or 10g
intel does not even start.

Thanks

Yinghai



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


Re: [edk2] iPXE efi chainloading grub2 pxe efi file

2015-10-14 Thread Andrei Borzenkov
[Redirecting to grub-devel where similar problem is being discussed 
right now and trying iPXE/EDK2 as well]


18.09.2015 22:59, Rivard, Matthew T пишет:

Thanks, its loading the menu now, however, I appear to be hitting the same 
problem I was going from grub to ipxe.  The adapters are there, but won't 
autoconfigure,


Exclusive SNP open used by iPXE quite likely tears down PXE information, 
so GRUB has nothing to autoconfigure card from.



and if I try to manually set an IP address, I see the debugging data start 
spewing from ipxe (which appears to be still running underneath grub) before 
the system eventually halts.



Well, now we have two *applications* each holding exclusive open on 
adapter. I do not know details about iPXE but if there is any remote 
chance it does background polling we are back at square one.


Unfortunately I do not really see what we can do in this case (iPXE => 
GRUB) from GRUB side. Switching GRUB to MNP may fix GRUB => iPXE case 
though. OTOH I do not know what happens long term. GRUB calls other 
image (let's say iPXE) passes control to it. Now firmware continues to 
queue packets for GRUB MNP instance, which GRUB never consumes. Does not 
really look good either.


In principle the same is true for GRUB pure if it is left sitting in 
menu/CLI for a long time. And for every other active MNP instance.



I'll try your rollback, but was it mean to come out in the email as a long hash 
string?



Did you have chance to test it?



-Original Message-
From: Andrei Borzenkov [mailto:arvidj...@gmail.com]
Sent: Thursday, September 17, 2015 8:52 PM
To: Rivard, Matthew T; help-g...@gnu.org
Subject: Re: iPXE efi chainloading grub2 pxe efi file

18.09.2015 03:05, Rivard, Matthew T пишет:

I've got a good working EFI Grub2 efi Bootloader that works fine when its 
directly handed off to by the DHCP for PXE, however, if I attempt to chainload 
it from iPXE snponly.efi, it goes straight to the grub command prompt.

I've tried embedding the grub.cfg file via -c on the grub-mkimage command, but it spews 
out the grub file as a stream of "command not found prompts" and then still 
goes to the grub command line.



Embedded config is processed very early, before normal.mod is loaded, so only 
commands available at rescue prompts are present.


If I try embedding all of the modules directly into grub.efi during mkimage, 
along with the config file, it then throws a grub_divmod64_full not found error.



Embedding all modules in grub.efi is usually wrong (not all modules can be 
loaded concurrently) either.

Try creating standalone image with grub-mkstandalone. This image contains all 
grub modules in memory disk (as cpio archive) and grub is configured with 
$prefix pointing to this disk. You can also add own files, in particular put 
grub.cfg in memory disk.


What is the ideal way to chain load my grub.efi file from iPXE so that it works 
the same as if it was the direct handoff from the DHCP/TFTP server?

Unfortunately, in order to allow for selecting either our EFI WDS Server or our 
EFI Linux Server, I have to use iPXE first, as chainloading snponly.efi from 
grub2 ends up with iPXE snp not being able to enumerate anything from the PCI 
Bus.



Hmm ... this actually sounds like exclusive SNP open (used by both iPXE and 
GRUB) messes something up. For testing you could try to revert
49426e9fd2e562c73a4f1206f32eff9e424a1a73 (and 
f348aee7b33dd85e7da62b497a96a7319a0bf9dd which depends on it) to see if it 
makes any difference.


Using git pulls for both that were from yesterday.

Matt R.




___
Help-grub mailing list
help-g...@gnu.org
https://lists.gnu.org/mailman/listinfo/help-grub





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


Re: [edk2] [grub PATCH] efinet: disable MNP background polling

2015-10-14 Thread Andrei Borzenkov

14.10.2015 09:15, Ye, Ting пишет:

May I know the details what problems it causes in some cases?



One is being discussed in this thread:

http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00013.html
http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00068.html

Another was reported recently:

http://lists.gnu.org/archive/html/help-grub/2015-09/msg00033.html
http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00071.html



Thanks,
Ye Ting

-Original Message-
From: Andrei Borzenkov [mailto:arvidj...@gmail.com]
Sent: Wednesday, October 14, 2015 1:58 PM
To: Ye, Ting; Laszlo Ersek; daniel.ki...@oracle.com; grub-de...@gnu.org
Cc: konrad.w...@oracle.com; edk2-devel-01; g...@suse.com; 
seth.goldb...@oracle.com; Mark Salter
Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling

14.10.2015 08:19, Ye, Ting пишет:

Hi all,

If I understand the issue correctly, I don't quite agree that UEFI spec is 
imprecise about SNP constraints described as following.
The "constraint" described here is that the grub should use attribute 
"EXCLUSIVE" to open SNP protocol to gain exclusive access. This usage is clearly 
described in page 184, chapter 6.3 EFI_BOOT_SERVICES.OpenProtocol().

EXCLUSIVE   Used by applications to gain exclusive access to a 
protocol interface.
If any drivers have the protocol interface opened with 
an attribute of BY_DRIVER,
then an attempt will be made to remove them by calling 
the driver's Stop() function.

The grub code should not assume that the SNP is not occupied by other drivers, 
instead, it should use EXCLUSIVE to open SNP protocol, or to be more precise, 
use OpenProtocolInformation() to check whether SNP is already opened by other 
driver, then decide whether need to use EXCLUSIVE to disconnect the other 
drivers. This is the typical usage for all UEFI protocol, not particular 
constraints to SNP protocol.



That is exactly what grub currently does - it opens SNP exclusively.
Apparently it is causing problems in some cases.



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


Re: [edk2] KVM: MTRR: fix memory type handling if MTRR is completely disabled

2015-10-14 Thread Janusz
I was able to run my virtual machine with this, but had very high cpu
usage when something happen in it like booting system. once, my virtual
machine hang and I couln't even get my mouse / keyboard back from qemu.
When I did vga passthrough, I didn't get any video output, and cpu usage
was also high. Tried it on 4.3

W dniu 14.10.2015 o 05:58, Xiao Guangrong pisze:
>
> Janusz,
>
> Could you please try this:
>
> $ git diff
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 185fc16..bdd564f 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -4957,12 +4957,14 @@ static int handle_emulation_failure(struct
> kvm_vcpu *vcpu)
>
> ++vcpu->stat.insn_emulation_fail;
> trace_kvm_emulate_insn_failed(vcpu);
> +#if 0
> if (!is_guest_mode(vcpu) && kvm_x86_ops->get_cpl(vcpu) == 0) {
> vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
> vcpu->run->internal.suberror =
> KVM_INTERNAL_ERROR_EMULATION;
> vcpu->run->internal.ndata = 0;
> r = EMULATE_FAIL;
> }
> +#endif
> kvm_queue_exception(vcpu, UD_VECTOR);
>
> return r;
>
> To see if the issue still there?
>
>
> On 10/02/2015 10:38 PM, Janusz wrote:
>> W dniu 01.10.2015 o 16:18, Paolo Bonzini pisze:
>>>
>>> On 01/10/2015 16:12, Janusz wrote:
 Now, I can also add, that the problem is only when I allow VM to use
 more than one core, so with option  for example:
 -smp 8,cores=4,threads=2,sockets=1 and other combinations like -smp
 4,threads=1 its not working, and without it I am always running VM
 without problems

 Any ideas what can it be? or any idea what would help to find out what
 is causing this?
>>> I am going to send a revert of the patch tomorrow.
>>>
>>> Paolo
>> Thanks, but revert patch doesn't help, so something else is wrong here
>>

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


Re: [edk2] KVM: MTRR: fix memory type handling if MTRR is completely disabled

2015-10-14 Thread Janusz
W dniu 14.10.2015 o 11:13, Janusz pisze:
> W dniu 14.10.2015 o 10:32, Xiao Guangrong pisze:
>>
>> On 10/14/2015 04:24 PM, Xiao Guangrong wrote:
>>>
>>> On 10/14/2015 03:37 PM, Janusz wrote:
 I was able to run my virtual machine with this, but had very high cpu
 usage when something happen in it like booting system. once, my virtual
 machine hang and I couln't even get my mouse / keyboard back from qemu.
 When I did vga passthrough, I didn't get any video output, and cpu
 usage
 was also high. Tried it on 4.3
>>> Which tree are you using? Is it kvm tree?
>>> Could you please work on queue brancn on current kvm tree based on
>>> top commit 73917739334c6509: KVM: x86: fix SMI to halted VCPU.
>>>
>>> Hmm... interesting, this diff works on my box...
>> Forgot to say that i built my test env following the instructions on
>> kvm-wiki:
>> http://www.linux-kvm.org/page/OVMF
>>
>> My test script is attached, and i will try to build the env like yours
>> as much
>> as possible...
> I attach my script. I see that you are using pc-i440fx-2.1 - I use
> default, I think its pc-i440fx-2.4, tried 2.3 some time ago and I get
> the same problem. I will try with 2.1 after work
> I am using  master from main kernel  tree, will also try this tree you
> mentioned after work
I am sending this one more time, as my message was rejected by intel
servers because of attached script... Script:
https://bpaste.net/show/8467c3af8b18
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [Patch V2] Update register hot key logic, return EFI_ALREADY_START status if same hot key already existed.

2015-10-14 Thread Gao, Liming
Reviewed-by: Liming Gao 

-Original Message-
From: Dong, Eric 
Sent: Wednesday, October 14, 2015 11:29 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming; Yao, Jiewen
Subject: [Patch V2] Update register hot key logic, return EFI_ALREADY_START 
status if same hot key already existed.

In current case, if one key already registered and it is registered again for 
another hot key, browser will override old hot key with new one. This behavior 
is not user friendly.
Now update the logic, return EFI_ALREADY_STARTED for this case. If user still 
want to override it, he must unregistered it first.

V2: Refine the function header, add new return type.

Cc: Liming Gao 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
---
 MdeModulePkg/Universal/SetupBrowserDxe/Setup.c | 24   
MdeModulePkg/Universal/SetupBrowserDxe/Setup.h |  1 +
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/MdeModulePkg/Universal/SetupBrowserDxe/Setup.c 
b/MdeModulePkg/Universal/SetupBrowserDxe/Setup.c
index 5793962..43cfc87 100644
--- a/MdeModulePkg/Universal/SetupBrowserDxe/Setup.c
+++ b/MdeModulePkg/Universal/SetupBrowserDxe/Setup.c
@@ -5888,10 +5888,11 @@ SetScope (
   
   @retval EFI_SUCCESSHot key is registered or unregistered.
   @retval EFI_INVALID_PARAMETER  KeyData is NULL or HelpString is NULL on 
register.
   @retval EFI_NOT_FOUND  KeyData is not found to be unregistered.
   @retval EFI_UNSUPPORTEDKey represents a printable character. It is 
conflicted with Browser.
+  @retval EFI_ALREADY_STARTEDKey already been registered for one hot key.
 **/
 EFI_STATUS
 EFIAPI
 RegisterHotKey (
   IN EFI_INPUT_KEY *KeyData,
@@ -5933,24 +5934,23 @@ RegisterHotKey (
   // The registered HotKey is not found. 
   //
   return EFI_NOT_FOUND;
 }
   }
-  
+
+  if (HotKey != NULL) {
+return EFI_ALREADY_STARTED;
+  }
+
   //
-  // Register HotKey into List.
+  // Create new Key, and add it into List.
   //
-  if (HotKey == NULL) {
-//
-// Create new Key, and add it into List.
-//
-HotKey = AllocateZeroPool (sizeof (BROWSER_HOT_KEY));
-ASSERT (HotKey != NULL);
-HotKey->Signature = BROWSER_HOT_KEY_SIGNATURE;
-HotKey->KeyData   = AllocateCopyPool (sizeof (EFI_INPUT_KEY), KeyData);
-InsertTailList (, >Link);
-  }
+  HotKey = AllocateZeroPool (sizeof (BROWSER_HOT_KEY));  ASSERT (HotKey 
+ != NULL);  HotKey->Signature = BROWSER_HOT_KEY_SIGNATURE;
+  HotKey->KeyData   = AllocateCopyPool (sizeof (EFI_INPUT_KEY), KeyData);
+  InsertTailList (, >Link);
 
   //
   // Fill HotKey information.
   //
   HotKey->Action = Action;
diff --git a/MdeModulePkg/Universal/SetupBrowserDxe/Setup.h 
b/MdeModulePkg/Universal/SetupBrowserDxe/Setup.h
index 1238197..61e706a 100644
--- a/MdeModulePkg/Universal/SetupBrowserDxe/Setup.h
+++ b/MdeModulePkg/Universal/SetupBrowserDxe/Setup.h
@@ -1306,10 +1306,11 @@ SetScope (
   
   @retval EFI_SUCCESSHot key is registered or unregistered.
   @retval EFI_INVALID_PARAMETER  KeyData is NULL.
   @retval EFI_NOT_FOUND  KeyData is not found to be unregistered.
   @retval EFI_UNSUPPORTEDKey represents a printable character. It is 
conflicted with Browser.
+  @retval EFI_ALREADY_STARTEDKey already been registered for one hot key.
 **/
 EFI_STATUS
 EFIAPI
 RegisterHotKey (
   IN EFI_INPUT_KEY *KeyData,
--
1.9.5.msysgit.1

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


Re: [edk2] [Patch] BaseTools: Fix the issue to support windows root directory

2015-10-14 Thread Zhu, Yonghong
Reviewed-by: Yonghong Zhu 

Best Regards,

Zhu Yonghong

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
Gao
Sent: Wednesday, October 14, 2015 5:29 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] BaseTools: Fix the issue to support windows root 
directory

Use os.path.relpath to get the relative directory instead of directly trim it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 BaseTools/Source/Python/Common/MultipleWorkspace.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Common/MultipleWorkspace.py 
b/BaseTools/Source/Python/Common/MultipleWorkspace.py
index 8088404..feb1f8d 100644
--- a/BaseTools/Source/Python/Common/MultipleWorkspace.py
+++ b/BaseTools/Source/Python/Common/MultipleWorkspace.py
@@ -41,7 +41,7 @@ class MultipleWorkspace(object):
 @classmethod
 def convertPackagePath(cls, Ws, Path):
 if str(os.path.normcase (Path)).startswith(Ws):
-return os.path.join(Ws, Path[len(Ws) + 1:])
+return os.path.join(Ws, os.path.relpath(Path, Ws))
 return Path
 
 ## setWs()
-- 
1.9.5.msysgit.0

___
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 2/3] MdeModulePkg: FaultTolerantWriteDxe: mellow DEBUGs about workspace reinit

2015-10-14 Thread Laszlo Ersek
On 10/14/15 04:16, Zeng, Star wrote:
> On 2015/10/13 19:55, Laszlo Ersek wrote:
>> The IsValidWorkSpace() function checks if the working block header of the
>> workspace is valid. A mismatch detected by this function is not
>> necessarily an error; it can happen with an as-yet unwritten flash chip,
>> which is e.g. common and normal when a new ArmVirtQemu virtual machine is
>> booted. Therefore downgrade the message emitted by IsValidWorkSpace()
>> from
>> EFI_D_ERROR to EFI_D_INFO, and change the wording from "error" to
>> "mismatch".
>>
>> The only caller of IsValidWorkSpace(), InitFtwProtocol(), handles all of
>> the following cases:
>>
>> (1) IsValidWorkSpace() succeeds for the working block -- this is normal
>>  operation,
>>
>> (2) IsValidWorkSpace() fails for the working block, but succeeds for the
>>  spare block -- InitFtwProtocol() then restores the working block
>> from
>>  the spare block,
>>
>> (3) IsValidWorkSpace() fails for both the working and spare blocks --
>>  InitFtwProtocol() reinitializes the full workspace.
>>
>> In cases (2) and (3), InitFtwProtocol() logs additional messages about
>> the
>> branch taken. Their current level is EFI_D_ERROR, but the messages are
>> arguably informative, not necessarily error reports.
>>
>> Downgrade these messages from EFI_D_ERROR to EFI_D_INFO, so that they
>> don't clutter the debug output when the PcdDebugPrintErrorLevel mask only
>> enables EFI_D_ERROR (i.e., in a "silent" build).
>>
>> These messages have annoyed / confused users; see for example:
>> - https://bugzilla.redhat.com/show_bug.cgi?id=1270279
>>
>> Cc: Star Zeng 
>> Cc: Liming Gao 
>> Cc: Drew Jones 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek 
>> ---
>>   MdeModulePkg/Universal/FaultTolerantWriteDxe/FtwMisc.c|
>> 6 --
>>   MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c |
>> 2 +-
>>   2 files changed, 5 insertions(+), 3 deletions(-)
> 
> Basically, I am ok with the patch.
> 
> Reviewed-by: Star Zeng 
> 
> It will be nicer if it can also cover below lines.
> FaultTolerantWrite.c:
>   FtwRestart():
> DEBUG ((EFI_D_ERROR, "Ftw: Restart() success \n")); -> EFI_D_INFO
>   FtwAbort():
> DEBUG ((EFI_D_ERROR, "Ftw: Abort() success \n")); -> EFI_D_INFO
>   FtwGetLastWrite():
> DEBUG ((EFI_D_ERROR, "Ftw: GetLasetWrite() success\n")); -> EFI_D_INFO

I will send an updated version for review.

Thanks!
Laszlo

> 
> 
> Thanks,
> Star
>>
>> diff --git a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FtwMisc.c
>> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FtwMisc.c
>> index 0922321..9604469 100644
>> --- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FtwMisc.c
>> +++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FtwMisc.c
>> @@ -1273,29 +1273,31 @@ InitFtwProtocol (
>>  FtwDevice->FtwWorkSpaceSize,
>>  FtwDevice->FtwWorkSpace
>>  );
>>   ASSERT_EFI_ERROR (Status);
>>
>>   //
>>   // If spare block is valid, then replace working block content.
>>   //
>>   if (IsValidWorkSpace (FtwDevice->FtwWorkSpaceHeader)) {
>> Status = FlushSpareBlockToWorkingBlock (FtwDevice);
>> -  DEBUG ((EFI_D_ERROR, "Ftw: Restart working block update in
>> InitFtwProtocol() - %r\n", Status));
>> +  DEBUG ((EFI_D_INFO, "Ftw: Restart working block update in %a()
>> - %r\n",
>> +__FUNCTION__, Status));
>> FtwAbort (>FtwInstance);
>> //
>> // Refresh work space.
>> //
>> Status = WorkSpaceRefresh (FtwDevice);
>> ASSERT_EFI_ERROR (Status);
>>   } else {
>> -  DEBUG ((EFI_D_ERROR, "Ftw: Both are invalid, init workspace\n"));
>> +  DEBUG ((EFI_D_INFO,
>> +"Ftw: Both working and spare blocks are invalid, init
>> workspace\n"));
>> //
>> // If both are invalid, then initialize work space.
>> //
>> SetMem (
>>   FtwDevice->FtwWorkSpace,
>>   FtwDevice->FtwWorkSpaceSize,
>>   FTW_ERASED_BYTE
>>   );
>> InitWorkSpaceHeader (FtwDevice->FtwWorkSpaceHeader);
>> //
>> diff --git
>> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c
>> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c
>> index 31f1e0b..d46a37f 100644
>> --- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c
>> +++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c
>> @@ -91,21 +91,21 @@ IsValidWorkSpace (
>> )
>>   {
>> if (WorkingHeader == NULL) {
>>   return FALSE;
>> }
>>
>> if (CompareMem (WorkingHeader, , sizeof
>> (EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER)) == 0) {
>>   return TRUE;
>> }
>>
>> -  DEBUG ((EFI_D_ERROR, "Ftw: Work block header check error\n"));
>> +  DEBUG ((EFI_D_INFO, "Ftw: Work block header check mismatch\n"));

Re: [edk2] [grub PATCH] efinet: disable MNP background polling

2015-10-14 Thread Ye, Ting
Could you please describe the details how does GRUB use UEFI network protocols?

I see the thread says that EXCLUSIVE open SNP causes PXE boot fail. 

If you read below description about 'EXCLUSIVE' in UEFI specification, you will 
find when GRUB exclusive opens SNP protocol, the UEFI will remove any drivers 
that opened SNP with BY_DRIVER by calling the driver's Stop() function. In UEFI 
network stack, MNP driver will open SNP 'BY_DRIVER'. So if GRUB/iPXE exclusive 
opens SNP, MNP will uninstall itself and the whole UEFI network stack is 
disconnected except SNP and UNDI. Hence, the UEFI PXE no longer work.


>> EXCLUSIVEUsed by applications to gain exclusive access to a 
>> protocol interface.
>>  If any drivers have the protocol interface opened with 
>> an attribute of BY_DRIVER,
>>  then an attempt will be made to remove them by calling 
>> the driver's Stop() function.


If GRUB would like to call SNP protocol only, it should use EXCLUSIVE open to 
gain the exclusive access and disconnect UEFI network stack since MNP. Then the 
MNP background polling is also disabled.
If GRUB still needs UEFI PXE capability, it should utilize PXE base code 
protocol to continue the process, rather than calling SNP, as SNP is already 
consumed by UEFI network stack.

Thanks,
Ye Ting


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrei 
Borzenkov
Sent: Wednesday, October 14, 2015 2:58 PM
To: Ye, Ting; Laszlo Ersek; daniel.ki...@oracle.com; grub-de...@gnu.org
Cc: edk2-devel-01; Mark Salter; g...@suse.com; seth.goldb...@oracle.com; 
konrad.w...@oracle.com
Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling

14.10.2015 09:15, Ye, Ting пишет:
> May I know the details what problems it causes in some cases?
>

One is being discussed in this thread:

http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00013.html
http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00068.html

Another was reported recently:

http://lists.gnu.org/archive/html/help-grub/2015-09/msg00033.html
http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00071.html


> Thanks,
> Ye Ting
>
> -Original Message-
> From: Andrei Borzenkov [mailto:arvidj...@gmail.com]
> Sent: Wednesday, October 14, 2015 1:58 PM
> To: Ye, Ting; Laszlo Ersek; daniel.ki...@oracle.com; grub-de...@gnu.org
> Cc: konrad.w...@oracle.com; edk2-devel-01; g...@suse.com; 
> seth.goldb...@oracle.com; Mark Salter
> Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling
>
> 14.10.2015 08:19, Ye, Ting пишет:
>> Hi all,
>>
>> If I understand the issue correctly, I don't quite agree that UEFI spec is 
>> imprecise about SNP constraints described as following.
>> The "constraint" described here is that the grub should use attribute 
>> "EXCLUSIVE" to open SNP protocol to gain exclusive access. This usage is 
>> clearly described in page 184, chapter 6.3 EFI_BOOT_SERVICES.OpenProtocol().
>>
>> EXCLUSIVEUsed by applications to gain exclusive access to a 
>> protocol interface.
>>  If any drivers have the protocol interface opened with 
>> an attribute of BY_DRIVER,
>>  then an attempt will be made to remove them by calling 
>> the driver's Stop() function.
>>
>> The grub code should not assume that the SNP is not occupied by other 
>> drivers, instead, it should use EXCLUSIVE to open SNP protocol, or to be 
>> more precise, use OpenProtocolInformation() to check whether SNP is already 
>> opened by other driver, then decide whether need to use EXCLUSIVE to 
>> disconnect the other drivers. This is the typical usage for all UEFI 
>> protocol, not particular constraints to SNP protocol.
>>
>
> That is exactly what grub currently does - it opens SNP exclusively.
> Apparently it is causing problems in some cases.
>

___
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 1/2] BaseTools VfrCompiler: In order to keep consistent, add an optional "; " for condition op-code.

2015-10-14 Thread Eric Dong
In current implementation, the "endif" opcode for suppressif has an end ";" for 
the statement opcode, but not for the option opcode. This is not a user 
friendly grammar. So this patch fixed this issue. Add an optional ";" end for 
option opcode to keep consistent with existed code. The same case also existed 
for grayoutif/disableif/inconsistentif/nosubmitif/warningif.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
---
 BaseTools/Source/C/VfrCompile/VfrSyntax.g | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/BaseTools/Source/C/VfrCompile/VfrSyntax.g 
b/BaseTools/Source/C/VfrCompile/VfrSyntax.g
index ad839b2..d74fec8 100644
--- a/BaseTools/Source/C/VfrCompile/VfrSyntax.g
+++ b/BaseTools/Source/C/VfrCompile/VfrSyntax.g
@@ -3256,39 +3256,39 @@ vfrStatementInconsistentIf :
   << CIfrInconsistentIf IIObj; >>
   L:InconsistentIf << 
IIObj.SetLineNo(L->getLine()); >>
   Prompt "=" "STRING_TOKEN" "\(" S:Number "\)" "," << IIObj.SetError 
(_STOSID(S->getText(), S->getLine())); >>
   { FLAGS "=" flagsField ( "\|" flagsField )* "," }
   vfrStatementExpression[0]
-  E:EndIf  << CRT_END_OP (E); >>
+  E:EndIf {";"}<< CRT_END_OP (E); >>
   ;
 
 vfrStatementNoSubmitIf :
   << CIfrNoSubmitIf NSIObj; >>
   L:NoSubmitIf << 
NSIObj.SetLineNo(L->getLine()); >>
   Prompt "=" "STRING_TOKEN" "\(" S:Number "\)" "," << NSIObj.SetError 
(_STOSID(S->getText(), S->getLine())); >>
   { FLAGS "=" flagsField ( "\|" flagsField )* "," }
   vfrStatementExpression[0]
-  E:EndIf  << CRT_END_OP (E); >>
+  E:EndIf {";"}<< CRT_END_OP (E); >>
   ;
 
 vfrStatementWarningIf :
   << CIfrWarningIf WIObj; >>
   L:WarningIf  << 
WIObj.SetLineNo(L->getLine()); >>
   Prompt "=" "STRING_TOKEN" "\(" S:Number "\)" "," << WIObj.SetWarning 
(_STOSID(S->getText(), S->getLine())); >>
   {Timeout "=" T:Number ","<< WIObj.SetTimeOut 
(_STOU8(T->getText(), T->getLine())); >>}
   vfrStatementExpression[0]
-  E:EndIf  << CRT_END_OP (E); >>
+  E:EndIf {";"}<< CRT_END_OP (E); >>
   ;
 
 vfrStatementDisableIfQuest :
   << 
 CIfrDisableIf DIObj; 
   >>
   L:DisableIf  << 
DIObj.SetLineNo(L->getLine()); >>
   vfrStatementExpression[0] ";"
   vfrStatementQuestionOptionList
-  E:EndIf  << CRT_END_OP (E); >>
+  E:EndIf {";"}<< CRT_END_OP (E); >>
   ;
 
 vfrStatementRefresh :
   << CIfrRefresh RObj; >>
   L:Refresh<< 
RObj.SetLineNo(L->getLine()); >>
@@ -3314,20 +3314,20 @@ vfrStatementSuppressIfQuest :
   << CIfrSuppressIf SIObj; >>
   L:SuppressIf << 
SIObj.SetLineNo(L->getLine()); >>
   { FLAGS "=" flagsField ( "\|" flagsField )* "," }
   vfrStatementExpression[0] ";"
   vfrStatementQuestionOptionList
-  E:EndIf  << CRT_END_OP (E); >>
+  E:EndIf {";"}<< CRT_END_OP (E); >>
   ;
 
 vfrStatementGrayOutIfQuest :
   << CIfrGrayOutIf GOIObj; >>
   L:GrayOutIf  << 
GOIObj.SetLineNo(L->getLine()); >>
   { FLAGS "=" flagsField ( "\|" flagsField )* "," }
   vfrStatementExpression[0] ";"
   vfrStatementQuestionOptionList
-  E:EndIf  << CRT_END_OP (E); >>
+  E:EndIf {";"}<< CRT_END_OP (E); >>
   ;
 
 vfrStatementOptions :
   vfrStatementOneOfOption
   ;
-- 
1.9.5.msysgit.1

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


[edk2] [Patch 2/2] MdeModulePkg DriverSampleDxe: Add optional "; " to keep consistent with existed vfr op-code.

2015-10-14 Thread Eric Dong
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
---
 MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr 
b/MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr
index bd28797..c48b06a 100644
--- a/MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr
+++ b/MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr
@@ -213,11 +213,11 @@ formset
 option text = STRING_TOKEN(STR_BOOT_OPTION2), value = 2, flags 
= 0;
 option text = STRING_TOKEN(STR_BOOT_OPTION1), value = 1, flags 
= 0;
 option text = STRING_TOKEN(STR_BOOT_OPTION3), value = 3, flags 
= 0;
   suppressif ideqval MyIfrNVData.BootOrderLarge == 0;
 option text = STRING_TOKEN(STR_BOOT_OPTION4), value = 4, flags 
= 0;
-  endif
+  endif;
   endlist;
 
   //
   // label should be paired with each other
   //
@@ -261,11 +261,11 @@ formset
   flags   = RESET_REQUIRED,
   option text = STRING_TOKEN(STR_ONE_OF_TEXT1), value = 0, flags = 0;
   option text = STRING_TOKEN(STR_ONE_OF_TEXT2), value = 1, flags = DEFAULT;
   warningif prompt = STRING_TOKEN(STR_WARNING_POPUP), timeout = 5,
 ideqval MyIfrNVData.TestLateCheck == 0
-  endif
+  endif;
 
 endoneof;
 
 oneof varid  = MyIfrNVData.TestLateCheck2,
   prompt  = STRING_TOKEN(STR_TEST_OPCODE2),
@@ -274,11 +274,11 @@ formset
   option text = STRING_TOKEN(STR_ONE_OF_TEXT1), value = 0, flags = DEFAULT;
   option text = STRING_TOKEN(STR_ONE_OF_TEXT2), value = 1, flags = 0;
 
   inconsistentif prompt = STRING_TOKEN(STR_ERROR_POPUP),
 ideqid MyIfrNVData.TestLateCheck == MyIfrNVData.TestLateCheck2
-  endif
+  endif;
 
 endoneof;
 
 oneof varid  = MyIfrNVData.QuestionAboutTreeHugging,
   prompt  = STRING_TOKEN(STR_ONE_OF_PROMPT_KEYWORD),
@@ -299,11 +299,11 @@ formset
   key  = 0x1236,
   minsize  = 6,
   maxsize  = 40,
   inconsistentif prompt = 
STRING_TOKEN(STR_STRING_CHECK_ERROR_POPUP),
 pushthis != stringref(STRING_TOKEN(STR_STRING_CHECK))
-  endif
+  endif;
 endstring;
 
 //
 // Define a numeric (EFI_IFR_NUMERIC)
 //
@@ -332,11 +332,11 @@ formset
   ideqval MyIfrNVData.HowOldAreYouInYearsManual == 99
   OR
   ideqid  MyIfrNVData.HowOldAreYouInYearsManual == MyEfiVar.Field8
   OR
   ideqvallist MyIfrNVData.HowOldAreYouInYearsManual == 1 3 5 7
-endif
+endif;
 
 endnumeric;
 
 numeric varid   = MyEfiVar.Field8,// Reference of EFI 
variable storage
 questionid  = 0x,
@@ -537,20 +537,20 @@ formset
 
 inconsistentif prompt = STRING_TOKEN(STR_ERROR_POPUP),
   ideqval Date.Day == 31
   AND
   ideqvallist Date.Month == 2 4 6 9 11
-endif
+endif;
 
 //
 // If the day is 30 AND month is 2
 //
 inconsistentif prompt = STRING_TOKEN(STR_ERROR_POPUP),
   ideqval Date.Day == 30
   AND
   ideqval Date.Month == 2
-endif
+endif;
 
 //
 // If the day is 29 AND month is 2 AND it year is NOT a leapyear
 //
 inconsistentif prompt = STRING_TOKEN(STR_ERROR_POPUP),
@@ -558,11 +558,11 @@ formset
   AND
   ideqval Date.Month == 2
   AND
   NOT
   ideqvallist Date.Year == 2004 2008 20012 20016 2020 2024 2028 2032 
2036
-endif
+endif;
 
   enddate;
 
   text
 help   = STRING_TOKEN(STR_SAVE_CURRENT_AND_EXIT),
-- 
1.9.5.msysgit.1

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


[edk2] [Patch 0/2] Refine vfr grammar, keep consistent for the same condition opcode.

2015-10-14 Thread Eric Dong
In current implementation, the "endif" opcode for suppressif has an end ";" 
for the statement opcode, but has not for the option opcode. This is not a user 
friendly rule. This patch fixed it. Add an optional ";" end 
for option opcode to keep consistent with existed code. The same case also 
existed for grayoutif/disableif/inconsistentif/nosubmitif/warningif.

Eric Dong (2):
  BaseTools VfrCompiler: In order to keep consistent, add an optional
";" for condition op-code.
  MdeModulePkg DriverSampleDxe: Add optional ";" to keep consistent with
existed vfr op-code.

 BaseTools/Source/C/VfrCompile/VfrSyntax.g  | 12 ++--
 MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr | 16 
 2 files changed, 14 insertions(+), 14 deletions(-)

-- 
1.9.5.msysgit.1

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


[edk2] Do Edk2 support Secure Hash Algorithm-3 (SHA-3) Standard?

2015-10-14 Thread 王晓峰
Dear All,
   NIST released SHA-3 Standard this year,
 http://www.nist.gov/manuscript-publication-search.cfm?pub_id=919061
  Do edk2 plant to support this new algorithm or it has already been done?
  Thanks in advance !
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] KVM: MTRR: fix memory type handling if MTRR is completely disabled

2015-10-14 Thread Janusz
W dniu 14.10.2015 o 10:32, Xiao Guangrong pisze:
>
>
> On 10/14/2015 04:24 PM, Xiao Guangrong wrote:
>>
>>
>> On 10/14/2015 03:37 PM, Janusz wrote:
>>> I was able to run my virtual machine with this, but had very high cpu
>>> usage when something happen in it like booting system. once, my virtual
>>> machine hang and I couln't even get my mouse / keyboard back from qemu.
>>> When I did vga passthrough, I didn't get any video output, and cpu
>>> usage
>>> was also high. Tried it on 4.3
>>
>> Which tree are you using? Is it kvm tree?
>> Could you please work on queue brancn on current kvm tree based on
>> top commit 73917739334c6509: KVM: x86: fix SMI to halted VCPU.
>>
>> Hmm... interesting, this diff works on my box...
>
> Forgot to say that i built my test env following the instructions on
> kvm-wiki:
> http://www.linux-kvm.org/page/OVMF
>
> My test script is attached, and i will try to build the env like yours
> as much
> as possible...
I attach my script. I see that you are using pc-i440fx-2.1 - I use
default, I think its pc-i440fx-2.4, tried 2.3 some time ago and I get
the same problem. I will try with 2.1 after work
I am using  master from main kernel  tree, will also try this tree you
mentioned after work
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [Patch 0/2] Refine vfr grammar, keep consistent for the same condition opcode.

2015-10-14 Thread Gao, Liming
Reviewed-by: Liming Gao 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Eric Dong
Sent: Wednesday, October 14, 2015 4:29 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch 0/2] Refine vfr grammar, keep consistent for the same 
condition opcode.

In current implementation, the "endif" opcode for suppressif has an end ";" 
for the statement opcode, but has not for the option opcode. This is not a user 
friendly rule. This patch fixed it. Add an optional ";" end for option opcode 
to keep consistent with existed code. The same case also existed for 
grayoutif/disableif/inconsistentif/nosubmitif/warningif.

Eric Dong (2):
  BaseTools VfrCompiler: In order to keep consistent, add an optional
";" for condition op-code.
  MdeModulePkg DriverSampleDxe: Add optional ";" to keep consistent with
existed vfr op-code.

 BaseTools/Source/C/VfrCompile/VfrSyntax.g  | 12 ++--
 MdeModulePkg/Universal/DriverSampleDxe/Vfr.vfr | 16 
 2 files changed, 14 insertions(+), 14 deletions(-)

--
1.9.5.msysgit.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] KVM: MTRR: fix memory type handling if MTRR is completely disabled

2015-10-14 Thread Laszlo Ersek
On 10/14/15 10:32, Xiao Guangrong wrote:
> 
> 
> On 10/14/2015 04:24 PM, Xiao Guangrong wrote:
>>
>>
>> On 10/14/2015 03:37 PM, Janusz wrote:
>>> I was able to run my virtual machine with this, but had very high cpu
>>> usage when something happen in it like booting system. once, my virtual
>>> machine hang and I couln't even get my mouse / keyboard back from qemu.
>>> When I did vga passthrough, I didn't get any video output, and cpu usage
>>> was also high. Tried it on 4.3
>>
>> Which tree are you using? Is it kvm tree?
>> Could you please work on queue brancn on current kvm tree based on
>> top commit 73917739334c6509: KVM: x86: fix SMI to halted VCPU.
>>
>> Hmm... interesting, this diff works on my box...
> 
> Forgot to say that i built my test env following the instructions on
> kvm-wiki:
> http://www.linux-kvm.org/page/OVMF

Wow! Someone actually cares about the whitepaper. Thank you. :)

Laszlo

> 
> My test script is attached, and i will try to build the env like yours
> as much
> as possible...

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


[edk2] [Patch] BaseTools: Fix the issue to support windows root directory

2015-10-14 Thread Liming Gao
Use os.path.relpath to get the relative directory instead of directly trim it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 BaseTools/Source/Python/Common/MultipleWorkspace.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Common/MultipleWorkspace.py 
b/BaseTools/Source/Python/Common/MultipleWorkspace.py
index 8088404..feb1f8d 100644
--- a/BaseTools/Source/Python/Common/MultipleWorkspace.py
+++ b/BaseTools/Source/Python/Common/MultipleWorkspace.py
@@ -41,7 +41,7 @@ class MultipleWorkspace(object):
 @classmethod
 def convertPackagePath(cls, Ws, Path):
 if str(os.path.normcase (Path)).startswith(Ws):
-return os.path.join(Ws, Path[len(Ws) + 1:])
+return os.path.join(Ws, os.path.relpath(Path, Ws))
 return Path
 
 ## setWs()
-- 
1.9.5.msysgit.0

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


Re: [edk2] [PATCH] ShellPkg: Use safe string functions to refine Tftp.c code.

2015-10-14 Thread Bjorge, Erik C
Please put the 'if' statement on its own line.

-Erik

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Qiu 
Shumin
Sent: Tuesday, October 13, 2015 10:00 PM
To: edk2-devel@lists.01.org
Cc: Carsey, Jaben ; Qiu, Shumin 
Subject: [edk2] [PATCH] ShellPkg: Use safe string functions to refine Tftp.c 
code.

Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin 
---
 ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c 
b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
index 4bb21aa..02099fe 100644
--- a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
+++ b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
@@ -955,6 +955,7 @@ CheckPacket (
   UINTN Index;
   UINTN LastStep;
   UINTN Step;
+  EFI_STATUSStatus;
 
   if ((NTOHS (Packet->OpCode)) != EFI_MTFTP4_OPCODE_DATA) {
 return EFI_SUCCESS;
@@ -984,7 +985,10 @@ CheckPacket (
 
   ShellPrintEx (-1, -1, L"%s", mTftpProgressDelete);
 
-  StrCpy (Progress, mTftpProgressFrame);
+  Status = StrCpyS (Progress, TFTP_PROGRESS_MESSAGE_SIZE, 
+ mTftpProgressFrame);  if (EFI_ERROR(Status)) {
+return Status;
+  }
   for (Index = 1; Index < Step; Index++) {
 Progress[Index] = L'=';
   }
--
1.9.5.msysgit.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


[edk2] [PATCH v3 16/52] OvmfPkg: AcpiS3SaveDxe: don't fake LockBox protocol if SMM_REQUIRE

2015-10-14 Thread Laszlo Ersek
In SVN r15306 (git commit d4ba06df), "OvmfPkg: S3 Resume: fake LockBox
protocol for BootScriptExecutorDxe", we installed a fake LockBox protocol
in OVMF's AcpiS3SaveDxe clone. While our other AcpiS3SaveDxe
customizations remain valid (or harmless), said change is invalid when
OVMF is built with -D SMM_REQUIRE and includes the real protocol provider,
"MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf".

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf |  3 ++-
 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c  | 14 --
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf 
b/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
index 4cc0713..a288b95 100644
--- a/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
+++ b/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
@@ -59,7 +59,7 @@ [Guids]
   gEfiEndOfDxeEventGroupGuid## CONSUMES  ## Event
 
 [Protocols]
-  gEfiLockBoxProtocolGuid   # PROTOCOL ALWAYS_PRODUCED
+  gEfiLockBoxProtocolGuid   # PROTOCOL SOMETIMES_PRODUCED
   gEfiLegacyBiosProtocolGuid# PROTOCOL ALWAYS_CONSUMED
   gEfiLegacyRegion2ProtocolGuid # PROTOCOL SOMETIMES_CONSUMED
   gFrameworkEfiMpServiceProtocolGuid# PROTOCOL SOMETIMES_CONSUMED
@@ -71,6 +71,7 @@ [Pcd]
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize## 
CONSUMES
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3BootScriptStackSize   ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire## 
CONSUMES
 
 [Depex]
   gEfiVariableArchProtocolGuid AND gEfiVariableWriteArchProtocolGuid
diff --git a/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c 
b/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
index f20560f..e3ff234 100644
--- a/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
+++ b/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
@@ -538,12 +538,14 @@ InstallEndOfDxeCallback (
 return EFI_LOAD_ERROR;
   }
 
-  Status = gBS->InstallMultipleProtocolInterfaces (
-  ,
-  , NULL,
-  NULL
-  );
-  ASSERT_EFI_ERROR (Status);
+  if (!FeaturePcdGet (PcdSmmSmramRequire)) {
+Status = gBS->InstallMultipleProtocolInterfaces (
+,
+, NULL,
+NULL
+);
+ASSERT_EFI_ERROR (Status);
+  }
 
   Status = gBS->CreateEventEx (
   EVT_NOTIFY_SIGNAL,
-- 
1.8.3.1


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


[edk2] [PATCH v3 24/52] OvmfPkg: SmmCpuFeaturesLib: remove unnecessary bits

2015-10-14 Thread Laszlo Ersek
From: Paolo Bonzini 

SMRR and MTRR support is not needed on a virtual platform.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini 
Acked-by: Laszlo Ersek 
[ler...@redhat.com: insert space between ASSERT and (), convert to CRLF]
Cc: Paolo Bonzini 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v3:
- new in v3

 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf |   4 -
 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c   | 180 
++--
 2 files changed, 18 insertions(+), 166 deletions(-)

diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf 
b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
index b04c028..656dd08 100644
--- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
+++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
@@ -32,8 +32,4 @@ [Packages]
 [LibraryClasses]
   BaseLib
   PcdLib
-  MemoryAllocationLib
   DebugLib
-
-[Pcd]
-  gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber## 
SOMETIMES_CONSUMES
diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c 
b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
index dd09387..078ea96 100644
--- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
+++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
@@ -15,46 +15,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
-//
-// Machine Specific Registers (MSRs)
-//
-#define  SMM_FEATURES_LIB_IA32_MTRR_CAP0x0FE
-#define  SMM_FEATURES_LIB_IA32_FEATURE_CONTROL 0x03A
-#define  SMM_FEATURES_LIB_IA32_SMRR_PHYSBASE   0x1F2
-#define  SMM_FEATURES_LIB_IA32_SMRR_PHYSMASK   0x1F3
-#define  SMM_FEATURES_LIB_IA32_CORE_SMRR_PHYSBASE  0x0A0
-#define  SMM_FEATURES_LIB_IA32_CORE_SMRR_PHYSMASK  0x0A1
-#defineEFI_MSR_SMRR_MASK   0xF000
-#defineEFI_MSR_SMRR_PHYS_MASK_VALIDBIT11
-
-//
-// Set default value to assume SMRR is not supported
-//
-BOOLEAN  mSmrrSupported = FALSE;
-
-//
-// Set default value to assume IA-32 Architectural MSRs are used
-//
-UINT32  mSmrrPhysBaseMsr = SMM_FEATURES_LIB_IA32_SMRR_PHYSBASE;
-UINT32  mSmrrPhysMaskMsr = SMM_FEATURES_LIB_IA32_SMRR_PHYSMASK;
-
-//
-// Set default value to assume MTRRs need to be configured on each SMI
-//
-BOOLEAN  mNeedConfigureMtrrs = TRUE;
-
-//
-// Array for state of SMRR enable on all CPUs
-//
-BOOLEAN  *mSmrrEnabled;
-
 /**
   The constructor function 
 
@@ -68,91 +33,9 @@ SmmCpuFeaturesLibConstructor (
   IN EFI_SYSTEM_TABLE  *SystemTable
   )
 {
-  UINT32  RegEax;
-  UINT32  RegEdx;
-  UINTN   FamilyId;
-  UINTN   ModelId;
-
   //
-  // Retrieve CPU Family and Model 
+  // No need to program SMRRs on our virtual platform.
   //
-  AsmCpuid (CPUID_VERSION_INFO, , NULL, NULL, );
-  FamilyId = (RegEax >> 8) & 0xf;
-  ModelId  = (RegEax >> 4) & 0xf;
-  if (FamilyId == 0x06 || FamilyId == 0x0f) {
-ModelId = ModelId | ((RegEax >> 12) & 0xf0);
-  }
-
-  //
-  // Check CPUID(CPUID_VERSION_INFO).EDX[12] for MTRR capability
-  //
-  if ((RegEdx & BIT12) != 0) {
-//
-// Check MTRR_CAP MSR bit 11 for SMRR support
-//
-if ((AsmReadMsr64 (SMM_FEATURES_LIB_IA32_MTRR_CAP) & BIT11) != 0) {
-  mSmrrSupported = TRUE;
-}
-  }
-
-  //
-  // Intel(R) 64 and IA-32 Architectures Software Developer's Manual
-  // Volume 3C, Section 35.3 MSRs in the Intel(R) Atom(TM) Processor Family
-  // 
-  // If CPU Family/Model is 06_1CH, 06_26H, 06_27H, 06_35H or 06_36H, then 
-  // SMRR Physical Base and SMM Physical Mask MSRs are not available.
-  //
-  if (FamilyId == 0x06) {
-if (ModelId == 0x1C || ModelId == 0x26 || ModelId == 0x27 || ModelId == 
0x35 || ModelId == 0x36) {
-  mSmrrSupported = FALSE;
-}
-  }
-
-  //
-  // Intel(R) 64 and IA-32 Architectures Software Developer's Manual
-  // Volume 3C, Section 35.2 MSRs in the Intel(R) Core(TM) 2 Processor Family
-  //
-  // If CPU Family/Model is 06_0F or 06_17, then use Intel(R) Core(TM) 2 
-  // Processor Family MSRs 
-  //
-  if (FamilyId == 0x06) {
-if (ModelId == 0x17 || ModelId == 0x0f) {
-  mSmrrPhysBaseMsr = SMM_FEATURES_LIB_IA32_CORE_SMRR_PHYSBASE;
-  mSmrrPhysMaskMsr = SMM_FEATURES_LIB_IA32_CORE_SMRR_PHYSMASK;
-}
-  }
-  
-  //
-  // Intel(R) 64 and IA-32 Architectures Software Developer's Manual
-  // Volume 3C, Section 34.4.2 SMRAM Caching
-  //   An IA-32 processor does not automatically write back and invalidate its 
-  //   caches before entering SMM or before exiting SMM. Because of this 
behavior, 
-  //   care must be taken in the placement of the SMRAM in system memory and 
in 
-  //   the caching of the SMRAM to prevent cache incoherence when switching 
back 
-  //   and forth between 

[edk2] [PATCH v3 20/52] OvmfPkg: resolve CpuExceptionHandlerLib for DXE_SMM_DRIVER modules

2015-10-14 Thread Laszlo Ersek
UefiCpuPkg/PiSmmCpuDxeSmm depends on this library (the
RegisterCpuInterruptHandler() function specifically) to set up its
specialized page fault handler (SmiPFHandler() -> DumpModuleInfoByIp()).
It doesn't hurt to resolve this library class for all DXE_SMM_DRIVER
modules.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- new in v2 (the CpuExceptionHandlerLib dependency  of PiSmmCpuDxeSmm is
  new in Mike's code, relative to Quark)

 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 3 files changed, 3 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 6a93fd2..f3de592 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -308,6 +308,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
 !else
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
+  
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index dbaf8fb..ee97c84 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -313,6 +313,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
 !else
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
+  
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index a7efe52..6ab7ffe 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -313,6 +313,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
 !else
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
+  
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
-- 
1.8.3.1


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


[edk2] [PATCH v3 21/52] OvmfPkg: resolve DebugAgentLib for DXE_SMM_DRIVER modules

2015-10-14 Thread Laszlo Ersek
From: Michael Kinney 

Add mappings to DebugAgentLib for SMM modules to prevent build breaks when
SMM_REQUIRE and SOURCE_DEBUG_ENABLE are both set.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
[ler...@redhat.com: cover the X64 dsc, update commit msg, kudos Jordan]
Cc: Michael Kinney 
Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---

Notes:
v3:
- new in v3

 OvmfPkg/OvmfPkgIa32.dsc| 3 +++
 OvmfPkg/OvmfPkgIa32X64.dsc | 3 +++
 OvmfPkg/OvmfPkgX64.dsc | 3 +++
 3 files changed, 9 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index f3de592..f229edf 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -309,6 +309,9 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
+!ifdef $(SOURCE_DEBUG_ENABLE)
+  DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
+!endif
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index ee97c84..557c15f 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -314,6 +314,9 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
+!ifdef $(SOURCE_DEBUG_ENABLE)
+  DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
+!endif
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 6ab7ffe..4b6e6db 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -314,6 +314,9 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
+!ifdef $(SOURCE_DEBUG_ENABLE)
+  DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
+!endif
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
-- 
1.8.3.1


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


[edk2] [PATCH v3 13/52] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER

2015-10-14 Thread Laszlo Ersek
The EFI_SMM_COMMUNICATION_PROTOCOL implementation that is provided by the
SMM core depends on EFI_SMM_CONTROL2_PROTOCOL; see the
mSmmControl2->Trigger() call in the SmmCommunicationCommunicate() function
[MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c].

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- Set (APMC_EN|GBL_SMI_EN) in SMI_EN from the boot script at S3 resume.
  Otherwise, because SMI_EN is cleared during warm reset,
  SmmControl2DxeTrigger() would fail to trigger an SMI, and variable
  access through the runtime services would fail.

  Set SMI_LOCK in GEN_PMCON_1 similarly.

 OvmfPkg/OvmfPkgIa32.dsc   |   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc|   1 +
 OvmfPkg/OvmfPkgX64.dsc|   1 +
 OvmfPkg/OvmfPkgIa32.fdf   |   1 +
 OvmfPkg/OvmfPkgIa32X64.fdf|   1 +
 OvmfPkg/OvmfPkgX64.fdf|   1 +
 OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf |  65 
 OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c   | 365 
 8 files changed, 436 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index d7bc38d..c71a2f4 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -675,4 +675,5 @@ [Components]
 
 !if $(SMM_REQUIRE) == TRUE
   OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index e17cbe5..a1e8f0d 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -682,4 +682,5 @@ [Components.X64]
 
 !if $(SMM_REQUIRE) == TRUE
   OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index a748fb3..1176629 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -680,4 +680,5 @@ [Components]
 
 !if $(SMM_REQUIRE) == TRUE
   OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 285720f..43c9c30 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -357,6 +357,7 @@ [FV.DXEFV]
 
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+INF  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
 !endif
 
 

diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 02e8752..9446896 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -357,6 +357,7 @@ [FV.DXEFV]
 
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+INF  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
 !endif
 
 

diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index f04c36b..b272b76 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -357,6 +357,7 @@ [FV.DXEFV]
 
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+INF  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
 !endif
 
 

diff --git a/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf 
b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
new file mode 100644
index 000..bc66a27
--- /dev/null
+++ b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
@@ -0,0 +1,65 @@
+## @file
+# A DXE_RUNTIME_DRIVER providing synchronous SMI activations via the
+# EFI_SMM_CONTROL2_PROTOCOL.
+#
+# We expect the PEI phase to have covered the following:
+# - ensure that the underlying QEMU machine type be Q35
+#   (responsible: OvmfPkg/SmmAccess/SmmAccessPei.inf)
+# - ensure that the ACPI PM IO space be configured
+#   (responsible: OvmfPkg/PlatformPei/PlatformPei.inf)
+#
+# Our own entry point is responsible for confirming the SMI feature and for
+# configuring it.
+#
+# Copyright (C) 2013, 2015, Red Hat, Inc.
+#
+# 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= 0x00010005
+  BASE_NAME  = SmmControl2Dxe
+  FILE_GUID  = 1206F7CA-A475-4624-A83E-E6FC9BB38E49
+  MODULE_TYPE= DXE_RUNTIME_DRIVER
+  VERSION_STRING = 1.0
+  PI_SPECIFICATION_VERSION   = 0x00010400
+  ENTRY_POINT= SmmControl2DxeEntryPoint
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES  

[edk2] [PATCH v3 25/52] OvmfPkg: SmmCpuFeaturesLib: implement SMRAM state save map access

2015-10-14 Thread Laszlo Ersek
From: Paolo Bonzini 

This implementation copies SMRAM state save map access from the
PiSmmCpuDxeSmm module.

The most notable change is:

- dropping support for EFI_SMM_SAVE_STATE_REGISTER_IO

- changing the implementation of EFI_SMM_SAVE_STATE_REGISTER_LMA to use
  the SMM revision id instead of a local variable (which
  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c initializes from CPUID's LM
  bit).  This accounts for QEMU's implementation of x86_64, which always
  uses revision 0x20064 even if the LM bit is zero.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini 
[ler...@redhat.com: reflow commit message & fix typo, convert patch to
 CRLF]
Cc: Paolo Bonzini 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v3:
- new in v3

 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf |   2 +
 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c   | 377 
+++-
 2 files changed, 376 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf 
b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
index 656dd08..594d85b 100644
--- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
+++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
@@ -31,5 +31,7 @@ [Packages]
   
 [LibraryClasses]
   BaseLib
+  BaseMemoryLib
   PcdLib
   DebugLib
+  SmmServicesTableLib
diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c 
b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
index 078ea96..bd825b4 100644
--- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
+++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
@@ -15,11 +15,18 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
+//
+// EFER register LMA bit
+//
+#define LMA BIT10
+
 /**
   The constructor function 
 
@@ -125,7 +132,35 @@ SmmCpuFeaturesHookReturnFromSmm (
   IN UINT64NewInstructionPointer
   )
 {
-  return 0;
+  UINT64 OriginalInstructionPointer;
+  SMRAM_SAVE_STATE_MAP  *CpuSaveState = (SMRAM_SAVE_STATE_MAP *)CpuState;
+
+  if ((CpuSaveState->x86.SMMRevId & 0x) == 0) {
+OriginalInstructionPointer = (UINT64)CpuSaveState->x86._EIP;
+CpuSaveState->x86._EIP = (UINT32)NewInstructionPointer;
+//
+// Clear the auto HALT restart flag so the RSM instruction returns
+// program control to the instruction following the HLT instruction.
+//
+if ((CpuSaveState->x86.AutoHALTRestart & BIT0) != 0) {
+  CpuSaveState->x86.AutoHALTRestart &= ~BIT0;
+}
+  } else {
+OriginalInstructionPointer = CpuSaveState->x64._RIP;
+if ((CpuSaveState->x64.IA32_EFER & LMA) == 0) {
+  CpuSaveState->x64._RIP = (UINT32)NewInstructionPointer32;
+} else {
+  CpuSaveState->x64._RIP = (UINT32)NewInstructionPointer;
+}
+//
+// Clear the auto HALT restart flag so the RSM instruction returns
+// program control to the instruction following the HLT instruction.
+//
+if ((CpuSaveState->x64.AutoHALTRestart & BIT0) != 0) {
+  CpuSaveState->x64.AutoHALTRestart &= ~BIT0;
+}
+  }
+  return OriginalInstructionPointer;
 }
 
 /**
@@ -356,6 +391,213 @@ SmmCpuFeaturesSetSmmRegister (
   ASSERT (FALSE);
 }
 
+///
+/// Macro used to simplify the lookup table entries of type 
CPU_SMM_SAVE_STATE_LOOKUP_ENTRY
+///
+#define SMM_CPU_OFFSET(Field) OFFSET_OF (SMRAM_SAVE_STATE_MAP, Field)
+
+///
+/// Macro used to simplify the lookup table entries of type 
CPU_SMM_SAVE_STATE_REGISTER_RANGE
+///
+#define SMM_REGISTER_RANGE(Start, End) { Start, End, End - Start + 1 }
+
+///
+/// Structure used to describe a range of registers
+///
+typedef struct {
+  EFI_SMM_SAVE_STATE_REGISTER  Start;
+  EFI_SMM_SAVE_STATE_REGISTER  End;
+  UINTNLength;
+} CPU_SMM_SAVE_STATE_REGISTER_RANGE;
+
+///
+/// Structure used to build a lookup table to retrieve the widths and offsets
+/// associated with each supported EFI_SMM_SAVE_STATE_REGISTER value
+///
+
+#define SMM_SAVE_STATE_REGISTER_FIRST_INDEX 1
+
+typedef struct {
+  UINT8   Width32;
+  UINT8   Width64;
+  UINT16  Offset32;
+  UINT16  Offset64Lo;
+  UINT16  Offset64Hi;
+  BOOLEAN Writeable;
+} CPU_SMM_SAVE_STATE_LOOKUP_ENTRY;
+
+///
+/// Table used by GetRegisterIndex() to convert an EFI_SMM_SAVE_STATE_REGISTER 
+/// value to an index into a table of type CPU_SMM_SAVE_STATE_LOOKUP_ENTRY
+///
+static CONST CPU_SMM_SAVE_STATE_REGISTER_RANGE mSmmCpuRegisterRanges[] = {
+  SMM_REGISTER_RANGE (EFI_SMM_SAVE_STATE_REGISTER_GDTBASE, 
EFI_SMM_SAVE_STATE_REGISTER_LDTINFO),
+  SMM_REGISTER_RANGE (EFI_SMM_SAVE_STATE_REGISTER_ES,  
EFI_SMM_SAVE_STATE_REGISTER_RIP),
+  SMM_REGISTER_RANGE (EFI_SMM_SAVE_STATE_REGISTER_RFLAGS,  

[edk2] [PATCH v3 26/52] OvmfPkg: SmmCpuFeaturesLib: customize state save map format

2015-10-14 Thread Laszlo Ersek
From: Paolo Bonzini 

This adjusts the previously introduced state save map access functions, to
account for QEMU and KVM's 64-bit state save map following the AMD spec
rather than the Intel one.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini 
[ler...@redhat.com: reflow commit message, convert patch to CRLF]
Cc: Paolo Bonzini 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v3:
- new in v3

 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf |   1 +
 OvmfPkg/Include/Register/QemuSmramSaveStateMap.h| 184 

 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c   |  50 +++---
 3 files changed, 212 insertions(+), 23 deletions(-)

diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf 
b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
index 594d85b..aaf4b02 100644
--- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
+++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
@@ -27,6 +27,7 @@ [Sources]
 
 [Packages]
   MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
   UefiCpuPkg/UefiCpuPkg.dec
   
 [LibraryClasses]
diff --git a/OvmfPkg/Include/Register/QemuSmramSaveStateMap.h 
b/OvmfPkg/Include/Register/QemuSmramSaveStateMap.h
new file mode 100644
index 000..389428d
--- /dev/null
+++ b/OvmfPkg/Include/Register/QemuSmramSaveStateMap.h
@@ -0,0 +1,184 @@
+/** @file
+SMRAM Save State Map Definitions.
+
+SMRAM Save State Map definitions based on contents of the 
+Intel(R) 64 and IA-32 Architectures Software Developer's Manual
+  Volume 3C, Section 34.4 SMRAM
+  Volume 3C, Section 34.5 SMI Handler Execution Environment
+  Volume 3C, Section 34.7 Managing Synchronous and Asynchronous SMIs
+
+and the AMD64 Architecture Programmer's Manual
+  Volume 2, Section 10.2 SMM Resources
+
+Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015, Red Hat, Inc.
+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 __QEMU_SMRAM_SAVE_STATE_MAP_H__
+#define __QEMU_SMRAM_SAVE_STATE_MAP_H__
+
+#pragma pack (1)
+
+///
+/// 32-bit SMRAM Save State Map
+///
+typedef struct {
+  UINT8   Reserved0[0x200]; // 7c00h
+  UINT8   Reserved1[0xf8];  // 7e00h
+  UINT32  SMBASE;   // 7ef8h
+  UINT32  SMMRevId; // 7efch
+  UINT16  IORestart;// 7f00h
+  UINT16  AutoHALTRestart;  // 7f02h
+  UINT8   Reserved2[0x9C];  // 7f08h
+  UINT32  IOMemAddr;// 7fa0h
+  UINT32  IOMisc;   // 7fa4h
+  UINT32  _ES;  // 7fa8h
+  UINT32  _CS;  // 7fach
+  UINT32  _SS;  // 7fb0h
+  UINT32  _DS;  // 7fb4h
+  UINT32  _FS;  // 7fb8h
+  UINT32  _GS;  // 7fbch
+  UINT32  Reserved3;// 7fc0h
+  UINT32  _TR;  // 7fc4h
+  UINT32  _DR7; // 7fc8h
+  UINT32  _DR6; // 7fcch
+  UINT32  _EAX; // 7fd0h
+  UINT32  _ECX; // 7fd4h
+  UINT32  _EDX; // 7fd8h
+  UINT32  _EBX; // 7fdch
+  UINT32  _ESP; // 7fe0h
+  UINT32  _EBP; // 7fe4h
+  UINT32  _ESI; // 7fe8h
+  UINT32  _EDI; // 7fech
+  UINT32  _EIP; // 7ff0h
+  UINT32  _EFLAGS;  // 7ff4h
+  UINT32  _CR3; // 7ff8h
+  UINT32  _CR0; // 7ffch
+} QEMU_SMRAM_SAVE_STATE_MAP32;
+
+///
+/// 64-bit SMRAM Save State Map
+///
+typedef struct {
+  UINT8   Reserved0[0x200];  // 7c00h
+
+  UINT16  _ES;   // 7e00h
+  UINT16  _ESAccessRights;   // 7e02h
+  UINT32  _ESLimit;  // 7e04h
+  UINT64  _ESBase;   // 7e08h
+
+  UINT16  _CS;   // 7e10h
+  UINT16  _CSAccessRights;   // 7e12h
+  UINT32  _CSLimit;  // 7e14h
+  UINT64  _CSBase;   // 7e18h
+
+  UINT16  _SS;   // 7e20h
+  UINT16  _SSAccessRights;   // 7e22h
+  UINT32  _SSLimit;  // 7e24h
+  UINT64  _SSBase;   // 7e28h
+
+  UINT16  _DS;   // 7e30h
+  UINT16  _DSAccessRights;   // 7e32h
+  UINT32  _DSLimit;  // 7e34h
+  UINT64  _DSBase;   // 7e38h
+
+  UINT16  _FS;   // 7e40h
+  UINT16  _FSAccessRights;   // 7e42h
+  UINT32  _FSLimit;  // 7e44h
+  UINT64  _FSBase;   // 7e48h
+
+  UINT16  _GS;   // 7e50h
+  UINT16  _GSAccessRights;   // 7e52h
+  UINT32  _GSLimit;  // 7e54h
+  UINT64  _GSBase;   // 7e58h
+
+  UINT32  _GDTRReserved1;// 7e60h
+  UINT16  _GDTRLimit;// 7e64h
+  UINT16  _GDTRReserved2;// 

[edk2] [PATCH v3 04/52] UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs

2015-10-14 Thread Laszlo Ersek
The

  Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuArchDxe

driver applies any MTRR changes to APs, if the EFI_MP_SERVICES_PROTOCOL is
available. We should do the same.

Additionally, the broadcast should occur at MP startup as well, not only
when MTRR settings are changed. The inspiration is taken from

  Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe/

(see the EarlyMpInit() function and its call sites in
"ProcessorConfig.c").

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jeff Fan 
---

Notes:
v3:
- Although Jeff reviewed this, I'm not committing it just yet, because
  contextually it is on top of Mike's pending patches. Picked up the R-b
  tag from Jeff though. No code changes.

v2:
- This patch replaces the following patches from v1:
  - UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory
block
  - UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs
  - UefiCpuPkg: CpuDxe: sync MTRR settings to APs at MP startup
  - UefiCpuPkg: CpuDxe: provide EFI_MP_SERVICES_PROTOCOL when there's no
AP

  The first v1 patch was deemed inappropriate for general use, and Mike
  suggested a good alternative for OVMF (=> grab MTRR settings in
  CpuS3DataDxe at EndOfDxe).

  The second and third v1 patches are now squashed together into this v2
  patch; they are small and belong together logically.

  The fourth v1 patch is redundant now; the same has been covered by
  Mike.

 UefiCpuPkg/CpuDxe/CpuMp.h  | 13 
 UefiCpuPkg/CpuDxe/CpuDxe.c | 26 +++
 UefiCpuPkg/CpuDxe/CpuMp.c  | 34 +++-
 3 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuMp.h b/UefiCpuPkg/CpuDxe/CpuMp.h
index d2866e4..503f3ae 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.h
+++ b/UefiCpuPkg/CpuDxe/CpuMp.h
@@ -643,5 +643,18 @@ ResetApStackless (
   IN UINT32 ProcessorId
   );
 
+/**
+  A minimal wrapper function that allows MtrrSetAllMtrrs() to be passed to
+  EFI_MP_SERVICES_PROTOCOL.StartupAllAPs() as Procedure.
+
+  @param[in] Buffer  Pointer to an MTRR_SETTINGS object, to be passed to
+ MtrrSetAllMtrrs().
+**/
+VOID
+EFIAPI
+SetMtrrsFromBuffer (
+  IN VOID *Buffer
+  );
+
 #endif // _CPU_MP_H_
 
diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c
index c9df4e1..daf97bd 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.c
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
@@ -350,6 +350,9 @@ CpuSetMemoryAttributes (
 {
   RETURN_STATUS Status;
   MTRR_MEMORY_CACHE_TYPECacheType;
+  EFI_STATUSMpStatus;
+  EFI_MP_SERVICES_PROTOCOL  *MpService;
+  MTRR_SETTINGS MtrrSettings;
 
   if (!IsMtrrSupported ()) {
 return EFI_UNSUPPORTED;
@@ -405,6 +408,29 @@ CpuSetMemoryAttributes (
  CacheType
  );
 
+  if (!RETURN_ERROR (Status)) {
+MpStatus = gBS->LocateProtocol (
+  ,
+  NULL,
+  (VOID **)
+  );
+//
+// Synchronize the update with all APs
+//
+if (!EFI_ERROR (MpStatus)) {
+  MtrrGetAllMtrrs ();
+  MpStatus = MpService->StartupAllAPs (
+  MpService,  // This
+  SetMtrrsFromBuffer, // Procedure
+  TRUE,   // SingleThread
+  NULL,   // WaitEvent
+  0,  // TimeoutInMicrosecsond
+  ,  // ProcedureArgument
+  NULL// FailedCpuList
+  );
+  ASSERT (MpStatus == EFI_SUCCESS || MpStatus == EFI_NOT_STARTED);
+}
+  }
   return (EFI_STATUS) Status;
 }
 
diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
index da3686e..fbe43f5 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -1626,6 +1626,22 @@ ExitBootServicesCallback (
 }
 
 /**
+  A minimal wrapper function that allows MtrrSetAllMtrrs() to be passed to
+  EFI_MP_SERVICES_PROTOCOL.StartupAllAPs() as Procedure.
+
+  @param[in] Buffer  Pointer to an MTRR_SETTINGS object, to be passed to
+ MtrrSetAllMtrrs().
+**/
+VOID
+EFIAPI
+SetMtrrsFromBuffer (
+  IN VOID *Buffer
+  )
+{
+  MtrrSetAllMtrrs (Buffer);
+}
+
+/**
   Initialize Multi-processor support.
 
 **/
@@ -1634,7 +1650,8 @@ InitializeMpSupport (
   VOID
   )
 {
-  EFI_STATUS Status;
+  EFI_STATUSStatus;
+  MTRR_SETTINGS MtrrSettings;
 
   gMaxLogicalProcessorNumber = (UINTN) PcdGet32 
(PcdCpuMaxLogicalProcessorNumber);
   if (gMaxLogicalProcessorNumber < 1) {
@@ -1690,6 +1707,21 @@ InitializeMpSupport (
   //
   CollectBistDataFromHob ();
 
+  //
+  // Synchronize MTRR settings to APs.
+  //
+  MtrrGetAllMtrrs ();
+  Status = mMpServicesTemplate.StartupAllAPs (
+  

[edk2] [PATCH v3 08/52] OvmfPkg: decompress FVs on S3 resume if SMM_REQUIRE is set

2015-10-14 Thread Laszlo Ersek
If OVMF was built with -D SMM_REQUIRE, that implies that the runtime OS is
not trusted and we should defend against it tampering with the firmware's
data.

One such datum is the PEI firmware volume (PEIFV). Normally PEIFV is
decompressed on the first boot by SEC, then the OS preserves it across S3
suspend-resume cycles; at S3 resume SEC just reuses the originally
decompressed PEIFV.

However, if we don't trust the OS, then SEC must decompress PEIFV from the
pristine flash every time, lest we execute OS-injected code or work with
OS-injected data.

Due to how FVMAIN_COMPACT is organized, we can't decompress just PEIFV;
the decompression brings DXEFV with itself, plus it uses a temporary
output buffer and a scratch buffer too, which even reach above the end of
the finally installed DXEFV. For this reason we must keep away a
non-malicious OS from DXEFV too, plus the memory up to
PcdOvmfDecomprScratchEnd.

The delay introduced by the LZMA decompression on S3 resume is negligible.

If -D SMM_REQUIRE is not specified, then PcdSmmSmramRequire remains FALSE
(from the DEC file), and then this patch has no effect (not counting some
changed debug messages).

If QEMU doesn't support S3 (or the user disabled it on the QEMU command
line), then this patch has no effect also.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---

Notes:
v2:
- PcdOvmfDecomprScratchEnd => PcdOvmfDecompressionScratchEnd [Jordan]
  

- "S3 resume (insecure)" => "S3 resume",
  "S3 resume (hopefully secure)" => "S3 resume (with PEI decompression)"
  [Jordan]
  

 OvmfPkg/PlatformPei/PlatformPei.inf |  4 +++
 OvmfPkg/PlatformPei/Fv.c| 27 +++-
 OvmfPkg/PlatformPei/MemDetect.c | 11 +++-
 OvmfPkg/Sec/SecMain.c   | 16 ++--
 4 files changed, 54 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 0c7ae5f..62f64fe 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -74,6 +74,7 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
   gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize
   gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
   gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
@@ -88,6 +89,9 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable
   gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
 
+[FeaturePcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
+
 [Ppis]
   gEfiPeiMasterBootModePpiGuid
 
diff --git a/OvmfPkg/PlatformPei/Fv.c b/OvmfPkg/PlatformPei/Fv.c
index 3ed775c..248c585 100644
--- a/OvmfPkg/PlatformPei/Fv.c
+++ b/OvmfPkg/PlatformPei/Fv.c
@@ -32,6 +32,8 @@ PeiFvInitialization (
   VOID
   )
 {
+  BOOLEAN SecureS3Needed;
+
   DEBUG ((EFI_D_INFO, "Platform PEI Firmware Volume Initialization\n"));
 
   //
@@ -50,16 +52,39 @@ PeiFvInitialization (
   //
   BuildFvHob (PcdGet32 (PcdOvmfDxeMemFvBase), PcdGet32 (PcdOvmfDxeMemFvSize));
 
+  SecureS3Needed = mS3Supported && FeaturePcdGet (PcdSmmSmramRequire);
+
   //
   // Create a memory allocation HOB for the DXE FV.
   //
+  // If "secure" S3 is needed, then SEC will decompress both PEI and DXE
+  // firmware volumes at S3 resume too, hence we need to keep away the OS from
+  // DXEFV as well. Otherwise we only need to keep away DXE itself from the
+  // DXEFV area.
+  //
   BuildMemoryAllocationHob (
 PcdGet32 (PcdOvmfDxeMemFvBase),
 PcdGet32 (PcdOvmfDxeMemFvSize),
-EfiBootServicesData
+SecureS3Needed ? EfiACPIMemoryNVS : EfiBootServicesData
 );
 
   //
+  // Additionally, said decompression will use temporary memory above the end
+  // of DXEFV, so let's keep away the OS from there too.
+  //
+  if (SecureS3Needed) {
+UINT32 DxeMemFvEnd;
+
+DxeMemFvEnd = PcdGet32 (PcdOvmfDxeMemFvBase) +
+  PcdGet32 (PcdOvmfDxeMemFvSize);
+BuildMemoryAllocationHob (
+  DxeMemFvEnd,
+  PcdGet32 (PcdOvmfDecompressionScratchEnd) - DxeMemFvEnd,
+  EfiACPIMemoryNVS
+  );
+  }
+
+  //
   // Let PEI know about the DXE FV so it can find the DXE Core
   //
   PeiServicesInstallFvInfoPpi (
diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 612bb4a..5fe8b28 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -222,7 +222,16 @@ PublishPeiMemory (
 //
 // Determine the range of memory to use during PEI
 //
-MemoryBase = PcdGet32 (PcdOvmfDxeMemFvBase) + PcdGet32 

[edk2] [PATCH v3 22/52] OvmfPkg: set gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection to FALSE

2015-10-14 Thread Laszlo Ersek
Explanation from Michael Kinney:

  This PCD allows a platform to provide PlatformSmmBspElection() in a
  platform specific SmmCpuPlatformHookLib instance to decide which CPU
  gets elected to be the BSP in each SMI.

  The SmmCpuPlatformHookLibNull [instance] always returns EFI_NOT_READY
  for that function, which makes the module behave the same as the PCD
  being set to FALSE.

  The default is TRUE, so the platform lib is always called, so a platform
  developer can implement the hook function and does not have to also
  change a PCD setting for the hook function to be active.

  A platform that wants to eliminate the call to the hook function
  [altogether] can set the PCD to FALSE.

  So for OVMF, I think it makes sense to set this PCD to FALSE in the DSC
  file.

Suggested-by: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- This patch replaces the v1 patch "OvmfPkg: import PCDs from
  Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg". That patch overrode the
  default for the PCD just the same, but it used different justification
  (= "Quark's IA32FamilyCpuBasePkg.dsc disables it too"). Plus, the goal
  of that patch was primarily to import PCDs to OvmfPkg.dec, under
  "gQuarkPortCpuTokenSpaceGuid", which is now unnecessary due to Mike's
  work.

 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 3 files changed, 3 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index f229edf..f115ce5 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -345,6 +345,7 @@ [PcdsFeatureFlag]
 !endif
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
 !endif
 
 [PcdsFixedAtBuild]
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 557c15f..4949028 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -350,6 +350,7 @@ [PcdsFeatureFlag]
 !endif
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
 !endif
 
 [PcdsFixedAtBuild]
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 4b6e6db..4095ce9 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -350,6 +350,7 @@ [PcdsFeatureFlag]
 !endif
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
 !endif
 
 [PcdsFixedAtBuild]
-- 
1.8.3.1


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


[edk2] [PATCH v3 18/52] OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRE

2015-10-14 Thread Laszlo Ersek
During DXE, drivers save data in the LockBox. A save operation is layered
as follows:

- The unprivileged driver wishing to store data in the LockBox links
  against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf"
  library instance.

  The library allows the unprivileged driver to format requests for the
  privileged SMM LockBox driver (see below), and to parse responses.

  We apply this resolution for DXE_DRIVER modules.

- The privileged SMM LockBox driver is built from
  "MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". This driver
  has module type DXE_SMM_DRIVER and can access SMRAM.

  The driver delegates command parsing and response formatting to
  "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf".

  Therefore we include this DXE_SMM_DRIVER in the build, and apply said
  resolution specifically to it.

  (Including the driver requires us to resolve a few of other library
  classes for DXE_SMM_DRIVER modules.)

- In PEI, the S3 Resume PEIM (UefiCpuPkg/Universal/Acpi/S3Resume2Pei)
  retrieves data from the LockBox. It is capable of searching SMRAM
  itself.

  We resolve LockBoxLib to
  "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" specifically
  for this one PEIM.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 16 
 OvmfPkg/OvmfPkgIa32X64.dsc | 16 
 OvmfPkg/OvmfPkgX64.dsc | 16 
 OvmfPkg/OvmfPkgIa32.fdf|  1 +
 OvmfPkg/OvmfPkgIa32X64.fdf |  1 +
 OvmfPkg/OvmfPkgX64.fdf |  1 +
 6 files changed, 51 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 6cfd58e..a19d4e2 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -106,7 +106,9 @@ [LibraryClasses]
   QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
   VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
   LoadLinuxLib|OvmfPkg/Library/LoadLinuxLib/LoadLinuxLib.inf
+!if $(SMM_REQUIRE) == FALSE
   LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
+!endif
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
 
 !ifdef $(SOURCE_DEBUG_ENABLE)
@@ -272,7 +274,11 @@ [LibraryClasses.common.DXE_DRIVER]
   DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
   PlatformBdsLib|OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
+!if $(SMM_REQUIRE) == TRUE
+  LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
+!else
   LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
+!endif
 !ifdef $(SOURCE_DEBUG_ENABLE)
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
 !endif
@@ -292,6 +298,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
 [LibraryClasses.common.DXE_SMM_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+  
MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
+  HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
+  SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
   
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
 !ifdef $(DEBUG_ON_SERIAL_PORT)
   DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
@@ -461,6 +470,9 @@ [Components]
   UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf {
 
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
+!if $(SMM_REQUIRE) == TRUE
+  LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
+!endif
   }
 !if $(SMM_REQUIRE) == TRUE
   OvmfPkg/SmmAccess/SmmAccessPei.inf {
@@ -708,4 +720,8 @@ [Components]
   # Privileged drivers (DXE_SMM_DRIVER modules)
   #
   UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
+  MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf {
+
+  LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
+  }
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 6679e8a..d177154 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -111,7 +111,9 @@ [LibraryClasses]
   QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
   VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
   LoadLinuxLib|OvmfPkg/Library/LoadLinuxLib/LoadLinuxLib.inf
+!if $(SMM_REQUIRE) == FALSE
   LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
+!endif
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
 
 !ifdef $(SOURCE_DEBUG_ENABLE)
@@ -277,7 +279,11 @@ [LibraryClasses.common.DXE_DRIVER]
   DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
   PlatformBdsLib|OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
+!if $(SMM_REQUIRE) == TRUE
+  LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
+!else
   

[edk2] [PATCH v3 27/52] OvmfPkg: use relaxed AP SMM synchronization mode

2015-10-14 Thread Laszlo Ersek
From: Paolo Bonzini 

Port 0xb2 on QEMU only sends an SMI to the currently executing processor.
The SMI handler, however, and in particular SmmWaitForApArrival, currently
expects that SmmControl2DxeTrigger triggers an SMI IPI on all processors
rather than just the BSP.  Thus all SMM invocations loop for a second (the
default value of PcdCpuSmmApSyncTimeout) before SmmWaitForApArrival sends
another SMI IPI to the APs.

With the default SmmCpuFeaturesLib, 32-bit machines must broadcast SMIs
because 32-bit machines must reset the MTRRs on each entry to system
management modes (they have no SMRRs).  However, our virtual platform
does not have problems with cacheability of SMRAM, so we can use "directed"
SMIs instead.  To do this, just set gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode
to 1 (aka SmmCpuSyncModeRelaxedAp).  This fixes SMM on multiprocessor virtual
machines.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini 
---

Notes:
v3:
- new in v3

 OvmfPkg/OvmfPkgIa32.dsc| 4 
 OvmfPkg/OvmfPkgIa32X64.dsc | 4 
 OvmfPkg/OvmfPkgX64.dsc | 4 
 3 files changed, 12 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index f115ce5..263d4d0 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -398,6 +398,10 @@ [PcdsFixedAtBuild]
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 
0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
 !endif
 
+!if $(SMM_REQUIRE) == TRUE
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
+!endif
+
 !if $(SECURE_BOOT_ENABLE) == TRUE
   # override the default values from SecurityPkg to ensure images from all 
sources are verified in secure boot
   gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 4949028..8101d91 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -404,6 +404,10 @@ [PcdsFixedAtBuild]
 !endif
 
 [PcdsFixedAtBuild.X64]
+!if $(SMM_REQUIRE) == TRUE
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
+!endif
+
 !if $(SECURE_BOOT_ENABLE) == TRUE
   # override the default values from SecurityPkg to ensure images from all 
sources are verified in secure boot
   gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 4095ce9..0482232 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -403,6 +403,10 @@ [PcdsFixedAtBuild]
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 
0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
 !endif
 
+!if $(SMM_REQUIRE) == TRUE
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
+!endif
+
 !if $(SECURE_BOOT_ENABLE) == TRUE
   # override the default values from SecurityPkg to ensure images from all 
sources are verified in secure boot
   gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04
-- 
1.8.3.1


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


[edk2] [PATCH v3 10/52] OvmfPkg: PlatformPei: account for TSEG size with PcdSmmSmramRequire set

2015-10-14 Thread Laszlo Ersek
PlatformPei calls GetSystemMemorySizeBelow4gb() in three locations:

- PublishPeiMemory(): on normal boot, the permanent PEI RAM is installed
  so that it ends with the RAM below 4GB,

- QemuInitializeRam(): on normal boot, memory resource descriptor HOBs are
  created for the RAM below 4GB; plus MTRR attributes are set
  (independently of S3 vs. normal boot)

- MemMapInitialization(): an MMIO resource descriptor HOB is created for
  PCI resource allocation, on normal boot, starting at max(RAM below 4GB,
  2GB).

The first two of these is adjusted for the configured TSEG size, if
PcdSmmSmramRequire is set:

- In PublishPeiMemory(), the permanent PEI RAM is kept under TSEG.

- In QemuInitializeRam(), we must keep the DXE out of TSEG.

  One idea would be to simply trim the [1MB .. LowerMemorySize] memory
  resource descriptor HOB, leaving a hole for TSEG in the memory space
  map.

  The SMM IPL will however want to massage the caching attributes of the
  SMRAM range that it loads the SMM core into, with
  gDS->SetMemorySpaceAttributes(), and that won't work on a hole. So,
  instead of trimming this range, split the TSEG area off, and report it
  as a cacheable reserved memory resource.

  Finally, since reserved memory can be allocated too, pre-allocate TSEG
  in InitializeRamRegions(), after QemuInitializeRam() returns. (Note that
  this step alone does not suffice without the resource descriptor HOB
  trickery: if we omit that, then the DXE IPL PEIM fails to load and start
  the DXE core.)

- In MemMapInitialization(), the start of the PCI MMIO range is not
  affected.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---
 OvmfPkg/OvmfPkg.dec |  7 
 OvmfPkg/PlatformPei/PlatformPei.inf |  1 +
 OvmfPkg/PlatformPei/MemDetect.c | 34 +++-
 3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 3fab2af..da6967f 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -93,6 +93,13 @@ [PcdsFixedAtBuild]
   gUefiOvmfPkgTokenSpaceGuid.PcdVirtioScsiMaxTargetLimit|31|UINT16|6
   gUefiOvmfPkgTokenSpaceGuid.PcdVirtioScsiMaxLunLimit|7|UINT32|7
 
+  ## The following setting controls how many megabytes we configure as TSEG on
+  #  Q35, for SMRAM purposes. Permitted values are: 1, 2, 8. Other values cause
+  #  undefined behavior.
+  #
+  #  This PCD is only consulted if PcdSmmSmramRequire is TRUE (see below).
+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|1|UINT8|0x20
+
 [PcdsFixedAtBuild]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogBase|0x0|UINT32|0x8
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogSize|0x0|UINT32|0x9
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 62f64fe..ee044a2 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -75,6 +75,7 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize
   gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
   gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 5fe8b28..1bdc2df 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -214,6 +214,12 @@ PublishPeiMemory (
 MemorySize = PcdGet32 (PcdS3AcpiReservedMemorySize);
   } else {
 LowerMemorySize = GetSystemMemorySizeBelow4gb ();
+if (FeaturePcdGet (PcdSmmSmramRequire)) {
+  //
+  // TSEG is chipped from the end of low RAM
+  //
+  LowerMemorySize -= FixedPcdGet8 (PcdQ35TsegMbytes) * SIZE_1MB;
+}
 
 PeiMemoryCap = GetPeiMemoryCap ();
 DEBUG ((EFI_D_INFO, "%a: mPhysMemAddressWidth=%d PeiMemoryCap=%u KB\n",
@@ -277,7 +283,18 @@ QemuInitializeRam (
 // Create memory HOBs
 //
 AddMemoryRangeHob (0, BASE_512KB + BASE_128KB);
-AddMemoryRangeHob (BASE_1MB, LowerMemorySize);
+
+if (FeaturePcdGet (PcdSmmSmramRequire)) {
+  UINT32 TsegSize;
+
+  TsegSize = FixedPcdGet8 (PcdQ35TsegMbytes) * SIZE_1MB;
+  AddMemoryRangeHob (BASE_1MB, LowerMemorySize - TsegSize);
+  AddReservedMemoryBaseSizeHob (LowerMemorySize - TsegSize, TsegSize,
+TRUE);
+} else {
+  AddMemoryRangeHob (BASE_1MB, LowerMemorySize);
+}
+
 if (UpperMemorySize != 0) {
   AddUntestedMemoryBaseSizeHob (BASE_4GB, UpperMemorySize);
 }
@@ -409,5 +426,20 @@ InitializeRamRegions (
   (UINT64)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize),
   mS3Supported ? EfiACPIMemoryNVS : EfiBootServicesData
   );
+
+if (FeaturePcdGet (PcdSmmSmramRequire)) {
+  UINT32 

[edk2] [PATCH v3 39/52] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: strip trailing whitespace

2015-10-14 Thread Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h | 16 
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c| 16 
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c |  6 +++---
 3 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
index 06a092d..0dcd26d 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
@@ -1,18 +1,18 @@
 /**@file
 
 Copyright (c) 2006, 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
-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.  
   
+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.
 
 Module Name:
 
   FwBlockService.h
-  
+
 Abstract:
 
   Firmware volume block driver for Intel Firmware Hub (FWH) device
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c
index 62f9158..4eb6961 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c
@@ -1,13 +1,13 @@
 /**@file
 
 Copyright (c) 2006, 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
-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.  
   
+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.
 
 Module Name:
 
@@ -75,7 +75,7 @@ EFI_FVB_MEDIA_INFO  mPlatformFvbMediaInfo[] = {
   FixedPcdGet32 (PcdFlashNvStorageFtwSpareSize) +
   FixedPcdGet32 (PcdOvmfFlashNvStorageEventLogSize),
   EFI_FVH_SIGNATURE,
-  EFI_FVB2_MEMORY_MAPPED |  
+  EFI_FVB2_MEMORY_MAPPED |
 EFI_FVB2_READ_ENABLED_CAP |
 EFI_FVB2_READ_STATUS |
 EFI_FVB2_WRITE_ENABLED_CAP |
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
index 9160bb8..075fac3 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
@@ -871,7 +871,7 @@ Returns:
   ) {
 return EFI_NOT_FOUND;
   }
-  
+
   //
   // Verify the header checksum
   //
@@ -944,7 +944,7 @@ InitializeVariableFvHeader (
 (EFI_FIRMWARE_VOLUME_HEADER *) (UINTN)
   PcdGet32 (PcdOvmfFlashNvStorageVariableBase);
 
-  Length = 
+  Length =
 (FixedPcdGet32 (PcdFlashNvStorageVariableSize) +
  FixedPcdGet32 (PcdFlashNvStorageFtwWorkingSize) +
  FixedPcdGet32 (PcdFlashNvStorageFtwSpareSize) +
@@ -1139,7 +1139,7 @@ Returns:
   } else {
 FvbDevice->DevicePath = (EFI_DEVICE_PATH_PROTOCOL *) AllocateCopyPool 
(sizeof (FV_PIWG_DEVICE_PATH), );
 CopyGuid (
-  &((FV_PIWG_DEVICE_PATH *)FvbDevice->DevicePath)->FvDevPath.FvName, 
+  &((FV_PIWG_DEVICE_PATH *)FvbDevice->DevicePath)->FvDevPath.FvName,
   (GUID *)(UINTN)(BaseAddress + FwVolHeader->ExtHeaderOffset)
   );
   }
-- 
1.8.3.1


___
edk2-devel mailing list
edk2-devel@lists.01.org

[edk2] [PATCH v3 41/52] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: fix VALID_ARCHITECTURES in INF

2015-10-14 Thread Laszlo Ersek
We build this driver for X64 as well -- the comment isn't overly
important, but it shouldn't be misleading.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
index ac903b5..5f0264b 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
@@ -30,7 +30,7 @@ [Defines]
 # The following information is for reference only and not required by the build
 # tools.
 #
-#  VALID_ARCHITECTURES   = IA32
+#  VALID_ARCHITECTURES   = IA32 X64
 #
 
 [Sources]
-- 
1.8.3.1


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


[edk2] [PATCH v3 38/52] OvmfPkg: build QuarkPort/CpuS3DataDxe for -D SMM_REQUIRE

2015-10-14 Thread Laszlo Ersek
Thanks to the previous patch, from Paolo, we can now build
QuarkPort/CpuS3DataDxe for X64 as well.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v3:
- new in v3; split out from
  "OvmfPkg: add skeleton QuarkPort/CpuS3DataDxe".

 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 OvmfPkg/OvmfPkgIa32.fdf| 1 +
 OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
 OvmfPkg/OvmfPkgX64.fdf | 1 +
 6 files changed, 6 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 292d3f8..126f084 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -715,6 +715,7 @@ [Components]
 !if $(SMM_REQUIRE) == TRUE
   OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
   OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
+  OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
 
   #
   # SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 85be5b9..810c6e7 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -722,6 +722,7 @@ [Components.X64]
 !if $(SMM_REQUIRE) == TRUE
   OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
   OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
+  OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
 
   #
   # SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 0dc2516..565c37c 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -720,6 +720,7 @@ [Components]
 !if $(SMM_REQUIRE) == TRUE
   OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
   OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
+  OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
 
   #
   # SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 7f9e201..e4e105a 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -358,6 +358,7 @@ [FV.DXEFV]
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
 INF  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
+INF  OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
 INF  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index d70736e..7dc2523 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -358,6 +358,7 @@ [FV.DXEFV]
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
 INF  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
+INF  OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
 INF  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index b9fee36..6bd333b 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -358,6 +358,7 @@ [FV.DXEFV]
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
 INF  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
+INF  OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
 INF  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
-- 
1.8.3.1


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


[edk2] [PATCH v3 33/52] OvmfPkg: import CpuConfigLib header from Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg

2015-10-14 Thread Laszlo Ersek
The next patch added to CpuS3DataDxe will depend on this header file;
import it.

The typedefs for REGISTER_TYPE, CPU_REGISTER_TABLE_ENTRY, and
CPU_REGISTER_TABLE are removed from the imported header file, because
"UefiCpuPkg/Include/AcpiCpuData.h" already provides those. Instead,
"CpuConfigLib.h" is made include "UefiCpuPkg/Include/AcpiCpuData.h".

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- This header file was a common dependency for both PiSmmCpuDxeSmm and
  CpuS3DataDxe in v1; in v2 it is only required by CpuS3DataDxe. Update
  the commit message, and move the patch to a later position in the
  series.
- In this version, the typedefs for REGISTER_TYPE,
  CPU_REGISTER_TABLE_ENTRY, and CPU_REGISTER_TABLE are removed from the
  imported header file, because Mike's
  "UefiCpuPkg/Include/AcpiCpuData.h" already provides those. Instead,
  "CpuConfigLib.h" is made include "UefiCpuPkg/Include/AcpiCpuData.h".

 OvmfPkg/OvmfPkg.dec  |  11 +
 OvmfPkg/QuarkPort/Include/Library/CpuConfigLib.h | 671 
 2 files changed, 682 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index da6967f..40f1d26 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -21,8 +21,19 @@ [Defines]
 
 [Includes]
   Include
+  QuarkPort/Include
 
 [LibraryClasses]
+  ## Library classes imported from "Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/"
+  #  follow.
+
+  ##  @libraryclass  CPU Configuration Library
+  #
+  CpuConfigLib|QuarkPort/Include/Library/CpuConfigLib.h
+
+  ## OvmfPkg's own library classes are listed below.
+  #
+
   ##  @libraryclass  Loads and boots a Linux kernel image
   #
   LoadLinuxLib|Include/Library/LoadLinuxLib.h
diff --git a/OvmfPkg/QuarkPort/Include/Library/CpuConfigLib.h 
b/OvmfPkg/QuarkPort/Include/Library/CpuConfigLib.h
new file mode 100644
index 000..964b2ee
--- /dev/null
+++ b/OvmfPkg/QuarkPort/Include/Library/CpuConfigLib.h
@@ -0,0 +1,671 @@
+/** @file
+  Public include file for the CPU Configuration Library
+
+  Copyright (c) 2013-2015 Intel Corporation.
+
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions
+  are met:
+
+  * Redistributions of source code must retain the above copyright
+  notice, this list of conditions and the following disclaimer.
+  * Redistributions in binary form must reproduce the above copyright
+  notice, this list of conditions and the following disclaimer in
+  the documentation and/or other materials provided with the
+  distribution.
+  * Neither the name of Intel Corporation nor the names of its
+  contributors may be used to endorse or promote products derived
+  from this software without specific prior written permission.
+
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+  Module Name:  CpuConfigLib.h
+
+**/
+
+#ifndef _CPU_CONFIG_LIB_H_
+#define _CPU_CONFIG_LIB_H_
+
+#include 
+
+//
+// Bits definition of PcdProcessorFeatureUserConfiguration,
+// PcdProcessorFeatureCapability, and PcdProcessorFeatureSetting
+//
+#define PCD_CPU_HT_BIT   0x0001
+#define PCD_CPU_CMP_BIT  0x0002
+#define PCD_CPU_L2_CACHE_BIT 0x0004
+#define PCD_CPU_L2_ECC_BIT   0x0008
+#define PCD_CPU_VT_BIT   0x0010
+#define PCD_CPU_LT_BIT   0x0020
+#define PCD_CPU_EXECUTE_DISABLE_BIT  0x0040
+#define PCD_CPU_L3_CACHE_BIT 0x0080
+#define PCD_CPU_MAX_CPUID_VALUE_LIMIT_BIT0x0100
+#define PCD_CPU_FAST_STRING_BIT  0x0200
+#define PCD_CPU_FERR_SIGNAL_BREAK_BIT0x0400
+#define PCD_CPU_PECI_BIT 0x0800
+#define PCD_CPU_HARDWARE_PREFETCHER_BIT  0x1000
+#define PCD_CPU_ADJACENT_CACHE_LINE_PREFETCH_BIT 0x2000
+#define PCD_CPU_DCU_PREFETCHER_BIT   0x4000
+#define PCD_CPU_IP_PREFETCHER_BIT0x8000
+#define PCD_CPU_MACHINE_CHECK_BIT0x0001
+#define PCD_CPU_THERMAL_MANAGEMENT_BIT 

[edk2] [PATCH v3 30/52] OvmfPkg: QuarkPort/CpuS3DataDxe: fill in ACPI_CPU_DATA.StartupVector

2015-10-14 Thread Laszlo Ersek
The StartupVector member of ACPI_CPU_DATA points to low level assembly
code that starts out in real mode, and is the boot code that gets run on
each AP in response to an INIT-Start-up-Start-up IPI sequence.

Importantly, *each* one of PiSmmCpuDxeSmm and CpuMpDxe (from
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/) has its own, private startup
vector implementation. They are similar, and are located in the respective
"IA32/MpFuncs.S" files (named RendezvousFunnelProcStart()).

With regard to the communication from CpuMpDxe to PiSmmCpuDxeSmm,
PiSmmCpuDxeSmm does not reuse CpuMpDxe's startup vector on the S3 resume
path (which would be unsafe anyway, unless the startup vector itself were
saved in SMRAM). PiSmmCpuDxeSmm only reuses (and overwrites) the reserved
memory *buffer* underneath ACPI_CPU_DATA.StartupVector that CpuMpDxe
allocated.

Therefore in this patch we only cover the allocation in our CpuS3DataDxe
driver; we can ignore everything else that CpuMpDxe would otherwise do
with its own startup vector.

PiSmmCpuDxeSmm silently assumes that its startup vector (plus the BSP-AP
communication structure that follows it directly) are not larger than the
same pair from CpuMpDxe. Because our CpuS3DataDxe driver has no such
things to key the allocation size off of, we allocate a single page (which
in practice is already larger than the original pair from CpuMpDxe).
PiSmmCpuDxeSmm should assert or enforce that this page is sufficient for
PiSmmCpuDxeSmm's startup vector and BSP-AP communication area.

The code added to CpuS3DataDxe is a little awkward; it looks like this
because it is built from positionally correct snippets (modified as
necessary) lifted from CpuMpDxe, preserving the original control flow:

  entry point (MultiProcessorInitialize() vs. CpuS3DataInitialize())
ProcessorConfiguration()
  WakeupAPAndCollectBist()
PrepareAPStartupVector()
  AllocateStartupVector()
// allocates mStartupVector

  SmmConfigurationEventNotify()
SaveCpuS3Data()
  // sets ACPI_CPU_DATA.StartupVector to mStartupVector

  ReAllocateMemoryForAP() -- optionally, if CSM is present
// reallocates mStartupVector from legacy region
// re-sets ACPI_CPU_DATA.StartupVector to mStartupVector

The CpuS3DataDxe subdirectory is supposed to be diffable against the
original CpuMpDxe.

(In fact the original CpuMpDxe has a bug; it *only* sets
mAcpiCpuData->StartupVector to mStartupVector when the Legacy BIOS
Protocol (ie. CSM) is present, and the startup vector is relocated into
the E or F segment.)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v3:
- This patch no longer breaks the X64 build, because we now delay
  building QuarkPort/CpuS3DataDxe until after Paolo's patch that enables
  it for X64 too. Update commit message accordingly.

v2:
- Drop the ASSERT() that v1 added to QuarkPort/PiSmmCpuDxeSmm, about the
  size of the area pre-allocated by CpuS3DataDxe. Instead, spell out
  this idea in the commit message; with Mike we've agreed that
  UefiCpuPkg/PiSmmCpuDxeSmm will verify or enforce this in the future
  somehow.

 OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf   |   6 ++
 OvmfPkg/QuarkPort/CpuS3DataDxe/Cpu.h  |  16 +++
 OvmfPkg/QuarkPort/CpuS3DataDxe/MpCommon.h |  42 
 OvmfPkg/QuarkPort/CpuS3DataDxe/{Cpu.h => IA32/ArchSpecific.c} |  34 +++
 OvmfPkg/QuarkPort/CpuS3DataDxe/MpCommon.c | 107 

 OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c  |  63 

 6 files changed, 251 insertions(+), 17 deletions(-)

diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
index efb71d4..be362d8 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
@@ -56,13 +56,17 @@ [Sources]
   Cpu.h
 
 [Sources.Ia32]
+  IA32/ArchSpecific.c
 
 [Packages]
   MdePkg/MdePkg.dec
+  IntelFrameworkPkg/IntelFrameworkPkg.dec
+  IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
   UefiCpuPkg/UefiCpuPkg.dec
 
 [LibraryClasses]
   UefiBootServicesTableLib
+  MemoryAllocationLib
   UefiDriverEntryPoint
   BaseMemoryLib
   UefiLib
@@ -72,6 +76,7 @@ [LibraryClasses]
 [Guids]
 
 [Protocols]
+  gEfiLegacyBiosProtocolGuid## SOMETIMES_CONSUMES
   gEfiSmmConfigurationProtocolGuid  # PROTOCOL ALWAYS_CONSUMED
 
 [FeaturePcd]
@@ -80,6 +85,7 @@ [FixedPcd]
 
 [Pcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuS3DataAddress
+  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdEbdaReservedMemorySize
 
 [Depex]
   TRUE
diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/Cpu.h 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/Cpu.h
index ca4816b..62faa0b 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/Cpu.h
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/Cpu.h
@@ -40,6 +40,22 @@
 
 #include "MpCommon.h"
 

[edk2] [PATCH v3 05/52] OvmfPkg: introduce -D SMM_REQUIRE and PcdSmmSmramRequire

2015-10-14 Thread Laszlo Ersek
This build time flag and corresponding Feature PCD will control whether
OVMF supports (and, equivalently, requires) SMM/SMRAM support from QEMU.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---
 OvmfPkg/OvmfPkg.dec| 10 ++
 OvmfPkg/OvmfPkgIa32.dsc|  4 
 OvmfPkg/OvmfPkgIa32X64.dsc |  4 
 OvmfPkg/OvmfPkgX64.dsc |  4 
 4 files changed, 22 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index d79aff4..f9decd3 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -121,3 +121,13 @@ [PcdsFeatureFlag]
   gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable|FALSE|BOOLEAN|3
   gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderPciTranslation|TRUE|BOOLEAN|0x1c
   gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderMmioTranslation|FALSE|BOOLEAN|0x1d
+
+  ## This feature flag enables SMM/SMRAM support. Note that it also requires
+  #  such support from the underlying QEMU instance; if that support is not
+  #  present, the firmware will reject continuing after a certain point.
+  #
+  #  The flag also acts as a general "security switch"; when TRUE, many
+  #  components will change behavior, with the goal of preventing a malicious
+  #  runtime OS from tampering with firmware structures (special memory ranges
+  #  used by OVMF, the varstore pflash chip, LockBox etc).
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|FALSE|BOOLEAN|0x1e
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 0d044c2..c6850ff 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -36,6 +36,7 @@ [Defines]
   DEFINE SECURE_BOOT_ENABLE  = FALSE
   DEFINE NETWORK_IP6_ENABLE  = FALSE
   DEFINE HTTP_BOOT_ENABLE= FALSE
+  DEFINE SMM_REQUIRE = FALSE
 
 [BuildOptions]
   GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
@@ -311,6 +312,9 @@ [PcdsFeatureFlag]
 !if $(SECURE_BOOT_ENABLE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable|TRUE
 !endif
+!if $(SMM_REQUIRE) == TRUE
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
+!endif
 
 [PcdsFixedAtBuild]
   gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 19d2221..dd65bf9 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -36,6 +36,7 @@ [Defines]
   DEFINE SECURE_BOOT_ENABLE  = FALSE
   DEFINE NETWORK_IP6_ENABLE  = FALSE
   DEFINE HTTP_BOOT_ENABLE= FALSE
+  DEFINE SMM_REQUIRE = FALSE
 
 [BuildOptions]
   GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
@@ -316,6 +317,9 @@ [PcdsFeatureFlag]
 !if $(SECURE_BOOT_ENABLE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable|TRUE
 !endif
+!if $(SMM_REQUIRE) == TRUE
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
+!endif
 
 [PcdsFixedAtBuild]
   gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index b8df1dc..0de3c85 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -36,6 +36,7 @@ [Defines]
   DEFINE SECURE_BOOT_ENABLE  = FALSE
   DEFINE NETWORK_IP6_ENABLE  = FALSE
   DEFINE HTTP_BOOT_ENABLE= FALSE
+  DEFINE SMM_REQUIRE = FALSE
 
 [BuildOptions]
   GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
@@ -316,6 +317,9 @@ [PcdsFeatureFlag]
 !if $(SECURE_BOOT_ENABLE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable|TRUE
 !endif
+!if $(SMM_REQUIRE) == TRUE
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
+!endif
 
 [PcdsFixedAtBuild]
   gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
-- 
1.8.3.1


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


[edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM from 64-bit mode

2015-10-14 Thread Laszlo Ersek
From: Paolo Bonzini 

According to Intel this is invalid.  Go back to 32-bit protected mode and
clear EFER.LME before executing RSM.

Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini 
---

Notes:
v3:
- New in v3, but included only for completeness here. This is a
  correction from Paolo for Mike's series "[edk2] [PATCH 0/7]
  UefiCpuPkg: Add CPU SMM and SecCore".

 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S   | 13 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm | 13 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S| 13 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.asm  | 13 +
 4 files changed, 52 insertions(+)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
index 8315593..0f1cab6 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
@@ -212,6 +212,19 @@ L1:
 .byte   0x48, 0x89, 0x0d# mov [rip + disp32], rcx
 .long   SSM_DR6 - (. + 4 - _SmiEntryPoint + 0x8000)
 L2:
+
+pushq   $PROTECT_MODE_CS
+pushq   $L3
+lretq
+L3:
+movq%cr0, %rbx
+btrl$31, %ebx
+movq%rbx, %cr0
+movl$0xc080, %ecx
+rdmsr
+andb$0xfe,%ah
+wrmsr
+
 rsm
 
 ASM_PFX(gcSmiHandlerSize):.word  . - _SmiEntryPoint
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm
index a1a7d3e..99eb403 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm
@@ -214,6 +214,19 @@ _SmiHandler:
 DB  48h, 89h, 0dh   ; mov [rip + disp32], rcx
 DD  SSM_DR6 - ($ + 4 - _SmiEntryPoint + 8000h)
 @2:
+
+pushPROTECT_MODE_CS
+push@3
+retfq
+@3:
+mov rbx, cr0
+btr ebx, 31
+mov cr0, rbx
+mov ecx, 0c080h
+rdmsr
+and ah, 0feh
+wrmsr
+
 rsm
 
 gcSmiHandlerSizeDW  $ - _SmiEntryPoint
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S
index 5ace1a6..fc7c2f9 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S
@@ -32,6 +32,7 @@ ASM_GLOBAL   ASM_PFX(mSmmRelocationOriginalAddressPtr32)
 ASM_GLOBAL   ASM_PFX(gSmmInitStack)
 ASM_GLOBAL   ASM_PFX(gcSmiInitGdtr)
 
+.equPROTECT_MODE_CS, 0x08
 
 .text
 
@@ -89,6 +90,18 @@ ASM_PFX(gSmmInitStack):  .space  8
 movdqa  0x40(%rsp), %xmm4
 movdqa  0x50(%rsp), %xmm5
 
+pushq   $PROTECT_MODE_CS # push 32-bit CS
+pushq   $L3
+lretq
+L3:
+movq%cr0, %rbx# get out of long mode
+btrl$31, %ebx
+movq%rbx, %cr0
+movl$0xc080, %ecx
+rdmsr
+andb$0xfe,%ah
+wrmsr
+
 rsm
 
 ASM_PFX(gcSmmInitTemplate):
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.asm 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.asm
index 25a0447..68540a6 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.asm
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.asm
@@ -32,6 +32,8 @@ EXTERNDEF   mSmmRelocationOriginalAddressPtr32:DWORD
 EXTERNDEF   gSmmInitStack:QWORD
 EXTERNDEF   gcSmiInitGdtr:FWORD
 
+PROTECT_MODE_CS EQU 08h
+
 .code
 
 gcSmiInitGdtr   LABEL   FWORD
@@ -88,6 +90,17 @@ gSmmInitStack   DQ  ?
 movdqa  xmm4, [rsp + 40h]
 movdqa  xmm5, [rsp + 50h]
 
+pushPROTECT_MODE_CS
+push@3
+retfq
+@3:
+mov rbx, cr0
+btr ebx, 31
+mov cr0, rbx
+mov ecx, 0c080h
+rdmsr
+and ah, 0feh
+wrmsr
 rsm
 SmmStartup  ENDP
 
-- 
1.8.3.1


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


[edk2] [PATCH v3 15/52] OvmfPkg: pull in CpuIo2Smm driver

2015-10-14 Thread Laszlo Ersek
This driver provides EFI_SMM_CPU_IO2_PROTOCOL, which the SMM core depends
on in its gEfiDxeSmmReadyToLockProtocolGuid callback
(SmmReadyToLockHandler(), "MdeModulePkg/Core/PiSmmCore/PiSmmCore.c").

Approached on a higher level, this driver provides the SmmIo member of the
EFI_SMM_SYSTEM_TABLE2 (SMST).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 11 +++
 OvmfPkg/OvmfPkgIa32X64.dsc | 11 +++
 OvmfPkg/OvmfPkgX64.dsc | 11 +++
 OvmfPkg/OvmfPkgIa32.fdf|  9 +
 OvmfPkg/OvmfPkgIa32X64.fdf |  9 +
 OvmfPkg/OvmfPkgX64.fdf |  9 +
 6 files changed, 60 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index ca3be30..6cfd58e 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -292,6 +292,12 @@ [LibraryClasses.common.UEFI_APPLICATION]
 [LibraryClasses.common.DXE_SMM_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+  
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
+!ifdef $(DEBUG_ON_SERIAL_PORT)
+  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!else
+  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+!endif
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -697,4 +703,9 @@ [Components]
   # SMM_CORE
   #
   MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+
+  #
+  # Privileged drivers (DXE_SMM_DRIVER modules)
+  #
+  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 60f085a..6679e8a 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -297,6 +297,12 @@ [LibraryClasses.common.UEFI_APPLICATION]
 [LibraryClasses.common.DXE_SMM_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+  
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
+!ifdef $(DEBUG_ON_SERIAL_PORT)
+  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!else
+  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+!endif
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -704,4 +710,9 @@ [Components.X64]
   # SMM_CORE
   #
   MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+
+  #
+  # Privileged drivers (DXE_SMM_DRIVER modules)
+  #
+  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 0621292..2651042 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -297,6 +297,12 @@ [LibraryClasses.common.UEFI_APPLICATION]
 [LibraryClasses.common.DXE_SMM_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+  
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
+!ifdef $(DEBUG_ON_SERIAL_PORT)
+  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!else
+  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+!endif
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -702,4 +708,9 @@ [Components]
   # SMM_CORE
   #
   MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+
+  #
+  # Privileged drivers (DXE_SMM_DRIVER modules)
+  #
+  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index f705918..e908198 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -360,6 +360,7 @@ [FV.DXEFV]
 INF  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+INF  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
 !endif
 
 

@@ -495,3 +496,11 @@ [Rule.Common.SMM_CORE]
 UI   STRING="$(MODULE_NAME)" Optional
 VERSION  STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
   }
+
+[Rule.Common.DXE_SMM_DRIVER]
+  FILE SMM = $(NAMED_GUID) {
+SMM_DEPEXSMM_DEPEX Optional  $(INF_OUTPUT)/$(MODULE_NAME).depex
+PE32 PE32$(INF_OUTPUT)/$(MODULE_NAME).efi
+UI   STRING="$(MODULE_NAME)" Optional
+VERSION  STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+  }
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 93a8d44..5300a71 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -360,6 +360,7 @@ [FV.DXEFV]
 INF  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+INF  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
 !endif
 
 

@@ -495,3 +496,11 

[edk2] [PATCH v3 23/52] OvmfPkg: import SmmCpuFeaturesLib from UefiCpuPkg

2015-10-14 Thread Laszlo Ersek
From: Paolo Bonzini 

The next patches will customize the implementation, but let's start from
the common version to better show the changes.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini 
[ler...@redhat.com: drop UNI file, keep whitespace intact, generate new
 FILE_GUID, split off DSC changes, reflow commit message]
Cc: Paolo Bonzini 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v3:
- new in v3

 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf |  39 ++
 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c   | 559 

 2 files changed, 598 insertions(+)

diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf 
b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
new file mode 100644
index 000..b04c028
--- /dev/null
+++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
@@ -0,0 +1,39 @@
+## @file
+#  The CPU specific programming for PiSmmCpuDxeSmm module.
+#
+#  Copyright (c) 2009 - 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
+#  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= 0x00010005
+  BASE_NAME  = SmmCpuFeaturesLib
+  MODULE_UNI_FILE= SmmCpuFeaturesLib.uni
+  FILE_GUID  = AC9991BE-D77A-464C-A8DE-A873DB8A4836
+  MODULE_TYPE= DXE_SMM_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = SmmCpuFeaturesLib
+  CONSTRUCTOR= SmmCpuFeaturesLibConstructor
+
+[Sources]
+  SmmCpuFeaturesLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  UefiCpuPkg/UefiCpuPkg.dec
+  
+[LibraryClasses]
+  BaseLib
+  PcdLib
+  MemoryAllocationLib
+  DebugLib
+
+[Pcd]
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber## 
SOMETIMES_CONSUMES
diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c 
b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
new file mode 100644
index 000..dd09387
--- /dev/null
+++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
@@ -0,0 +1,559 @@
+/** @file
+The CPU specific programming for PiSmmCpuDxeSmm module.
+
+Copyright (c) 2010 - 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
+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 
+
+//
+// Machine Specific Registers (MSRs)
+//
+#define  SMM_FEATURES_LIB_IA32_MTRR_CAP0x0FE
+#define  SMM_FEATURES_LIB_IA32_FEATURE_CONTROL 0x03A
+#define  SMM_FEATURES_LIB_IA32_SMRR_PHYSBASE   0x1F2
+#define  SMM_FEATURES_LIB_IA32_SMRR_PHYSMASK   0x1F3
+#define  SMM_FEATURES_LIB_IA32_CORE_SMRR_PHYSBASE  0x0A0
+#define  SMM_FEATURES_LIB_IA32_CORE_SMRR_PHYSMASK  0x0A1
+#defineEFI_MSR_SMRR_MASK   0xF000
+#defineEFI_MSR_SMRR_PHYS_MASK_VALIDBIT11
+
+//
+// Set default value to assume SMRR is not supported
+//
+BOOLEAN  mSmrrSupported = FALSE;
+
+//
+// Set default value to assume IA-32 Architectural MSRs are used
+//
+UINT32  mSmrrPhysBaseMsr = SMM_FEATURES_LIB_IA32_SMRR_PHYSBASE;
+UINT32  mSmrrPhysMaskMsr = SMM_FEATURES_LIB_IA32_SMRR_PHYSMASK;
+
+//
+// Set default value to assume MTRRs need to be configured on each SMI
+//
+BOOLEAN  mNeedConfigureMtrrs = TRUE;
+
+//
+// Array for state of SMRR enable on all CPUs
+//
+BOOLEAN  *mSmrrEnabled;
+
+/**
+  The constructor function 
+
+  @retval EFI_SUCCESS   The constructor always returns RETURN_SUCCESS.
+
+**/
+EFI_STATUS
+EFIAPI
+SmmCpuFeaturesLibConstructor (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  UINT32  RegEax;
+  UINT32  RegEdx;
+  UINTN   FamilyId;
+  UINTN   ModelId;
+
+  //
+  // Retrieve CPU Family and Model 
+  //
+  AsmCpuid (CPUID_VERSION_INFO, , NULL, NULL, );
+  FamilyId = (RegEax >> 8) & 0xf;
+  ModelId  = (RegEax >> 4) & 0xf;
+  if (FamilyId == 0x06 || FamilyId == 0x0f) {
+ModelId = ModelId | ((RegEax >> 12) & 0xf0);
+  }
+
+  //
+  // Check CPUID(CPUID_VERSION_INFO).EDX[12] for MTRR capability
+  //
+  if ((RegEdx 

[edk2] [PATCH v3 19/52] OvmfPkg: resolve ReportStatusCodeLib for DXE_SMM_DRIVER modules

2015-10-14 Thread Laszlo Ersek
PiSmmCpuDxeSmm depends on this library class, and it's okay to resolve it
generally for all DXE_SMM_DRIVER modules.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 3 files changed, 3 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index a19d4e2..6a93fd2 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -299,6 +299,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
   
MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
+  
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
   SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
   
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index d177154..dbaf8fb 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -304,6 +304,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
   
MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
+  
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
   SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
   
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 7908a31..a7efe52 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -304,6 +304,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
   
MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
+  
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
   SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
   
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
-- 
1.8.3.1


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


[edk2] [PATCH v3 07/52] OvmfPkg: Sec: assert the build-time calculated end of the scratch buffer

2015-10-14 Thread Laszlo Ersek
The DecompressMemFvs() function in "OvmfPkg/Sec/SecMain.c" uses more
memory, temporarily, than what PEIFV and DXEFV will ultimately need.
First, it uses an output buffer for decompression, second, the
decompression itself needs a scratch buffer (and this scratch buffer is
the highest area that SEC uses).

DecompressMemFvs() used to be called on normal boots only (ie. not on S3
resume), which is why the decompression output buffer and the scratch
buffer were allowed to scribble over RAM. However, we'll soon start to
worry during S3 resume that the runtime OS might tamper with the
pre-decompressed PEIFV, and we'll decompress the firmware volumes on S3
resume too, from pristine flash. For this we'll need to know the end of
the scratch buffer in advance, so we can prepare a non-malicious OS for
it.

Calculate the end of the scratch buffer statically in the FDF files, and
assert in DecompressMemFvs() that the runtime decompression will match it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---

Notes:
v2:
- PcdOvmfDecomprScratchEnd => PcdOvmfDecompressionScratchEnd [Jordan]
  
- SCRATCH => DECOMP_SCRATCH [Jordan]
  (same)

 OvmfPkg/OvmfPkg.dec   |  1 +
 OvmfPkg/OvmfPkgIa32.fdf   |  4 +-
 OvmfPkg/OvmfPkgIa32X64.fdf|  4 +-
 OvmfPkg/OvmfPkgX64.fdf|  4 +-
 OvmfPkg/Sec/SecMain.inf   |  1 +
 OvmfPkg/Sec/SecMain.c |  8 +++
 OvmfPkg/DecomprScratchEnd.fdf.inc | 72 
 OvmfPkg/OvmfPkg.fdf.inc   |  2 +
 8 files changed, 93 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index f9decd3..3fab2af 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -110,6 +110,7 @@ [PcdsFixedAtBuild]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase|0x0|UINT32|0x18
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize|0x0|UINT32|0x19
   gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize|0x0|UINT32|0x1a
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd|0x0|UINT32|0x1f
 
 [PcdsDynamic, PcdsDynamicEx]
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 2581fdb..44e4a92 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -78,7 +78,7 @@ [FD.OVMF_CODE]
 

 
 [FD.MEMFD]
-BaseAddress   = 0x80
+BaseAddress   = $(MEMFD_BASE_ADDRESS)
 Size  = 0xA0
 ErasePolarity = 1
 BlockSize = 0x1
@@ -384,6 +384,8 @@ [FV.FVMAIN_COMPACT]
}
  }
 
+!include DecomprScratchEnd.fdf.inc
+
 

 
 [Rule.Common.SEC]
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 01f384a..67bfbe7 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -78,7 +78,7 @@ [FD.OVMF_CODE]
 

 
 [FD.MEMFD]
-BaseAddress   = 0x80
+BaseAddress   = $(MEMFD_BASE_ADDRESS)
 Size  = 0xA0
 ErasePolarity = 1
 BlockSize = 0x1
@@ -384,6 +384,8 @@ [FV.FVMAIN_COMPACT]
}
  }
 
+!include DecomprScratchEnd.fdf.inc
+
 

 
 [Rule.Common.SEC]
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 4ad89fb..6624789 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -78,7 +78,7 @@ [FD.OVMF_CODE]
 

 
 [FD.MEMFD]
-BaseAddress   = 0x80
+BaseAddress   = $(MEMFD_BASE_ADDRESS)
 Size  = 0xA0
 ErasePolarity = 1
 BlockSize = 0x1
@@ -384,6 +384,8 @@ [FV.FVMAIN_COMPACT]
}
  }
 
+!include DecomprScratchEnd.fdf.inc
+
 

 
 [Rule.Common.SEC]
diff --git a/OvmfPkg/Sec/SecMain.inf b/OvmfPkg/Sec/SecMain.inf
index e4bbb33..2215dd9 100644
--- a/OvmfPkg/Sec/SecMain.inf
+++ b/OvmfPkg/Sec/SecMain.inf
@@ -69,6 +69,7 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
   gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
   gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
 
 [FeaturePcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
index d61d303..aebb645 100644
--- a/OvmfPkg/Sec/SecMain.c
+++ b/OvmfPkg/Sec/SecMain.c
@@ -361,6 +361,14 @@ DecompressMemFvs (
 
   OutputBuffer = (VOID*) ((UINT8*)(UINTN) PcdGet32 (PcdOvmfDxeMemFvBase) + 
SIZE_1MB);
   ScratchBuffer = ALIGN_POINTER ((UINT8*) OutputBuffer + OutputBufferSize, 

[edk2] [PATCH v3 29/52] OvmfPkg: add skeleton QuarkPort/CpuS3DataDxe

2015-10-14 Thread Laszlo Ersek
The PiSmmCpuDxeSmm driver depends on the ACPI_CPU_DATA structure, from a
platform- and CPU-specific driver, in order to support S3. The address of
this structure is communicated through the dynamic PCD
PcdCpuS3DataAddress.

The data and control flows are as follows (CpuMpDxe stands for the
original Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe/ driver, from
which CpuS3DataDxe is being extracted):

  CpuMpDxeS3ResumePei  PiSmmCpuDxeSmm
  (DXE_DRIVER)(PEIM)   (DXE_SMM_DRIVER)
  ---  ---
normalcollects datainstalls
boot  |EFI_SMM_CONFIGUR...PROTOCOL
  |in PiCpuSmmEntry()
  v |
  SmmConfi...Notify() <-+
  |
  v
  saves data into
  ACPI_CPU_DATA in
  AcpiNVS memory,
  sets
  PcdCpuS3DataAddress
  in SaveCpuS3Data()
  |
SMM ready +--> SmmReadyToLockEv...Notify()
to lock |
v
   gets PcdCpuS3DataAddress,
   copies ACPI_CPU_DATA from
   AcpiNVS to SMRAM
   (mAcpiCpuData)

runtime

S3
suspend

S3transfers
resumecontrol to
  PiSmmCpuDxeSmm
  via
  SmmS3Res...Point
  |
  +--> SmmRestoreCpu() and its
   callees use mAcpiCpuData
   from SMRAM

Since CpuMpDxe is very complex and covers much more functionality, we're
going to gradually import only the above feature. This patch pulls in the
basic skeleton of the driver.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v3:
- don't add the driver to the DSC/FDF files just yet; a patch from
  Paolo will enable this driver for X64 as well -- later in the series.

v2:
- PcdCpuS3DataAddress comes from "UefiCpuPkg/UefiCpuPkg.dec" now
- adapt the commit message to the fact that Mike added PiSmmCpuDxeSmm
  to UefiCpuPkg

 OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf  |  85 +++
 OvmfPkg/QuarkPort/CpuS3DataDxe/Cpu.h |  57 
 OvmfPkg/QuarkPort/CpuS3DataDxe/MpCommon.h|  67 +
 OvmfPkg/QuarkPort/CpuS3DataDxe/MpService.h   |  49 +++
 OvmfPkg/QuarkPort/CpuS3DataDxe/MpCommon.c|  76 ++
 OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c | 147 
 6 files changed, 481 insertions(+)

diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
new file mode 100644
index 000..efb71d4
--- /dev/null
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
@@ -0,0 +1,85 @@
+## @file
+#
+# DXE driver that populates ACPI_CPU_DATA for PiSmmCpuDxeSmm.
+#
+# Based on Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe.
+#
+# Copyright (C) 2015, Red Hat, Inc.
+# Copyright (c) 2013-2015 Intel Corporation.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+#
+# * Redistributions of source code must retain the above copyright
+# notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in
+# the documentation and/or other materials provided with the
+# distribution.
+# * Neither the name of Intel Corporation nor the names of its
+# contributors may be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE

[edk2] [PATCH v3 17/52] OvmfPkg: LockBox: -D SMM_REQUIRE excludes our fake lockbox

2015-10-14 Thread Laszlo Ersek
When the user builds OVMF with -D SMM_REQUIRE, our LockBox implementation
must not be used, since it doesn't actually protect data in the LockBox
from the runtime guest OS. Add an according assert to
LockBoxLibInitialize().

Furthermore, since our LockBox must not be selected with -D SMM_REQUIRE,
it makes sense to set aside memory for it only if -D SMM_REQUIRE is
absent. Modify InitializeRamRegions() accordingly.

This patch completes the -D SMM_REQUIRE-related tweaking of the special
OVMF memory areas.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf |  3 ++
 OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf  |  3 ++
 OvmfPkg/Library/LockBoxLib/LockBoxLib.c   |  2 +
 OvmfPkg/PlatformPei/MemDetect.c   | 40 ++--
 4 files changed, 29 insertions(+), 19 deletions(-)

diff --git a/OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf 
b/OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
index 7203d07..81c893e 100644
--- a/OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
+++ b/OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
@@ -42,3 +42,6 @@ [LibraryClasses]
 [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
+
+[FeaturePcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
diff --git a/OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf 
b/OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
index a4d27a5..08973a4 100644
--- a/OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
+++ b/OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
@@ -43,3 +43,6 @@ [LibraryClasses]
 [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
+
+[FeaturePcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
diff --git a/OvmfPkg/Library/LockBoxLib/LockBoxLib.c 
b/OvmfPkg/Library/LockBoxLib/LockBoxLib.c
index 89050ac..45481b9 100644
--- a/OvmfPkg/Library/LockBoxLib/LockBoxLib.c
+++ b/OvmfPkg/Library/LockBoxLib/LockBoxLib.c
@@ -44,6 +44,8 @@ LockBoxLibInitialize (
 {
   UINTN NumEntries;
 
+  ASSERT (!FeaturePcdGet (PcdSmmSmramRequire));
+
   if (PcdGet32 (PcdOvmfLockBoxStorageSize) < sizeof (LOCK_BOX_GLOBAL)) {
 return RETURN_UNSUPPORTED;
   }
diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 1bdc2df..455fcbb 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -407,25 +407,27 @@ InitializeRamRegions (
   }
 
   if (mBootMode != BOOT_ON_S3_RESUME) {
-//
-// Reserve the lock box storage area
-//
-// Since this memory range will be used on S3 resume, it must be
-// reserved as ACPI NVS.
-//
-// If S3 is unsupported, then various drivers might still write to the
-// LockBox area. We ought to prevent DXE from serving allocation requests
-// such that they would overlap the LockBox storage.
-//
-ZeroMem (
-  (VOID*)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
-  (UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize)
-  );
-BuildMemoryAllocationHob (
-  (EFI_PHYSICAL_ADDRESS)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
-  (UINT64)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize),
-  mS3Supported ? EfiACPIMemoryNVS : EfiBootServicesData
-  );
+if (!FeaturePcdGet (PcdSmmSmramRequire)) {
+  //
+  // Reserve the lock box storage area
+  //
+  // Since this memory range will be used on S3 resume, it must be
+  // reserved as ACPI NVS.
+  //
+  // If S3 is unsupported, then various drivers might still write to the
+  // LockBox area. We ought to prevent DXE from serving allocation requests
+  // such that they would overlap the LockBox storage.
+  //
+  ZeroMem (
+(VOID*)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
+(UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize)
+);
+  BuildMemoryAllocationHob (
+(EFI_PHYSICAL_ADDRESS)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
+(UINT64)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize),
+mS3Supported ? EfiACPIMemoryNVS : EfiBootServicesData
+);
+}
 
 if (FeaturePcdGet (PcdSmmSmramRequire)) {
   UINT32 TsegSize;
-- 
1.8.3.1


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


[edk2] [PATCH v3 02/52] UefiCpuPkg: PiSmmCpuDxeSmm: prepare PT in InitPaging before filling in PDE

2015-10-14 Thread Laszlo Ersek
From: Paolo Bonzini 

InitPaging() is setting a page directory entry before initializing the
corresponding page table.  This works on real hardware (including KVM),
but the TLB of QEMU's emulation mode is different (possibly it has
different associativity, I don't really know) so at some point execution
goes to nowhere's land.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini 
[ler...@redhat.com: converted patch to CRLF]
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v3:
- New in v3, but included only for completeness here. This is a fixup
  from Paolo for Mike's series "[edk2] [PATCH 0/7] UefiCpuPkg: Add CPU
  SMM and SecCore".

 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
index e6eacb5..f2281f5 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
@@ -555,12 +555,12 @@ InitPaging (
   Pt = AllocatePages (1);
   ASSERT (Pt != NULL);
   
-  *Pte = (UINTN)Pt | IA32_PG_RW | IA32_PG_P;
-  
   // Split it
-  for (Level4 = 0; Level4 < SIZE_4KB / sizeof(*Pt); Level4++, Pt++) {
-*Pt = Address + ((Level4 << 12) | IA32_PG_RW | IA32_PG_P);
+  for (Level4 = 0; Level4 < SIZE_4KB / sizeof(*Pt); Level4++) {
+Pt[Level4] = Address + ((Level4 << 12) | IA32_PG_RW | IA32_PG_P);
   } // end for PT
+
+  *Pte = (UINTN)Pt | IA32_PG_RW | IA32_PG_P;
 } // end if IsAddressSplit
   } // end for PTE
 } // end for PDE
-- 
1.8.3.1


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


[edk2] [PATCH v3 35/52] OvmfPkg: QuarkPort/CpuS3DataDxe: fill in ACPI_CPU_DATA.MtrrTable

2015-10-14 Thread Laszlo Ersek
It has been deemed inappropriate, for general use, for UefiCpuPkg/CpuDxe
to keep reflecting the most recent MTRR settings to an AcpiNVS buffer, for
CpuS3DataDxe to pass through to PiSmmCpuDxeSmm. Instead, Michael Kinney
suggested to fetch and save the MTRR settings in CpuS3DataDxe, in a
similarly delayed manner: at EndOfDxe.

That idea matches OVMF's BDS very well. The events are sequenced like
this:
- PiSmmCpuDxeSmm installs EFI_SMM_CONFIGURATION_PROTOCOL.

- SmmConfigurationEventNotify() is invoked in CpuS3DataDxe, which in turn
  calls SaveCpuS3Data().

- SaveCpuS3Data() allocates AcpiNVS memory for ACPI_CPU_DATA, and (with
  this patch) MTRR_SETTINGS too, linking the latter into the former.

- SaveCpuS3Data() registers a handler for EndOfDxe.

- Later, OVMF's BDS signals EndOfDxe, thus CpuS3DataDxe populates the
  MTRR_SETTINGS block, with the then-current MTRR settings.

- Right after, BDS writes the last opcode (an INFO opcode) to the S3 boot
  script, and installs gEfiDxeSmmReadyToLockProtocolGuid in the DXE
  protocol database.

- In turn, the SMM core installs gEfiSmmReadyToLockProtocolGuid in the SMM
  protocol database.

- In turn, SmmReadyToLockEventNotify() is called in PiSmmCpuDxeSmm, which
  copies the MTRR settings from AcpiNVS to SMRAM.

On the S3 resume path, PiSmmCpuDxeSmm will apply the MTRR settings to all
APs directly from SMRAM.

This patch significantly diverges from the original
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe/ driver.

Suggested-by: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- This approach is new in v2. In v1, QuarkPort/CpuS3DataDxe simply
  relayed the PcdCpuMtrrTableAddress value from UefiCpuPkg/CpuDxe to
  PiSmmCpuDxeSmm.

 OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf  |  2 +
 OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c | 41 
 2 files changed, 43 insertions(+)

diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
index 249408b..2610a63 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
@@ -78,8 +78,10 @@ [LibraryClasses]
   UefiLib
   DebugLib
   BaseLib
+  MtrrLib
 
 [Guids]
+  gEfiEndOfDxeEventGroupGuid
 
 [Protocols]
   gEfiMpServiceProtocolGuid # PROTOCOL ALWAYS_CONSUMED
diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c
index a69c58c..25ac8b1 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c
@@ -34,6 +34,8 @@
 
 **/
 
+#include 
+
 #include "MpService.h"
 #include "Cpu.h"
 #include "MpApic.h"
@@ -220,6 +222,27 @@ WakeupAPAndCollectBist (
 }
 
 /**
+  Callback function executed when the EndOfDxe event group is signaled.
+
+  We delay saving the MTRR settings until BDS signals EndOfDxe.
+
+  @param[in]  EventEvent whose notification function is being invoked.
+  @param[out] Context  Pointer to the MTRR_SETTINGS buffer to fill in.
+**/
+STATIC
+VOID
+EFIAPI
+SaveMtrrsOnEndOfDxe (
+  IN EFI_EVENT Event,
+  OUT VOID *Context
+  )
+{
+  DEBUG ((EFI_D_VERBOSE, "%a\n", __FUNCTION__));
+  MtrrGetAllMtrrs (Context);
+  gBS->CloseEvent (Event);
+}
+
+/**
   Prepare ACPI NVS memory below 4G memory for use of S3 resume.
   
   This function allocates ACPI NVS memory below 4G memory for use of S3 resume,
@@ -234,6 +257,9 @@ SaveCpuS3Data (
   )
 {
   MP_CPU_SAVED_DATA   *MpCpuSavedData;
+  MTRR_SETTINGS   *MtrrSettings;
+  EFI_STATUS  Status;
+  EFI_EVENT   EndOfDxeEvent;
 
   //
   // Allocate ACPI NVS memory below 4G memory for use of S3 resume.
@@ -241,6 +267,20 @@ SaveCpuS3Data (
   MpCpuSavedData = AllocateAcpiNvsMemoryBelow4G (sizeof (MP_CPU_SAVED_DATA));
 
   //
+  // Allocate buffer for MTRR settings.
+  //
+  MtrrSettings = AllocateAcpiNvsMemoryBelow4G (sizeof *MtrrSettings);
+
+  //
+  // Install notification callback for EndOfDxe that will fill in the MTRR
+  // settings.
+  //
+  Status = gBS->CreateEventEx (EVT_NOTIFY_SIGNAL, TPL_CALLBACK,
+  SaveMtrrsOnEndOfDxe, MtrrSettings,
+  , );
+  ASSERT_EFI_ERROR (Status);
+
+  //
   // Set the value for CPU data
   //
   mAcpiCpuData = &(MpCpuSavedData->AcpiCpuData);
@@ -252,6 +292,7 @@ SaveCpuS3Data (
   mAcpiCpuData->StackAddress   =
 (EFI_PHYSICAL_ADDRESS) (UINTN) mExchangeInfo->StackStart;
   mAcpiCpuData->StackSize  = PcdGet32 (PcdCpuApStackSize);
+  mAcpiCpuData->MtrrTable  = (EFI_PHYSICAL_ADDRESS)(UINTN)MtrrSettings;
 
   mAcpiCpuData->ApMachineCheckHandlerBase = mApMachineCheckHandlerBase;
   mAcpiCpuData->ApMachineCheckHandlerSize = mApMachineCheckHandlerSize;
-- 
1.8.3.1


___
edk2-devel mailing list
edk2-devel@lists.01.org

[edk2] [PATCH v3 37/52] OvmfPkg: port CpuS3DataDxe to X64

2015-10-14 Thread Laszlo Ersek
From: Paolo Bonzini 

The descriptor format is different and the assembly source is
converted to nasm, but otherwise there is no difference.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini 
---

Notes:
v3:
- new in v3

 OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf  |   5 +
 OvmfPkg/QuarkPort/CpuS3DataDxe/X64/ArchSpecificDef.h |  59 +++
 OvmfPkg/QuarkPort/CpuS3DataDxe/X64/ArchSpecific.c| 108 
 OvmfPkg/QuarkPort/CpuS3DataDxe/X64/CpuAsm.nasm   |  58 +++
 4 files changed, 230 insertions(+)

diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
index 2610a63..4bec056 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
@@ -63,6 +63,11 @@ [Sources.Ia32]
   IA32/ArchSpecificDef.h
   IA32/ArchSpecific.c
 
+[Sources.X64]
+  X64/CpuAsm.nasm
+  X64/ArchSpecificDef.h
+  X64/ArchSpecific.c
+
 [Packages]
   MdePkg/MdePkg.dec
   IntelFrameworkPkg/IntelFrameworkPkg.dec
diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/X64/ArchSpecificDef.h 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/X64/ArchSpecificDef.h
new file mode 100644
index 000..5ea4cf6
--- /dev/null
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/X64/ArchSpecificDef.h
@@ -0,0 +1,59 @@
+/** @file
+
+Copyright (C) 2015, Red Hat, Inc.
+Copyright (c) 2013-2015 Intel Corporation.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+
+Module Name:
+
+  ProcessorDef.h
+
+Abstract:
+
+  Definition for X64 processor
+
+**/
+
+#ifndef _PROCESSOR_DEF_H_
+#define _PROCESSOR_DEF_H_
+
+#pragma pack(1)
+
+typedef struct {
+  UINT16  OffsetLow;
+  UINT16  SegmentSelector;
+  UINT16  Attributes;
+  UINT16  OffsetHigh;
+  UINT32  OffsetUpper;
+  UINT32  Zero;
+} INTERRUPT_GATE_DESCRIPTOR;
+
+#pragma pack()
+
+#endif
diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/X64/ArchSpecific.c 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/X64/ArchSpecific.c
new file mode 100644
index 000..544816d
--- /dev/null
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/X64/ArchSpecific.c
@@ -0,0 +1,108 @@
+/** @file
+
+  Memory Operation Functions for IA32 Architecture.
+
+  Copyright (C) 2015, Red Hat, Inc.
+  Copyright (c) 2013-2015 Intel Corporation.
+
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions
+  are met:
+
+  * Redistributions of source code must retain the above copyright
+  notice, this list of conditions and the following disclaimer.
+  * Redistributions in binary form must reproduce the above copyright
+  notice, this list of conditions and the following disclaimer in
+  the documentation and/or other materials provided with the
+  distribution.
+  * Neither the name of Intel Corporation nor the names of its
+  contributors may be used to endorse or promote products derived
+  from this software without specific prior written permission.
+
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+  THEORY OF 

[edk2] [PATCH v3 47/52] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: add DXE_SMM_DRIVER build

2015-10-14 Thread Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf  | 89 

 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c | 66 +++
 2 files changed, 155 insertions(+)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
new file mode 100644
index 000..6af0649
--- /dev/null
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
@@ -0,0 +1,89 @@
+## @file
+#  Component description file for QEMU Flash Fimware Volume Block SMM driver
+#  module.
+#
+#  This SMM driver implements and produces the SMM Fimware Volue Block Protocol
+#  for a QEMU flash device.
+#
+#  Copyright (C) 2015, Red Hat, Inc.
+#  Copyright (c) 2006 - 2013, 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
+#  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= 0x00010005
+  BASE_NAME  = FvbServicesSmm
+  FILE_GUID  = 2E7DB7A7-608E-4041-B45F-00359E0766C6
+  MODULE_TYPE= DXE_SMM_DRIVER
+  VERSION_STRING = 1.0
+  PI_SPECIFICATION_VERSION   = 0x0001000A
+  ENTRY_POINT= FvbInitialize
+
+#
+# The following information is for reference only and not required by the build
+# tools.
+#
+#  VALID_ARCHITECTURES   = IA32 X64
+#
+
+[Sources]
+  FvbInfo.c
+  FwBlockService.c
+  FwBlockServiceSmm.c
+  QemuFlash.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  OvmfPkg/OvmfPkg.dec
+
+[LibraryClasses]
+  BaseLib
+  BaseMemoryLib
+  DebugLib
+  DevicePathLib
+  DxeServicesTableLib
+  MemoryAllocationLib
+  PcdLib
+  SmmServicesTableLib
+  UefiBootServicesTableLib
+  UefiDriverEntryPoint
+
+[Guids]
+
+[Protocols]
+  gEfiSmmFirmwareVolumeBlockProtocolGuid# PROTOCOL ALWAYS_PRODUCED
+  gEfiDevicePathProtocolGuid# PROTOCOL ALWAYS_PRODUCED
+
+[FixedPcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwSpareBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize
+
+[Pcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogBase
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable
+
+
+[Depex]
+  TRUE
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c
new file mode 100644
index 000..e77129e
--- /dev/null
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c
@@ -0,0 +1,66 @@
+/**@file
+  Functions related to the Firmware Volume Block service whose
+  implementation is specific to the SMM driver build.
+
+  Copyright (C) 2015, Red Hat, Inc.
+  Copyright (c) 2006 - 2014, 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
+  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 "FwBlockService.h"
+
+VOID
+InstallProtocolInterfaces (
+  IN EFI_FW_VOL_BLOCK_DEVICE *FvbDevice
+  )
+{
+  EFI_HANDLE FvbHandle;
+  EFI_STATUS Status;
+
+  //
+  // There is no SMM service that can install multiple protocols in the SMM
+  // protocol database in one go.
+  //
+  // The SMM Firmware Volume Block protocol structure is the same as the
+  // Firmware Volume Block protocol structure.
+  //
+  FvbHandle = NULL;
+  DEBUG ((EFI_D_INFO, "Installing QEMU flash SMM FVB\n"));
+  Status = 

[edk2] [PATCH v3 46/52] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: clean up includes and libraries

2015-10-14 Thread Laszlo Ersek
Before introducing the SMM driver interface, clean up #include directives
and [LibraryClasses] by:
- removing what's not directly used,
- adding what's used but not spelled out,
- sorting the result.

This helps with seeing each source file's dependencies and with
determining the library classes for the SMM driver.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf | 13 
++---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c | 16 
++--
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c  |  8 
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c   |  2 +-
 4 files changed, 13 insertions(+), 26 deletions(-)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
index 480b694..ea8413f 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
@@ -46,17 +46,16 @@ [Packages]
   OvmfPkg/OvmfPkg.dec
 
 [LibraryClasses]
-  UefiBootServicesTableLib
-  MemoryAllocationLib
+  BaseLib
   BaseMemoryLib
-  HobLib
   DebugLib
-  UefiRuntimeLib
+  DevicePathLib
   DxeServicesTableLib
-  BaseLib
-  UefiDriverEntryPoint
-  UefiLib
+  MemoryAllocationLib
   PcdLib
+  UefiBootServicesTableLib
+  UefiDriverEntryPoint
+  UefiRuntimeLib
 
 [Guids]
   gEfiEventVirtualAddressChangeGuid   # ALWAYS_CONSUMED
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c
index ec6bfdb..6edbeed 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c
@@ -24,28 +24,16 @@
 //
 // The package level header files this module uses
 //
-#include 
+#include 
+
 //
 // The protocols, PPI and GUID defintions for this module
 //
-#include 
-#include 
 #include 
-#include 
-#include 
 //
 // The Library classes this module consumes
 //
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 
 typedef struct {
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
index 0158bf9..c37aed1 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
@@ -23,19 +23,19 @@
 //
 // The protocols, PPI and GUID defintions for this module
 //
-#include 
 #include 
+#include 
 
 //
 // The Library classes this module consumes
 //
 #include 
-#include 
-#include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
-#include 
 
 #include "FwBlockService.h"
 #include "QemuFlash.h"
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
index 5b03046..28bcb13 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
@@ -13,8 +13,8 @@
 
 **/
 
-#include 
 #include 
+#include 
 #include 
 
 #include "QemuFlash.h"
-- 
1.8.3.1


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


[edk2] [PATCH v3 52/52] OvmfPkg: README: document SMM status

2015-10-14 Thread Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v3:
- this documentation is not accurate any longer, but since Paolo and
  myself are getting different test results, I'm not bothering updating
  this until our results converge

v2:
- documented "-nx" VCPU feature flag
  

 OvmfPkg/README | 43 
 1 file changed, 43 insertions(+)

diff --git a/OvmfPkg/README b/OvmfPkg/README
index 147e6e0..49aaae4 100644
--- a/OvmfPkg/README
+++ b/OvmfPkg/README
@@ -118,6 +118,49 @@ $ OvmfPkg/build.sh -a X64 qemu -cdrom 
/path/to/disk-image.iso
 To build a 32-bit OVMF without debug messages using GCC 4.5:
 $ OvmfPkg/build.sh -a IA32 -b RELEASE -t GCC45
 
+=== SMM support ===
+
+OVMF is capable of utilizing SMM if the underlying QEMU or KVM hypervisor
+emulates SMM. SMM is put to use in the S3 suspend and resume infrastructure,
+and in the UEFI variable driver stack. The purpose is (virtual) hardware
+separation between the runtime guest OS and the firmware (OVMF), with the
+intent to make Secure Boot actually secure, by preventing the runtime guest OS
+from tampering with the variable store and S3 areas.
+
+For SMM support, OVMF must be built with the "-D SMM_REQUIRE" option. The
+resultant firmware binary will check if QEMU actually provides SMM emulation;
+if it doesn't, then OVMF will log an error and trigger an assertion failure
+during boot (even in RELEASE builds). Both the naming of the flag (SMM_REQUIRE,
+instead of SMM_ENABLE), and this behavior are consistent with the goal
+described above: this is supposed to be a security feature, and fallbacks are
+not allowed. Similarly, a pflash-backed variable store is a requirement.
+
+QEMU should be started with the following flags (in addition to any other
+flags):
+
+  qemu-system-i386 \
+-machine q35,smm=on,accel=(tcg|kvm) \
+-global driver=cfi.pflash01,property=secure,value=on \
+-smp cpus=1 \
+-cpu coreduo,-nx \
+...
+
+OVMF's SMM support is subject to the following by-design limitations:
+- only the q35 machine type of QEMU is supported,
+- for 32-bit VCPUs ("qemu-system-i386" and "qemu-system-x86_64 -cpu
+  ,-lm"), the NX processor feature flag has to be disabled ("-cpu
+  ,...,-nx").
+
+OVMF's SMM support is subject to the following shortcomings:
+- it works only in uniprocessor guests,
+- with TCG acceleration, it works only on qemu-system-i386 (not on
+  qemu-system-x86_64),
+- with KVM acceleration, it should work on qemu-system-x86_64 in addition to
+  qemu-system-i386, but a 32-bit VCPU is required nonetheless (that is, long
+  mode must be disabled with the "-cpu ,-lm" switch).
+
+These issues will hopefully be addressed in the future.
+
 === Network Support ===
 
 OVMF provides a UEFI network stack by default. Its lowest level driver is the
-- 
1.8.3.1

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


[edk2] [PATCH v3 40/52] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: rewrap source code to 79 chars

2015-10-14 Thread Laszlo Ersek
Some of the line lengths in this driver are atrocious. While we have to
put up with the status quo outside of OvmfPkg, we can at least rewrap this
driver before refactoring it.

In the FvbInitialize() function there's no way around introducing two
local variables, just for the sake of sensibly rewrapping the code.

Furthermore, in "FwBlockService.c" the function comment blocks are now
indented; their original position causes diff to print bogus function
names at the top of hunks.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf |  25 +-
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h  |  31 +-
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h   |   7 +-
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c |  36 +-
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c  | 513 
+++-
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c   |   7 +-
 6 files changed, 337 insertions(+), 282 deletions(-)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
index e3e7176..ac903b5 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
@@ -1,17 +1,20 @@
 ## @file
-# Component description file for QEMU Flash Fimware Volume Block DXE driver 
module.
+#  Component description file for QEMU Flash Fimware Volume Block DXE driver
+#  module.
 #
-# This DXE runtime driver implements and produces the Fimware Volue Block 
Protocol
-# for a QEMU flash device.
+#  This DXE runtime driver implements and produces the Fimware Volue Block
+#  Protocol for a QEMU flash device.
 #
-# Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2013, 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
+#  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.
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
+#  IMPLIED.
 #
 ##
 
@@ -24,7 +27,8 @@ [Defines]
   ENTRY_POINT= FvbInitialize
 
 #
-# The following information is for reference only and not required by the 
build tools.
+# The following information is for reference only and not required by the build
+# tools.
 #
 #  VALID_ARCHITECTURES   = IA32
 #
@@ -53,7 +57,8 @@ [LibraryClasses]
   PcdLib
 
 [Guids]
-  gEfiEventVirtualAddressChangeGuid # ALWAYS_CONSUMED  Create 
Event: EVENT_GROUP_GUID
+  gEfiEventVirtualAddressChangeGuid   # ALWAYS_CONSUMED
+  # gEfiEventVirtualAddressChangeGuid # Create Event: EVENT_GROUP_GUID
 
 [Protocols]
   gEfiFirmwareVolumeBlockProtocolGuid   # PROTOCOL SOMETIMES_PRODUCED
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
index 0dcd26d..6fa7c7e 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
@@ -1,21 +1,22 @@
 /**@file
 
-Copyright (c) 2006, 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
-http://opensource.org/licenses/bsd-license.php
+  Copyright (c) 2006, Intel Corporation. All rights reserved.
 
-THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+  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
 
-Module Name:
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
-  FwBlockService.h
+  Module Name:
 
-Abstract:
+FwBlockService.h
 
-  Firmware volume block driver for Intel Firmware Hub (FWH) device
+  Abstract:
+
+Firmware volume block driver for Intel Firmware Hub (FWH) device
 
 **/
 
@@ -44,8 +45,12 @@ 

[edk2] [PATCH v3 51/52] OvmfPkg: double the SMRAM (TSEG) size for the 64-bit DXE phase builds

2015-10-14 Thread Laszlo Ersek
When building OVMF with -D SMM_REQUIRE -D SECURE_BOOT_ENABLE, using
gcc-4.8, for the DEBUG build target, and with DEBUG_VERBOSE enabled in
PcdDebugPrintErrorLevel, the build report files report the following
binary sizes for the SMM_CORE and SMM modules, in kilobytes:

  Driver  Ia32  X64
    --  ---
  PiSmmCore  56.7598.22
  CpuIo2Smm  13.4722.72
  SmmLockBox 24.6239.69
  PiSmmCpuDxeSmm 66.06   123.03
  FvbServicesSmm 22.2237.06
  SmmFaultTolerantWriteDxe   35.1960.06
  VariableSmm   356.88   640.28
    --  ---
  Total 575.19  1021.06

The 1 MB default for PcdQ35TsegMbytes, from OvmfPkg.dec, is insufficient
for loading the privileged half of the variable driver (VariableSmm) on
X64. This results in many warnings about the dependent drivers being
impossible to dispatch, and ultimately a DXE core assertion failure.

PcdQ35TsegMbytes can assume the values 1, 2 or 8; set it to 2 for the DSC
files with 64-bit DXE phases. For consistency between the DSC files, spell
out 1 in OvmfPkgIa32.dsc too.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v3:
- new in v3

 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 3 files changed, 3 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 9040bdc..660a645 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -401,6 +401,7 @@ [PcdsFixedAtBuild]
 
 !if $(SMM_REQUIRE) == TRUE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|1
 !endif
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 4aa7ba5..16dd785 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -407,6 +407,7 @@ [PcdsFixedAtBuild]
 [PcdsFixedAtBuild.X64]
 !if $(SMM_REQUIRE) == TRUE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|2
 !endif
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 6ea135d..fe4889a 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -406,6 +406,7 @@ [PcdsFixedAtBuild]
 
 !if $(SMM_REQUIRE) == TRUE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|2
 !endif
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
-- 
1.8.3.1


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


[edk2] [PATCH v3 45/52] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: split out runtime DXE specifics

2015-10-14 Thread Laszlo Ersek
In preparation for introducing an SMM interface to this driver, move the
following traits to separate files, so that we can replace them in the new
SMM INF file:

- Protocol installations. The SMM driver will install protocol interfaces
  in the SMM protocol database, using SMM services.

- Virtual address change handler and pointer conversions. SMM drivers run
  with physical mappings and pointers must not be converted.

There are further restrictions and changes for an SMM driver, but the rest
of the code either complies with those already, or will handle the changes
transparently. For example:

- SMM drivers have access to both UEFI and SMM protocols in their entry
  points (see the PI spec 1.4, "1.7 SMM Driver Initialization"),

- MemoryAllocationLib has an SMM instance that serves allocation requests
  with the gSmst->SmmAllocatePool() service transparently, allocating
  runtime-marked SMRAM.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf |   2 +
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h  |  15 ++
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h   |   2 +
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c  | 122 
+---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c   | 154 

 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c   |  17 +--
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlashDxe.c|  28 
 7 files changed, 209 insertions(+), 131 deletions(-)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
index 5f0264b..480b694 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
@@ -36,7 +36,9 @@ [Defines]
 [Sources]
   FvbInfo.c
   FwBlockService.c
+  FwBlockServiceDxe.c
   QemuFlash.c
+  QemuFlashDxe.c
 
 [Packages]
   MdePkg/MdePkg.dec
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
index 5e8c2c7..1f9287b 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
@@ -34,6 +34,8 @@ typedef struct {
   EFI_FW_VOL_INSTANCE *FvInstance;
 } ESAL_FWB_GLOBAL;
 
+extern ESAL_FWB_GLOBAL *mFvbModuleGlobal;
+
 //
 // Fvb Protocol instance data
 //
@@ -174,4 +176,17 @@ FvbProtocolEraseBlocks (
   ...
   );
 
+//
+// The following functions have different implementations dependent on the
+// module type chosen for building this driver.
+//
+VOID
+InstallProtocolInterfaces (
+  IN EFI_FW_VOL_BLOCK_DEVICE *FvbDevice
+  );
+
+VOID
+InstallVirtualAddressChangeHandler (
+  VOID
+  );
 #endif
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
index 975010e..8d83dca 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
@@ -18,6 +18,8 @@
 
 #include 
 
+extern UINT8 *mFlashBase;
+
 /**
   Read from QEMU Flash
 
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
index 3eccb1f..0158bf9 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
@@ -21,25 +21,16 @@
 **/
 
 //
-// The package level header files this module uses
-//
-#include 
-
-//
 // The protocols, PPI and GUID defintions for this module
 //
-#include 
 #include 
 #include 
 
 //
 // The Library classes this module consumes
 //
-#include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -117,56 +108,6 @@ EFI_FW_VOL_BLOCK_DEVICE mFvbDeviceTemplate = {
 };
 
 
-
-VOID
-EFIAPI
-FvbVirtualddressChangeEvent (
-  IN EFI_EVENTEvent,
-  IN VOID *Context
-  )
-/*++
-
-  Routine Description:
-
-Fixup internal data so that EFI and SAL can be call in virtual mode.
-Call the passed in Child Notify event and convert the mFvbModuleGlobal
-date items to there virtual address.
-
-  Arguments:
-
-(Standard EFI notify event - EFI_EVENT_NOTIFY)
-
-  Returns:
-
-None
-
---*/
-{
-  EFI_FW_VOL_INSTANCE *FwhInstance;
-  UINTN   Index;
-
-  FwhInstance = mFvbModuleGlobal->FvInstance;
-  EfiConvertPointer (0x0, (VOID **) >FvInstance);
-
-  //
-  // Convert the base address of all the instances
-  //
-  Index   = 0;
-  while (Index < mFvbModuleGlobal->NumFv) {
-EfiConvertPointer (0x0, (VOID **) >FvBase);
-FwhInstance = (EFI_FW_VOL_INSTANCE *)
-  (
-(UINTN) ((UINT8 *) FwhInstance) +
-FwhInstance->VolumeHeader.HeaderLength +
-(sizeof (EFI_FW_VOL_INSTANCE) - sizeof (EFI_FIRMWARE_VOLUME_HEADER))
-  

[edk2] [PATCH v3 50/52] OvmfPkg: pull in SMM-based variable driver stack

2015-10-14 Thread Laszlo Ersek
When -D SMM_REQUIRE is given, replace both
- OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf and
- OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
with
- OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf.

The outermost (= runtime DXE driver) VariableSmmRuntimeDxe enters SMM, and
the rest:
- the privileged half of the variable driver, VariableSmm,
- the fault tolerant write driver, FaultTolerantWriteSmm,
- and the FVB driver, FvbServicesSmm,
work in SMM purely.

We also resolve the BaseCryptLib class for DXE_SMM_DRIVER modules, for the
authenticated VariableSmm driver's sake.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- hook VarCheckUefiLib into VariableSmm
  


 OvmfPkg/OvmfPkgIa32.dsc| 18 --
 OvmfPkg/OvmfPkgIa32X64.dsc | 18 --
 OvmfPkg/OvmfPkgX64.dsc | 18 --
 OvmfPkg/OvmfPkgIa32.fdf| 16 ++--
 OvmfPkg/OvmfPkgIa32X64.fdf | 16 ++--
 OvmfPkg/OvmfPkgX64.fdf | 16 ++--
 6 files changed, 90 insertions(+), 12 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index b119c77..9040bdc 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -312,6 +312,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
 !ifdef $(SOURCE_DEBUG_ENABLE)
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
 !endif
+  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -731,10 +732,22 @@ [Components]
   SmmLib|MdePkg/Library/SmmLibNull/SmmLibNull.inf
   SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
   }
-!endif
 
   #
-  # Variable driver stack
+  # Variable driver stack (SMM)
+  #
+  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
+  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
+
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  }
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
+
+!else
+
+  #
+  # Variable driver stack (non-SMM)
   #
   OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
   OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
@@ -746,3 +759,4 @@ [Components]
 
   NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
   }
+!endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index a4f287b..4aa7ba5 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -317,6 +317,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
 !ifdef $(SOURCE_DEBUG_ENABLE)
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
 !endif
+  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -738,10 +739,22 @@ [Components.X64]
   SmmLib|MdePkg/Library/SmmLibNull/SmmLibNull.inf
   SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
   }
-!endif
 
   #
-  # Variable driver stack
+  # Variable driver stack (SMM)
+  #
+  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
+  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
+
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  }
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
+
+!else
+
+  #
+  # Variable driver stack (non-SMM)
   #
   OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
   OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
@@ -753,3 +766,4 @@ [Components.X64]
 
   NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
   }
+!endif
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 3f5f94d..6ea135d 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -317,6 +317,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
 !ifdef $(SOURCE_DEBUG_ENABLE)
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
 !endif
+  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -736,10 +737,22 @@ [Components]
   SmmLib|MdePkg/Library/SmmLibNull/SmmLibNull.inf
   SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
   }
-!endif
 
   #
-  # Variable driver stack
+  # Variable driver stack (SMM)
+  #
+  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
+  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
+
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  }
+  

[edk2] [PATCH v3 42/52] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: remove FvbDevLock field

2015-10-14 Thread Laszlo Ersek
The EFI_FW_VOL_INSTANCE.FvbDevLock member is initialized and then never
used. Remove it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h | 1 -
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
index 6fa7c7e..67140d0 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
@@ -30,7 +30,6 @@
 #define FVB_VIRTUAL   1
 
 typedef struct {
-  EFI_LOCKFvbDevLock;
   UINTN   FvBase[2];
   UINTN   NumOfBlocks;
   EFI_FIRMWARE_VOLUME_HEADER  VolumeHeader;
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
index c542482..3e7fe68 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
@@ -1119,7 +1119,6 @@ FvbInitialize (
   CopyMem ((UINTN *) &(FwhInstance->VolumeHeader), (UINTN *) FwVolHeader,
 FwVolHeader->HeaderLength);
   FwVolHeader = &(FwhInstance->VolumeHeader);
-  EfiInitializeLock (&(FwhInstance->FvbDevLock), TPL_HIGH_LEVEL);
 
   NumOfBlocks = 0;
 
-- 
1.8.3.1


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


[edk2] [PATCH v3 48/52] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: adhere to -D SMM_REQUIRE

2015-10-14 Thread Laszlo Ersek
When the user requires "security" by passing -D SMM_REQUIRE, and
consequently by setting PcdSmmSmramRequire, enforce flash-based variables.

Furthermore, add two ASSERT()s to catch if the wrong module were pulled
into the build.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf | 2 ++
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf| 2 ++
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c   | 3 +++
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c   | 3 +++
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c   | 1 +
 5 files changed, 11 insertions(+)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
index ea8413f..c0dda75 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
@@ -85,6 +85,8 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable
 
+[FeaturePcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
 
 [Depex]
   TRUE
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
index 6af0649..ba2d367 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
@@ -84,6 +84,8 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable
 
+[FeaturePcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
 
 [Depex]
   TRUE
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
index c11f598..63b3086 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -34,6 +35,8 @@ InstallProtocolInterfaces (
   EFI_HANDLE FwbHandle;
   EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL *OldFwbInterface;
 
+  ASSERT (!FeaturePcdGet (PcdSmmSmramRequire));
+
   //
   // Find a handle with a matching device path that has supports FW Block
   // protocol
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c
index e77129e..e0617f2 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c
@@ -15,6 +15,7 @@
 **/
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,8 @@ InstallProtocolInterfaces (
   EFI_HANDLE FvbHandle;
   EFI_STATUS Status;
 
+  ASSERT (FeaturePcdGet (PcdSmmSmramRequire));
+
   //
   // There is no SMM service that can install multiple protocols in the SMM
   // protocol database in one go.
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
index 28bcb13..5677b5e 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
@@ -245,6 +245,7 @@ QemuFlashInitialize (
   mFdBlockCount = PcdGet32 (PcdOvmfFirmwareFdSize) / mFdBlockSize;
 
   if (!QemuFlashDetected ()) {
+ASSERT (!FeaturePcdGet (PcdSmmSmramRequire));
 return EFI_WRITE_PROTECTED;
   }
 
-- 
1.8.3.1


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


[edk2] [PATCH v3 49/52] OvmfPkg: consolidate variable driver stack in DSC and FDF files

2015-10-14 Thread Laszlo Ersek
The following modules constitute the variable driver stack:

- QemuFlashFvbServicesRuntimeDxe and EmuVariableFvbRuntimeDxe, runtime
  alternatives for providing the Firmware Volume Block(2) Protocol,
  dependent on qemu pflash presence,

- FaultTolerantWriteDxe, providing the Fault Tolerant Write Protocol,

- MdeModulePkg/Universal/Variable/RuntimeDxe, independently of
  -D SECURE_BOOT_ENABLE, providing the Variable and Variable Write
  Architectural Protocols.

Let's move these drivers closer to each other in the DSC and FDF files, so
that we can switch the variable driver stack to SMM with more local
changes.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 24 
 OvmfPkg/OvmfPkgIa32X64.dsc | 24 
 OvmfPkg/OvmfPkgX64.dsc | 24 
 OvmfPkg/OvmfPkgIa32.fdf| 12 ++
 OvmfPkg/OvmfPkgIa32X64.fdf | 12 ++
 OvmfPkg/OvmfPkgX64.fdf | 12 ++
 6 files changed, 66 insertions(+), 42 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 126f084..b119c77 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -541,19 +541,9 @@ [Components]
   OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
   OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
-  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
   OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
   OvmfPkg/XenBusDxe/XenBusDxe.inf
   OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
-  OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
-
-  PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
-  }
-  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
-  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
-
-  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
-  }
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
@@ -742,3 +732,17 @@ [Components]
   SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
   }
 !endif
+
+  #
+  # Variable driver stack
+  #
+  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+  OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
+
+  PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
+  }
+  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  }
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 810c6e7..a4f287b 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -548,19 +548,9 @@ [Components.X64]
   OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
   OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
-  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
   OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
   OvmfPkg/XenBusDxe/XenBusDxe.inf
   OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
-  OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
-
-  PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
-  }
-  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
-  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
-
-  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
-  }
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
@@ -749,3 +739,17 @@ [Components.X64]
   SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
   }
 !endif
+
+  #
+  # Variable driver stack
+  #
+  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+  OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
+
+  PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
+  }
+  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  }
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 565c37c..3f5f94d 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -546,19 +546,9 @@ [Components]
   OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
   OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
-  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
   OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
   OvmfPkg/XenBusDxe/XenBusDxe.inf
   OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
-  OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
-
-  

[edk2] [PATCH v3 36/52] OvmfPkg: QuarkPort/CpuS3DataDxe: handle register tables in ACPI_CPU_DATA

2015-10-14 Thread Laszlo Ersek
Each one of the "PreSmmInitRegisterTable" and "RegisterTable" fields in
ACPI_CPU_DATA is a pointer to an array of CPU_REGISTER_TABLE objects; one
object per logical processor. Each table carries a variable number of
CPU_REGISTER_TABLE_ENTRY objects; each entry prescribes a specific
register setting for the CPU whose CPU_REGISTER_TABLE the entry is in.

Such entries are added to the tables with the following CpuConfigLib
functions:
- WriteRegisterTableEx(): internal helper,
- WriteRegisterTable(): public function for RegisterTable,
- WritePreSmmInitRegisterTable(): public function for
  PreSmmInitRegisterTable.

* The driver

Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe/

  allocates the array of CPU_REGISTER_TABLEs in AcpiNVS for
  ACPI_CPU_DATA.PreSmmInitRegisterTable, and sets the InitialApicID field
  of each table object. (This is then later used by PiSmmCpuDxeSmm to
  match a table against a logical CPU.)

  However, CpuMpDxe never actually adds any register entries to any
  processor's table in the PreSmmInitRegisterTable, either with
  WritePreSmmInitRegisterTable(), or manually.

* CpuMpDxe is theoretically capable of adding register entries (MSR, CRn
  changes etc) to the elements of the array pointed-to by
  ACPI_CPU_DATA.RegisterTable. See the following call tree in CpuMpDxe:

  ProduceRegisterTable()
MaxCpuidLimitReg()
  WriteRegisterTable(
..., MSR_IA32_MISC_ENABLE, N_MSR_LIMIT_CPUID_MAXVAL, ...
)
XdReg()
  WriteRegisterTable(
..., MSR_IA32_MISC_ENABLE, N_MSR_XD_BIT_DISABLE, ...
)

  However, both MaxCpuidLimitReg() and XdReg() are gated by feature PCDs;
  we'll just consider those disabled.

Therefore, we'll explicitly instruct PiSmmCpuDxeSmm to do nothing in
response to these tables: we allocate both arrays, but leave them
zero-filled.

That will short-circuit the processing in PiSmmCpuDxeSmm for most logical
CPUs, in the

  (RegisterTableList[Index].InitialApicId == InitApicId)

checks. And when those checks don't fail, and SetProcessorRegister() gets
called, then the

  RegisterTable->TableLength == 0

equality will short-circuit that function.

Suggested-by: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- This patch replaces the following v1 patches:
  - OvmfPkg: QuarkPort: drop ACPI_CPU_DATA.PreSmmInitRegisterTable
  - OvmfPkg: QuarkPort: drop ACPI_CPU_DATA.RegisterTable
  It intends to have the same effect, but without modifying the
  ACPI_CPU_DATA structure, or PiSmmCpuDxeSmm.

 OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c
index 25ac8b1..1f4a081 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c
@@ -57,6 +57,9 @@ PrepareMemoryForConfiguration (
   VOID
   )
 {
+  UINTNNumberOfProcessors;
+  UINTNRegisterTableSize;
+
   //
   // Claim memory for AP stack.
   //
@@ -64,6 +67,17 @@ PrepareMemoryForConfiguration (
 PcdGet32 (PcdCpuMaxLogicalProcessorNumber) *
 PcdGet32 (PcdCpuApStackSize)
 );
+
+  //
+  // OVMF port note: leaving these tables zero-filled tells PiSmmCpuDxeSmm that
+  // there is no work to do.
+  //
+  NumberOfProcessors = mCpuConfigConextBuffer.NumberOfProcessors;
+  RegisterTableSize = sizeof (CPU_REGISTER_TABLE) * NumberOfProcessors;
+  mCpuConfigConextBuffer.RegisterTable =
+AllocateAcpiNvsMemoryBelow4G (RegisterTableSize);
+  mCpuConfigConextBuffer.PreSmmInitRegisterTable =
+AllocateAcpiNvsMemoryBelow4G (RegisterTableSize);
 }
 
 /**
@@ -294,6 +308,12 @@ SaveCpuS3Data (
   mAcpiCpuData->StackSize  = PcdGet32 (PcdCpuApStackSize);
   mAcpiCpuData->MtrrTable  = (EFI_PHYSICAL_ADDRESS)(UINTN)MtrrSettings;
 
+  mAcpiCpuData->RegisterTable =
+(EFI_PHYSICAL_ADDRESS)(UINTN)mCpuConfigConextBuffer.RegisterTable;
+  mAcpiCpuData->PreSmmInitRegisterTable =
+(EFI_PHYSICAL_ADDRESS)(UINTN)
+  mCpuConfigConextBuffer.PreSmmInitRegisterTable;
+
   mAcpiCpuData->ApMachineCheckHandlerBase = mApMachineCheckHandlerBase;
   mAcpiCpuData->ApMachineCheckHandlerSize = mApMachineCheckHandlerSize;
 
-- 
1.8.3.1


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


[edk2] [PATCH v3 43/52] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: remove FvbScratchSpace field

2015-10-14 Thread Laszlo Ersek
The ESAL_FWB_GLOBAL.FvbScratchSpace array is never initialized (it
contains garbage from AllocateRuntimePool()). Its element at subscript one
(=FVB_VIRTUAL), containing garbage as well, is converted to virtual
mapping. Then the array is never used again.

Remove it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h | 1 -
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c | 2 --
 2 files changed, 3 deletions(-)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
index 67140d0..7e4ff1e 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
@@ -38,7 +38,6 @@ typedef struct {
 typedef struct {
   UINT32  NumFv;
   EFI_FW_VOL_INSTANCE *FvInstance[2];
-  UINT8   *FvbScratchSpace[2];
 } ESAL_FWB_GLOBAL;
 
 //
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
index 3e7fe68..95ae8cc 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
@@ -169,8 +169,6 @@ FvbVirtualddressChangeEvent (
 Index++;
   }
 
-  EfiConvertPointer (0x0,
-(VOID **) >FvbScratchSpace[FVB_VIRTUAL]);
   EfiConvertPointer (0x0, (VOID **) );
   QemuFlashConvertPointers ();
 }
-- 
1.8.3.1


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


[edk2] [PATCH v3 44/52] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: no dual addressing needed

2015-10-14 Thread Laszlo Ersek
Currently the EFI_FW_VOL_INSTANCE and ESAL_FWB_GLOBAL structures declare
the following entries as arrays, with two entries each:

- EFI_FW_VOL_INSTANCE.FvBase[2]
- ESAL_FWB_GLOBAL.FvInstance[2]

In every case, the entry at subscript zero is meant as "physical address",
while the entry at subscript one is meant as "virtual address" -- a
pointer to the same object. The virtual address entry is originally
initialized to the physical address, and then it is converted to the
virtual mapping in FvbVirtualddressChangeEvent().

Functions that (a) read the listed fields and (b) run both before and
after the virtual address change event -- since this is a runtime DXE
driver -- derive the correct array subscript by calling the
EfiGoneVirtual() function from UefiRuntimeLib.

The problem with the above infrastructure is that it's entirely
superfluous.

EfiGoneVirtual() "knows" whether EFI has gone virtual only because the
UefiRuntimeLib constructor registers the exact same kind of virtual
address change callback, and the callback flips a static variabe to TRUE,
and EfiGoneVirtual() queries that static variable.

In effect this means for QemuFlashFvbServicesRuntimeDxe: "when there is a
virtual address change, convert the entries with subscript one from
physical to virtual, and from then on use the entries with subscript one".

This would only make sense if QemuFlashFvbServicesRuntimeDxe ever needed
the original (physical) addresses (ie. the entries with subscript zero)
after the virtual address change, but that is not the case.

Replace the arrays with single elements. The subscript zero elements
simply disappear, and the single elements take the role of the prior
subscript one elements.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h | 22 ++
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c | 77 
++--
 2 files changed, 30 insertions(+), 69 deletions(-)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
index 7e4ff1e..5e8c2c7 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
@@ -23,21 +23,15 @@
 #ifndef _FW_BLOCK_SERVICE_H
 #define _FW_BLOCK_SERVICE_H
 
-//
-// BugBug: Add documentation here for data structure
-//
-#define FVB_PHYSICAL  0
-#define FVB_VIRTUAL   1
-
 typedef struct {
-  UINTN   FvBase[2];
+  UINTN   FvBase;
   UINTN   NumOfBlocks;
   EFI_FIRMWARE_VOLUME_HEADER  VolumeHeader;
 } EFI_FW_VOL_INSTANCE;
 
 typedef struct {
   UINT32  NumFv;
-  EFI_FW_VOL_INSTANCE *FvInstance[2];
+  EFI_FW_VOL_INSTANCE *FvInstance;
 } ESAL_FWB_GLOBAL;
 
 //
@@ -78,24 +72,21 @@ EFI_STATUS
 FvbSetVolumeAttributes (
   IN UINTNInstance,
   IN OUT EFI_FVB_ATTRIBUTES_2 *Attributes,
-  IN ESAL_FWB_GLOBAL  *Global,
-  IN BOOLEAN  Virtual
+  IN ESAL_FWB_GLOBAL  *Global
   );
 
 EFI_STATUS
 FvbGetVolumeAttributes (
   IN UINTNInstance,
   OUT EFI_FVB_ATTRIBUTES_2*Attributes,
-  IN ESAL_FWB_GLOBAL  *Global,
-  IN BOOLEAN  Virtual
+  IN ESAL_FWB_GLOBAL  *Global
   );
 
 EFI_STATUS
 FvbGetPhysicalAddress (
   IN UINTNInstance,
   OUT EFI_PHYSICAL_ADDRESS*Address,
-  IN ESAL_FWB_GLOBAL  *Global,
-  IN BOOLEAN  Virtual
+  IN ESAL_FWB_GLOBAL  *Global
   );
 
 EFI_STATUS
@@ -120,8 +111,7 @@ FvbGetLbaAddress (
   OUT UINTN   *LbaAddress,
   OUT UINTN   *LbaLength,
   OUT UINTN   *NumOfBlocks,
-  IN  ESAL_FWB_GLOBAL *Global,
-  IN  BOOLEAN Virtual
+  IN  ESAL_FWB_GLOBAL *Global
   );
 
 //
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
index 95ae8cc..3eccb1f 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
@@ -132,11 +132,6 @@ FvbVirtualddressChangeEvent (
 Call the passed in Child Notify event and convert the mFvbModuleGlobal
 date items to there virtual address.
 
-mFvbModuleGlobal->FvInstance[FVB_PHYSICAL]  - Physical copy of instance
-  data
-mFvbModuleGlobal->FvInstance[FVB_VIRTUAL]   - Virtual pointer to common
-  instance data.
-
   Arguments:
 
 (Standard EFI notify event - EFI_EVENT_NOTIFY)
@@ -150,16 

[edk2] [PATCH v3 01/52] UefiCpuPkg: CpuDxe: Fix ASSERT() when only 1 CPU detected

2015-10-14 Thread Laszlo Ersek
From: Michael Kinney 

When only 1 CPU is detected and the max CPUs is greater than 1,
an ASSERT() is generated because the pages associated with the
AP stack have already been freed.  Only do this FreePages() call
if there is more than 1 CPU detected.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---

Notes:
v2:
- New in v2, but this is just a fixup from Mike on top of his series
  "[edk2] [PATCH 0/7] UefiCpuPkg: Add CPU SMM and SecCore". I'm
  including it here for completeness; the next version of Mike's series
  will contain it squashed-in.

 UefiCpuPkg/CpuDxe/CpuMp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
index 22a0d9d..da3686e 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -1697,7 +1697,7 @@ InitializeMpSupport (
   );
   ASSERT_EFI_ERROR (Status);
 
-  if (mMpSystemData.NumberOfProcessors < gMaxLogicalProcessorNumber) {
+  if (mMpSystemData.NumberOfProcessors > 1 && mMpSystemData.NumberOfProcessors 
< gMaxLogicalProcessorNumber) {
 if (mApStackStart != NULL) {
   FreePages (mApStackStart, EFI_SIZE_TO_PAGES (
   (gMaxLogicalProcessorNumber - 
mMpSystemData.NumberOfProcessors) *
-- 
1.8.3.1


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


Re: [edk2] [PATCH 1/3] ArmPlatformPkg: NorFlashDxe: mellow DEBUG messages about flash reinit

2015-10-14 Thread Laszlo Ersek
On 10/13/15 15:36, Leif Lindholm wrote:
> On Tue, Oct 13, 2015 at 03:32:46PM +0200, Laszlo Ersek wrote:
// Install the Default FVB header if required
if (EFI_ERROR(Status)) {
  // There is no valid header, so time to install one.
 -DEBUG((EFI_D_ERROR,"NorFlashFvbInitialize: ERROR - The FVB Header is 
 not valid. Installing a correct one for this volume.\n"));
 +DEBUG ((EFI_D_INFO, "%a: The FVB Header is not valid. Installing a "
 +  "correct one for this volume.\n", __FUNCTION__));
>>>
>>> While I approve of breaking output lines up to reviewable lengths,
>>> this one actually breaks up the message string itself - making
>>> tracking it down in the source more tedious. Could you either leave
>>> the message string whole, or break the two sentences into separate
>>> DEBUG statements?
>>
>> I'll break them up. I don't like overlong lines. :)
> 
> Sure.
>  
>> I assume you'd like to see the two sentences on separate lines in the
>> log output as well (so that noone is tempted to search for the full line
>> in the source). Is that right?
> 
> Exactly, thanks!
> 
>>> Do that and:
>>> Reviewed-by: Leif Lindholm 

I'll send a new version of the set soon; not picking up your R-b just
yet. I'd appreciate a quick skim. :)

Thanks!
Laszlo

>>
>> Thanks!
>> Laszlo
>>
>>>
  
  // Erase all the NorFlash that is reserved for variable storage
  FvbNumLba = (PcdGet32(PcdFlashNvStorageVariableSize) + 
 PcdGet32(PcdFlashNvStorageFtwWorkingSize) + 
 PcdGet32(PcdFlashNvStorageFtwSpareSize)) / Instance->Media.BlockSize;
  
  Status = FvbEraseBlocks (>FvbProtocol, (EFI_LBA)0, 
 FvbNumLba, EFI_LBA_LIST_TERMINATOR);
  if (EFI_ERROR(Status)) {
return Status;
  }
  
  // Install all appropriate headers
 -- 
 1.8.3.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 11/41] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER

2015-10-14 Thread Paolo Bonzini
On 13/10/2015 15:26, Laszlo Ersek wrote:
>>//
>> +  // The write to the control register is synchronous and only affects the
>> +  // current CPU, so bring in the APs first.  The SMI handler expects that
>> +  // all APs will rendez-vous within one PcdCpuSmmApSyncTimeout (though it
>> +  // helpfully tries sending SMI IPIs to the missing processors if there are
>> +  // any).
>> +  //
>> +  SendSmiIpiAllExcludingSelf ();
>> +
>> +  //

Nevermind, this patch is unfortunately broken.

SendSmiIpiAllExcludingSelf does not work after ExitBootServices, because
it hardcodes the physical address of the APIC.  While that could be
fixed in LocalApicLib, it turns out that using SmmSyncModeRelaxedAp is a
trivial addition to my series that introduces a SmmCpuFeaturesLib
implementation specific to OvmfPkg.  Therefore, I'm withdrawing this
patch and submitting another in that thread.

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


[edk2] [PATCH v2 11/16] UefiCpuPkg: Add ACPI CPU Data include file

2015-10-14 Thread Michael Kinney
Add AcpuCpuData.h that defines a data structure that is shared between
modules and is required for ACPI S3 support.
APState field removed between V1 and V2 patch.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
Cc: Laszlo Ersek 
---
 UefiCpuPkg/Include/AcpiCpuData.h | 71 
 1 file changed, 71 insertions(+)
 create mode 100644 UefiCpuPkg/Include/AcpiCpuData.h

diff --git a/UefiCpuPkg/Include/AcpiCpuData.h b/UefiCpuPkg/Include/AcpiCpuData.h
new file mode 100644
index 000..a367257
--- /dev/null
+++ b/UefiCpuPkg/Include/AcpiCpuData.h
@@ -0,0 +1,71 @@
+/** @file
+Definitions for CPU S3 data.
+
+Copyright (c) 2013 - 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
+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 _ACPI_CPU_DATA_H_
+#define _ACPI_CPU_DATA_H_
+
+//
+// Register types in register table
+//
+typedef enum _REGISTER_TYPE {
+  Msr,
+  ControlRegister,
+  MemoryMapped,
+  CacheControl
+} REGISTER_TYPE;
+
+//
+// Element of register table entry
+//
+typedef struct {
+  REGISTER_TYPE RegisterType;
+  UINT32Index;
+  UINT8 ValidBitStart;
+  UINT8 ValidBitLength;
+  UINT64Value;
+} CPU_REGISTER_TABLE_ENTRY;
+
+//
+// Register table definition, including current table length,
+// allocated size of this table, and pointer to the list of table entries.
+//
+typedef struct {
+  UINT32   TableLength;
+  UINT32   NumberBeforeReset;
+  UINT32   AllocatedSize;
+  UINT32   InitialApicId;
+  CPU_REGISTER_TABLE_ENTRY *RegisterTableEntry;
+} CPU_REGISTER_TABLE;
+
+typedef struct {
+  EFI_PHYSICAL_ADDRESS  StartupVector;
+  EFI_PHYSICAL_ADDRESS  GdtrProfile;
+  EFI_PHYSICAL_ADDRESS  IdtrProfile;
+  EFI_PHYSICAL_ADDRESS  StackAddress;
+  UINT32StackSize;
+  UINT32NumberOfCpus;
+  EFI_PHYSICAL_ADDRESS  MtrrTable;
+  //
+  // Physical address of a CPU_REGISTER_TABLE structure
+  //
+  EFI_PHYSICAL_ADDRESS  PreSmmInitRegisterTable;
+  //
+  // Physical address of a CPU_REGISTER_TABLE structure
+  //
+  EFI_PHYSICAL_ADDRESS  RegisterTable;
+  EFI_PHYSICAL_ADDRESS  ApMachineCheckHandlerBase;
+  UINT32ApMachineCheckHandlerSize;
+} ACPI_CPU_DATA;
+
+#endif
-- 
1.9.5.msysgit.1

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


[edk2] [PATCH v2 07/16] UefiCpuPkg: Add SmmCpuFeaturesLib

2015-10-14 Thread Michael Kinney
Add SmmCpuFeaturesLib that provides CPU specific functions that are
used to initialize SMM and process SMIs.  A functional implementation
of this library class is provided that is based on the
Intel(R) 64 and IA-32 Architectures Software Developer's Manual

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 UefiCpuPkg/Include/Library/SmmCpuFeaturesLib.h | 366 ++
 .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c  | 559 +
 .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf|  39 ++
 .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.uni| Bin 0 -> 1674 bytes
 4 files changed, 964 insertions(+)
 create mode 100644 UefiCpuPkg/Include/Library/SmmCpuFeaturesLib.h
 create mode 100644 UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
 create mode 100644 UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
 create mode 100644 UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.uni

diff --git a/UefiCpuPkg/Include/Library/SmmCpuFeaturesLib.h 
b/UefiCpuPkg/Include/Library/SmmCpuFeaturesLib.h
new file mode 100644
index 000..133a1b8
--- /dev/null
+++ b/UefiCpuPkg/Include/Library/SmmCpuFeaturesLib.h
@@ -0,0 +1,366 @@
+/** @file
+Library that provides CPU specific functions to support the PiSmmCpuDxeSmm 
module.
+
+Copyright (c) 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
+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 __SMM_FEATURES_LIB_H__
+#define __SMM_FEATURES_LIB_H__
+
+#include 
+#include 
+#include 
+#include 
+
+///
+/// Enumeration of SMM registers that are accessed using the library functions
+/// SmmCpuFeaturesIsSmmRegisterSupported (), SmmCpuFeaturesGetSmmRegister (), 
+/// and SmmCpuFeaturesSetSmmRegister ().
+///
+typedef enum {
+  ///
+  /// Read-write register to provides access to MSR_SMM_FEATURE_CONTROL if the 
+  /// CPU supports this MSR.
+  ///
+  SmmRegFeatureControl,
+  ///
+  /// Read-only register that returns a non-zero value if the CPU is able to 
+  /// respond to SMIs.
+  ///
+  SmmRegSmmEnable,
+  ///
+  /// Read-only register that returns a non-zero value if the CPU is able to 
+  /// respond to SMIs, but is busy with other actions that are causing a delay 
+  /// in responding to an SMI.  This register abstracts access to 
MSR_SMM_DELAYED
+  /// if the CPU supports this MSR.
+  ///
+  SmmRegSmmDelayed,
+  ///
+  /// Read-only register that returns a non-zero value if the CPU is able to 
+  /// respond to SMIs, but is busy with other actions that are blocking its 
+  /// ability to respond to an SMI.  This register abstracts access to 
+  /// MSR_SMM_BLOCKED if the CPU supports this MSR.
+  ///
+  SmmRegSmmBlocked
+} SMM_REG_NAME;
+
+/**
+  Called during the very first SMI into System Management Mode to initialize
+  CPU features, including SMBASE, for the currently executing CPU.  Since this
+  is the first SMI, the SMRAM Save State Map is at the default address of
+  SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET.  The currently executing 
+  CPU is specified by CpuIndex and CpuIndex can be used to access information 
+  about the currently executing CPU in the ProcessorInfo array and the 
+  HotPlugCpuData data structure.
+
+  @param[in] CpuIndexThe index of the CPU to initialize.  The value 
+ must be between 0 and the NumberOfCpus field in 
+ the System Management System Table (SMST).
+  @param[in] IsMonarch   TRUE if the CpuIndex is the index of the CPU that 
+ was elected as monarch during System Management 
+ Mode initialization.
+ FALSE if the CpuIndex is not the index of the CPU 
+ that was elected as monarch during System 
+ Management Mode initialization.
+  @param[in] ProcessorInfo   Pointer to an array of EFI_PROCESSOR_INFORMATION 
+ structures.  ProcessorInfo[CpuIndex] contains the 
+ information for the currently executing CPU.
+  @param[in] HotPlugCpuData  Pointer to the CPU_HOT_PLUG_DATA structure that
+ contains the ApidId and SmBase arrays.
+**/
+VOID
+EFIAPI
+SmmCpuFeaturesInitializeProcessor (
+  IN UINTN  CpuIndex,
+  IN BOOLEANIsMonarch,
+  IN EFI_PROCESSOR_INFORMATION  *ProcessorInfo,
+  IN CPU_HOT_PLUG_DATA  *CpuHotPlugData
+  );
+
+/**
+  This function updates the SMRAM save state on the currently executing CPU
+  to resume 

[edk2] [PATCH v2 12/16] UefiCpuPkg: Add CPU Hot Plug Data include file

2015-10-14 Thread Michael Kinney
Add CpuHotPlugData.h that defines a data structure that is shared between
modules and is required for to support hot plug CPUs.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 UefiCpuPkg/Include/CpuHotPlugData.h | 33 +
 1 file changed, 33 insertions(+)
 create mode 100644 UefiCpuPkg/Include/CpuHotPlugData.h

diff --git a/UefiCpuPkg/Include/CpuHotPlugData.h 
b/UefiCpuPkg/Include/CpuHotPlugData.h
new file mode 100644
index 000..2a0d9fa
--- /dev/null
+++ b/UefiCpuPkg/Include/CpuHotPlugData.h
@@ -0,0 +1,33 @@
+/** @file
+Definition for a structure sharing information for CPU hot plug.
+
+Copyright (c) 2013 - 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
+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 _CPU_HOT_PLUG_DATA_H_
+#define _CPU_HOT_PLUG_DATA_H_
+
+#define  CPU_HOT_PLUG_DATA_REVISION_1  0x0001
+
+typedef struct {
+  UINT32Revision;  // Used for version identification for this 
structure
+  UINT32ArrayLength;   // The entries number of the following ApicId 
array and SmBase array
+  //
+  // Data required for SMBASE relocation
+  //
+  UINT64*ApicId;   // Pointer to ApicId array
+  UINTN *SmBase;   // Pointer to SmBase array
+  UINT32Reserved;
+  UINT32SmrrBase;
+  UINT32SmrrSize;
+} CPU_HOT_PLUG_DATA;
+
+#endif
-- 
1.9.5.msysgit.1

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


[edk2] [PATCH v2 13/16] UefiCpuPkg: Update DEC/DSC files for new includes and libraries

2015-10-14 Thread Michael Kinney
Add SmmCpuPlatformHookLib library class declaration
Add SmmCpuFeaturesLib library class declaration
Add gEfiSmmCpuServiceProtocolGuid protocol declaration
Build SmmCpuPlatformHookLibNull library instance
Build SmmCpuFeaturesLib library instance

Changes between [PATCH v1] and [PATCH v2]:
1) Use module type specific CpuExceptionHandlerLib in DSC file
   instead of Null library instance

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
Cc: Laszlo Ersek 
---
 UefiCpuPkg/UefiCpuPkg.dec | 13 -
 UefiCpuPkg/UefiCpuPkg.dsc | 10 --
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index fe9b2a5..4f7065f 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -41,11 +41,22 @@
   ##  @libraryclass  Provides platform specific initialization functions in 
the SEC phase.
   ##
   PlatformSecLib|Include/Library/PlatformSecLib.h
-
   
+  ##  @libraryclass  Public include file for the SMM CPU Platform Hook Library.
+  ##
+  SmmCpuPlatformHookLib|Include/Library/SmmCpuPlatformHookLib.h
+  
+  ##  @libraryclass  Provides the CPU specific programming for PiSmmCpuDxeSmm 
module.
+  ##
+  SmmCpuFeaturesLib|Include/Library/SmmCpuFeaturesLib.h
+
 [Guids]
   gUefiCpuPkgTokenSpaceGuid  = { 0xac05bf33, 0x995a, 0x4ed4, { 0xaa, 0xb8, 
0xef, 0x7a, 0xe8, 0xf, 0x5c, 0xb0 }}
 
+[Protocols]
+  ## Include/Protocol/SmmCpuService.h
+  gEfiSmmCpuServiceProtocolGuid  = { 0x1d202cab, 0xc8ab, 0x4d5c, { 0x94, 0xf7, 
0x3c, 0xfc, 0xc0, 0xd3, 0xd3, 0x35 }}
+  
 #
 # [Error.gUefiCpuPkgTokenSpaceGuid]
 #   0x8001 | Invalid value provided.
diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc
index 68400e3..961c970 100644
--- a/UefiCpuPkg/UefiCpuPkg.dsc
+++ b/UefiCpuPkg/UefiCpuPkg.dsc
@@ -32,6 +32,7 @@
   BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
   CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
+  SerialPortLib|MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf 
 
   
DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
   DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
   UefiCpuLib|UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
@@ -51,14 +52,16 @@
   DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
   LocalApicLib|UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf
   
ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseReportStatusCodeLibNull.inf
-  
CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf
   
SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
   SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
+  
SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
+  SmmCpuFeaturesLib|UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
   
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
   
PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf
 
 [LibraryClasses.common.SEC]
   PlatformSecLib|UefiCpuPkg/Library/PlatformSecLibNull/PlatformSecLibNull.inf
+  
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
   
 [LibraryClasses.common.PEIM]
   
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
@@ -74,11 +77,13 @@
 [LibraryClasses.common.DXE_DRIVER]
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
+  
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
 
 [LibraryClasses.common.DXE_SMM_DRIVER]
   
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
   
MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
+  
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
 
 #
 # Drivers/Libraries within this package
@@ -101,8 +106,9 @@
   UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
   UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
   UefiCpuPkg/Library/PlatformSecLibNull/PlatformSecLibNull.inf
+  UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
+  UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
   UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.inf
   UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationSmm.inf
   UefiCpuPkg/SecCore/SecCore.inf
   UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
-
-- 
1.9.5.msysgit.1

___

[edk2] [PATCH v2 10/16] UefiCpuPkg: Add SMRAM Save State include file

2015-10-14 Thread Michael Kinney
Add SmramSaveStateMap.h file that defines the 32-bit and 64-bit CPU
SMRAM Save State Map.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 UefiCpuPkg/Include/Register/SmramSaveStateMap.h | 190 
 1 file changed, 190 insertions(+)
 create mode 100644 UefiCpuPkg/Include/Register/SmramSaveStateMap.h

diff --git a/UefiCpuPkg/Include/Register/SmramSaveStateMap.h 
b/UefiCpuPkg/Include/Register/SmramSaveStateMap.h
new file mode 100644
index 000..f8c1e05
--- /dev/null
+++ b/UefiCpuPkg/Include/Register/SmramSaveStateMap.h
@@ -0,0 +1,190 @@
+/** @file
+SMRAM Save State Map Definitions.
+
+SMRAM Save State Map definitions based on contents of the 
+Intel(R) 64 and IA-32 Architectures Software Developer's Manual
+  Volume 3C, Section 34.4 SMRAM
+  Volume 3C, Section 34.5 SMI Handler Execution Environment
+  Volume 3C, Section 34.7 Managing Synchronous and Asynchronous SMIs
+
+Copyright (c) 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
+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 __SMRAM_SAVE_STATE_MAP_H__
+#define __SMRAM_SAVE_STATE_MAP_H__
+
+///
+/// Default SMBASE address
+///
+#define SMM_DEFAULT_SMBASE   0x3
+
+///
+/// Offset of SMM handler from SMBASE
+///
+#define SMM_HANDLER_OFFSET   0x8000
+
+///
+/// Offset of SMRAM Save State Map from SMBASE
+///
+#define SMRAM_SAVE_STATE_MAP_OFFSET  0xfc00
+
+#pragma pack (1)
+
+/// 
+/// 32-bit SMRAM Save State Map
+///
+typedef struct {
+  UINT8   Reserved[0x200];  // 7c00h  
+// Padded an extra 0x200 bytes so 32-bit and 
64-bit 
+// SMRAM Save State Maps are the same size
+  UINT8   Reserved1[0xf8];  // 7e00h
+  UINT32  SMBASE;   // 7ef8h
+  UINT32  SMMRevId; // 7efch
+  UINT16  IORestart;// 7f00h
+  UINT16  AutoHALTRestart;  // 7f02h
+  UINT8   Reserved2[0x9C];  // 7f08h
+  UINT32  IOMemAddr;// 7fa0h
+  UINT32  IOMisc;   // 7fa4h
+  UINT32  _ES;  // 7fa8h
+  UINT32  _CS;  // 7fach
+  UINT32  _SS;  // 7fb0h
+  UINT32  _DS;  // 7fb4h
+  UINT32  _FS;  // 7fb8h
+  UINT32  _GS;  // 7fbch
+  UINT32  Reserved3;// 7fc0h
+  UINT32  _TR;  // 7fc4h
+  UINT32  _DR7; // 7fc8h
+  UINT32  _DR6; // 7fcch
+  UINT32  _EAX; // 7fd0h
+  UINT32  _ECX; // 7fd4h
+  UINT32  _EDX; // 7fd8h
+  UINT32  _EBX; // 7fdch
+  UINT32  _ESP; // 7fe0h
+  UINT32  _EBP; // 7fe4h
+  UINT32  _ESI; // 7fe8h
+  UINT32  _EDI; // 7fech
+  UINT32  _EIP; // 7ff0h
+  UINT32  _EFLAGS;  // 7ff4h
+  UINT32  _CR3; // 7ff8h 
+  UINT32  _CR0; // 7ffch
+} SMRAM_SAVE_STATE_MAP32;
+
+/// 
+/// 64-bit SMRAM Save State Map
+///
+typedef struct {
+  UINT8   Reserved1[0x1d0];  // 7c00h
+  UINT32  GdtBaseHiDword;// 7dd0h
+  UINT32  LdtBaseHiDword;// 7dd4h
+  UINT32  IdtBaseHiDword;// 7dd8h
+  UINT8   Reserved2[0xc];// 7ddch
+  UINT64  IO_EIP;// 7de8h
+  UINT8   Reserved3[0x50];   // 7df0h
+  UINT32  _CR4;  // 7e40h
+  UINT8   Reserved4[0x48];   // 7e44h
+  UINT32  GdtBaseLoDword;// 7e8ch
+  UINT32  Reserved5; // 7e90h
+  UINT32  IdtBaseLoDword;// 7e94h
+  UINT32  Reserved6; // 7e98h
+  UINT32  LdtBaseLoDword;// 7e9ch
+  UINT8   Reserved7[0x38];   // 7ea0h
+  UINT64  EptVmxControl; // 7ed8h
+  UINT32  EnEptVmxControl;   // 7ee0h
+  UINT8   Reserved8[0x14];   // 7ee4h
+  UINT32  SMBASE;// 7ef8h
+  UINT32  SMMRevId;  // 7efch
+  UINT16  IORestart; // 7f00h
+  UINT16  AutoHALTRestart;   // 7f02h
+  UINT8   Reserved9[0x18];   // 7f04h
+  UINT64  _R15;  // 7f1ch
+  UINT64  _R14;
+  UINT64  _R13;
+  UINT64  _R12;
+  UINT64  _R11;
+  UINT64  _R10;
+  UINT64  _R9;
+  UINT64  _R8;
+  UINT64  _RAX;  // 7f5ch
+  UINT64  _RCX;
+  UINT64  _RDX;
+  UINT64  _RBX;
+  UINT64  _RSP;
+  UINT64  _RBP;
+  UINT64  _RSI;
+  UINT64  _RDI;
+  UINT64  IOMemAddr; // 7f9ch
+  UINT32  IOMisc;// 7fa4h
+  UINT32  _ES;   // 7fa8h
+  UINT32  _CS;
+  UINT32  _SS;
+  UINT32  _DS;
+  UINT32  _FS;
+  UINT32  _GS;
+  UINT32  _LDTR; // 7fc0h
+  UINT32  _TR;
+  UINT64  _DR7;  // 7fc8h
+  UINT64  _DR6;
+  UINT64  _RIP;  // 7fd8h
+  UINT64  IA32_EFER; // 7fe0h
+  UINT64  _RFLAGS;   // 7fe8h
+  UINT64  _CR3;  // 

[edk2] [PATCH v2 04/16] UefiCpuPkg: Add PlatformSecLib

2015-10-14 Thread Michael Kinney
Add PlatformSecLib class and PlatformSecLibNull instance
that is used by the SecCore.  PlatformSecLibNull should
not be used in a platform build.  Instead, it should be
used as a template for implementing a platform specific
instance of the PlatformSecLib library class.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 UefiCpuPkg/Include/Library/PlatformSecLib.h|  70 
 .../PlatformSecLibNull/PlatformSecLibNull.c|  90 +
 .../PlatformSecLibNull/PlatformSecLibNull.inf  |  37 +
 .../PlatformSecLibNull/PlatformSecLibNull.uni  | Bin 0 -> 1646 bytes
 4 files changed, 197 insertions(+)
 create mode 100644 UefiCpuPkg/Include/Library/PlatformSecLib.h
 create mode 100644 UefiCpuPkg/Library/PlatformSecLibNull/PlatformSecLibNull.c
 create mode 100644 UefiCpuPkg/Library/PlatformSecLibNull/PlatformSecLibNull.inf
 create mode 100644 UefiCpuPkg/Library/PlatformSecLibNull/PlatformSecLibNull.uni

diff --git a/UefiCpuPkg/Include/Library/PlatformSecLib.h 
b/UefiCpuPkg/Include/Library/PlatformSecLib.h
new file mode 100644
index 000..32700bc
--- /dev/null
+++ b/UefiCpuPkg/Include/Library/PlatformSecLib.h
@@ -0,0 +1,70 @@
+/** @file
+This library class defines interface for platform to perform platform
+specific initialization in SEC phase.
+
+Copyright (c) 2013 - 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
+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 __PLATFORM_SEC_LIB_H__
+#define __PLATFORM_SEC_LIB_H__
+
+/**
+  A developer supplied function to perform platform specific operations.
+
+  It's a developer supplied function to perform any operations appropriate to a
+  given platform. It's invoked just before passing control to PEI core by SEC
+  core. Platform developer may modify the SecCoreData passed to PEI Core.
+  It returns a platform specific PPI list that platform wishes to pass to PEI 
core.
+  The Generic SEC core module will merge this list to join the final list 
passed to
+  PEI core.
+
+  @param  SecCoreData   The same parameter as passing to PEI core. It
+could be overridden by this function.
+
+  @return The platform specific PPI list to be passed to PEI core or
+  NULL if there is no need of such platform specific PPI list.
+
+**/
+EFI_PEI_PPI_DESCRIPTOR *
+EFIAPI
+SecPlatformMain (
+  IN OUT   EFI_SEC_PEI_HAND_OFF*SecCoreData
+  );
+
+/**
+  This interface conveys state information out of the Security (SEC) phase 
into PEI.
+
+  @param  PeiServices   Pointer to the PEI Services Table.
+  @param  StructureSize Pointer to the variable describing size of 
the input buffer.
+  @param  PlatformInformationRecord Pointer to the 
EFI_SEC_PLATFORM_INFORMATION_RECORD.
+
+  @retval EFI_SUCCESS   The data was successfully returned.
+  @retval EFI_BUFFER_TOO_SMALL  The buffer was too small.
+
+**/
+EFI_STATUS
+EFIAPI
+SecPlatformInformation (  
+  IN CONST EFI_PEI_SERVICES **PeiServices,
+  IN OUT   UINT64   *StructureSize,
+ OUT   EFI_SEC_PLATFORM_INFORMATION_RECORD  *PlatformInformationRecord
+  );
+
+/**
+  This interface disables temporary memory in SEC Phase.
+**/
+VOID
+EFIAPI
+SecPlatformDisableTemporaryMemory (  
+  VOID
+  );
+
+#endif
diff --git a/UefiCpuPkg/Library/PlatformSecLibNull/PlatformSecLibNull.c 
b/UefiCpuPkg/Library/PlatformSecLibNull/PlatformSecLibNull.c
new file mode 100644
index 000..2b8f18a
--- /dev/null
+++ b/UefiCpuPkg/Library/PlatformSecLibNull/PlatformSecLibNull.c
@@ -0,0 +1,90 @@
+/** @file
+Null instance of Platform Sec Lib.
+
+Copyright (c) 2013 - 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
+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 
+
+/**
+  A developer supplied function to perform platform specific operations.
+
+  It's a developer supplied function to perform any operations appropriate to a
+  given platform. It's invoked just before passing control to PEI core by SEC
+  core. Platform developer may modify the SecCoreData passed to PEI Core.
+  It returns a platform specific PPI list that platform wishes to pass to PEI 
core.
+ 

[edk2] [PATCH v2 08/16] UefiCpuPkg: Add SmmCpuPlatformHookLib

2015-10-14 Thread Michael Kinney
Add SmmCpuPlatformHookLib that provides platform specific functions
that are used to initialize SMM and process SMIs.  A Null instance
of this library is provided that should work for most platforms.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 UefiCpuPkg/Include/Library/SmmCpuPlatformHookLib.h | 109 +
 .../SmmCpuPlatformHookLibNull.c| 108 
 .../SmmCpuPlatformHookLibNull.inf  |  40 
 .../SmmCpuPlatformHookLibNull.uni  | Bin 0 -> 1606 bytes
 4 files changed, 257 insertions(+)
 create mode 100644 UefiCpuPkg/Include/Library/SmmCpuPlatformHookLib.h
 create mode 100644 
UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.c
 create mode 100644 
UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
 create mode 100644 
UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.uni

diff --git a/UefiCpuPkg/Include/Library/SmmCpuPlatformHookLib.h 
b/UefiCpuPkg/Include/Library/SmmCpuPlatformHookLib.h
new file mode 100644
index 000..4633d77
--- /dev/null
+++ b/UefiCpuPkg/Include/Library/SmmCpuPlatformHookLib.h
@@ -0,0 +1,109 @@
+/** @file
+  Public include file for the SMM CPU Platform Hook Library.
+
+  Copyright (c) 2010 - 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
+  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 __SMM_CPU_PLATFORM_HOOK_LIB_H__
+#define __SMM_CPU_PLATFORM_HOOK_LIB_H__
+
+///
+/// SMM Page Size Type
+///
+typedef enum {
+SmmPageSize4K,
+SmmPageSize2M,
+SmmPageSize1G,
+MaxSmmPageSizeType
+} SMM_PAGE_SIZE_TYPE;
+
+/**
+  Checks if platform produces a valid SMI. 
+  
+  This function checks if platform produces a valid SMI. This function is 
+  called at SMM entry to detect if this is a spurious SMI. This function 
+  must be implemented in an MP safe way because it is called by multiple CPU
+  threads.
+  
+  @retval TRUE  There is a valid SMI
+  @retval FALSE There is no valid SMI
+
+**/
+BOOLEAN
+EFIAPI
+PlatformValidSmi (
+  VOID
+  );
+
+/**
+  Clears platform top level SMI status bit. 
+  
+  This function clears platform top level SMI status bit.
+  
+  @retval TRUE  The platform top level SMI status is cleared.
+  @retval FALSE The platform top level SMI status cannot be 
cleared.
+
+**/
+BOOLEAN
+EFIAPI
+ClearTopLevelSmiStatus (
+  VOID
+  );
+
+/**
+  Performs platform specific way of SMM BSP election.
+  
+  This function performs platform specific way of SMM BSP election.
+  
+  @param  IsBsp Output parameter. TRUE: the CPU this function 
executes
+on is elected to be the SMM BSP. FALSE: the CPU 
this 
+function executes on is to be SMM AP.
+
+  @retval EFI_SUCCESS   The function executes successfully.
+  @retval EFI_NOT_READY The function does not determine whether this CPU 
should be
+BSP or AP. This may occur if hardware init 
sequence to
+enable the determination is yet to be done, or the 
function
+chooses not to do BSP election and will let SMM 
CPU driver to
+use its default BSP election process.
+  @retval EFI_DEVICE_ERROR  The function cannot determine whether this CPU 
should be
+BSP or AP due to hardware error.
+
+**/
+EFI_STATUS
+EFIAPI
+PlatformSmmBspElection (
+  OUT BOOLEAN *IsBsp
+  );
+
+/**
+  Get platform page table attribute .
+
+  This function gets page table attribute of platform.
+
+  @param  AddressInput parameter. Obtain the page table entries 
attribute on this address.
+  @param  PageSize   Output parameter. The size of the page.
+  @param  NumOfPages Output parameter. Number of page.
+  @param  PageAttribute  Output parameter. Paging Attributes (WB, UC, etc).
+  
+  @retval EFI_SUCCESS  The platform page table attribute from the address 
is determined.
+  @retval EFI_UNSUPPORTED  The platform does not support getting page table 
attribute for the address.
+
+**/
+EFI_STATUS
+EFIAPI
+GetPlatformPageTableAttribute (
+  IN  UINT64Address,
+  OUT SMM_PAGE_SIZE_TYPE*PageSize,
+  OUT UINTN *NumOfPages,
+  OUT UINTN *PageAttribute
+  );
+
+#endif   
diff --git 
a/UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.c 

[edk2] [PATCH v2 06/16] UefiCpuPkg: Add SecCore module and supporting library class and PCD

2015-10-14 Thread Michael Kinney
Add declaration of PlatformSecLib library class to DEC file
Add declaration of PcdPeiTemporaryRamStackSize PCD to DEC/UNI file
Add build of PlatformSecLibNull to DSC file
Add build of SecCore to DSC file

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 UefiCpuPkg/UefiCpuPkg.dec |   9 +
 UefiCpuPkg/UefiCpuPkg.dsc |   8 +++-
 UefiCpuPkg/UefiCpuPkg.uni | Bin 6628 -> 7222 bytes
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index 202e719..fe9b2a5 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -37,6 +37,11 @@
   ##  @libraryclass  Provides functions to manage the Local APIC on IA32 and 
X64 CPUs.
   ##
   LocalApicLib|Include/Library/LocalApicLib.h
+
+  ##  @libraryclass  Provides platform specific initialization functions in 
the SEC phase.
+  ##
+  PlatformSecLib|Include/Library/PlatformSecLib.h
+
   
 [Guids]
   gUefiCpuPkgTokenSpaceGuid  = { 0xac05bf33, 0x995a, 0x4ed4, { 0xaa, 0xb8, 
0xef, 0x7a, 0xe8, 0xf, 0x5c, 0xb0 }}
@@ -62,6 +67,10 @@
   # @Prompt Configure stack size for Application Processor (AP)
   gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize|0x8000|UINT32|0x0003
 
+  ## Specifies stack size in the temporary RAM. 0 means half of 
TemporaryRamSize.
+  # @Prompt Stack size in the temporary RAM.
+  gUefiCpuPkgTokenSpaceGuid.PcdPeiTemporaryRamStackSize|0|UINT32|0x10001003
+
 [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
   ## Specifies timeout value in microseconds for the BSP to detect all APs for 
the first time.
   # @Prompt Timeout for the BSP to detect all APs for the first time.
diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc
index a4117a2..68400e3 100644
--- a/UefiCpuPkg/UefiCpuPkg.dsc
+++ b/UefiCpuPkg/UefiCpuPkg.dsc
@@ -54,8 +54,12 @@
   
CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf
   
SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
   SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
+  
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
+  
PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf
 
-
+[LibraryClasses.common.SEC]
+  PlatformSecLib|UefiCpuPkg/Library/PlatformSecLibNull/PlatformSecLibNull.inf
+  
 [LibraryClasses.common.PEIM]
   
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
   HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
@@ -96,7 +100,9 @@
   UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
   UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
   UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
+  UefiCpuPkg/Library/PlatformSecLibNull/PlatformSecLibNull.inf
   UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.inf
   UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationSmm.inf
+  UefiCpuPkg/SecCore/SecCore.inf
   UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
 
diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni
index 
2f2d20f7fd87879dde9f9b1cd59a0503399a4a7c..4fe2faf981581025adcbbfd9829512e2328c889b
 100644
GIT binary patch
delta 262
zcmaE2yv<_66UoVSVnMP245|kAS)kC;_wGUFwpf?Kz(`)N({UVTwn|U`N%cl

delta 7
OcmdmH@x*w;6G;FMf&;Sv

-- 
1.9.5.msysgit.1

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


[edk2] [PATCH v2 05/16] UefiCpuPkg: Add SecCore module

2015-10-14 Thread Michael Kinney
Add SecCore module that uses the PlatformSecLib class for platform
specific actions.  The SecCore module also uses a new PCD to
configure the size of the stack used in the SEC phase.  If the
stack size PCD is set to 0, the stack is configured to use half
of the available temporary RAM.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 UefiCpuPkg/SecCore/FindPeiCore.c   | 198 ++
 UefiCpuPkg/SecCore/Ia32/ResetVec.asm16 | 106 
 UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb | 103 
 UefiCpuPkg/SecCore/SecCore.inf |  72 
 UefiCpuPkg/SecCore/SecCore.uni | Bin 0 -> 2908 bytes
 UefiCpuPkg/SecCore/SecCoreExtra.uni| Bin 0 -> 1320 bytes
 UefiCpuPkg/SecCore/SecMain.c   | 295 +
 UefiCpuPkg/SecCore/SecMain.h   | 109 
 8 files changed, 883 insertions(+)
 create mode 100644 UefiCpuPkg/SecCore/FindPeiCore.c
 create mode 100644 UefiCpuPkg/SecCore/Ia32/ResetVec.asm16
 create mode 100644 UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb
 create mode 100644 UefiCpuPkg/SecCore/SecCore.inf
 create mode 100644 UefiCpuPkg/SecCore/SecCore.uni
 create mode 100644 UefiCpuPkg/SecCore/SecCoreExtra.uni
 create mode 100644 UefiCpuPkg/SecCore/SecMain.c
 create mode 100644 UefiCpuPkg/SecCore/SecMain.h

diff --git a/UefiCpuPkg/SecCore/FindPeiCore.c b/UefiCpuPkg/SecCore/FindPeiCore.c
new file mode 100644
index 000..e0ee958
--- /dev/null
+++ b/UefiCpuPkg/SecCore/FindPeiCore.c
@@ -0,0 +1,198 @@
+/** @file
+  Locate the entry point for the PEI Core
+
+  Copyright (c) 2008 - 2011, 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
+  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 "SecMain.h"
+
+/**
+  Find core image base.
+  
+  @param   BootFirmwareVolumePtrPoint to the boot firmware volume.
+  @param   SecCoreImageBase The base address of the SEC core image.
+  @param   PeiCoreImageBase The base address of the PEI core image.
+
+**/
+EFI_STATUS
+EFIAPI
+FindImageBase (
+  IN  EFI_FIRMWARE_VOLUME_HEADER   *BootFirmwareVolumePtr,
+  OUT EFI_PHYSICAL_ADDRESS *SecCoreImageBase,
+  OUT EFI_PHYSICAL_ADDRESS *PeiCoreImageBase
+  )
+{
+  EFI_PHYSICAL_ADDRESSCurrentAddress;
+  EFI_PHYSICAL_ADDRESSEndOfFirmwareVolume;
+  EFI_FFS_FILE_HEADER *File;
+  UINT32  Size;
+  EFI_PHYSICAL_ADDRESSEndOfFile;
+  EFI_COMMON_SECTION_HEADER   *Section;
+  EFI_PHYSICAL_ADDRESSEndOfSection;
+
+  *SecCoreImageBase = 0;
+  *PeiCoreImageBase = 0;
+
+  CurrentAddress = (EFI_PHYSICAL_ADDRESS)(UINTN) BootFirmwareVolumePtr;
+  EndOfFirmwareVolume = CurrentAddress + BootFirmwareVolumePtr->FvLength;
+
+  //
+  // Loop through the FFS files in the Boot Firmware Volume
+  //
+  for (EndOfFile = CurrentAddress + BootFirmwareVolumePtr->HeaderLength; ; ) {
+
+CurrentAddress = (EndOfFile + 7) & 0xfff8ULL;
+if (CurrentAddress > EndOfFirmwareVolume) {
+  return EFI_NOT_FOUND;
+}
+
+File = (EFI_FFS_FILE_HEADER*)(UINTN) CurrentAddress;
+if (IS_FFS_FILE2 (File)) {
+  Size = FFS_FILE2_SIZE (File);
+  if (Size <= 0x00FF) {
+return EFI_NOT_FOUND;
+  }
+} else {
+  Size = FFS_FILE_SIZE (File);
+  if (Size < sizeof (EFI_FFS_FILE_HEADER)) {
+return EFI_NOT_FOUND;
+  }
+}
+
+EndOfFile = CurrentAddress + Size;
+if (EndOfFile > EndOfFirmwareVolume) {
+  return EFI_NOT_FOUND;
+}
+
+//
+// Look for SEC Core / PEI Core files
+//
+if (File->Type != EFI_FV_FILETYPE_SECURITY_CORE &&
+File->Type != EFI_FV_FILETYPE_PEI_CORE) {
+  continue;
+}
+
+//
+// Loop through the FFS file sections within the FFS file
+//
+if (IS_FFS_FILE2 (File)) {
+  EndOfSection = (EFI_PHYSICAL_ADDRESS) (UINTN) ((UINT8 *) File + sizeof 
(EFI_FFS_FILE_HEADER2));
+} else {
+  EndOfSection = (EFI_PHYSICAL_ADDRESS) (UINTN) ((UINT8 *) File + sizeof 
(EFI_FFS_FILE_HEADER));
+}
+for (;;) {
+  CurrentAddress = (EndOfSection + 3) & 0xfffcULL;
+  Section = (EFI_COMMON_SECTION_HEADER*)(UINTN) CurrentAddress;
+
+  if (IS_SECTION2 (Section)) {
+Size = SECTION2_SIZE (Section);
+if (Size <= 0x00FF) {
+  return EFI_NOT_FOUND;
+}
+  } else {
+Size = SECTION_SIZE (Section);
+if (Size < sizeof (EFI_COMMON_SECTION_HEADER)) {
+  return EFI_NOT_FOUND;
+}
+  }
+
+  

[edk2] [PATCH v2 01/16] UefiCpuPkg: Add Cpuid.h include files for CPUID related defines

2015-10-14 Thread Michael Kinney
Move CPUID related defines from LocalApic.h to Cpuid.h
Update LocalApicLib instances to include Cpuid.h
Update CpuMpPei module to include Cpuid.h

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 UefiCpuPkg/CpuMpPei/CpuMpPei.h |  1 +
 UefiCpuPkg/Include/Register/Cpuid.h| 51 ++
 UefiCpuPkg/Include/Register/LocalApic.h| 13 --
 UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c |  1 +
 .../BaseXApicX2ApicLib/BaseXApicX2ApicLib.c|  1 +
 5 files changed, 54 insertions(+), 13 deletions(-)
 create mode 100644 UefiCpuPkg/Include/Register/Cpuid.h

diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.h b/UefiCpuPkg/CpuMpPei/CpuMpPei.h
index 19e649e..9325a12 100644
--- a/UefiCpuPkg/CpuMpPei/CpuMpPei.h
+++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.h
@@ -22,6 +22,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #include 
diff --git a/UefiCpuPkg/Include/Register/Cpuid.h 
b/UefiCpuPkg/Include/Register/Cpuid.h
new file mode 100644
index 000..0232915
--- /dev/null
+++ b/UefiCpuPkg/Include/Register/Cpuid.h
@@ -0,0 +1,51 @@
+/** @file
+CPUID Definitions.
+
+CPUID definitions based on contents of the Intel(R) 64 and IA-32 Architectures 
+Software Developer's Manual, Volume 2A, CPUID instruction.
+
+Copyright (c) 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
+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 __CPUID_H__
+#define __CPUID_H__
+
+//
+// Definitions for CPUID instruction
+//
+#define CPUID_SIGNATURE 0x0
+
+#define CPUID_VERSION_INFO  0x1
+
+#define CPUID_CACHE_INFO0x2
+
+#define CPUID_SERIAL_NUMBER 0x3
+
+#define CPUID_CACHE_PARAMS  0x4
+
+#define CPUID_EXTENDED_TOPOLOGY 0xB
+#define   CPUID_EXTENDED_TOPOLOGY_LEVEL_TYPE_INVALID  0x0
+#define   CPUID_EXTENDED_TOPOLOGY_LEVEL_TYPE_SMT  0x1
+#define   CPUID_EXTENDED_TOPOLOGY_LEVEL_TYPE_CORE 0x2
+
+#define CPUID_EXTENDED_FUNCTION 0x8000
+
+#define CPUID_EXTENDED_CPU_SIG  0x8001
+
+#define CPUID_BRAND_STRING1 0x8002
+
+#define CPUID_BRAND_STRING2 0x8003
+
+#define CPUID_BRAND_STRING3 0x8004
+
+#define CPUID_VIR_PHY_ADDRESS_SIZE  0x8008
+
+#endif
diff --git a/UefiCpuPkg/Include/Register/LocalApic.h 
b/UefiCpuPkg/Include/Register/LocalApic.h
index cf335a6..346cce6 100644
--- a/UefiCpuPkg/Include/Register/LocalApic.h
+++ b/UefiCpuPkg/Include/Register/LocalApic.h
@@ -21,19 +21,6 @@
 #define MSR_IA32_APIC_BASE_ADDRESS  0x1B
 
 //
-// Definitions for CPUID instruction
-//
-#define CPUID_SIGNATURE 0x0
-#define CPUID_VERSION_INFO  0x1
-#define CPUID_CACHE_PARAMS  0x4
-#define CPUID_EXTENDED_TOPOLOGY 0xB
-#define   CPUID_EXTENDED_TOPOLOGY_LEVEL_TYPE_INVALID 0x0
-#define   CPUID_EXTENDED_TOPOLOGY_LEVEL_TYPE_SMT 0x1
-#define   CPUID_EXTENDED_TOPOLOGY_LEVEL_TYPE_CORE0x2
-#define CPUID_EXTENDED_FUNCTION 0x8000
-#define CPUID_VIR_PHY_ADDRESS_SIZE  0x8008
-
-//
 // Definition for Local APIC registers and related values
 //
 #define XAPIC_ID_OFFSET 0x20
diff --git a/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c 
b/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c
index 08bcef7..6cf36cb 100644
--- a/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c
+++ b/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c
@@ -14,6 +14,7 @@
 
 **/
 
+#include 
 #include 
 
 #include 
diff --git a/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c 
b/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c
index 1a91116..0503942 100644
--- a/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c
+++ b/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c
@@ -15,6 +15,7 @@
 
 **/
 
+#include 
 #include 
 
 #include 
-- 
1.9.5.msysgit.1

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


[edk2] [PATCH v2 03/16] UefiCpuPkg: Add SMM Communication PPI and Handler Modules

2015-10-14 Thread Michael Kinney
Add modules that produce the SMM Communications PPI and
install a SW SMI handler for SMM Communication requests

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 .../PiSmmCommunication/PiSmmCommunicationPei.c | 425 +
 .../PiSmmCommunication/PiSmmCommunicationPei.inf   |  70 
 .../PiSmmCommunication/PiSmmCommunicationPei.uni   | Bin 0 -> 2066 bytes
 .../PiSmmCommunicationPeiExtra.uni | Bin 0 -> 1374 bytes
 .../PiSmmCommunication/PiSmmCommunicationPrivate.h |  30 ++
 .../PiSmmCommunication/PiSmmCommunicationSmm.c | 269 +
 .../PiSmmCommunication/PiSmmCommunicationSmm.inf   |  82 
 .../PiSmmCommunication/PiSmmCommunicationSmm.uni   | Bin 0 -> 3004 bytes
 .../PiSmmCommunicationSmmExtra.uni | Bin 0 -> 1396 bytes
 UefiCpuPkg/UefiCpuPkg.dsc  |   5 +
 10 files changed, 881 insertions(+)
 create mode 100644 UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.c
 create mode 100644 UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.inf
 create mode 100644 UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.uni
 create mode 100644 UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPeiExtra.uni
 create mode 100644 UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPrivate.h
 create mode 100644 UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationSmm.c
 create mode 100644 UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationSmm.inf
 create mode 100644 UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationSmm.uni
 create mode 100644 UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationSmmExtra.uni

diff --git a/UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.c 
b/UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.c
new file mode 100644
index 000..e5d448b
--- /dev/null
+++ b/UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.c
@@ -0,0 +1,425 @@
+/** @file
+PiSmmCommunication PEI Driver.
+
+Copyright (c) 2010 - 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
+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 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "PiSmmCommunicationPrivate.h"
+
+/**
+  the whole picture is below:
+
+  +--+
+  | ACPI_VARIABLE_HOB|
+  |   SmramDescriptor| <- DRAM
+  | CpuStart |---
+  +--+   |
+ |
+  +--+<--
+  | SMM_S3_RESUME_STATE  |
+  |   Signature  | <- SMRAM
+  |   Smst   |---
+  +--+   |
+ |
+  +--+<--
+  | EFI_SMM_SYSTEM_TABLE2|
+  |   NumberOfTableEntries   | <- SMRAM
+  |   SmmConfigurationTable  |---
+  +--+   |
+ |
+  +--+<--
+  | EFI_SMM_COMMUNICATION_CONTEXT|
+  |   SwSmiNumber| <- SMRAM
+  |   BufferPtrAddress   |
+  +--+|
+  |
+  +--+|
+  | EFI_SMM_COMMUNICATION_ACPI_TABLE ||
+  |   SwSmiNumber| <- AcpiTable   |
+  |   BufferPtrAddress   |--- |
+  +--+   ||
+ ||
+  +--+<---
+  | Communication Buffer Pointer | <- AcpiNvs
+  +--+---
+ |
+  +--+<--
+  | EFI_SMM_COMMUNICATE_HEADER   |
+  |   HeaderGuid | <- DRAM
+  |   MessageLength  |
+  +--+
+
+**/
+
+#if defined (MDE_CPU_IA32)
+typedef struct {
+  EFI_TABLE_HEADERHdr;
+  UINT64  SmmFirmwareVendor;
+  UINT64  SmmFirmwareRevision;
+  UINT64  SmmInstallConfigurationTable;
+  UINT64  SmmIoMemRead;
+  UINT64  SmmIoMemWrite;
+  UINT64  SmmIoIoRead;
+  UINT64  SmmIoIoWrite;
+  UINT64  SmmAllocatePool;
+  UINT64  SmmFreePool;
+  UINT64  

Re: [edk2] [Patch] IntelFrameworkModulePkg BdsDxe: Use PcdSet##S to replace PcdSet##

2015-10-14 Thread Zeng, Star

On 2015/10/14 13:35, Eric Dong wrote:

PcdSet## has no error status returned, then the caller has no idea about 
whether the set operation is successful or not.
PcdSet##S were added to return error status and PcdSet## APIs were put in 
ifndef DISABLE_NEW_DEPRECATED_INTERFACES condition.
To adopt PcdSet##S and further code development with 
DISABLE_NEW_DEPRECATED_INTERFACES defined, we need to Replace PcdSet## usage 
with PcdSet##S.

Normally, DynamicDefault PCD set is expected to be success, but DynamicHii PCD 
set failure is a legal case.
So for DynamicDefault, we add assert when set failure. For DynamicHii, we add 
logic to handle it.

Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
---
  .../Universal/BdsDxe/BootMaint/Variable.c  |  8 +---
  IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c   | 18 --
  IntelFrameworkModulePkg/Universal/BdsDxe/MemoryTest.c  |  5 -
  3 files changed, 21 insertions(+), 10 deletions(-)


Reviewed-by: Star Zeng 



diff --git a/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/Variable.c 
b/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/Variable.c
index 616549e..b933dd9 100644
--- a/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/Variable.c
+++ b/IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint/Variable.c
@@ -1368,11 +1368,13 @@ Var_UpdateConMode (

Mode = CallbackData->BmmFakeNvData.ConsoleOutMode;

Status = gST->ConOut->QueryMode (gST->ConOut, Mode, &(ModeInfo.Column), 
&(ModeInfo.Row));
if (!EFI_ERROR(Status)) {
-PcdSet32 (PcdSetupConOutColumn, (UINT32) ModeInfo.Column);
-PcdSet32 (PcdSetupConOutRow, (UINT32) ModeInfo.Row);
+Status = PcdSet32S (PcdSetupConOutColumn, (UINT32) ModeInfo.Column);
+if (!EFI_ERROR (Status)){
+  Status = PcdSet32S (PcdSetupConOutRow, (UINT32) ModeInfo.Row);
+}
}

-  return EFI_SUCCESS;
+  return Status;
  }
diff --git a/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c 
b/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
index 14a7ae2..0a9238c 100644
--- a/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
+++ b/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c
@@ -1393,12 +1393,14 @@ BdsSetConsoleMode (
Status = SimpleTextOut->SetMode (SimpleTextOut, Index);
ASSERT_EFI_ERROR (Status);
//
// Update text mode PCD.
//
-  PcdSet32 (PcdConOutColumn, mSetupTextModeColumn);
-  PcdSet32 (PcdConOutRow, mSetupTextModeRow);
+  Status = PcdSet32S (PcdConOutColumn, mSetupTextModeColumn);
+  ASSERT_EFI_ERROR (Status);
+  Status = PcdSet32S (PcdConOutRow, mSetupTextModeRow);
+  ASSERT_EFI_ERROR (Status);
FreePool (Info);
return EFI_SUCCESS;
  }
}
  }
@@ -1435,14 +1437,18 @@ BdsSetConsoleMode (

//
// Set PCD to Inform GraphicsConsole to change video resolution.
// Set PCD to Inform Consplitter to change text mode.
//
-  PcdSet32 (PcdVideoHorizontalResolution, NewHorizontalResolution);
-  PcdSet32 (PcdVideoVerticalResolution, NewVerticalResolution);
-  PcdSet32 (PcdConOutColumn, NewColumns);
-  PcdSet32 (PcdConOutRow, NewRows);
+  Status = PcdSet32S (PcdVideoHorizontalResolution, NewHorizontalResolution);
+  ASSERT_EFI_ERROR (Status);
+  Status = PcdSet32S (PcdVideoVerticalResolution, NewVerticalResolution);
+  ASSERT_EFI_ERROR (Status);
+  Status = PcdSet32S (PcdConOutColumn, NewColumns);
+  ASSERT_EFI_ERROR (Status);
+  Status = PcdSet32S (PcdConOutRow, NewRows);
+  ASSERT_EFI_ERROR (Status);


//
// Video mode is changed, so restart graphics console driver and higher 
level driver.
// Reconnect graphics console driver and higher level driver.
diff --git a/IntelFrameworkModulePkg/Universal/BdsDxe/MemoryTest.c 
b/IntelFrameworkModulePkg/Universal/BdsDxe/MemoryTest.c
index fedb151..700e3e6 100644
--- a/IntelFrameworkModulePkg/Universal/BdsDxe/MemoryTest.c
+++ b/IntelFrameworkModulePkg/Universal/BdsDxe/MemoryTest.c
@@ -424,10 +424,13 @@ Done:
// Use a DynamicHii type pcd to save the boot status, which is used to
// control configuration mode, such as FULL/MINIMAL/NO_CHANGES 
configuration.
//
IsFirstBoot = PcdGetBool(PcdBootState);
if (IsFirstBoot) {
-PcdSetBool(PcdBootState, FALSE);
+Status = PcdSetBoolS(PcdBootState, FALSE);
+if (EFI_ERROR (Status)) {
+  DEBUG ((EFI_D_ERROR, "Set PcdBootState to FALSE failed.\n"));
+}
}

return ReturnStatus;
  }



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


Re: [edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM from 64-bit mode

2015-10-14 Thread Fan, Jeff
Ersek & Bonzini,

>From SDM 34.5.2, SMI Handler Operating Mode Switching.
"Any required change to operating mode is performed by the RSM instruction; 
there is no need for the SMI
handler to change modes explicitly prior to executing RSM."

So, I don't think we need to go back to 32-bit PM before RSM.

Thanks!
Jeff
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Thursday, October 15, 2015 6:26 AM
To: edk2-de...@ml01.01.org
Cc: Kinney, Michael D
Subject: [edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM 
from 64-bit mode

From: Paolo Bonzini 

According to Intel this is invalid.  Go back to 32-bit protected mode and clear 
EFER.LME before executing RSM.

Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini 
---

Notes:
v3:
- New in v3, but included only for completeness here. This is a
  correction from Paolo for Mike's series "[edk2] [PATCH 0/7]
  UefiCpuPkg: Add CPU SMM and SecCore".

 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S   | 13 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm | 13 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S| 13 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.asm  | 13 +
 4 files changed, 52 insertions(+)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
index 8315593..0f1cab6 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.S
@@ -212,6 +212,19 @@ L1:
 .byte   0x48, 0x89, 0x0d# mov [rip + disp32], rcx
 .long   SSM_DR6 - (. + 4 - _SmiEntryPoint + 0x8000)
 L2:
+
+pushq   $PROTECT_MODE_CS
+pushq   $L3
+lretq
+L3:
+movq%cr0, %rbx
+btrl$31, %ebx
+movq%rbx, %cr0
+movl$0xc080, %ecx
+rdmsr
+andb$0xfe,%ah
+wrmsr
+
 rsm
 
 ASM_PFX(gcSmiHandlerSize):.word  . - _SmiEntryPoint
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm
index a1a7d3e..99eb403 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.asm
@@ -214,6 +214,19 @@ _SmiHandler:
 DB  48h, 89h, 0dh   ; mov [rip + disp32], rcx
 DD  SSM_DR6 - ($ + 4 - _SmiEntryPoint + 8000h)
 @2:
+
+pushPROTECT_MODE_CS
+push@3
+retfq
+@3:
+mov rbx, cr0
+btr ebx, 31
+mov cr0, rbx
+mov ecx, 0c080h
+rdmsr
+and ah, 0feh
+wrmsr
+
 rsm
 
 gcSmiHandlerSizeDW  $ - _SmiEntryPoint
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S
index 5ace1a6..fc7c2f9 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.S
@@ -32,6 +32,7 @@ ASM_GLOBAL   ASM_PFX(mSmmRelocationOriginalAddressPtr32)
 ASM_GLOBAL   ASM_PFX(gSmmInitStack)
 ASM_GLOBAL   ASM_PFX(gcSmiInitGdtr)
 
+.equPROTECT_MODE_CS, 0x08
 
 .text
 
@@ -89,6 +90,18 @@ ASM_PFX(gSmmInitStack):  .space  8
 movdqa  0x40(%rsp), %xmm4
 movdqa  0x50(%rsp), %xmm5
 
+pushq   $PROTECT_MODE_CS # push 32-bit CS
+pushq   $L3
+lretq
+L3:
+movq%cr0, %rbx# get out of long mode
+btrl$31, %ebx
+movq%rbx, %cr0
+movl$0xc080, %ecx
+rdmsr
+andb$0xfe,%ah
+wrmsr
+
 rsm
 
 ASM_PFX(gcSmmInitTemplate):
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.asm 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.asm
index 25a0447..68540a6 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.asm
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.asm
@@ -32,6 +32,8 @@ EXTERNDEF   mSmmRelocationOriginalAddressPtr32:DWORD
 EXTERNDEF   gSmmInitStack:QWORD
 EXTERNDEF   gcSmiInitGdtr:FWORD
 
+PROTECT_MODE_CS EQU 08h
+
 .code
 
 gcSmiInitGdtr   LABEL   FWORD
@@ -88,6 +90,17 @@ gSmmInitStack   DQ  ?
 movdqa  xmm4, [rsp + 40h]
 movdqa  xmm5, [rsp + 50h]
 
+pushPROTECT_MODE_CS
+push@3
+retfq
+@3:
+mov rbx, cr0
+btr ebx, 31
+mov cr0, rbx
+mov ecx, 0c080h
+rdmsr
+and ah, 0feh
+wrmsr
 rsm
 SmmStartup  ENDP
 
--
1.8.3.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


[edk2] [PATCH v2 7/8] ArmPlatformPkg: PrePi: write early hello message to the serial port

2015-10-14 Thread Laszlo Ersek
The FixedPcdGetSize() macro expands to an integer constant, therefore an
optimizing compiler can eliminate the new code, if the platform DSC
doesn't override the empty string (size=1) default of
PcdEarlyHelloMessage.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Drew Jones 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- new in v2 [Drew]

 ArmPlatformPkg/PrePi/PeiMPCore.inf  | 2 ++
 ArmPlatformPkg/PrePi/PeiUniCore.inf | 2 ++
 ArmPlatformPkg/PrePi/MainMPCore.c   | 5 +
 ArmPlatformPkg/PrePi/MainUniCore.c  | 5 +
 4 files changed, 14 insertions(+)

diff --git a/ArmPlatformPkg/PrePi/PeiMPCore.inf 
b/ArmPlatformPkg/PrePi/PeiMPCore.inf
index ac1f8d0..cad4d5a 100755
--- a/ArmPlatformPkg/PrePi/PeiMPCore.inf
+++ b/ArmPlatformPkg/PrePi/PeiMPCore.inf
@@ -101,6 +101,8 @@ [FixedPcd]
 
   gArmPlatformTokenSpaceGuid.PcdCoreCount
 
+  gArmPlatformTokenSpaceGuid.PcdEarlyHelloMessage
+
   gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
   gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize
 
diff --git a/ArmPlatformPkg/PrePi/PeiUniCore.inf 
b/ArmPlatformPkg/PrePi/PeiUniCore.inf
index c566390..c3fbff1 100755
--- a/ArmPlatformPkg/PrePi/PeiUniCore.inf
+++ b/ArmPlatformPkg/PrePi/PeiUniCore.inf
@@ -94,6 +94,8 @@ [FixedPcd]
 
   gArmPlatformTokenSpaceGuid.PcdCoreCount
 
+  gArmPlatformTokenSpaceGuid.PcdEarlyHelloMessage
+
   gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
   gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize
 
diff --git a/ArmPlatformPkg/PrePi/MainMPCore.c 
b/ArmPlatformPkg/PrePi/MainMPCore.c
index bf81373..a08b658 100644
--- a/ArmPlatformPkg/PrePi/MainMPCore.c
+++ b/ArmPlatformPkg/PrePi/MainMPCore.c
@@ -26,6 +26,11 @@ PrimaryMain (
   IN  UINT64StartTimeStamp
   )
 {
+  if (FixedPcdGetSize (PcdEarlyHelloMessage) > 1) {
+SerialPortWrite (FixedPcdGetPtr (PcdEarlyHelloMessage),
+  FixedPcdGetSize (PcdEarlyHelloMessage) - 1);
+  }
+
   // Enable the GIC Distributor
   ArmGicEnableDistributor(PcdGet32(PcdGicDistributorBase));
 
diff --git a/ArmPlatformPkg/PrePi/MainUniCore.c 
b/ArmPlatformPkg/PrePi/MainUniCore.c
index 43588a5..8d548e7 100644
--- a/ArmPlatformPkg/PrePi/MainUniCore.c
+++ b/ArmPlatformPkg/PrePi/MainUniCore.c
@@ -22,6 +22,11 @@ PrimaryMain (
   IN  UINT64StartTimeStamp
   )
 {
+  if (FixedPcdGetSize (PcdEarlyHelloMessage) > 1) {
+SerialPortWrite (FixedPcdGetPtr (PcdEarlyHelloMessage),
+  FixedPcdGetSize (PcdEarlyHelloMessage) - 1);
+  }
+
   DEBUG_CODE_BEGIN();
 // On MPCore system, PeiMpCore.inf should be used instead of PeiUniCore.inf
 ASSERT(ArmIsMpCore() == 0);
-- 
1.8.3.1


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


[edk2] [PATCH v2 0/8] serial and DEBUG output tweaks

2015-10-14 Thread Laszlo Ersek
Addressing v1 review feedback, and adding an early hello message for
ARM. Changes are noted per patch.

Testing on Xen and/or physical ARM|AARCH64 platforms would be
appreciated. (The patches should be easy to apply from the mailing list
-- no new files are created, so just use "git am --keep-cr".)

Thanks!
Laszlo

Cc: Ard Biesheuvel 
Cc: Liming Gao 
Cc: Drew Jones 
Cc: Leif Lindholm 
Cc: Yehuda Yitschak 
Cc: Star Zeng 

Laszlo Ersek (8):
  ArmPlatformPkg: NorFlashDxe: mellow DEBUG messages about flash reinit
  MdeModulePkg: FaultTolerantWriteDxe: mellow DEBUGs about workspace
reinit
  MdeModulePkg: FaultTolerantWriteDxe: clean up some "success" messages
  MdeModulePkg: SmbiosDxe: soften DEBUG messages about table
reallocation
  ArmPlatformPkg: introduce fixed PCD for early hello message
  ArmPlatformPkg: PrePeiCore: write early hello message to the serial
port
  ArmPlatformPkg: PrePi: write early hello message to the serial port
  ArmVirtPkg: set early hello message

 ArmPlatformPkg/ArmPlatformPkg.dec |  7 +++
 ArmVirtPkg/ArmVirt.dsc.inc|  1 +
 ArmPlatformPkg/PrePeiCore/PrePeiCoreMPCore.inf|  2 ++
 ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf   |  2 ++
 ArmPlatformPkg/PrePi/PeiMPCore.inf|  2 ++
 ArmPlatformPkg/PrePi/PeiUniCore.inf   |  2 ++
 ArmPlatformPkg/PrePeiCore/PrePeiCore.h|  1 +
 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c   | 19 
+--
 ArmPlatformPkg/PrePeiCore/MainMPCore.c|  5 +
 ArmPlatformPkg/PrePeiCore/MainUniCore.c   |  5 +
 ArmPlatformPkg/PrePi/MainMPCore.c |  5 +
 ArmPlatformPkg/PrePi/MainUniCore.c|  5 +
 MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.c |  6 +++---
 MdeModulePkg/Universal/FaultTolerantWriteDxe/FtwMisc.c|  6 --
 MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c |  2 +-
 MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.c  |  6 --
 16 files changed, 62 insertions(+), 14 deletions(-)

-- 
1.8.3.1

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


[edk2] [PATCH v2 6/8] ArmPlatformPkg: PrePeiCore: write early hello message to the serial port

2015-10-14 Thread Laszlo Ersek
The FixedPcdGetSize() macro expands to an integer constant, therefore an
optimizing compiler can eliminate the new code, if the platform DSC
doesn't override the empty string (size=1) default of
PcdEarlyHelloMessage.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Drew Jones 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- new in v2 [Drew]

 ArmPlatformPkg/PrePeiCore/PrePeiCoreMPCore.inf  | 2 ++
 ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf | 2 ++
 ArmPlatformPkg/PrePeiCore/PrePeiCore.h  | 1 +
 ArmPlatformPkg/PrePeiCore/MainMPCore.c  | 5 +
 ArmPlatformPkg/PrePeiCore/MainUniCore.c | 5 +
 5 files changed, 15 insertions(+)

diff --git a/ArmPlatformPkg/PrePeiCore/PrePeiCoreMPCore.inf 
b/ArmPlatformPkg/PrePeiCore/PrePeiCoreMPCore.inf
index 5ba0231..e806423 100644
--- a/ArmPlatformPkg/PrePeiCore/PrePeiCoreMPCore.inf
+++ b/ArmPlatformPkg/PrePeiCore/PrePeiCoreMPCore.inf
@@ -75,6 +75,8 @@ [FixedPcd]
 
   gArmPlatformTokenSpaceGuid.PcdPeiGlobalVariableSize
 
+  gArmPlatformTokenSpaceGuid.PcdEarlyHelloMessage
+
   gArmTokenSpaceGuid.PcdGicDistributorBase
   gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase
   gArmTokenSpaceGuid.PcdGicSgiIntId
diff --git a/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf 
b/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf
index d677f15..cb89f6a 100644
--- a/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf
+++ b/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf
@@ -72,3 +72,5 @@ [FixedPcd]
   gArmPlatformTokenSpaceGuid.PcdCPUCoreSecondaryStackSize
 
   gArmPlatformTokenSpaceGuid.PcdPeiGlobalVariableSize
+
+  gArmPlatformTokenSpaceGuid.PcdEarlyHelloMessage
diff --git a/ArmPlatformPkg/PrePeiCore/PrePeiCore.h 
b/ArmPlatformPkg/PrePeiCore/PrePeiCore.h
index 20684e2..c6c6d79 100644
--- a/ArmPlatformPkg/PrePeiCore/PrePeiCore.h
+++ b/ArmPlatformPkg/PrePeiCore/PrePeiCore.h
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/ArmPlatformPkg/PrePeiCore/MainMPCore.c 
b/ArmPlatformPkg/PrePeiCore/MainMPCore.c
index a86f739..33d2fcf 100644
--- a/ArmPlatformPkg/PrePeiCore/MainMPCore.c
+++ b/ArmPlatformPkg/PrePeiCore/MainMPCore.c
@@ -117,6 +117,11 @@ PrimaryMain (
   UINTN   TemporaryRamBase;
   UINTN   TemporaryRamSize;
 
+  if (FixedPcdGetSize (PcdEarlyHelloMessage) > 1) {
+SerialPortWrite (FixedPcdGetPtr (PcdEarlyHelloMessage),
+  FixedPcdGetSize (PcdEarlyHelloMessage) - 1);
+  }
+
   CreatePpiList (, );
 
   // Enable the GIC Distributor
diff --git a/ArmPlatformPkg/PrePeiCore/MainUniCore.c 
b/ArmPlatformPkg/PrePeiCore/MainUniCore.c
index 6317f17..47ff065 100644
--- a/ArmPlatformPkg/PrePeiCore/MainUniCore.c
+++ b/ArmPlatformPkg/PrePeiCore/MainUniCore.c
@@ -35,6 +35,11 @@ PrimaryMain (
   UINTN   TemporaryRamBase;
   UINTN   TemporaryRamSize;
 
+  if (FixedPcdGetSize (PcdEarlyHelloMessage) > 1) {
+SerialPortWrite (FixedPcdGetPtr (PcdEarlyHelloMessage),
+  FixedPcdGetSize (PcdEarlyHelloMessage) - 1);
+  }
+
   CreatePpiList (, );
 
   // Adjust the Temporary Ram as the new Ppi List (Common + Platform Ppi 
Lists) is created at
-- 
1.8.3.1


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


[edk2] [PATCH v2 2/8] MdeModulePkg: FaultTolerantWriteDxe: mellow DEBUGs about workspace reinit

2015-10-14 Thread Laszlo Ersek
The IsValidWorkSpace() function checks if the working block header of the
workspace is valid. A mismatch detected by this function is not
necessarily an error; it can happen with an as-yet unwritten flash chip,
which is e.g. common and normal when a new ArmVirtQemu virtual machine is
booted. Therefore downgrade the message emitted by IsValidWorkSpace() from
EFI_D_ERROR to EFI_D_INFO, and change the wording from "error" to
"mismatch".

The only caller of IsValidWorkSpace(), InitFtwProtocol(), handles all of
the following cases:

(1) IsValidWorkSpace() succeeds for the working block -- this is normal
operation,

(2) IsValidWorkSpace() fails for the working block, but succeeds for the
spare block -- InitFtwProtocol() then restores the working block from
the spare block,

(3) IsValidWorkSpace() fails for both the working and spare blocks --
InitFtwProtocol() reinitializes the full workspace.

In cases (2) and (3), InitFtwProtocol() logs additional messages about the
branch taken. Their current level is EFI_D_ERROR, but the messages are
arguably informative, not necessarily error reports.

Downgrade these messages from EFI_D_ERROR to EFI_D_INFO, so that they
don't clutter the debug output when the PcdDebugPrintErrorLevel mask only
enables EFI_D_ERROR (i.e., in a "silent" build).

These messages have annoyed / confused users; see for example:
- https://bugzilla.redhat.com/show_bug.cgi?id=1270279

Cc: Star Zeng 
Cc: Liming Gao 
Cc: Drew Jones 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Star Zeng 
---
 MdeModulePkg/Universal/FaultTolerantWriteDxe/FtwMisc.c| 6 --
 MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c | 2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FtwMisc.c 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FtwMisc.c
index 0922321..9604469 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FtwMisc.c
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FtwMisc.c
@@ -1280,7 +1280,8 @@ InitFtwProtocol (
 //
 if (IsValidWorkSpace (FtwDevice->FtwWorkSpaceHeader)) {
   Status = FlushSpareBlockToWorkingBlock (FtwDevice);
-  DEBUG ((EFI_D_ERROR, "Ftw: Restart working block update in 
InitFtwProtocol() - %r\n", Status));
+  DEBUG ((EFI_D_INFO, "Ftw: Restart working block update in %a() - %r\n",
+__FUNCTION__, Status));
   FtwAbort (>FtwInstance);
   //
   // Refresh work space.
@@ -1288,7 +1289,8 @@ InitFtwProtocol (
   Status = WorkSpaceRefresh (FtwDevice);
   ASSERT_EFI_ERROR (Status);
 } else {
-  DEBUG ((EFI_D_ERROR, "Ftw: Both are invalid, init workspace\n"));
+  DEBUG ((EFI_D_INFO,
+"Ftw: Both working and spare blocks are invalid, init workspace\n"));
   //
   // If both are invalid, then initialize work space.
   //
diff --git a/MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c
index 31f1e0b..d46a37f 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c
@@ -98,7 +98,7 @@ IsValidWorkSpace (
 return TRUE;
   }
 
-  DEBUG ((EFI_D_ERROR, "Ftw: Work block header check error\n"));
+  DEBUG ((EFI_D_INFO, "Ftw: Work block header check mismatch\n"));
   return FALSE;
 }
 
-- 
1.8.3.1


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


[edk2] [PATCH v2 5/8] ArmPlatformPkg: introduce fixed PCD for early hello message

2015-10-14 Thread Laszlo Ersek
Drew has proposed that ARM|AARCH64 platform firmware (especially virtual
machine firmware) print a reasonably early, simple hello message to the
serial port, regardless of debug mask settings. This should inform
interactive users, and provide some rough help in localizing boot
problems, even with restrictive debug masks.

If a platform doesn't want this feature, it should stick with the default
empty string.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Drew Jones 
Suggested-by: Drew Jones 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- new in v2 [Drew]

 ArmPlatformPkg/ArmPlatformPkg.dec | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec 
b/ArmPlatformPkg/ArmPlatformPkg.dec
index 45aeaee..f1b3090 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -137,6 +137,13 @@ [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L""|VOID*|0x001B
   gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L""|VOID*|0x001C
 
+  #
+  # Early hello message (ASCII string), printed to the serial port.
+  # If set to the empty string, nothing is printed.
+  # Otherwise, a trailing newline character should be specified explicitly.
+  #
+  gArmPlatformTokenSpaceGuid.PcdEarlyHelloMessage|""|VOID*|0x002F
+
 [PcdsFixedAtBuild.common,PcdsDynamic.common]
   ## PL031 RealTimeClock
   gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x0|UINT32|0x0024
-- 
1.8.3.1


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


[edk2] [PATCH v2 1/8] ArmPlatformPkg: NorFlashDxe: mellow DEBUG messages about flash reinit

2015-10-14 Thread Laszlo Ersek
The ValidateFvHeader() function checks several conditions against the
firmware volume header. Failure of the first of these checks, reported as
"No Firmware Volume header present", is a common situation for unformatted
flash images, especially when a new virtual machine is created.

Similarly, "Variable Store Guid non-compatible" is common when the
firmware binary is switched from Secure Boot-incapable to Secure
Boot-capable, or vice versa.

The only caller of ValidateFvHeader(), NorFlashFvbInitialize(), handles
all these mismatches by installing a new FVB header. It also emits
another, loud ERROR message (which is even less justified when it is
triggered by (BootMode == BOOT_WITH_DEFAULT_SETTINGS)).

Downgrade these messages from EFI_D_ERROR to EFI_D_INFO, so that they
don't clutter the debug output when the PcdDebugPrintErrorLevel mask only
enables EFI_D_ERROR (i.e., in a "silent" build).

These messages have annoyed / confused users; see for example:
- https://bugzilla.redhat.com/show_bug.cgi?id=1270279
- http://thread.gmane.org/gmane.comp.bios.edk2.devel/2772/focus=2869

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Drew Jones 
Cc: Yehuda Yitschak 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- Split long info message to separate sentences / lines in the log and
  in the source [Leif]. Not picking up Leif's R-b just yet; let's make
  sure he likes this.

 ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c 
b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c
index 3ed3bb9..e0edc62 100644
--- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c
+++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c
@@ -158,20 +158,23 @@ ValidateFvHeader (
   || (FwVolHeader->FvLength  != FvLength)
   )
   {
-DEBUG ((EFI_D_ERROR, "ValidateFvHeader: No Firmware Volume header 
present\n"));
+DEBUG ((EFI_D_INFO, "%a: No Firmware Volume header present\n",
+  __FUNCTION__));
 return EFI_NOT_FOUND;
   }
 
   // Check the Firmware Volume Guid
   if( CompareGuid (>FileSystemGuid, ) == 
FALSE ) {
-DEBUG ((EFI_D_ERROR, "ValidateFvHeader: Firmware Volume Guid 
non-compatible\n"));
+DEBUG ((EFI_D_INFO, "%a: Firmware Volume Guid non-compatible\n",
+  __FUNCTION__));
 return EFI_NOT_FOUND;
   }
 
   // Verify the header checksum
   Checksum = CalculateSum16((UINT16*)FwVolHeader, FwVolHeader->HeaderLength);
   if (Checksum != 0) {
-DEBUG ((EFI_D_ERROR, "ValidateFvHeader: FV checksum is invalid 
(Checksum:0x%X)\n",Checksum));
+DEBUG ((EFI_D_INFO, "%a: FV checksum is invalid (Checksum:0x%X)\n",
+  __FUNCTION__, Checksum));
 return EFI_NOT_FOUND;
   }
 
@@ -179,13 +182,15 @@ ValidateFvHeader (
 
   // Check the Variable Store Guid
   if (!CompareGuid (>Signature, mNorFlashVariableGuid)) {
-DEBUG ((EFI_D_ERROR, "ValidateFvHeader: Variable Store Guid 
non-compatible\n"));
+DEBUG ((EFI_D_INFO, "%a: Variable Store Guid non-compatible\n",
+  __FUNCTION__));
 return EFI_NOT_FOUND;
   }
 
   VariableStoreLength = PcdGet32 (PcdFlashNvStorageVariableSize) - 
FwVolHeader->HeaderLength;
   if (VariableStoreHeader->Size != VariableStoreLength) {
-DEBUG ((EFI_D_ERROR, "ValidateFvHeader: Variable Store Length does not 
match\n"));
+DEBUG ((EFI_D_INFO, "%a: Variable Store Length does not match\n",
+  __FUNCTION__));
 return EFI_NOT_FOUND;
   }
 
@@ -731,7 +736,9 @@ NorFlashFvbInitialize (
   // Install the Default FVB header if required
   if (EFI_ERROR(Status)) {
 // There is no valid header, so time to install one.
-DEBUG((EFI_D_ERROR,"NorFlashFvbInitialize: ERROR - The FVB Header is not 
valid. Installing a correct one for this volume.\n"));
+DEBUG ((EFI_D_INFO, "%a: The FVB Header is not valid.\n", __FUNCTION__));
+DEBUG ((EFI_D_INFO, "%a: Installing a correct one for this volume.\n",
+  __FUNCTION__));
 
 // Erase all the NorFlash that is reserved for variable storage
 FvbNumLba = (PcdGet32(PcdFlashNvStorageVariableSize) + 
PcdGet32(PcdFlashNvStorageFtwWorkingSize) + 
PcdGet32(PcdFlashNvStorageFtwSpareSize)) / Instance->Media.BlockSize;
-- 
1.8.3.1


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


Re: [edk2] [PATCH v2 3/8] MdeModulePkg: FaultTolerantWriteDxe: clean up some "success" messages

2015-10-14 Thread Zeng, Star

On 2015/10/14 20:30, Laszlo Ersek wrote:

The "success" messages in FtwRestart(), FtwAbort(), and FtwGetLastWrite()
should be logged on EFI_D_INFO level. We can also unify their format with
the __FUNCTION__ macro.

Cc: Star Zeng 
Cc: Liming Gao 
Cc: Drew Jones 
Suggested-by: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
 v2:
 - new in v2; modify three more DEBUGs [Star]

  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)


Reviewed-by: Star Zeng 

Thanks to do that.
Star



diff --git a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.c 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.c
index 7a6c377..2e3e8c7 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.c
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.c
@@ -720,7 +720,7 @@ FtwRestart (
  return EFI_ABORTED;
}

-  DEBUG ((EFI_D_ERROR, "Ftw: Restart() success \n"));
+  DEBUG ((EFI_D_INFO, "%a(): success\n", __FUNCTION__));
return EFI_SUCCESS;
  }

@@ -775,7 +775,7 @@ FtwAbort (

FtwDevice->FtwLastWriteHeader->Complete = FTW_VALID_STATE;

-  DEBUG ((EFI_D_ERROR, "Ftw: Abort() success \n"));
+  DEBUG ((EFI_D_INFO, "%a(): success\n", __FUNCTION__));
return EFI_SUCCESS;
  }

@@ -886,7 +886,7 @@ FtwGetLastWrite (
  Status = EFI_SUCCESS;
}

-  DEBUG ((EFI_D_ERROR, "Ftw: GetLasetWrite() success\n"));
+  DEBUG ((EFI_D_INFO, "%a(): success\n", __FUNCTION__));

return Status;
  }



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


Re: [edk2] [PATCH v2 11/41] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER

2015-10-14 Thread Laszlo Ersek
On 10/14/15 13:37, Paolo Bonzini wrote:
> On 13/10/2015 15:26, Laszlo Ersek wrote:
>>>//
>>> +  // The write to the control register is synchronous and only affects the
>>> +  // current CPU, so bring in the APs first.  The SMI handler expects that
>>> +  // all APs will rendez-vous within one PcdCpuSmmApSyncTimeout (though it
>>> +  // helpfully tries sending SMI IPIs to the missing processors if there 
>>> are
>>> +  // any).
>>> +  //
>>> +  SendSmiIpiAllExcludingSelf ();
>>> +
>>> +  //
> 
> Nevermind, this patch is unfortunately broken.
> 
> SendSmiIpiAllExcludingSelf does not work after ExitBootServices, because
> it hardcodes the physical address of the APIC.  While that could be
> fixed in LocalApicLib, it turns out that using SmmSyncModeRelaxedAp is a
> trivial addition to my series that introduces a SmmCpuFeaturesLib
> implementation specific to OvmfPkg.  Therefore, I'm withdrawing this
> patch and submitting another in that thread.

Thank you.

If you create the SmmCpuFeaturesLib instance as a copy, initially,
please make sure that you use, as basis, the CRLF-converted patches of
Mike that I pushed last night. So that the copy come from a
CRLF-terminated source, and your further customizations be similar.

Thank you!
Laszlo

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


[edk2] [PATCH 5/4] OvmfPkg: use relaxed AP SMM synchronization mode

2015-10-14 Thread Paolo Bonzini
Port 0xb2 on QEMU only sends an SMI to the currently executing processor.
The SMI handler, however, and in particular SmmWaitForApArrival, currently
expects that SmmControl2DxeTrigger triggers an SMI IPI on all processors
rather than just the BSP.  Thus all SMM invocations loop for a second (the
default value of PcdCpuSmmApSyncTimeout) before SmmWaitForApArrival sends
another SMI IPI to the APs.

With the default SmmCpuFeaturesLib, 32-bit machines must broadcast SMIs
because 32-bit machines must reset the MTRRs on each entry to system
management modes (they have no SMRRs).  However, our virtual platform
does not have problems with cacheability of SMRAM, so we can use "directed"
SMIs instead.  To do this, just set gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode
to 1 (aka SmmCpuSyncModeRelaxedAp).  This fixes SMM on multiprocessor virtual
machines.

Signed-off-by: Paolo Bonzini 
---
 OvmfPkg/OvmfPkgIa32.dsc| 4 
 OvmfPkg/OvmfPkgIa32X64.dsc | 4 
 OvmfPkg/OvmfPkgX64.dsc | 4 
 3 files changed, 12 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 81adb31..96bdc73 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -373,6 +373,10 @@
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 
0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
 !endif
 
+!if $(SMM_REQUIRE) == TRUE
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
+!endif
+
 !if $(SECURE_BOOT_ENABLE) == TRUE
   # override the default values from SecurityPkg to ensure images from all 
sources are verified in secure boot
   gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 1a8bfd2..4e4d65b 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -379,6 +379,10 @@
 !endif
 
 [PcdsFixedAtBuild.X64]
+!if $(SMM_REQUIRE) == TRUE
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
+!endif
+
 !if $(SECURE_BOOT_ENABLE) == TRUE
   # override the default values from SecurityPkg to ensure images from all 
sources are verified in secure boot
   gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 9bf720a..54353d6 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -378,6 +378,10 @@
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 
0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
 !endif
 
+!if $(SMM_REQUIRE) == TRUE
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
+!endif
+
 !if $(SECURE_BOOT_ENABLE) == TRUE
   # override the default values from SecurityPkg to ensure images from all 
sources are verified in secure boot
   gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04
-- 
2.5.0

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


[edk2] [Patch] BaseTools: Add MultipleWorkspace.py in the common dependency.

2015-10-14 Thread Liming Gao
Add new added MultipleWorkspace.py in the common dependency to freeze
python tools for Windows.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 BaseTools/Source/Python/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/BaseTools/Source/Python/Makefile b/BaseTools/Source/Python/Makefile
index 4044fce..d3f1baa 100644
--- a/BaseTools/Source/Python/Makefile
+++ b/BaseTools/Source/Python/Makefile
@@ -59,6 +59,7 @@ 
COMMON_PYTHON=$(BASE_TOOLS_PATH)\Source\Python\Common\BuildToolError.py \
   $(BASE_TOOLS_PATH)\Source\Python\Common\ToolDefClassObject.py \
   $(BASE_TOOLS_PATH)\Source\Python\Common\VpdInfoFile.py \
   $(BASE_TOOLS_PATH)\Source\Python\Common\BuildVersion.py \
+  $(BASE_TOOLS_PATH)\Source\Python\Common\MultipleWorkspace.py \
   $(BASE_TOOLS_PATH)\Source\Python\CommonDataClass\CommonClass.py \
   $(BASE_TOOLS_PATH)\Source\Python\CommonDataClass\DataClass.py \
   $(BASE_TOOLS_PATH)\Source\Python\CommonDataClass\Exceptions.py \
-- 
1.9.5.msysgit.0

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


[edk2] [PATCH] MdeModulePkg VariableRuntimeDxe: Add the missing gEfiImageSecurityDatabaseGuid

2015-10-14 Thread Star Zeng
Otherwise there will be build failure if without VarCheckUefiLib linked.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf | 4 
 1 file changed, 4 insertions(+)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
index 74b35ec..62c1568 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
@@ -101,6 +101,10 @@ [Guids]
   gEdkiiFaultTolerantWriteGuid  ## SOMETIMES_CONSUMES   ## HOB
   gEdkiiVarErrorFlagGuid## CONSUMES ## GUID
 
+  ## SOMETIMES_CONSUMES   ## Variable:L"DB"
+  ## SOMETIMES_CONSUMES   ## Variable:L"DBX"
+  gEfiImageSecurityDatabaseGuid
+
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize  ## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase  ## 
SOMETIMES_CONSUMES
-- 
1.9.5.msysgit.0

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


[edk2] [PATCH] SecurityPkg AuthVariableLib: Add the missing gEfiAuthenticatedVariableGuid

2015-10-14 Thread Star Zeng
There is no real build failure, as AuthVariableLib always links to variable 
driver.
But for code integrity, we should add it.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf | 4 
 1 file changed, 4 insertions(+)

diff --git a/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf 
b/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
index d0c0cc2..3709f7b 100644
--- a/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
+++ b/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
@@ -81,6 +81,10 @@ [Guids]
   ## PRODUCES## Variable:L"VendorKeysNv"
   gEfiVendorKeysNvGuid
 
+  ## CONSUMES## Variable:L"AuthVarKeyDatabase"
+  ## PRODUCES## Variable:L"AuthVarKeyDatabase"
+  gEfiAuthenticatedVariableGuid
+
   gEfiCertTypeRsa2048Sha256Guid  ## SOMETIMES_CONSUMES   ## GUID  # Unique ID 
for the type of the certificate.
   gEfiCertPkcs7Guid  ## SOMETIMES_CONSUMES   ## GUID  # Unique ID 
for the type of the certificate.
   gEfiCertX509Guid   ## SOMETIMES_CONSUMES   ## GUID  # Unique ID 
for the type of the signature.
-- 
1.9.5.msysgit.0

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


[edk2] [PATCH] MdeModulepkg VarCheckLib: Return NULL when no property set

2015-10-14 Thread Star Zeng
to variable with wildcard name.

VarCheckLib has zeroed property for variable with wildcard name
and is waiting for property set. The code should return NULL
when no property set to variable with wildcard name, but not
return the zeroed property that will impact the functionality of
SetVariableCheck.

The issue does not appear with VarCheckUefiLib linked as the library
just has the expected property set.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Library/VarCheckLib/VarCheckLib.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Library/VarCheckLib/VarCheckLib.c 
b/MdeModulePkg/Library/VarCheckLib/VarCheckLib.c
index cf00154..3d1f8f6 100644
--- a/MdeModulePkg/Library/VarCheckLib/VarCheckLib.c
+++ b/MdeModulePkg/Library/VarCheckLib/VarCheckLib.c
@@ -141,11 +141,19 @@ VariablePropertyGetWithWildcardName (
 VarCheckInternalIsHexaDecimalDigitCharacter 
(VariableName[NameLength + 1]) &&
 VarCheckInternalIsHexaDecimalDigitCharacter 
(VariableName[NameLength + 2]) &&
 VarCheckInternalIsHexaDecimalDigitCharacter 
(VariableName[NameLength + 3])) {
-  return [Index].VariableProperty;
+  if 
(mVarCheckVariableWithWildcardName[Index].VariableProperty.Revision != 
VAR_CHECK_VARIABLE_PROPERTY_REVISION) {
+return NULL;
+  } else {
+return [Index].VariableProperty;
+  }
 }
   }
   if (StrCmp (mVarCheckVariableWithWildcardName[Index].Name, VariableName) 
== 0) {
-return  [Index].VariableProperty;
+if (mVarCheckVariableWithWildcardName[Index].VariableProperty.Revision 
!= VAR_CHECK_VARIABLE_PROPERTY_REVISION) {
+  return NULL;
+} else {
+  return  [Index].VariableProperty;
+}
   }
 }
   }
-- 
1.9.5.msysgit.0

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


Re: [edk2] [PATCH] ShellPkg: Use safe string functions to refine Tftp.c code.

2015-10-14 Thread Qiu, Shumin
It was found through code review. Use safe string functions (StrCpyS, 
StrCatS...) can avoid potential buffer overflow.
I will update the commit message.

-Shumin

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif 
Lindholm
Sent: Wednesday, October 14, 2015 10:26 PM
To: Qiu, Shumin
Cc: Carsey, Jaben; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH] ShellPkg: Use safe string functions to refine 
Tftp.c code.

On Wed, Oct 14, 2015 at 01:00:15PM +0800, Qiu Shumin wrote:
> Cc: Jaben Carsey 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qiu Shumin 

Could we have a commit message, please?
Does this resolve an observed problem, or was it found through code review?

Regards,

Leif

> ---
>  ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c 
> b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> index 4bb21aa..02099fe 100644
> --- a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> +++ b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> @@ -955,6 +955,7 @@ CheckPacket (
>UINTN Index;
>UINTN LastStep;
>UINTN Step;
> +  EFI_STATUSStatus;
>  
>if ((NTOHS (Packet->OpCode)) != EFI_MTFTP4_OPCODE_DATA) {
>  return EFI_SUCCESS;
> @@ -984,7 +985,10 @@ CheckPacket (
>  
>ShellPrintEx (-1, -1, L"%s", mTftpProgressDelete);
>  
> -  StrCpy (Progress, mTftpProgressFrame);
> +  Status = StrCpyS (Progress, TFTP_PROGRESS_MESSAGE_SIZE, 
> + mTftpProgressFrame);  if (EFI_ERROR(Status)) {
> +return Status;
> +  }
>for (Index = 1; Index < Step; Index++) {
>  Progress[Index] = L'=';
>}
> --
> 1.9.5.msysgit.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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH] MdeModulepkg VarCheckLib: Return NULL when no property set

2015-10-14 Thread Yao, Jiewen
Looks good, reviewed by jiewen@intel.com


-Original Message-
From: Zeng, Star 
Sent: Thursday, October 15, 2015 10:58 AM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen
Subject: [PATCH] MdeModulepkg VarCheckLib: Return NULL when no property set

to variable with wildcard name.

VarCheckLib has zeroed property for variable with wildcard name and is waiting 
for property set. The code should return NULL when no property set to variable 
with wildcard name, but not return the zeroed property that will impact the 
functionality of SetVariableCheck.

The issue does not appear with VarCheckUefiLib linked as the library just has 
the expected property set.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Library/VarCheckLib/VarCheckLib.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Library/VarCheckLib/VarCheckLib.c 
b/MdeModulePkg/Library/VarCheckLib/VarCheckLib.c
index cf00154..3d1f8f6 100644
--- a/MdeModulePkg/Library/VarCheckLib/VarCheckLib.c
+++ b/MdeModulePkg/Library/VarCheckLib/VarCheckLib.c
@@ -141,11 +141,19 @@ VariablePropertyGetWithWildcardName (
 VarCheckInternalIsHexaDecimalDigitCharacter 
(VariableName[NameLength + 1]) &&
 VarCheckInternalIsHexaDecimalDigitCharacter 
(VariableName[NameLength + 2]) &&
 VarCheckInternalIsHexaDecimalDigitCharacter 
(VariableName[NameLength + 3])) {
-  return [Index].VariableProperty;
+  if 
(mVarCheckVariableWithWildcardName[Index].VariableProperty.Revision != 
VAR_CHECK_VARIABLE_PROPERTY_REVISION) {
+return NULL;
+  } else {
+return [Index].VariableProperty;
+  }
 }
   }
   if (StrCmp (mVarCheckVariableWithWildcardName[Index].Name, VariableName) 
== 0) {
-return  [Index].VariableProperty;
+if (mVarCheckVariableWithWildcardName[Index].VariableProperty.Revision 
!= VAR_CHECK_VARIABLE_PROPERTY_REVISION) {
+  return NULL;
+} else {
+  return  [Index].VariableProperty;
+}
   }
 }
   }
--
1.9.5.msysgit.0

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


Re: [edk2] [PATCH] SecurityPkg AuthVariableLib: Add the missing gEfiAuthenticatedVariableGuid

2015-10-14 Thread Yao, Jiewen
reviewed by jiewen@intel.com

-Original Message-
From: Zeng, Star 
Sent: Thursday, October 15, 2015 10:58 AM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen
Subject: [PATCH] SecurityPkg AuthVariableLib: Add the missing 
gEfiAuthenticatedVariableGuid

There is no real build failure, as AuthVariableLib always links to variable 
driver.
But for code integrity, we should add it.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf | 4 
 1 file changed, 4 insertions(+)

diff --git a/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf 
b/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
index d0c0cc2..3709f7b 100644
--- a/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
+++ b/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
@@ -81,6 +81,10 @@ [Guids]
   ## PRODUCES## Variable:L"VendorKeysNv"
   gEfiVendorKeysNvGuid
 
+  ## CONSUMES## Variable:L"AuthVarKeyDatabase"
+  ## PRODUCES## Variable:L"AuthVarKeyDatabase"
+  gEfiAuthenticatedVariableGuid
+
   gEfiCertTypeRsa2048Sha256Guid  ## SOMETIMES_CONSUMES   ## GUID  # Unique ID 
for the type of the certificate.
   gEfiCertPkcs7Guid  ## SOMETIMES_CONSUMES   ## GUID  # Unique ID 
for the type of the certificate.
   gEfiCertX509Guid   ## SOMETIMES_CONSUMES   ## GUID  # Unique ID 
for the type of the signature.
-- 
1.9.5.msysgit.0

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


Re: [edk2] [PATCH] MdeModulePkg VariableRuntimeDxe: Add the missing gEfiImageSecurityDatabaseGuid

2015-10-14 Thread Yao, Jiewen
reviewed by jiewen@intel.com

-Original Message-
From: Zeng, Star 
Sent: Thursday, October 15, 2015 10:58 AM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen
Subject: [PATCH] MdeModulePkg VariableRuntimeDxe: Add the missing 
gEfiImageSecurityDatabaseGuid

Otherwise there will be build failure if without VarCheckUefiLib linked.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf | 4 
 1 file changed, 4 insertions(+)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
index 74b35ec..62c1568 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
@@ -101,6 +101,10 @@ [Guids]
   gEdkiiFaultTolerantWriteGuid  ## SOMETIMES_CONSUMES   ## HOB
   gEdkiiVarErrorFlagGuid## CONSUMES ## GUID
 
+  ## SOMETIMES_CONSUMES   ## Variable:L"DB"
+  ## SOMETIMES_CONSUMES   ## Variable:L"DBX"
+  gEfiImageSecurityDatabaseGuid
+
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize  ## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase  ## 
SOMETIMES_CONSUMES
-- 
1.9.5.msysgit.0

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


  1   2   >