from:"Jordan Justen"

Re: [edk2] Library refinement: OptionRomPkg/BltLib

2015-08-13 Thread Jordan Justen

Did you get a chance to review the commit message on caebd915 /
r11520?

On 2015-08-09 20:09:54, Ni, Ruiyu wrote:
Jordan and Laszlo,
 
I reviewed the OptionRomPkg/BltLib again and would like to discuss with
you about the potential API refinement.
 
I attached two versions of the refined BltLib.h.
 
 
 
The common part of the two versions is:
 
1.  BltLibGetSizes() is removed.
 
Because the size information is actually passed from the library consumer
to the library. Caller do not need to get the information from the library
interface.

Yeah. I guess you have a point here.

2.  BltLibBufferToVideoEx and BltLibVideoToBltBufferEx are removed and
the accordingly non-Ex version of APIs will be used for *Ex operation.
 
Just for reducing the library APIs and avoid the different APIs have
overlapped functionality.

Part of the reason was to make simpler functions available for blit
operations. I think for the common operations, it is nice to not have
to add 3 extra zero parameters.

3.  BltLibGopBlt() is removed
 
Same reason as the above #2.

I thought this would be convenient for a GOP driver to use to
implement the GOP Blt function, but I suppose it is easy enough for a
GOP driver to just have the switch in its Blt function.

BltLib2.h contains another change.
 
4.  BltLibConfigure() is removed and the frame buffer information will
be passed through the four BltLib* APIs.
 
Because it can remove the restriction to allow the library can be
re-entry.

Does that mean the library will have to check to see if the mode is
different?

OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c:BltLibConfigure
does do some work.

Similar to my comment above about #2, I liked that the current
interface's BltLibBufferToVideo interface was pretty simple.

With all these suggestions it will go from 5 parameters to 10
parameters.

What's example use where re-entry would be important?

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

Re: [edk2] [Patch 6/8] OptionRomPkg/OvmfPkg: Remove BltLib::BltConfigure API

2015-08-17 Thread Jordan Justen

On 2015-08-17 06:45:27, Ruiyu Ni wrote:
 The BltConfigure() API caches the video frame buffer meta data which
 forbids the library to be implemented to support re-entry.

How does this help? GraphicsOutputDxe will set a mode, and then use
BltLib with that mode.

I already asked this, and I had some other questions:

http://article.gmane.org/gmane.comp.bios.edk2.devel/1209

-Jordan

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ruiyu Ni ruiyu...@intel.com
 Cc: Laszlo Ersek ler...@redhat.com
 Cc: Jordan Justen jordan.l.jus...@intel.com
 ---
  .../Application/BltLibSample/BltLibSample.c| 129 +++---
  OptionRomPkg/Include/Library/BltLib.h  | 151 +++---
  .../Library/FrameBufferBltLib/FrameBufferBltLib.c  | 514 
 +++--
  OptionRomPkg/Library/GopBltLib/GopBltLib.c | 289 ++--
  OvmfPkg/QemuVideoDxe/Gop.c |  13 +-
  5 files changed, 576 insertions(+), 520 deletions(-)
 
 diff --git a/OptionRomPkg/Application/BltLibSample/BltLibSample.c 
 b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
 index 333b054..3c7e392 100644
 --- a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
 +++ b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
 @@ -18,6 +18,7 @@
  #include Library/UefiLib.h
  #include Library/UefiApplicationEntryPoint.h
  #include Library/UefiBootServicesTableLib.h
 +#include Library/MemoryAllocationLib.h
  
  
  UINT64
 @@ -68,8 +69,8 @@ Rand32 (
  
  VOID
  TestFills (
 -  UINT32 HorizontalResolution,
 -  UINT32 VerticalResolution
 +  IN  VOID *FrameBuffer,
 +  IN  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
)
  {
EFI_GRAPHICS_OUTPUT_BLT_PIXEL  Color;
 @@ -79,44 +80,45 @@ TestFills (
UINTN  W;
UINTN  H;
  
 -  for (Loop = 0; Loop  1; Loop++) {
 -W = HorizontalResolution - (Rand32 () % HorizontalResolution);
 -H = VerticalResolution - (Rand32 () % VerticalResolution);
 -if (W != HorizontalResolution) {
 -  X = Rand32 () % (HorizontalResolution - W);
 +  for (Loop = 0; Loop  1000; Loop++) {
 +W = FrameBufferInfo-HorizontalResolution - (Rand32 () % 
 FrameBufferInfo-HorizontalResolution);
 +H = FrameBufferInfo-VerticalResolution - (Rand32 () % 
 FrameBufferInfo-VerticalResolution);
 +if (W != FrameBufferInfo-HorizontalResolution) {
 +  X = Rand32 () % (FrameBufferInfo-HorizontalResolution - W);
  } else {
X = 0;
  }
 -if (H != VerticalResolution) {
 -  Y = Rand32 () % (VerticalResolution - H);
 +if (H != FrameBufferInfo-VerticalResolution) {
 +  Y = Rand32 () % (FrameBufferInfo-VerticalResolution - H);
  } else {
Y = 0;
  }
  *(UINT32*) (Color) = Rand32 ()  0xff;
 -BltVideoFill (Color, X, Y, W, H);
 +BltVideoFill (FrameBuffer, FrameBufferInfo, Color, X, Y, W, H);
}
  }
  
  
  VOID
  TestColor1 (
 -  UINT32 HorizontalResolution,
 -  UINT32 VerticalResolution
 +  IN  VOID *FrameBuffer,
 +  IN  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
)
  {
 -  EFI_GRAPHICS_OUTPUT_BLT_PIXEL  Color;
 +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL  *BltBuffer;
UINTN  X;
UINTN  Y;
  
 -  *(UINT32*) (Color) = 0;
 +  BltBuffer = AllocatePool (sizeof (*BltBuffer) * 
 FrameBufferInfo-HorizontalResolution);
 +  ASSERT (BltBuffer != NULL);
  
 -  for (Y = 0; Y  VerticalResolution; Y++) {
 -for (X = 0; X  HorizontalResolution; X++) {
 -  Color.Red =   (UINT8) ((X * 0x100) / HorizontalResolution);
 -  Color.Green = (UINT8) ((Y * 0x100) / VerticalResolution);
 -  Color.Blue =  (UINT8) ((Y * 0x100) / VerticalResolution);
 -  BltVideoFill (Color, X, Y, 1, 1);
 +  for (Y = 0; Y  FrameBufferInfo-VerticalResolution; Y++) {
 +for (X = 0; X  FrameBufferInfo-HorizontalResolution; X++) {
 +  BltBuffer[X].Red =   (UINT8) ((X * 0x100) / 
 FrameBufferInfo-HorizontalResolution);
 +  BltBuffer[X].Green = (UINT8) ((Y * 0x100) / 
 FrameBufferInfo-VerticalResolution);
 +  BltBuffer[X].Blue =  (UINT8) ((Y * 0x100) / 
 FrameBufferInfo-VerticalResolution);
  }
 +BltBufferToVideo (FrameBuffer, FrameBufferInfo, BltBuffer, 0, 0, 0, Y, 
 FrameBufferInfo-HorizontalResolution, 1, 0);
}
  }
  
 @@ -176,8 +178,8 @@ GetTriColor (
  
  VOID
  TestColor (
 -  UINT32 HorizontalResolution,
 -  UINT32 VerticalResolution
 +  IN  VOID *FrameBuffer,
 +  IN  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
)
  {
EFI_GRAPHICS_OUTPUT_BLT_PIXEL  Color;
 @@ -187,34 +189,38 @@ TestColor (
UINTN  LineWidth, TriWidth;
UINTN  TriHeight;
UINT32 ColorDist

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-17 Thread Jordan Justen

On 2015-08-17 07:24:57, Ard Biesheuvel wrote:
This got a bit out of hand after I noticed the ELFGCC and UNIXGCC
toolchains that needed some tlc as well.

Anyway, this series aims to refactor the toolchains definitions for
UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC,
CYGGCC and CYGGCCxASL so that they share as much of the settings as

UNIXGCC and CYGGCC are GCC 4.3 mingw based. Did this get tested?

I think ELFGCC is unused at this point. (And has been since UnixPkg
was deprecated.)

I think we should deprecate all three of these toolchains. I would
like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll
add Larry to this email, because I think he disagrees with deprecating
toolchains...

If you make these changes and it breaks those toolchains, I don't
think we would be able to notice, because I don't think we test them
in our build pool anymore. To me this is all the more reason to move
them out of tools_def.template.

-Jordan

possible. Currently, there is very little coordination between these,
which means for instance that the 4 KB alignment feature is only supported
on GCC4x at the moment.

The primary difference between these toolchains is that GCC4x and ELFGCC
are entirely ELF based, whereas the other are PE/COFF based (but only when
building for IA32 or X64)

Note that this series does not remove any toolchains, nor should it result
in major changes in the command lines that are passed to the various tools.
However, things may be reordered, and (in case of ELFGCC), missing
functionality
such as increased section alignment has been added so there are some changes
there.

Patch #1 is a patch from Scott that I am reposting, but updated to cover
AARCH64 as well.

Patch #2 fixes a problem in the GenFv tool where it may access unallocated
memory while rebasing the FFS when using large section and file alignment.

Patch #3 removes an unused DEFINE from tools_def

Patch #4 moved some warning flags that were applied to GCC4x 4.6 and up to
all GCC versions.

Patch #5 is the first big refactor patch that introduces PE and ELF variants
for some CC flags.

Patch #6 unifies the IA32 and X64 CC flags for all toolchains listed above.

Patch #7 fixes the issue mentioned by Bill where the underscore decoration
is erroneously applied on X64 as well.

Patch #8 is the second refactor the introduces PE and ELF variants for the
various DLINK flags.

Patch #9 changes the way the start of the .data section is set in GccBase.lds.
This is needed since the linker will reorganize the internal layout of the
.data
section rather than update its start address to ensure all objects that it
contains meet their respective alignments, even if the start address is not
aligned to the max value of all inputs.

Patch #10 removes the explicit 64 byte alignment applied to GCC 4.9. The
latest
GenFw and linker script propagate the alignment automatically, i.e., if
objects
with such alignment requirement are present, GCC will set the ELF header
accordingly, and this value will be used for the PE/COFF section alignment
as well.

Patch #11 unifies the IA32 and X64 linker flags for all toolchains listed
above.

Patch #12 unifies the ARM and AARCH64 CC flags, i.e., it removes all the
redundant definitions.

Patch #13 as #11 but for the linker.

Patch #14 unifies the ASM flags for all archs.

Patch #15 brings the remaining configuration options of ELFGCC in line with
the GCC4x series.

Patch #16 is a PoC that allows Ovmf/X64 to be built with 4 KB section
alignment
for DXE_RUNTIME modules using UNIXGCC and ELFGCC, as is required to support
the properties table memprotection feature.

Changes since v1:
- added patch #9 to address the IA32 and X86 failures on 4.9 reported by Scott
- don't pass -mno-unaligned-access to ARM 4.6 compiler (Scott)
- improved wording of commit messages of various patches
- rebased onto latest upstream, which includes a fix related to the ARM 4.6
issue mentioned above

Branch can be found here
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/unify-gcc-v2

Ard Biesheuvel (15):
BaseTools/GenFv: use PE/COFF virtual section size if raw size is
larger
BaseTools GCC: remove unused definition of GCC_WINDRES_FLAGS
BaseTools GCC: merge warning flags for all GCC versions
BaseTools GCC: refactor tools_def internal GCC defines for CC flags
BaseTools GCC: unify all IA32 and X64 CC flags for ELF based GCC
BaseTools GCC: use leading underscore for symbol names where
appropriate
BaseTools GCC: refactor tools_def internal GCC defines for [AS]DLINK
BaseTools GCC: don't set .data address explicitly
BaseTools GCC: remove GCC 4.9 specific linker alignment override
BaseTools GCC: unify all IA32 and X64 [AS]DLINK[2] flags for ELF based
GCC
BaseTools GCC: unify ARM and AARCH64 GCC compiler flags
BaseTools GCC: unify ARM and AARCH64

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-18 Thread Jordan Justen

On 2015-08-18 03:57:51, Ard Biesheuvel wrote:
 On 17 August 2015 at 20:53, Jordan Justen jordan.l.jus...@intel.com wrote:
  On 2015-08-17 11:25:56, Ard Biesheuvel wrote:
  MinGW generates PE/COFF not ELF, so much of the linker command line is
  different, and it really deserves a toolchain of its own
 
  Why does it deserve a toolchain of its own if the other toolchain
  produces better code? Why should EDK II care about using the different
  linker path if it isn't the best recommended way to build images?
 
 
 By the same logic, why on earth do we insist on retaining support for
 GCC44 and GCC45?

Last time I checked, GCC44 ~ GCC49 all produced images roughly in the
same ball park size-wise. UNIXGCC produced much larger images because
it could not strip unused functions/data.

Personally, I would not mind deprecating GCC44, but the biggest
question I would have is what toolchains do the latest UDK releases
claim to support.

We also have the issue that every time I ask about deprecating a
toolchain, Larry looks at me like I'm crazy. :)

 Note that it is not about the linker path, but about the options that
 we pass, for instance to get 4 KB section alignment. MinGW does not
 need a linker script for this, you can simply set --section-alignment
 and --file-alignment on the command line.
 
 As for the PE/COFF support: if you are incorporating PE/COFF binary
 static libraries into your build, you need a native PE/COFF toolchain.

Is this something we want to support?

 But in general, I think the ELF to PE/COFF conversion is not the most
 elegant step in the build, and I would prefer to avoid it if possible
 (only, there is no PE/COFF support in the GNU tools for ARM or
 AARCH64)

It is doing a better job than any other GCC based option we have.

Certainly LTO will be a big change for our GCC based builds. If
somehow LTO support is finally integrated into EDK II and manages to
directly produce a PE/COFF image easily on Linux, then I don't think
ELF is needed.

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

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-17 Thread Jordan Justen

On 2015-08-17 11:10:57, Bill Paul wrote:
 Of all the gin joints in all the towns in all the world, David Woodhouse had 
 to walk into mine at 11:00:23 on Monday 17 August 2015 and say:
 
  On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote:
   UNIXGCC and CYGGCC are GCC 4.3  mingw based. Did this get tested?
   
   I think ELFGCC is unused at this point. (And has been since UnixPkg
   was deprecated.)
   
   I think we should deprecate all three of these toolchains. I would
   like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll
   add Larry to this email, because I think he disagrees with
   deprecating
   toolchains...
   
   If you make these changes and it breaks those toolchains, I don't
   think we would be able to notice, because I don't think we test them
   in our build pool anymore. To me this is all the more reason to move
   them out of tools_def.template.
  
  I was building with UNIXGCC last week, to test LLP64 builds without the
  pain of actually having to deal with Windows.
  
  I'd rather see it updated to work with modern MinGW rather than
  deprecated.
 
 I use UNIXGCC with the cross-compiler toolchain generated by mingw-gcc-
 build.py. Yes, I know the existing version of the script uses GCC 4.3.0. 
 That's why I made an updated version that uses 4.9.3:
 
 http://people.freebsd.org/~wpaul/edk2/mingw-gcc-build.py
 
 I know you don't want to support this script, that's why I did the work for 
 you. :) Yes I've tested both IA32 and X64 builds. Yes they work fine.
 
 There is value in being able to bootstrap your own cross-build toolchain on 
 whatever platform. I don't think you should be so quick to remove it.

Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?

I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
you count the comment in tools_def :) This is why I'd rather deprecate
it as a toolchain, and use the GCC4X toolchains instead.

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

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-17 Thread Jordan Justen

On 2015-08-17 11:25:56, Ard Biesheuvel wrote:
 On 17 August 2015 at 20:22, Jordan Justen jordan.l.jus...@intel.com wrote:
  Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?
 
  I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
  based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
  of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
  you count the comment in tools_def :) This is why I'd rather deprecate
  it as a toolchain, and use the GCC4X toolchains instead.
 
 
 No, you can't really.
 
 MinGW generates PE/COFF not ELF, so much of the linker command line is
 different, and it really deserves a toolchain of its own

Why does it deserve a toolchain of its own if the other toolchain
produces better code? Why should EDK II care about using the different
linker path if it isn't the best recommended way to build images?

 Making version 4.3.0 part of the definition of UNIXGCC sounds awkward
 to me. In fact, the idea of supporting all toolchains into eternity
 sounds awkward, and it is obviously not working, since many are
 deprecated and don't work at all or only partially. It would be much
 better imo to allow a definition like UNIXGCC to evolve with the state
 of the art

I mostly agree, but I would rather see us add new toolchains and
deprecate the old ones rather than evolving the requirements for a
particular toolchain.

I think the name UNIXGCC is too generic and too short sighted. It made
sense at the time, but I don't think we should keep moving it forward
and turn it into a moving target.

The MYTOOLS toolchain was what you are describing, but for MSVC. It
looks like it is stuck at VS2008 though. Anyway, I guess we should
also deprecate MYTOOLS. :)

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

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-17 Thread Jordan Justen

On 2015-08-17 11:25:41, David Woodhouse wrote:
 On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote:
  Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?
 
 Not for testing LLP64, no.

How/who is this helping?

  I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
  based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
  of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
  you count the comment in tools_def :) This is why I'd rather deprecate
  it as a toolchain, and use the GCC4X toolchains instead.
 
 Or kill UNIXGCC and replace it with MINGWGCC so the historical baggage
 is lost.

Maybe MINGW49. But, please not before we figure out how to actually
deprecate toolchains. :)

By 'figure out', I mean get to the point where we are okay with
actually deprecating toolchains.

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

Re: [edk2] [Patch 6/8] OptionRomPkg/OvmfPkg: Remove BltLib::BltConfigure API

2015-08-23 Thread Jordan Justen

On 2015-08-23 20:09:23, Ni, Ruiyu wrote:
 Jordan,
 reply embedded in the mail.
 
 Mike,
 Jordan proposed to add a new parameter Configuration in BltConfigure, 
 instead of removing this API, to eliminate the global variables in 
 library implementation. I think it's also a good solution and can 
 benefit the library performance. What's your thoughts?
 EFI_STATUS
 EFIAPI
 BltConfigure (
 IN  VOID *FrameBuffer,
 IN  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo,
 OUT EFI_HANDLE   *Configuration
 );

I also had considered:

EFI_STATUS
EFIAPI
BltLibConfigureGop (
IN  EFI_GRAPHICS_OUTPUT_PROTOCOL *Gop,
OUT EFI_HANDLE   *Configuration
);

Which would either configure based on the current GOP settings, or in
the case of GopBltLib, it could just save the pointer to the GOP
protocol and call the protocol Blt function.

 EFI_STATUS
 EFIAPI
 BltFreeConfiguration (
 IN  EFI_HANDLE  Configuration
 );
 
 
 On 2015/8/24 6:28, Jordan Justen wrote:
  Previously you said to Laszlo in regard to keeping the BltLibVideoFill
  function: The reason I wanted to use the four APIs instead of only
  one BltLibGopBlt is if user just wants to fill video, he can supply
  less parameters.
 
  This is exactly why I think the current BltLibVideoToBltBuffer and
  BltLibBufferToVideo are useful. They have less parameters, and should
  be useful in a case where the buffer is sized exactly to the blit
  operation.
 
  It is also very easy to implement in the library by just calling the
  other 'Ex' functions.
 
  If you just want to avoid overlapping functions, then why not just
  keep *only* the BltLibGopBlt function?
 
 True we can choose *only keep the BltLibGopBlt function, instead of
 keeping the current four functions. We can assume the interfaces of
 GOP protocol defined in spec were carefully reviewed, then, why not
 just align to these interfaces. It's a little bit confusing when the
 protocol implementation of BltVideoToBltBuffer operation calls a
 BltVideoToBltBuffer*Ex* library API. After all for the additional
 parameters, caller can simply pass 0.

I was not serious about the suggestion to just have the single blit
function. My preference would be to leave all of the current
functions.

One of my goals for BltLib was that it would make it easier for code
to use the blit operations. Think of it similar to HobLib. The Build*
functions in that library make it easier to create HOBs.

But, I thought the BltLibGopBlt function was nice for a GOP driver to
use, so I added it to the library interface.

I do agree that BltLibConfigure was not the greatest design. I wanted
to make it easier to wrapper a GOP protocol as I mentioned above.

If we only have a single blit function, then it makes GopBltLib
pointless, whereas I was hoping that the BltLib interface could make
calling the GOP protocol a little easier and with more readable code.

  Q2: If removing BltConfigure, does that mean the library will have
  to check to see if the mode is different? what's the benefit?
 
  After removing BltConfigure(), the library will calculate the
  shift/mask every time when doing the BLT operations. The benefit is
  to make the library stateless so it doesn't contain any state
  information so it can be called from different threads/CPUs.
 
  I don't think the GOP protocol blit is reentrant, so I'm still not
  sure about where the requirement comes from.
 
 A GOP implementation can choose to utilize all the processors to fill 
 the frame buffer simultaneously for good performance. I don't know 
 whether there is any such GOP MP implementation but we'd better not to 
 restrict it from the API interface level.

Hmm. I'm not convinced it is necessary. Do you know who originally
proposed that this would be a requirement?

I guess it would be nice for a multi-screen/framebuffer situation to
not have to call BltLibConfigure to blit to all of the screens.

If we add the hidden 'Configuration' struct mentioned above, I guess
it seems reasonable.

  But, I did have another idea. What if BltLibConfigure has an output
  EFI_HANDLE, and each BltLib function has this handle as it's first
  parameter. Then we only need 1 parameter to each function, and it can
  encapsulate any data needed for that configuration. For example, it
  can still calculate the shifts and masks just once.
 
  Since the returned handle would likely be an allocated structure, I
  think we should also then add a BltLibFreeConfiguration.
 
  In other words:
 
  EFI_STATUS
  EFIAPI
  BltLibConfigure (
 IN  VOID *FrameBuffer,
 IN  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo,
 OUT EFI_HANDLE   *Configuration
 );
 
  EFI_STATUS
  EFIAPI
  BltLibFreeConfiguration (
 IN  EFI_HANDLE  Configuration
 );
 
 I agree with your idea, with just a little modification. Do not use

Re: [edk2] [PATCH] EmbeddedPkg: Added Marvell Yukon Ethernet support

2015-07-29 Thread Jordan Justen

On 2015-07-28 10:51:38, Leif Lindholm wrote:
Hi Jordan,

Sorry, (metaphorically) snowed under for a few days.

On Fri, Jul 17, 2015 at 02:44:10PM -0700, Jordan Justen wrote:
Does this depend on ArmPkg / EmbeddedPkg, or is this just a generic
PCI based driver?

It could be nice to have a generic place for such drivers, but I think
OptionRomPkg is the closest we have today.

Well, I'm planning to add it to my OpenPlatformPkg tree.
If that was to be merged into edk2, that would contain such a generic
place.

But, the name 'open platform' also sounds strange, assuming this a
plain PCI bus driver. Couldn't it live in a 'pci drivers' package?

Personally, I think we should rename OptionRomPkg to DriversPkg, or
split it into UsbDriversPkg and PciDriversPkg.

Mike,

This seems like another thing we've been talking about for years. :)

What do you think about adding:

DriversPkg
DriversPkg/Pci
DriversPkg/Usb

PciDriversPkg
UsbDriversPkg

One possible concern is who will own/maintain such a package. In this
case, it might make sense to have a separate Maintainers.txt file
under the package.

Or, what I would suggest is that we just start out by saying that
edk2-devel collectively owns it, and that any other package maintainer
can commit contributions to the package.

-Jordan

So, OpenPlatformPkg is my current way of dealing with the lack of a
unified handling of platform/driver code in edk2. It is not something
I mind giving up if this situation resolves itself another way. Or
renaming to something more palatable :)

I gave a presentation (more like lightning talk) at the spring
plugfest in Seattle on this:
http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_Platforms_Tree_May_2015.pdf

If we simply rename OptionRomPkg to DriversPkg (and restructure a bit
in there), then that solves the drivers part of my problem. But I
still need something for opensource platform support.

Re: [edk2] [PATCH v3 09/12] ArmPlatformPkg/ArmVExpressPkg: move to unified GCC linker script

2015-07-29 Thread Jordan Justen

On 2015-07-29 08:11:59, Ard Biesheuvel wrote:
 Move to the parametrised generic GCC linker script and set 64 KB
 alignment, instead of using the AARCH64 specific incremental linker
 script for 64 KB alignment which is about to be removed.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc 
 b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
 index 7e0d8ff4b6e6..d2f8f5aa6d41 100644
 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
 +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
 @@ -13,7 +13,7 @@
  #
  
  [BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER]
 -  GCC:*_*_AARCH64_DLINK_FLAGS = 
 --script=$(EDK_TOOLS_PATH)/Scripts/gcc-aarch64-64K-align-ld-script
 +  GCC:*_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x1

Nice. This seems like a big improvement.

common-page-size doesn't map exactly to 'image section alignment', so
there is a little bit of a disconnect here in terminology.

I think you said that something like
--defsym=IMAGE_SECTION_ALIGN=0x1 can't be used because it doesn't
work in the linker script. Is that right?

I guess if we added -z common-page-size=$(SECTIONALIGN_FLAGS) directly
in build_rule, then we might be able to use:

  GCC:*_*_*_SECTIONALIGN_FLAGS = 0x1

That's not great either.

-Jordan

  
  [LibraryClasses.common]
  !if $(TARGET) == RELEASE
 -- 
 1.9.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 v3 12/12] BaseTools/X86|IA32: move to unified GCC linker script

2015-07-29 Thread Jordan Justen

Subject prefix: BaseTools/X86|IA32 = BaseTools IA32/X64

What about 1 more step? :)

This change starts to make use of the -z common-page-size and
--defsym=PECOFF_HEADER_SIZE params, but the description says 'move to
unified script'.

So, how about first modifying the gcc*-ld-script files to use -z
common-page-size and --defsym=PECOFF_HEADER_SIZE and then the last
patch is trivial:

  BaseTools IA32/X64: Use GccBase.lds instead of gcc*-ld-script

  These scripts all now have the same contents, so we only need to use
  GccBase.lds. Therefore we can delete gcc-4K-align-ld-script,
  gcc4.4-ld-script and gcc4.9-ld-script.

With that change, the series is

  Reviewed-by: Jordan Justen jordan.l.jus...@intel.com

although, I would like someone to test the changes on a '4k' aligned
image build. Liming, do you know who might be able to do that?

-Jordan

On 2015-07-29 08:12:02, Ard Biesheuvel wrote:
 Drop the GCC 4.4/X86 and 4.9/X86 specific linker scripts and use
 the new unified one instead.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  BaseTools/Conf/tools_def.template| 28 +--
  BaseTools/Scripts/gcc-4K-align-ld-script | 38 
  BaseTools/Scripts/gcc4.4-ld-script   | 38 
  BaseTools/Scripts/gcc4.9-ld-script   | 38 
  4 files changed, 26 insertions(+), 116 deletions(-)
 
 diff --git a/BaseTools/Conf/tools_def.template 
 b/BaseTools/Conf/tools_def.template
 index d3dfdc41ada1..eeb488fb3597 100644
 --- a/BaseTools/Conf/tools_def.template
 +++ b/BaseTools/Conf/tools_def.template
 @@ -3847,10 +3847,12 @@ DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O 
 elf64-littleaarch64 -B aarch64
  DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing 
 -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -c 
 -include AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
  DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 
 -malign-double -fno-stack-protector -D EFI32
  DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
 -fno-stack-protector -DEFIAPI=__attribute__((ms_abi)) -DNO_BUILTIN_VA_FUNCS 
 -mno-red-zone -Wno-address -mcmodel=large
 -DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -n -q --gc-sections 
 --script=$(EDK_TOOLS_PATH)/Scripts/gcc4.4-ld-script
 +DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -n -q --gc-sections -z 
 common-page-size=0x20
  DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON) 
 --entry ReferenceAcpiTable -u ReferenceAcpiTable
  DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON) 
 --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map 
 $(DEST_DIR_DEBUG)/$(BASE_NAME).map
 +DEFINE GCC44_IA32_DLINK2_FLAGS   = DEF(GCC_DLINK2_FLAGS_COMMON) 
 --defsym=PECOFF_HEADER_SIZE=0x220
  DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS)  
 -melf_x86_64 --oformat=elf64-x86-64
 +DEFINE GCC44_X64_DLINK2_FLAGS= DEF(GCC_DLINK2_FLAGS_COMMON) 
 --defsym=PECOFF_HEADER_SIZE=0x228
  DEFINE GCC44_ASM_FLAGS   = DEF(GCC_ASM_FLAGS)
  
  DEFINE GCC45_IA32_CC_FLAGS   = DEF(GCC44_IA32_CC_FLAGS)
 @@ -3858,7 +3860,9 @@ DEFINE GCC45_X64_CC_FLAGS= 
 DEF(GCC44_X64_CC_FLAGS)
  DEFINE GCC45_IA32_X64_DLINK_COMMON   = DEF(GCC44_IA32_X64_DLINK_COMMON)
  DEFINE GCC45_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_ASLDLINK_FLAGS)
  DEFINE GCC45_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_FLAGS)
 +DEFINE GCC45_IA32_DLINK2_FLAGS   = DEF(GCC44_IA32_DLINK2_FLAGS)
  DEFINE GCC45_X64_DLINK_FLAGS = DEF(GCC44_X64_DLINK_FLAGS)
 +DEFINE GCC45_X64_DLINK2_FLAGS= DEF(GCC44_X64_DLINK2_FLAGS)
  DEFINE GCC45_ASM_FLAGS   = DEF(GCC44_ASM_FLAGS)
  
  DEFINE GCC46_IA32_CC_FLAGS   = DEF(GCC45_IA32_CC_FLAGS) -Wno-address 
 -Wno-unused-but-set-variable
 @@ -3866,7 +3870,9 @@ DEFINE GCC46_X64_CC_FLAGS= 
 DEF(GCC45_X64_CC_FLAGS) -Wno-address -Wno
  DEFINE GCC46_IA32_X64_DLINK_COMMON   = DEF(GCC45_IA32_X64_DLINK_COMMON)
  DEFINE GCC46_IA32_X64_ASLDLINK_FLAGS = DEF(GCC45_IA32_X64_ASLDLINK_FLAGS)
  DEFINE GCC46_IA32_X64_DLINK_FLAGS= DEF(GCC45_IA32_X64_DLINK_FLAGS)
 +DEFINE GCC46_IA32_DLINK2_FLAGS   = DEF(GCC45_IA32_DLINK2_FLAGS)
  DEFINE GCC46_X64_DLINK_FLAGS = DEF(GCC45_X64_DLINK_FLAGS)
 +DEFINE GCC46_X64_DLINK2_FLAGS= DEF(GCC45_X64_DLINK2_FLAGS)
  DEFINE GCC46_ASM_FLAGS   = DEF(GCC45_ASM_FLAGS)
  DEFINE GCC46_ARM_ASM_FLAGS   = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) 
 DEF(GCC_ASM_FLAGS) -mlittle-endian
  DEFINE GCC46_ARM_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
 DEF(GCC44_ALL_CC_FLAGS) DEF(GCC_ARM_CC_FLAGS) -fstack-protector
 @@ -3878,7 +3884,9 @@ DEFINE GCC47_X64_CC_FLAGS= 
 DEF(GCC46_X64_CC_FLAGS)
  DEFINE GCC47_IA32_X64_DLINK_COMMON   = DEF(GCC46_IA32_X64_DLINK_COMMON)
  DEFINE

Re: [edk2] efi acpidump port

2015-07-29 Thread Jordan Justen

On 2015-07-29 16:27:38, Andrew Fish wrote:
On Jul 29, 2015, at 4:11 PM, Jordan Justen jordan.l.jus...@intel.com
wrote:
On 2015-07-29 13:43:43, Smith, Jonathan D wrote:
Attaching a zip of the files

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org
mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Smith, Jonathan D
Sent: Wednesday, July 29, 2015 1:37 PM
To: 'Andrew Fish'; 'edk2-devel@lists.01.org
mailto:edk2-devel@lists.01.org'
Subject: Re: [edk2] efi acpidump port

Hi all,

Let me know if the attachments to this message do not show up.

I’ve elaborated the build metadata, reduced the ACPICA changes
(moving alterations into additional files as needed), and verified
that the compiled AcpicaPkg provides a correct implementation of
acpidump that works for Minnow.

To set up the EDK2 AcpicaPkg from the ACPICA sources:

1.) Go to https://acpica.org/downloads https://acpica.org/downloads and
download
aspia-unix-20150619.tarhttps://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar
https://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar

2.) Extract the tar and put it in the root of edk2 as AcpicaPkg

3.) Apply acenv.patch to
edk2\AcpicaPkg\source\include\platform\acenv.h or just add the two
lines manually.

4.) Add the files AcpicaPkg.dec, AcpicaPkg.dsc, acpidump.inf, and
acpi_main.c to the dir edk2\AcpicaPkg

5.) Add the file acedk2efi.h to the dir
edk2\AcpicaPkg\source\include\platform

This seems a little silly.

Like the Intel email server removing the INF from the zip file?

It is usually pretty entertaining to watch people trying to outsmart
this filtering. Wow. After all these years, I think I finally
convinced myself that this filtering is good for something. :)

Seems silly to make a branch to add a single package.

This is a perfect example of how much better it is to work with git
than svn. There is no fuss to work on a new feature such as this on a
new branch and make it available to everyone...

How do you add a subproject? Like the FatPkg?

He can just run mkdir and add the files in his branch. Hopefully
they'll make it into EDK II proper at some point.

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

Re: [edk2] efi acpidump port

2015-07-29 Thread Jordan Justen

On 2015-07-29 13:43:43, Smith, Jonathan D wrote:
Attaching a zip of the files

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Smith,
Jonathan D
Sent: Wednesday, July 29, 2015 1:37 PM
To: 'Andrew Fish'; 'edk2-devel@lists.01.org'
Subject: Re: [edk2] efi acpidump port

Hi all,

Let me know if the attachments to this message do not show up.

To set up the EDK2 AcpicaPkg from the ACPICA sources:

1.) Go to https://acpica.org/downloads and download
aspia-unix-20150619.tarhttps://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar

2.) Extract the tar and put it in the root of edk2 as AcpicaPkg

3.) Apply acenv.patch to
edk2\AcpicaPkg\source\include\platform\acenv.h or just add the two
lines manually.

4.) Add the files AcpicaPkg.dec, AcpicaPkg.dsc, acpidump.inf, and
acpi_main.c to the dir edk2\AcpicaPkg

5.) Add the file acedk2efi.h to the dir
edk2\AcpicaPkg\source\include\platform

This seems a little silly.

Maybe you can just fork edk2, make the required changes and provide a
link to your branch?

https://github.com/tianocore/edk2

Also, what about 'Contributed-under'? (MdePkg/Contributions.txt)

By the way, I think Prince (Cc'd) did a port of acpidump in the past,
but never tried to release it externally.

-Jordan

I had to make several changes to link to the edk2 implementation of
LibC. Now the only code in ACPICA that changes is the #ifdef that
includes our acedk2efi.h file; this is a slightly modified version
of the #else block in acefi.h we had earlier.

Cheers,
Jonathan Smith

From: Andrew Fish [mailto:af...@apple.com]
Sent: Saturday, July 18, 2015 12:44 PM
To: Smith, Jonathan D
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] efi acpidump port

On Jul 18, 2015, at 11:23 AM, Smith, Jonathan D
jonathan.d.sm...@intel.commailto:jonathan.d.sm...@intel.com wrote:

The issues I ran into were after solving issues with the /D options. I’ve
been working with /D _EDK2_EFI /D _ACPI_DUMP_APP so far. A lot of warnings
escalated to errors were simple fixes, such as unsigned-to-signed
comparisons. I was asking whether the parameter I mentioned called “Address”
which was declared as type ACPI_SIZE should have been declared
ACPI_PHYSICAL_ADDRESS, since every use of that function (OslMapTable) passes
in type ACPI_PHYSICAL_ADDRESS. Changing to the address type fixes some
compile warnings, but I was wondering if there was some implicit reason why
we used the size type instead.

Jonathan,

1st off this code comes from acpica, so the experts about this code don’t
subscribe to this mailing list. You would need to ask questions about why on
some acpica list. I only looked at the acpiaca code for the 1st time to try
and port it.

ACPI_PHYSICAL_ADDRESS is defined in actypes.h. This file supports different
modes of acpica, but it is tool agnostic. So I did not change it.This file is
modified by #define’s so you probably have the wrong combination?

You probably have some more fundamental bug that you are hiding by changing
the common code. The acpica code supports being compiled for VC++ and gcc, so
it “should work”?
The edk2 defines EFI_PHYSICAL_ADDERSS as:
typedef UINT64EFI_PHYSICAL_ADDRESS;

~/work/src/edk2/acpica(acpica)git grep --untracked ACPI_PHYSICAL_ADDRESS --
*.h | grep typedef
source/include/actypes.h:238:typedef UINT64
ACPI_PHYSICAL_ADDRESS;
source/include/actypes.h:285:typedef UINT32
ACPI_PHYSICAL_ADDRESS;
source/include/actypes.h:295:typedef UINT64
ACPI_PHYSICAL_ADDRESS;

Thus you don’t really need to set things to EFI_PHYSICAL_ADDRESS, you just
need to make sure acpica has the right settings. It looks like
ACPI_32BIT_PHYSICAL_ADDRESS getting set will cause a 32-bit address. If
EFI_PHYSICAL_ADDERSS and EFI_PHYSICAL_ADDERSS are both defined to be UINT64 I
would not thing you would have an issue?

I’m running into further issues now with the ACPICA package trying to define
functions like memcpy which are intrinsic and cause a fatal error on compile

What error are you getting? You should fix the thing that is throwing the
error, and not modify the code. I thin the gcc side might depend on that
code? The edk2 StdLib includes a memcpy, so this issue must have been solved?

. My workaround is to do #if !defined(_EDK2_EFI) guards since I searched the
package and didn’t find any uses of those functions.

I added the _EDK2_EFI, I don’t think it is a good idea to work around some
compiler specific issue you are hitting by adding it in new locations.

Currently I’m just combing the code for any

Re: [edk2] BaseTools features: multiple workspaces

2015-08-03 Thread Jordan Justen

On 2015-08-03 14:32:15, Andrew Fish wrote:

On Aug 3, 2015, at 2:04 PM, Jordan Justen jordan.l.jus...@intel.com wrote:

On 2015-08-03 12:58:28, Kinney, Michael D wrote:
Jordan,

If we make a slight change to the requirements, we can provide clear
priority rules.

WORKSPACE is used to find Build and Conf.

If WORKSPACE_MULTIPLE exists, then it is used as a prioritized list
of paths to resolve all other workspace relative paths. This means
WORKSPACE_MULTIPLE will need to also contain that path to WORKSPACE
as one of its path if WORKSPACE has packages in it too. This means
rule 4b needs to be adjusted.

I like this a little better, since you only need to search one thing
for the set of workspaces. But, it doesn't let you keep your workspace
build area separate from your workspace sources.

We could also add WORKSPACE_BUILD and make WORKSPACE be the separated
list. If WORKSPACE_BUILD is not set, the first WORKSPACE path could be
used instead. Adding WORKSPACE_BUILD seems more intuitive to me than
adding WORKSPACE_MULTIPLE.

I think having two lists makes the most sense.

Two lists?

Especially since WORKSPACE is required for the build to function
(path to the build executable).

We have 4 distinct things of interest:

1. Package source paths

2. Build

3. Conf (probably combinable with Build location)

4. BaseTools

Today WORKSPACE is all of those. We want to make #1 be more than a
single path. Personally when I think of WORKSPACE, I'm usually
thinking of #1, but I understand it is used for all 4 items.

source ekdsetup.sh BaseTools
WORKSPACE_MULTIPLE=“”${WORKSPACE}/edk2/;${WORKSPACE}/Vendor/Intel/;${WORKSPACE}/Vendor/OurCode/

I want support cases where one of the paths is not under WORKSPACE.

For example, why can't we install UDK2014 under C:\UDK2014 or
/usr/include/udk/2014?

In other words, I don't think $(WORKSPACE)/MdePkg nor
$(WORKSPACE)/edk2/MdePkg should be something we require to be present.

-Jordan

The two lists are also the simplest form for the user. Tim’s request
to set the WORKSPACE_MULTIPLE from the DSC also is a good example
that the lists really are separate.

Thanks,

Andrew Fish

-Jordan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Jordan Justen
Sent: Monday, August 03, 2015 11:55 AM
To: Tim Lewis; Gao, Liming; Paolo Bonzini
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] BaseTools features: multiple workspaces

Cc: edk2-devel

On 2015-08-03 10:41:43, Tim Lewis wrote:
There are dozens of tools in commercial environments (including some
by Insyde) which will fail in this case. In addition, there are
codebases that I am aware of where $(WORKSPACE) is allowed directly
in other build files.

Will all these 'dozens of tools in commercial environments' fare any
better with the WORKSPACE_MULTIPLE option?

As a quick example, say C:\ssl\CryptoPkg has open-ssl integrated, and
C:\edk2 is the plain EDK II tree.

Thus, we want to set WORKSPACE=C:\ssl and WORKSPACE_MULTIPLE=C:\edk2
so the open-ssl integrated version of CryptoPkg will take priority.

Are these tools likely to work as expected? I am guessing no. I'm
thinking that these tools will probably have to insist on a fully
integrated single workspace until they can be updated to the new
design.

At that point whether WORKSPACE can have multiple directories, or we
add WORKSPACE_MULTIPLE, it will not make a big difference to these
tools.

-Jordan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Jordan Justen
Sent: Monday, August 03, 2015 10:36 AM
To: Gao, Liming liming@intel.com; Paolo Bonzini
pbonz...@redhat.com; edk2-devel@lists.01.org
Subject: Re: [edk2] BaseTools features: multiple workspaces

On 2015-08-03 02:08:14, Gao, Liming wrote:
Paolo:
I think that keep the exiting syntax for WORKSPACE to be a single
path can minimize the impacts to exiting tools that assume a
single workspace.

I know you originally suggested to use WORKSPACE, but got some feedback
that it might be better to create a new variable to not break some
unspecified tools.

Was anyone able to name an actual tool that would be impacted? Why not
work to update these tools at the same time? An easy 'fix' will be for
any such tool to give an error message if it sees ':' or ';' in the
WORKSPACE environment variable. Although this is really not a fix, it
will be just as much support as if they ignore the new WORKSPACE_MULTIPLE
environment variable.

I think that using the single separated WORKSPACE environment variable is
more intuitive/expected. From using env vars such as PATH, we all know
what it means.

For WORKSPACE+WORKSPACE_MULTIPLE, I don't know which has priority. I
assume WORKSPACE is checked first, and then WORKSPACE_MULTIPLE?

Will this work

Re: [edk2] [PATCH] EmbeddedPkg: Added Marvell Yukon Ethernet support

2015-07-30 Thread Jordan Justen

On 2015-07-30 11:51:56, Kinney, Michael D wrote:
Jordan,

I agree with the concept of having package(s) for device driver content.

OptionRomPkg is really only intended to provide good examples for
writing drivers, and we want to restrict what goes in there to a
good example for each driver type.

Thus, if we have good example drivers in DriversPkg, then OptionRomPkg
is not needed? :)

So I do not think OptionRomPkg is a good landing zone for this type
of content.

I think the hardest part is deciding how to organizer the driver
content in package(s)/directories. Some device vendors may prefer to
have vendor specific package/directory names to store families of
drivers. Other vendors may be fine with putting their driver in a
common package.

The other part that may cause some confusion is that we already have
drivers for some controllers in existing packages so finding the
drivers already requires looking in multiple packages. Those drivers
tend to be based on industry standard register sets (i.e. UHCI,
EHCI, SATA, USB, etc).

If we want to follow dir structure that matches what we have done in
MdeModulePkg for industry standard host controllers, buses, and
devices and support vendor specific areas, maybe we can do something
like the following:

DriversPkg
DriversPkg/Vendor/VendorName
DriversPkg/Bus/BusType

Would we expect this too?

DriversPkg/Vendor/VendorName/Bus/BusType

I'm not sure how necessary the 'Vendor' directory level is. Seems fine
though.

-Jordan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif
Lindholm
Sent: Thursday, July 30, 2015 8:20 AM
To: Justen, Jordan L
Cc: Kinney, Michael D; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH] EmbeddedPkg: Added Marvell Yukon Ethernet support

Hi Jordan,

On Wed, Jul 29, 2015 at 02:59:04PM -0700, Jordan Justen wrote:
But, the name 'open platform' also sounds strange, assuming this a
plain PCI bus driver. Couldn't it live in a 'pci drivers' package?

Personally, I think we should rename OptionRomPkg to DriversPkg, or
split it into UsbDriversPkg and PciDriversPkg.

This seems like another thing we've been talking about for years. :)

What do you think about adding:

DriversPkg
DriversPkg/Pci
DriversPkg/Usb

PciDriversPkg
UsbDriversPkg

bikeshed
We may well need support for drivers (read: I already have) that are
neither USB nor PCI. Should connecting interface still be the primary
filter?
/bikeshed

One possible concern is who will own/maintain such a package. In this
case, it might make sense to have a separate Maintainers.txt file
under the package.

Or, what I would suggest is that we just start out by saying that
edk2-devel collectively owns it, and that any other package maintainer
can commit contributions to the package.

I think that is a sensible thing to do until there is sufficient
amount of code in there to require a dedicated (set of) maintainer(s).

What about platform code?

/
Leif

I gave a presentation (more like lightning talk) at the spring
plugfest in Seattle on this:
http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_Platforms_Tree_May_2015.pdf

If we simply rename OptionRomPkg to DriversPkg (and restructure a bit
in there), then that solves the drivers part of my problem. But I
still need something for opensource platform support.

/
Leif
___
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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] EmbeddedPkg: Added Marvell Yukon Ethernet support

2015-07-30 Thread Jordan Justen

On 2015-07-30 15:35:58, Yao, Jiewen wrote:
 Hello
 Do we consider below 2 options?
 -- DriversPkg/Vendor/VendorName/Bus/BusType ?
 or
 -- DriversPkg/Bus/BusType/Vendor/VendorName ?
 
 Another option is that we add DriverCategory, like
 GOP/UNDI/RAID/SIO. Then we can put UNDI driver together, no matter
 it is PCI based or USB based.

The Linux drivers directory seems to be organized like that:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers

drivers/net
drivers/gpu

...

-Jordan

 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
 Justen
 Sent: Friday, July 31, 2015 6:17 AM
 To: Kinney, Michael D; Leif Lindholm; Kinney, Michael D
 Cc: edk2-devel@lists.01.org
 Subject: Re: [edk2] [PATCH] EmbeddedPkg: Added Marvell Yukon Ethernet support
 
 On 2015-07-30 11:51:56, Kinney, Michael D wrote:
  Jordan,
  
  I agree with the concept of having package(s) for device driver content.
  
  OptionRomPkg is really only intended to provide good examples for 
  writing drivers, and we want to restrict what goes in there to a good 
  example for each driver type.
 
 Thus, if we have good example drivers in DriversPkg, then OptionRomPkg is not 
 needed? :)
 
  So I do not think OptionRomPkg is a good landing zone for this type of 
  content.
  
  I think the hardest part is deciding how to organizer the driver 
  content in package(s)/directories. Some device vendors may prefer to 
  have vendor specific package/directory names to store families of 
  drivers. Other vendors may be fine with putting their driver in a 
  common package.
  
  The other part that may cause some confusion is that we already have 
  drivers for some controllers in existing packages so finding the 
  drivers already requires looking in multiple packages. Those drivers 
  tend to be based on industry standard register sets (i.e. UHCI, EHCI, 
  SATA, USB, etc).
  
  If we want to follow dir structure that matches what we have done in 
  MdeModulePkg for industry standard host controllers, buses, and 
  devices and support vendor specific areas, maybe we can do something 
  like the following:
  
  DriversPkg
  DriversPkg/Vendor/VendorName
  DriversPkg/Bus/BusType
 
 Would we expect this too?
 
 DriversPkg/Vendor/VendorName/Bus/BusType
 
 I'm not sure how necessary the 'Vendor' directory level is. Seems fine though.
 
 -Jordan
 
  -Original Message-
  From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
  Leif Lindholm
  Sent: Thursday, July 30, 2015 8:20 AM
  To: Justen, Jordan L
  Cc: Kinney, Michael D; edk2-devel@lists.01.org
  Subject: Re: [edk2] [PATCH] EmbeddedPkg: Added Marvell Yukon Ethernet 
  support
  
  Hi Jordan,
  
  On Wed, Jul 29, 2015 at 02:59:04PM -0700, Jordan Justen wrote:
 But, the name 'open platform' also sounds strange, assuming this 
 a plain PCI bus driver. Couldn't it live in a 'pci drivers' package?
 
 Personally, I think we should rename OptionRomPkg to DriversPkg, 
 or split it into UsbDriversPkg and PciDriversPkg.
   
   This seems like another thing we've been talking about for years. :)
   
   What do you think about adding:
   
   DriversPkg
   DriversPkg/Pci
   DriversPkg/Usb
   
or
   
   PciDriversPkg
   UsbDriversPkg
  
  bikeshed
  We may well need support for drivers (read: I already have) that are 
  neither USB nor PCI. Should connecting interface still be the primary 
  filter?
  /bikeshed
  
   One possible concern is who will own/maintain such a package. In 
   this case, it might make sense to have a separate Maintainers.txt 
   file under the package.
   
   Or, what I would suggest is that we just start out by saying that 
   edk2-devel collectively owns it, and that any other package 
   maintainer can commit contributions to the package.
  
  I think that is a sensible thing to do until there is sufficient 
  amount of code in there to require a dedicated (set of) maintainer(s).
  
  What about platform code?
  
  /
  Leif
  
So, OpenPlatformPkg is my current way of dealing with the lack of 
a unified handling of platform/driver code in edk2. It is not 
something I mind giving up if this situation resolves itself 
another way. Or renaming to something more palatable :)

I gave a presentation (more like lightning talk) at the spring 
plugfest in Seattle on this:
http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_Pl
atforms_Tree_May_2015.pdf

If we simply rename OptionRomPkg to DriversPkg (and restructure a 
bit in there), then that solves the drivers part of my problem. 
But I still need something for opensource platform support.

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

Re: [edk2] [PATCH 17/58] OvmfPkg: import PiSmmCpuDxeSmm from Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg

2015-07-28 Thread Jordan Justen

Note: Cc: edk2-devel

Mike,

Can you *please* help out with this?? We've been discussing this since
April...

1. Why should we import all this code under the OVMF platform?

2. Why should we have a different license from the rest of EDK II if
   this is all Intel code?

Last time we talked about this in early June, I thought you had a plan
for this. Any updates??

Thanks,

-Jordan

On 2015-07-24 16:00:23, Laszlo Ersek wrote:
 This mammoth DXE_SMM_DRIVER provides gEfiSmmConfigurationProtocolGuid
 (among many other things), which is a dependency of the SMM Initial
 Program Load module (MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c). It
 provides the mixed (assembly and C) language, lowest level SMM entry
 point.
 
 It is also responsible for populating the SMM_S3_RESUME_STATE object on
 normal boot that OvmfPkg/SmmAccess/SmmAccessPei.c sets aside in SMRAM
 and that MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c uses on
 S3 resume.
 
 Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg can be found at
 https://downloadcenter.intel.com/download/23197, and comes under the
 3-clause BSD License (which is allowed by OvmfPkg/Contributions.txt)
 
 We don't try to build the driver at the moment, just import it. The
 following patches will port it to, and slim it down for, OVMF.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Laszlo Ersek ler...@redhat.com
 ---
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf|  156 ++
  OvmfPkg/QuarkPort/Include/AcpiCpuData.h|   53 +
  OvmfPkg/QuarkPort/Include/CpuHotPlugData.h |   52 +
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/CpuService.h  |  213 +++
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/SmmProfileArch.h |  116 ++
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h  |  782 +
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/SmmFeatures.h |  191 +++
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/SmmProfile.h  |   83 +
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/SmmProfileInternal.h  |  184 ++
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/CpuS3.c   |  454 +
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/CpuService.c  |  500 ++
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/PageTbl.c|  116 ++
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/Semaphore.c  |   78 +
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/SmmProfileArch.c |   84 +
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/MpService.c   | 1813 
 
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c  | 1530 
 +
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/SmmFeatures.c |  380 
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/SmmProfile.c  | 1376 +++
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/SyncTimer.c   |  130 ++
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/MpFuncs.S|  186 ++
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/MpFuncs.asm  |  190 ++
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/SmiEntry.S   |  171 ++
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/SmiEntry.asm |  176 ++
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/SmiException.S   | 1196 +
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/SmiException.asm |  883 ++
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/SmmInit.S|  122 ++
  OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32/SmmInit.asm  |  132 ++
  27 files changed, 11347 insertions(+)
 
 diff --git a/OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf 
 b/OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
 new file mode 100644
 index 000..b64db8f
 --- /dev/null
 +++ b/OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
 @@ -0,0 +1,156 @@
 +## @file
 +#
 +#  Agent Module to load other modules to deploy SMM Entry Vector for X86 CPU.
 +#  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

Re: [edk2] BaseTools features: multiple workspaces

2015-08-05 Thread Jordan Justen

On 2015-08-05 07:06:46, Gao, Liming wrote:
 Thanks for your all comments. 
 
 Most people prefers to keep WOSKAPCE as single directory, and
 introduce new env $(WORKSPACE_MULTIPLE).

I'm not sure about this conclusion. I think Paolo, Laszlo and I all
expressed that using WORKSPACE for the multiple directories seemed
more natural.

I think you originally suggested just using WORKSPACE, but maybe now
have changed your mind.

I know Tim had some big concerns with expanding WORKSPACE. I agree
with his concerns, but I don't think it will be much better with
WORKSPACE_MULTIPLE. (The same tools will break.)

Mike and Andrew appear to prefer WORKSPACE_MULTIPLE.

What about this suggestion?

WORKSPACE: expand to a list of directories

WORKSPACE_BUILD: if not set, use first path in WORKSPACE + '/Build'

WORKSPACE_CONF: if not set, scan WORKSPACE paths to find 'Conf' dir

WORKSPACE_TOOLS: if not set, scan WORKSPACE paths to find 'BaseTools' dir

With WORKSPACE and WORKSPACE_MULTIPLE we have a strange intersection
of 'part of the source tree' and 'all of the source tree'. I think the
variables I recommend avoid that partial overlap.

-Jordan

 I think Mike solution can
 make them more clear if WORKSPACE_MULTIPLE is set.
 
 On QA team impact, it should be small. QA team can still use the
 current working model to place all packages in root directory, and
 set WORKSPACE only. QA team just needs to know the package list.
 
 Tim gave another idea to define multiple source locations in
 Platform DSC file. It doesn't conflict with this proposal. We can
 implement $(WORKSPACE_MULTIPLE) feature first, and evaluate DSC
 update. On the fixed tree layout, these two solutions can work. Once
 the end user reorganizes its tree layout, he needs to set
 $(WORKSPACE_MULTIPLE) env or update Platform DSC file, and build
 platform DSC.
 
 Thanks
 Liming
 -Original Message-
 From: Laszlo Ersek [mailto:ler...@redhat.com] 
 Sent: Tuesday, August 04, 2015 7:20 PM
 To: Justen, Jordan L
 Cc: Gao, Liming; Paolo Bonzini; edk2-devel@lists.01.org
 Subject: Re: [edk2] BaseTools features: multiple workspaces
 
 On 08/03/15 19:35, Jordan Justen wrote:
  On 2015-08-03 02:08:14, Gao, Liming wrote:
  Paolo:
I think that keep the exiting syntax for WORKSPACE to be a single
path can minimize the impacts to exiting tools that assume a
single workspace.
  
  I know you originally suggested to use WORKSPACE, but got some 
  feedback that it might be better to create a new variable to not break 
  some unspecified tools.
  
  Was anyone able to name an actual tool that would be impacted? Why not 
  work to update these tools at the same time? An easy 'fix' will be for 
  any such tool to give an error message if it sees ':' or ';' in the 
  WORKSPACE environment variable. Although this is really not a fix, it 
  will be just as much support as if they ignore the new 
  WORKSPACE_MULTIPLE environment variable.
  
  I think that using the single separated WORKSPACE environment variable 
  is more intuitive/expected. From using env vars such as PATH, we all 
  know what it means.
  
  For WORKSPACE+WORKSPACE_MULTIPLE, I don't know which has priority. I 
  assume WORKSPACE is checked first, and then WORKSPACE_MULTIPLE?
 
 This was described in Liming's email, in point 4b.
 
  
  Will this work for the integrated CryptoPkg + open-ssl? It seems like 
  we need a priority above EDK II for this. I guess WORKSPACE will not 
  be set to EDK II in this case?
  
  Anyway, it just seems a little odd.
 
 For me a colon-separated (well, separator-separated :)) single WORKSPACE 
 variable would be more intuitive, but WORKSPACE_MULTIPLE can be defined well 
 enough too. For example:
 - WORKSPACE must not contain separators
 - if WORKSPACE_MULTIPLE is set, then the effect is as if
   ${WORKSPACE}:${WORKSPACE_MULTIPLE} were specified under the
   well-known PATH semantics.
 
 No clue about the CryptoPkg impact. Can you remind me please why CryptoPkg / 
 OpensslLib are special wrt. WORKSPACE?
 
 Thanks
 Laszlo
 
  
  -Jordan
  
  -Original Message-
  From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
  Of Paolo Bonzini
  Sent: Monday, August 03, 2015 4:31 PM
  To: Gao, Liming; edk2-devel@lists.01.org
  Subject: Re: [edk2] BaseTools features: multiple workspaces
 
 
  On 03/08/2015 05:56, Gao, Liming wrote:
  Hi, all
We will update BaseTools feature to allow more than one workspaces. The 
  detail design in the below. Please help review it. If you have any 
  comments, please let me know.
 
  1.   Keep $(WORKSPACE) environment as is
 
  a.   $(WORKSPACE) determines location of Build and Conf directory.
 
  2.   New optional $(WORKSPACE_MULTIPLE) environment is added to 
  include more directories with the separator ';', like $(PATH)
 
  Why is $(WORKSPACE_MULTIPLE) necessary?  On Linux it is okay to break 
  preexisting paths that contain a :; on Windows semicolons are allowed in 
  theory but in practice break

Re: [edk2] BaseTools features: multiple workspaces

2015-08-05 Thread Jordan Justen

On 2015-08-05 12:19:47, Andrew Fish wrote:
 
  On Aug 5, 2015, at 12:09 PM, Jordan Justen jordan.l.jus...@intel.com 
  wrote:
  
  On 2015-08-05 07:06:46, Gao, Liming wrote:
  Thanks for your all comments. 
  
  Most people prefers to keep WOSKAPCE as single directory, and
  introduce new env $(WORKSPACE_MULTIPLE).
  
  I'm not sure about this conclusion. I think Paolo, Laszlo and I all
  expressed that using WORKSPACE for the multiple directories seemed
  more natural.
  
 
 Have your really thought this out? It breaks all of my internal
 build tips, and a lot of the edk2 build tips.

Unless we do something about most of those references then WORKSPACE
will have to be set to your 'edk2' tree. Therefore your Conf files
must exist in your edk2 tree, and your build output must exist in your
edk2 tree, and BaseTools must exist in your edk2 tree.

Many of those references map to the three new variables I mentioned.
$WORKSPACE/EmulatorPkg doesn't. I don't know if that means that we
need an EDKII variable, or maybe PLATFORM_WORKSPACE, or perhaps
something else...

-Jordan

 git grep WORKSPACE — 
 ...
 EmulatorPkg/Unix/Host/Host.inf:148:   XCODE:*_*_X64_CC_FLAGS = 
 -I$(WORKSPACE)/EmulatorPkg/Unix/Host/X11IncludeHack
 EmulatorPkg/build.sh:22:if [ -z $WORKSPACE ]
 EmulatorPkg/build.sh:37:  echo Building from: $WORKSPACE
 EmulatorPkg/build.sh:178:BUILD_OUTPUT_DIR=$WORKSPACE/Build/Emulator32
 EmulatorPkg/build.sh:184:BUILD_OUTPUT_DIR=$WORKSPACE/Build/Emulator
 EmulatorPkg/build.sh:201:PLATFORMFILE=$WORKSPACE/EmulatorPkg/EmulatorPkg.dsc
 EmulatorPkg/build.sh:209:  make -C $WORKSPACE/BaseTools
 EmulatorPkg/build.sh:214:  make -C $WORKSPACE/BaseTools
 EmulatorPkg/build.sh:232:cp $WORKSPACE/EmulatorPkg/Unix/lldbefi.py 
 $BUILD_OUTPUT_DIR/DEBUG_$TARGET_TOOLS/$PROCESSOR
 EmulatorPkg/build.sh:233:cd $BUILD_ROOT_ARCH; /usr/bin/lldb --source 
 $WORKSPACE/EmulatorPkg/Unix/lldbinit Host
 EmulatorPkg/build.sh:236:cp $WORKSPACE/EmulatorPkg/Unix/.gdbinit 
 $BUILD_OUTPUT_DIR/DEBUG_$TARGET_TOOLS/$PROCESSOR
 EmulatorPkg/build.sh:241:  /usr/bin/gdb $BUILD_ROOT_ARCH/Host -q 
 -cd=$BUILD_ROOT_ARCH -x $WORKSPACE/EmulatorPkg/Unix/GdbRun
 EmulatorPkg/build.sh:247:build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc 
 -a $PROCESSOR -b $BUILDTARGET -t $HOST_TOOLS -D UNIX_SEC_BUILD -n 3 clean
 EmulatorPkg/build.sh:248:build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc 
 -a $PROCESSOR -b $BUILDTARGET -t $TARGET_TOOLS -n 3 clean
 EmulatorPkg/build.sh:252:make -C $WORKSPACE/BaseTools clean
 EmulatorPkg/build.sh:253:build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc 
 -a $PROCESSOR -b $BUILDTARGET -t $HOST_TOOLS -D UNIX_SEC_BUILD -n 3 clean
 EmulatorPkg/build.sh:254:build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc 
 -a $PROCESSOR -b $BUILDTARGET -t $TARGET_TOOLS -n 3 clean
 EmulatorPkg/build.sh:255:build -p $WORKSPACE/ShellPkg/ShellPkg.dsc -a 
 IA32 -b $BUILDTARGET -t $TARGET_TOOLS -n 3 clean
 EmulatorPkg/build.sh:265:  build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc 
 $BUILD_OPTIONS -a $PROCESSOR -b $BUILDTARGET -t $TARGET_TOOLS -D 
 BUILD_$ARCH_SIZE -D UNIX_SEC_BUILD $NETWORK_SUPPORT $BUILD_NEW_SHELL 
 $BUILD_FAT -n 3
 EmulatorPkg/build.sh:267:  build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc 
 $BUILD_OPTIONS -a $PROCESSOR -b $BUILDTARGET -t $HOST_TOOLS  -D 
 BUILD_$ARCH_SIZE -D UNIX_SEC_BUILD -D SKIP_MAIN_BUILD -n 3 modules
 EmulatorPkg/build.sh:268:  build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc 
 $BUILD_OPTIONS -a $PROCESSOR -b $BUILDTARGET -t $TARGET_TOOLS -D 
 BUILD_$ARCH_SIZE $NETWORK_SUPPORT $BUILD_NEW_SHELL $BUILD_FAT -n 3
 OvmfPkg/README:48:under the $WORKSPACE/Build/*/*/FV directory.  The actual 
 path will
 OvmfPkg/README:179:- Install the drivers into a directory called Intel3.5 
 in your WORKSPACE.
 OvmfPkg/ResetVector/ResetVector.inf:36:   *_*_IA32_NASMB_FLAGS = 
 -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
 OvmfPkg/ResetVector/ResetVector.inf:37:   *_*_X64_NASMB_FLAGS = 
 -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
 OvmfPkg/build.sh:22:if [ -z $WORKSPACE ]
 OvmfPkg/build.sh:37:  echo Building from: $WORKSPACE
 OvmfPkg/build.sh:215:  PLATFORMFILE=$WORKSPACE/OvmfPkg/OvmfPkg$Processor.dsc
 OvmfPkg/build.sh:249:BUILD_ROOT=$WORKSPACE/Build/$PLATFORM_BUILD_DIR/$BUILDTARGET_$TARGET_TOOLS
 OvmfPkg/build.sh:258:  make -C $WORKSPACE/BaseTools
 OvmfPkg/build.sh:263:  make -C $WORKSPACE/BaseTools
 ShellBinPkg/ReadMe.txt:9:1. Check out EDK II to $(WORKSPACE) 
 ShellBinPkg/ReadMe.txt:12:2. Under $(WORKSPACE) directory (i.e. c:\EdkII),
 StdLib/StdLib.inc:114:RVCT:*_*_*_CC_FLAGS = --library_interface=none 
 -DUEFI_C_SOURCE -J$(WORKSPACE)/StdLib/Include 
 -J$(WORKSPACE)/StdLib/Include/Arm
 StdLib/StdLib.inc:124:RVCT:*_*_*_CC_FLAGS = --library_interface=none 
 -DUEFI_C_SOURCE -J$(WORKSPACE)/StdLib/Include 
 -J$(WORKSPACE)/StdLib/Include/Arm
 Vlv2TbltDevicePkg/PlatformPkg.fdf:963:DXE_DEPEX DXE_DEPEX Optional  
 $(WORKSPACE)/$(PLATFORM_PACKAGE)/IntelGopDepex

Re: [edk2] BaseTools features: multiple workspaces

2015-08-05 Thread Jordan Justen

On 2015-08-05 13:21:37, Andrew Fish wrote:
  On Aug 5, 2015, at 12:16 PM, Jordan Justen jordan.l.jus...@intel.com 
  wrote:
  On 2015-08-05 07:06:46, Gao, Liming wrote:
  Tim gave another idea to define multiple source locations in
  Platform DSC file. It doesn't conflict with this proposal. We can
  implement $(WORKSPACE_MULTIPLE) feature first, and evaluate DSC
  update. On the fixed tree layout, these two solutions can work. Once
  the end user reorganizes its tree layout, he needs to set
  $(WORKSPACE_MULTIPLE) env or update Platform DSC file, and build
  platform DSC.
  
  At one point Mike suggested updating target.txt to be able to add
  paths.
  
  I think this might be better than hard coding them into the dsc
  (source code) files.
  
  Tim, any thoughts on this?
 
 I’m not Tim, but PLEASE NOOO!!
 
 We don’t want “one tree per product”, we want multiple products per
 tree. target.txt is really helpful if you want to save typing on the
 command line, but that is about it.

I happen to agree. I haven't used target.txt in years. I love being
able to run these two commands easily in the same tree:

$ OvmfPkg/build.sh

$ EmulatorPkg/build.sh

If anything, I'd like to see us make the Conf directory optional. (And
use BaseTools/Conf by default.)

 Now I have seen some vendors that do sill stuff like write a script
 that patches target.txt and then calls build.exe. I say silly as the
 script could have just passed the arguments build.exe directly, as
 target.txt is just the default value for the args of the build
 command.

Apparently we have a 'TargetTool' that helps with this? Who knew? (Not
I ... seriously.)

Anyway, I'm just responding to not wanting to bake hard coded package
paths into the .dsc. Not that I like target.txt. :)

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

Re: [edk2] BaseTools features: multiple workspaces

2015-08-03 Thread Jordan Justen

Cc: edk2-devel

On 2015-08-03 10:41:43, Tim Lewis wrote:
 There are dozens of tools in commercial environments (including some
 by Insyde) which will fail in this case. In addition, there are
 codebases that I am aware of where $(WORKSPACE) is allowed directly
 in other build files.

Will all these 'dozens of tools in commercial environments' fare any
better with the WORKSPACE_MULTIPLE option?

As a quick example, say C:\ssl\CryptoPkg has open-ssl integrated, and
C:\edk2 is the plain EDK II tree.

Thus, we want to set WORKSPACE=C:\ssl and WORKSPACE_MULTIPLE=C:\edk2
so the open-ssl integrated version of CryptoPkg will take priority.

Are these tools likely to work as expected? I am guessing no. I'm
thinking that these tools will probably have to insist on a fully
integrated single workspace until they can be updated to the new
design.

At that point whether WORKSPACE can have multiple directories, or we
add WORKSPACE_MULTIPLE, it will not make a big difference to these
tools.

-Jordan

 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
 Justen
 Sent: Monday, August 03, 2015 10:36 AM
 To: Gao, Liming liming@intel.com; Paolo Bonzini pbonz...@redhat.com; 
 edk2-devel@lists.01.org
 Subject: Re: [edk2] BaseTools features: multiple workspaces
 
 On 2015-08-03 02:08:14, Gao, Liming wrote:
  Paolo:
I think that keep the exiting syntax for WORKSPACE to be a single
path can minimize the impacts to exiting tools that assume a
single workspace.
 
 I know you originally suggested to use WORKSPACE, but got some feedback that 
 it might be better to create a new variable to not break some unspecified 
 tools.
 
 Was anyone able to name an actual tool that would be impacted? Why not work 
 to update these tools at the same time? An easy 'fix' will be for any such 
 tool to give an error message if it sees ':' or ';' in the WORKSPACE 
 environment variable. Although this is really not a fix, it will be just as 
 much support as if they ignore the new WORKSPACE_MULTIPLE environment 
 variable.
 
 I think that using the single separated WORKSPACE environment variable is 
 more intuitive/expected. From using env vars such as PATH, we all know what 
 it means.
 
 For WORKSPACE+WORKSPACE_MULTIPLE, I don't know which has priority. I assume 
 WORKSPACE is checked first, and then WORKSPACE_MULTIPLE?
 
 Will this work for the integrated CryptoPkg + open-ssl? It seems like we need 
 a priority above EDK II for this. I guess WORKSPACE will not be set to EDK II 
 in this case?
 
 Anyway, it just seems a little odd.
 
 -Jordan
 
  -Original Message-
  From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
  Paolo Bonzini
  Sent: Monday, August 03, 2015 4:31 PM
  To: Gao, Liming; edk2-devel@lists.01.org
  Subject: Re: [edk2] BaseTools features: multiple workspaces
  
  
  On 03/08/2015 05:56, Gao, Liming wrote:
   Hi, all
 We will update BaseTools feature to allow more than one workspaces. The 
   detail design in the below. Please help review it. If you have any 
   comments, please let me know.
   
   1.   Keep $(WORKSPACE) environment as is
   
   a.   $(WORKSPACE) determines location of Build and Conf directory.
   
   2.   New optional $(WORKSPACE_MULTIPLE) environment is added to 
   include more directories with the separator ';', like $(PATH)
  
  Why is $(WORKSPACE_MULTIPLE) necessary?  On Linux it is okay to break 
  preexisting paths that contain a :; on Windows semicolons are allowed in 
  theory but in practice break in several ways.
  
  Paolo
  
   a.   Produce the same behavior if $(WORKSPACE_MULTIPLE) is not set.
   
   3.   Update edksetup.bat/edksetup.sh to find BaseTools directory from 
   $(WORKSPACE) and $(WORKSPACE_MULTIPLE) directories.
   
   4.   Update BaseTools to support multiple workspaces
   
   a.   For the relative file path (INF, DSC and FDF), BaseTools will 
   search them from $(WORKSPACE) and $(WORKSPACE_MULTIPLE) directories.
   
   b.  Search priority from high to low: $(WORKSPACE), 
   $(WORKSPACE_MULTIPLE).
   
   This is a compatible feature. It has no impact on current EDKII 
   project.
  ___
  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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] BaseTools features: multiple workspaces

2015-08-03 Thread Jordan Justen

On 2015-08-03 02:08:14, Gao, Liming wrote:
 Paolo:
   I think that keep the exiting syntax for WORKSPACE to be a single
   path can minimize the impacts to exiting tools that assume a
   single workspace.

I know you originally suggested to use WORKSPACE, but got some
feedback that it might be better to create a new variable to not break
some unspecified tools.

Was anyone able to name an actual tool that would be impacted? Why not
work to update these tools at the same time? An easy 'fix' will be for
any such tool to give an error message if it sees ':' or ';' in the
WORKSPACE environment variable. Although this is really not a fix, it
will be just as much support as if they ignore the new
WORKSPACE_MULTIPLE environment variable.

I think that using the single separated WORKSPACE environment variable
is more intuitive/expected. From using env vars such as PATH, we all
know what it means.

For WORKSPACE+WORKSPACE_MULTIPLE, I don't know which has priority. I
assume WORKSPACE is checked first, and then WORKSPACE_MULTIPLE?

Will this work for the integrated CryptoPkg + open-ssl? It seems like
we need a priority above EDK II for this. I guess WORKSPACE will not
be set to EDK II in this case?

Anyway, it just seems a little odd.

-Jordan

 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Paolo 
 Bonzini
 Sent: Monday, August 03, 2015 4:31 PM
 To: Gao, Liming; edk2-devel@lists.01.org
 Subject: Re: [edk2] BaseTools features: multiple workspaces
 
 
 On 03/08/2015 05:56, Gao, Liming wrote:
  Hi, all
We will update BaseTools feature to allow more than one workspaces. The 
  detail design in the below. Please help review it. If you have any 
  comments, please let me know.
  
  1.   Keep $(WORKSPACE) environment as is
  
  a.   $(WORKSPACE) determines location of Build and Conf directory.
  
  2.   New optional $(WORKSPACE_MULTIPLE) environment is added to include 
  more directories with the separator ';', like $(PATH)
 
 Why is $(WORKSPACE_MULTIPLE) necessary?  On Linux it is okay to break 
 preexisting paths that contain a :; on Windows semicolons are allowed in 
 theory but in practice break in several ways.
 
 Paolo
 
  a.   Produce the same behavior if $(WORKSPACE_MULTIPLE) is not set.
  
  3.   Update edksetup.bat/edksetup.sh to find BaseTools directory from 
  $(WORKSPACE) and $(WORKSPACE_MULTIPLE) directories.
  
  4.   Update BaseTools to support multiple workspaces
  
  a.   For the relative file path (INF, DSC and FDF), BaseTools will 
  search them from $(WORKSPACE) and $(WORKSPACE_MULTIPLE) directories.
  
  b.  Search priority from high to low: $(WORKSPACE), 
  $(WORKSPACE_MULTIPLE).
  
  This is a compatible feature. It has no impact on current EDKII project.
 ___
 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] more code sharing joy between OvmfPkg and ArmVirtPkg, re SMBIOS

2015-07-30 Thread Jordan Justen

On 2015-07-30 10:09:34, Laszlo Ersek wrote:
 (Sigh, I left off the list address. This should be discussed publicly.
 Resending.)
 
 Clearly, the SMBIOS patches I posted and got committed last time are not
 good enough. That's because the SMBIOS 3.0 entry point is structurally
 different from the prior versions (because why not). Therefore, now that
 Wei has QEMU generate SMBIOS 3.0 payload for the firmware, the checks we
 currently have in place, fail.
 
 (First and foremost, the *size* of the 3.0 entry point is different from
 that of the 2.8 one. We correctly catch this, but we incorrectly don't
 recognize 3.0.)
 
 I can write the code for telling apart 2.8 from 3.0; that's not the
 problem. The problem is that this code would have to be triplicated, as
 things currently stand:
 
 (1) ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c sets
 PcdSmbiosVersion for MdeModulePkg/Universal/SmbiosDxe in the
 ArmVirtPkg build, early in the DXE phase,
 
 (2) OvmfPkg/PlatformPei/Platform.c sets the same PCD for the same
 generic driver in the OvmfPkg build, in the PEI phase,
 
 (3) OvmfPkg/SmbiosPlatformDxe/Qemu.c verifies the entry point again,
 and fetches the actual tables. (Note that
 (TablesSize != QemuAnchor.TableLength) is checked too, so there is a
 cross-dependency between the two blobs, the entry point and the
 actual tables.)
 
 Now, the current triplication we have is simplistic, so it shouldn't be
 a large problem. But, if I need to add smarts for detecting v2 versus
 v3, I would hate to triplicate that logic too. This is what code sites
 (1) and (2) both should do, for determining PcdSmbiosVersion:
 
 - Find etc/smbios/smbios-anchor. If it is missing, bail.
 - Compare the size of that fw-cfg blob against SMBIOS_TABLE_ENTRY_POINT.
 - If it is a match, perform the current _SM_ and _DMI_ checks.
 - If they fail, bail.
 - If they match, check that QemuAnchor.MajorVersion is actually 2.
 - If that fails, bail.
 - If it matches, set PcdSmbiosVersion to 0x02__.
 - Otherwise, compare the size of the anchor blob against
   SMBIOS_TABLE_3_0_ENTRY_POINT.
 - If it is a match, perform the (new) _SM3_ check.
 - If it fails, bail.
 - Check that MajorVersion (which now lives at a different offset) is
   3.
 - If that fails, bail.
 - If it matches, set PcdSmbiosVersion to 0x03__.
 - Otherwise, bail.
 
 In (3):
 - repeat all of the above, except do not *set* the PCD -- enforce it
   instead. ASSERT() that the PCD already has the right value (because
   at this point MdeModulePkg/Universal/SmbiosDxe is expected to have
   been dispatched, and consumed the PCD).
 - If the version is 2, then compare TableLength == tables blob size.
   If it fails, return NULL; otherwise return the tables.
 - If the version is 3, then compare TableMaximumSize = tables blob
   size. If it fails, return NULL; otherwise return the tables.
 - If the version is something different, return NULL.
 
 As I said, this can be coded as-written, but I strongly dislike the code
 triplication, and I expect you guys will too. So what do you propose? I
 could extract a tiny BASE library (a single function) that:
 - depends on QemuFwCfgLib
 - takes a BOOLEAN parameter that tells it whether to set the PCD, or
   check and enforce the PCD
 - return the detected SMBIOS version (2, 3, or missing/unknown)
 
 Then I could use this function in sites (1) and (2) for setting the PCD,
 and then use it in (3) for enforcing the PCD, and based on the returned
 SMBIOS version, perform the version-specific tables blob size check too.

Would it help if you used a NULL library with a constructor to set
gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion?

  MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf {
LibraryClasses
  NULL|OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.inf
  }

I'm not sure about the enforce part, but maybe this could allow you to
also share some code between detect  enforce:

  OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf {
LibraryClasses
  NULL|OvmfPkg/Library/SmbiosVersionLib/ValidateSmbiosVersionLib.inf
  }

But, I'm a little skeptical of the necessity of this second one...

-Jordan

 Small problem: you are going to hate me for introducing a
 single-function library *class*.
 
 So how do I share *one function* between different *phase* modules of
 different top-level packages? Should we introduce BaseCrapLib ^W
 BaseUtilityLib, and just keep throwing such functions in there?
 
 If so, what names (pathnames, basenames, library class and instance
 names etc) do you recommend?
 
 Thanks
 Laszlo
 ___
 edk2-devel mailing list
 edk2-devel@lists.01.org
 https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] OvmfPkg: PlatformDebugLibIoPort: fix AsciiSPrint() format string

2015-08-06 Thread Jordan Justen

Reviewed-by: Jordan Justen jordan.l.jus...@intel.com

On 2015-08-05 09:32:17, Laszlo Ersek wrote:
 The LineNumber parameter of the DebugAssert() function has type UINTN.
 DebugAssert() passes it to AsciiSPrint() with the %d conversion specifier
 at the moment, but %d would require an INT32 argument.
 
 Fix this by casting LineNumber to UINT64, also employing the matching
 decimal conversion specifier, %Lu.
 
 (Another possibility would be to cast LineNumber to INT32, but a
 UINTN-INT32 cast is not value preserving, generally speaking.)
 
 Cc: Jordan Justen jordan.l.jus...@intel.com
 Cc: Scott Duplichan sc...@notabs.org
 Reported-by: Scott Duplichan sc...@notabs.org
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Laszlo Ersek ler...@redhat.com
 ---
  OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c 
 b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
 index 88f9e55..e1ff103 100644
 --- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
 +++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
 @@ -134,7 +134,8 @@ DebugAssert (
//
// Generate the ASSERT() message in Ascii format
//
 -  AsciiSPrint (Buffer, sizeof (Buffer), ASSERT %a(%d): %a\n, FileName, 
 LineNumber, Description);
 +  AsciiSPrint (Buffer, sizeof Buffer, ASSERT %a(%Lu): %a\n, FileName,
 +(UINT64)LineNumber, Description);
  
//
// Send the print string to the Console Output device
 -- 
 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 v3 7/7] BaseTools: add support for CLANG compiler to GCC family

2015-08-07 Thread Jordan Justen

I think the subject should say 'Add CLANG toolchain with AARCH64
support' to highlight that a new toolchain name is being defined.

Should we consider adding the version to the toolchain name, like
CLANG37? Then we can change parameters between major releases. At
least for GCC it has proved useful.

-Jordan

On 2015-08-07 07:23:23, Ard Biesheuvel wrote:
 This adds support for building the AARCH64 platforms using the
 Clang compiler and assembler combined with the GNU (cross-)linker.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 Reviewed-by: Leif Lindholm leif.lindh...@linaro.org
 Tested-by: Leif Lindholm leif.lindh...@linaro.org
 ---
  BaseTools/Conf/tools_def.template | 51 
  1 file changed, 51 insertions(+)
 
 diff --git a/BaseTools/Conf/tools_def.template 
 b/BaseTools/Conf/tools_def.template
 index eeb488fb3597..974c9805435b 100644
 --- a/BaseTools/Conf/tools_def.template
 +++ b/BaseTools/Conf/tools_def.template
 @@ -4644,6 +4644,57 @@ RELEASE_GCC49_AARCH64_CC_FLAGS   = 
 DEF(GCC49_AARCH64_CC_FLAGS) -Wno-unused-but-s
  
  
 
  #
 +# CLANG   - This configuration is used to compile under Linux to produce
 +#   PE/COFF binaries using the clang compiler and assembler and GNU 
 linker
 +#
 +
 +*_CLANG_*_*_FAMILY   = GCC
 +
 +*_CLANG_*_MAKE_PATH  = make
 +*_CLANG_*_*_DLL  = ENV(CLANG_DLL)
 +*_CLANG_*_ASL_PATH   = DEF(UNIX_IASL_BIN)
 +
 +*_CLANG_*_PP_FLAGS   = DEF(GCC_PP_FLAGS)
 +*_CLANG_*_ASLPP_FLAGS= DEF(GCC_ASLPP_FLAGS)
 +*_CLANG_*_ASLCC_FLAGS= DEF(GCC_ASLCC_FLAGS)
 +*_CLANG_*_VFRPP_FLAGS= DEF(GCC_VFRPP_FLAGS)
 +*_CLANG_*_APP_FLAGS  =
 +*_CLANG_*_ASL_FLAGS  = DEF(IASL_FLAGS)
 +*_CLANG_*_ASL_OUTFLAGS   = DEF(IASL_OUTFLAGS)
 +
 +*_CLANG_*_CC_PATH= ENV(CLANG_BIN)clang
 +*_CLANG_*_ASM_PATH   = ENV(CLANG_BIN)clang
 +*_CLANG_*_PP_PATH= ENV(CLANG_BIN)clang
 +*_CLANG_*_VFRPP_PATH = ENV(CLANG_BIN)clang
 +*_CLANG_*_ASLCC_PATH = ENV(CLANG_BIN)clang
 +*_CLANG_*_ASLPP_PATH = ENV(CLANG_BIN)clang
 +
 +DEFINE CLANG_WARNING_OVERRIDES   = -Wno-parentheses-equality 
 -Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare 
 -Wno-empty-body
 +DEFINE CLANG_AARCH64_CC_FLAGS= DEF(GCC_AARCH64_CC_FLAGS) -target aarch64 
 -mcmodel=small -mstrict-align DEF(CLANG_WARNING_OVERRIDES)
 +
 +##
 +# CLANG AARCH64 definitions
 +##
 +*_CLANG_AARCH64_SLINK_PATH   = ENV(CLANG_AARCH64_PREFIX)ar
 +*_CLANG_AARCH64_DLINK_PATH   = ENV(CLANG_AARCH64_PREFIX)ld
 +*_CLANG_AARCH64_ASLDLINK_PATH= ENV(CLANG_AARCH64_PREFIX)ld
 +*_CLANG_AARCH64_RC_PATH  = ENV(CLANG_AARCH64_PREFIX)objcopy
 +
 +*_CLANG_AARCH64_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS)
 +*_CLANG_AARCH64_ASLDLINK_FLAGS   = DEF(GCC_AARCH64_ASLDLINK_FLAGS)
 +*_CLANG_AARCH64_ASM_FLAGS= DEF(GCC_ASM_FLAGS) $(ARCHASM_FLAGS) 
 $(PLATFORM_FLAGS) -target aarch64 -Qunused-arguments
 +*_CLANG_AARCH64_DLINK_FLAGS  = DEF(GCC_AARCH64_DLINK_FLAGS) -z 
 common-page-size=0x1000
 +*_CLANG_AARCH64_DLINK2_FLAGS = DEF(GCC_DLINK2_FLAGS_COMMON) 
 --defsym=PECOFF_HEADER_SIZE=0x228
 +*_CLANG_AARCH64_PLATFORM_FLAGS   =
 +*_CLANG_AARCH64_PP_FLAGS = DEF(GCC_PP_FLAGS) $(ARCHCC_FLAGS) 
 $(PLATFORM_FLAGS)
 +*_CLANG_AARCH64_RC_FLAGS = DEF(GCC_AARCH64_RC_FLAGS)
 +*_CLANG_AARCH64_VFRPP_FLAGS  = DEF(GCC_VFRPP_FLAGS) $(ARCHCC_FLAGS) 
 $(PLATFORM_FLAGS)
 +
 +  DEBUG_CLANG_AARCH64_CC_FLAGS   = DEF(CLANG_AARCH64_CC_FLAGS) 
 $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -O0
 +RELEASE_CLANG_AARCH64_CC_FLAGS   = DEF(CLANG_AARCH64_CC_FLAGS) 
 $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -Oz
 +
 +
 +#
  # Cygwin GCC And Intel ACPI Compiler
  #
  
 
 -- 
 1.9.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 v3 7/7] BaseTools: add support for CLANG compiler to GCC family

2015-08-07 Thread Jordan Justen

On 2015-08-07 07:59:24, Ard Biesheuvel wrote:
 On 7 August 2015 at 16:51, Jordan Justen jordan.l.jus...@intel.com wrote:
  I think the subject should say 'Add CLANG toolchain with AARCH64
  support' to highlight that a new toolchain name is being defined.
 
 
 OK. I can fix that up before applying.
 
  Should we consider adding the version to the toolchain name, like
  CLANG37? Then we can change parameters between major releases. At
  least for GCC it has proved useful.
 
 
 Actually, I was going to suggest folding everything except GCC-4.4
 into GCC4X since the differences are so minor.

Minor, but there are differences. Would you propose forcing people to
have to cusomize tools_def if they don't use the GCC-4.X that
tools_def currently supports? How would that work?

 (and GCC-4.4 may be on its way out due to its poor support of
 ms_abi).

Arg. Not that tired old argument about how difficult it is to use
EFIAPI properly? :)

By the way, we have never deprecated a toolchain in EDK II. Personally
I think we should move some older toolchains to
BaseTools/Conf/tools_def.deprecated.

 With GCC 5.0 and 5.1 around the corner, it is becoming a bit
 unwieldy by my taste.

There would be a GCC5 and GCC6. Not GCC50 and GCC51. (GCC moved
releases to bumping the first version number.)

https://gcc.gnu.org/develop.html#num_scheme

This method does add 1~2 toolchains per year, but it doesn't seem too
bad.

CLANG seems to have releases about 1~2 per year as well, and it would
be good to plan for some minor parameter tweaks between releases.
That's why I'd suggest CLANG37, to match up with CLANG/LLVM release
numbering.

-Jordan

 For clang, there is no reason right now afaict. So perhaps we could
 use CLANG3X instead? That way, we can still keep the current support
 as newer CLANG versions become available, but are not forced to
 declare 2 or 3 discrete but identical versions right from the start.
 
 -- 
 Ard.
 
  On 2015-08-07 07:23:23, Ard Biesheuvel wrote:
  This adds support for building the AARCH64 platforms using the
  Clang compiler and assembler combined with the GNU (cross-)linker.
 
  Contributed-under: TianoCore Contribution Agreement 1.0
  Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
  Reviewed-by: Leif Lindholm leif.lindh...@linaro.org
  Tested-by: Leif Lindholm leif.lindh...@linaro.org
  ---
   BaseTools/Conf/tools_def.template | 51 
   1 file changed, 51 insertions(+)
 
  diff --git a/BaseTools/Conf/tools_def.template 
  b/BaseTools/Conf/tools_def.template
  index eeb488fb3597..974c9805435b 100644
  --- a/BaseTools/Conf/tools_def.template
  +++ b/BaseTools/Conf/tools_def.template
  @@ -4644,6 +4644,57 @@ RELEASE_GCC49_AARCH64_CC_FLAGS   = 
  DEF(GCC49_AARCH64_CC_FLAGS) -Wno-unused-but-s
 
   
  
   #
  +# CLANG   - This configuration is used to compile under Linux to produce
  +#   PE/COFF binaries using the clang compiler and assembler and 
  GNU linker
  +#
  +
  +*_CLANG_*_*_FAMILY   = GCC
  +
  +*_CLANG_*_MAKE_PATH  = make
  +*_CLANG_*_*_DLL  = ENV(CLANG_DLL)
  +*_CLANG_*_ASL_PATH   = DEF(UNIX_IASL_BIN)
  +
  +*_CLANG_*_PP_FLAGS   = DEF(GCC_PP_FLAGS)
  +*_CLANG_*_ASLPP_FLAGS= DEF(GCC_ASLPP_FLAGS)
  +*_CLANG_*_ASLCC_FLAGS= DEF(GCC_ASLCC_FLAGS)
  +*_CLANG_*_VFRPP_FLAGS= DEF(GCC_VFRPP_FLAGS)
  +*_CLANG_*_APP_FLAGS  =
  +*_CLANG_*_ASL_FLAGS  = DEF(IASL_FLAGS)
  +*_CLANG_*_ASL_OUTFLAGS   = DEF(IASL_OUTFLAGS)
  +
  +*_CLANG_*_CC_PATH= ENV(CLANG_BIN)clang
  +*_CLANG_*_ASM_PATH   = ENV(CLANG_BIN)clang
  +*_CLANG_*_PP_PATH= ENV(CLANG_BIN)clang
  +*_CLANG_*_VFRPP_PATH = ENV(CLANG_BIN)clang
  +*_CLANG_*_ASLCC_PATH = ENV(CLANG_BIN)clang
  +*_CLANG_*_ASLPP_PATH = ENV(CLANG_BIN)clang
  +
  +DEFINE CLANG_WARNING_OVERRIDES   = -Wno-parentheses-equality 
  -Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare 
  -Wno-empty-body
  +DEFINE CLANG_AARCH64_CC_FLAGS= DEF(GCC_AARCH64_CC_FLAGS) -target 
  aarch64 -mcmodel=small -mstrict-align DEF(CLANG_WARNING_OVERRIDES)
  +
  +##
  +# CLANG AARCH64 definitions
  +##
  +*_CLANG_AARCH64_SLINK_PATH   = ENV(CLANG_AARCH64_PREFIX)ar
  +*_CLANG_AARCH64_DLINK_PATH   = ENV(CLANG_AARCH64_PREFIX)ld
  +*_CLANG_AARCH64_ASLDLINK_PATH= ENV(CLANG_AARCH64_PREFIX)ld
  +*_CLANG_AARCH64_RC_PATH  = ENV(CLANG_AARCH64_PREFIX)objcopy
  +
  +*_CLANG_AARCH64_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS)
  +*_CLANG_AARCH64_ASLDLINK_FLAGS   = DEF(GCC_AARCH64_ASLDLINK_FLAGS)
  +*_CLANG_AARCH64_ASM_FLAGS= DEF(GCC_ASM_FLAGS) $(ARCHASM_FLAGS) 
  $(PLATFORM_FLAGS) -target aarch64 -Qunused-arguments

Re: [edk2] [PATCH 0/9] OvmfPkg, ArmVirtPkg: SMBIOS 3.0, round 2

2015-08-05 Thread Jordan Justen

Series Reviewed-by: Jordan Justen jordan.l.jus...@intel.com

On 2015-07-31 11:40:52, Laszlo Ersek wrote:
 The SMBIOS 3.x entry point is structurally different from the 2.x
 variant, therefore the current code used by OvmfPkg and ArmVirtPkg
 doesn't recognize an SMBIOS 3.0 entry point structure even if QEMU
 exports one. This series rectifies that.
 
 The first four patches implement Jordan's great idea: they refactor the
 code without any observable changes, unifying the currently duplicated
 QEMU SMBIOS entry point checks / version setting between OvmfPkg and
 ArmVirtPkg.
 
 Patches 5 to 7, inclusive, eliminate yet another instance of the entry
 point checks, this time the last one, from SmbiosPlatformDxe.
 
 Building on the centralized QEMU SMBIOS entry point examination, patches
 8 and 9 add SMBIOS 3.0 support for real.
 
 The series builds at every stage. I regression-tested it with OVMF (2.8
 entry point), and tested the 3.0 entry point support using Wei's QEMU
 series pending at
 http://thread.gmane.org/gmane.comp.emulators.qemu/353282, with a small
 QEMU fix on top (which I posted in that thread).
 
 As I wrote in that thread as well, I didn't test with dmidecode in an
 aarch64 Linux guest just yet; I used the smbiosview UEFI shell command
 in the guest.
 
 Public branch: https://github.com/lersek/edk2/commits/smbios30_round2.
 
 Wei, you can find a binary at
 http://people.redhat.com/~lersek/smbios30_round2_v1/QEMU_EFI.fd.xz,
 for testing any further QEMU changes.
 
 Cc: Ard Biesheuvel ard.biesheu...@linaro.org
 Cc: Wei Huang w...@redhat.com
 Cc: Jordan Justen jordan.l.jus...@intel.com
 Cc: Gabriel L. Somlo so...@cmu.edu
 
 Thanks
 Laszlo
 
 Laszlo Ersek (9):
   OvmfPkg: SmbiosVersionLib: add plugin for detecting SMBIOS version
   OvmfPkg: set SMBIOS version in DetectSmbiosVersionLib instead of
 PlatformPei
   ArmVirtPkg: set SMBIOS version in DetectSmbiosVersionLib instead of
 QemuFwCfgToPcdDxe
   ArmVirtPkg: revert ArmVirtPkg: add QemuFwCfgToPcdDxe
   OvmfPkg: introduce PcdQemuSmbiosValidated
   ArmVirtPkg/ArmVirtQemu.dsc: set default for PcdQemuSmbiosValidated
   OvmfPkg: SmbiosPlatformDxe: eliminate duplicate entry point validation
   ArmVirtPkg: set default for PcdSmbiosDocRev
   OvmfPkg: SmbiosVersionLib: recognize SMBIOS 3.x entry point
 
  ArmVirtPkg/ArmVirtQemu.dsc  |   8 +-
  ArmVirtPkg/ArmVirtQemu.fdf  |   2 -
  ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c   |  73 
 -
  ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf |  46 -
  OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.c   | 107 
 
  OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.inf |  53 ++
  OvmfPkg/OvmfPkg.dec |   1 +
  OvmfPkg/OvmfPkgIa32.dsc |   7 +-
  OvmfPkg/OvmfPkgIa32X64.dsc  |   7 +-
  OvmfPkg/OvmfPkgX64.dsc  |   7 +-
  OvmfPkg/PlatformPei/Platform.c  |  39 ---
  OvmfPkg/PlatformPei/PlatformPei.inf |   2 -
  OvmfPkg/SmbiosPlatformDxe/Qemu.c|  30 ++
  OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf |   4 +
  14 files changed, 198 insertions(+), 188 deletions(-)
  create mode 100644 OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.c
  create mode 100644 
 OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.inf
  delete mode 100644 ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c
  delete mode 100644 ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
 
 -- 
 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] MdeModulePkg:Add ESC key support in setup browser pop-up message box

2015-07-27 Thread Jordan Justen

On 2015-07-26 23:57:27, Bi, Dandan wrote:
   .../Universal/DisplayEngineDxe/FormDisplay.c|   3 ++-
   .../Universal/DisplayEngineDxe/FormDisplayStr.uni   | Bin 17032 - 17056 
  bytes
 
 What about making 2 patches? The first patch can convert
 FormDisplayStr.uni to UTF-8 without changing the text, and then this
 patch can be the second patch. Then we will be able to see the diff
 in the FormDisplayStr.uni file.

I guess you didn't think this was a good idea?

-Jordan

   2 files changed, 2 insertions(+), 1 deletion(-)
  
  diff --git a/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c 
  b/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
  index ae3038b..aba149f 100644
  --- a/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
  +++ b/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
  @@ -2257,11 +2257,12 @@ FxConfirmPopup (
 StrCatS (CfmStr, MaxLen, gConfirmMsgEnd);
   
 do {
   CreateDialog (Key, gEmptyString, CfmStr, gConfirmOpt, gEmptyString, 
  NULL);
 } while (((Key.UnicodeChar | UPPER_LOWER_CASE_OFFSET) != 
  (gConfirmOptYes[0] | UPPER_LOWER_CASE_OFFSET)) 
  -   ((Key.UnicodeChar | UPPER_LOWER_CASE_OFFSET) != 
  (gConfirmOptNo[0] | UPPER_LOWER_CASE_OFFSET)));
  +   ((Key.UnicodeChar | UPPER_LOWER_CASE_OFFSET) != 
  (gConfirmOptNo[0] | UPPER_LOWER_CASE_OFFSET)) 
  +   (Key.ScanCode != SCAN_ESC));
   
 if ((Key.UnicodeChar | UPPER_LOWER_CASE_OFFSET) == (gConfirmOptYes[0] | 
  UPPER_LOWER_CASE_OFFSET)) {
   RetVal = TRUE;
 } else {
   RetVal = FALSE;
  diff --git 
  a/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplayStr.uni 
  b/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplayStr.uni
  index 
  5c6ad48433b2c6f50016dc27a5801da90930e76f..ff94518b06d3294c3f581d9d18a1
  9c28d8399730 100644 GIT binary patch delta 38 
  lcmeBZWn9q8xZ#2+r#^!^gDXQYgY)FGriT%{An#7xdGnb3o-xz
  
  delta 26
  hcmZ3`%GlA$xZ#57U6JZfLLbo33I*8pUlA0|2L}3}OHP
  
  --
  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 0/7] Add missing PCD usage information in UNI and DEC files.

2015-07-27 Thread Jordan Justen

On 2015-07-21 05:50:25, Qiu Shumin wrote:
 When PCD defined in DEC file, PCD Help/Prompt information must be provided.
 PCD Help and Prompt string is required in Package DEC and Package
 UNI file. PCD Valid Range is optional. If specified, its format
 should be valid.
 
 Qiu Shumin (7):
   MdePkg: Add missing PCD usage information in UNI files.
   MdeModulePkg: Add missing PCD usage information in UNI and DEC files.
   IntelFrameworkModulePkg: Add missing PCD usage information in UNI and
 DEC files.
   NetworkPkg: Add missing PCD usage information in UNI and DEC files.
   SecurityPkg: Add missing PCD usage information in UNI files.
   UefiCpuPkg: Add missing PCD usage information in UNI files.
   SourceLevelDebugPkg: Add missing PCD usage information in UNI files.
 
  .../IntelFrameworkModulePkg.dec|   4 
  .../IntelFrameworkModulePkg.uni| Bin 33748 - 37454 bytes

How about converting these from UTF-16 to UTF-8 so the changes will
show up in the diff? (They won't be treated as bin files.)

-Jordan

  MdeModulePkg/MdeModulePkg.dec  |   3 +++
  MdeModulePkg/MdeModulePkg.uni  | Bin 166792 - 178978 
 bytes
  MdePkg/MdePkg.uni  | Bin 66564 - 69572 bytes
  NetworkPkg/NetworkPkg.dec  |   1 +
  NetworkPkg/NetworkPkg.uni  | Bin 6182 - 7948 bytes
  SecurityPkg/SecurityPkg.uni| Bin 35774 - 37742 bytes
  SourceLevelDebugPkg/SourceLevelDebugPkg.uni| Bin 12228 - 17346 bytes
  UefiCpuPkg/UefiCpuPkg.uni  | Bin 3320 - 6586 bytes
  10 files changed, 8 insertions(+)
 
 -- 
 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] TianoCore Subversion down?

2015-07-22 Thread Jordan Justen

On 2015-07-22 12:57:13, Laszlo Ersek wrote:
On 07/22/15 21:44, Bruce Cran wrote:
On 7/22/2015 4:18 AM, Laszlo Ersek wrote:
How about someone creates a temporary branch off the github master
branch, and applies all new patches from the list that have been
reviewed thus far? Then once SVN is back up, the patches from that git
branch could be committed to SVN by a single person, in one go, nicely
ordered.

Wouldn't a fork be preferable? Anyone can create one, and it doesn't
pollute the main repository.

The branch should be owned by an Intel associate, trusted by the entire
community. Having the same level access as needed by the current main
git repo / master branch too. The point is that *everyone* should start
working against this new branch, until SVN returns to life.

I don't think it is a good idea to temporarily setup an alternate
official 'upstream'. Unlike if we were using git, we can't just push
the branch back to the main server once it comes back online. Instead,
we'll have to use git-svn dcommit, and this will put all the patches
onto a diverged branch.

As you suggest, I can see trying to collect up the outstanding
ready-to-merge patches onto a temporary branch so they don't get lost.
Maybe I could just try to collect patches into a svn-offline branch in
my personal repo? I guess we could also put a temporary repo at
github.com/tianocore/edk2-svn-offline...

SF have posted an update
(http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-722/):

Yeah, I saw it.

- SourceForge Allura Subversion (SVN) service –*offline,*filesystem
checks complete, data restoration at 50%. Restoration priority after
Git and Hg services. _ETA TBD_, Future update will provide ETA.

Yeah, they don't know when they'll know an ETA. I guess we can forget
about SVN until next week.

I'll cease all edk2 activity until the SVN repo is back up. This is
intolerable.

I agree. When it went offline last week, I couldn't imagine the
downtime would stretch on for a week.

I hope that anyone trying to push back on switching to from svn to git
can see how dependent the svn centralized model leaves us on a single
server.

With git, although there would be some hiccups, it would be much more
feasible to setup a temporary alternate upstream location in the event
that the main server goes offline...

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

Re: [edk2] Is source repositories svn address changed?

2015-07-24 Thread Jordan Justen

On 2015-07-23 23:14:17, winddy wrote:
 Dear Experts,
   Rcently, I find udk open source SVN cannot be accessed.
   (https://svn.code.sf.net/p/edk2/code/trunk/edk2)

The reason for this is that sourceforge svn servers have been offline
for over a week now.

http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-722/

  According to http://www.tianocore.org/edk2, it says:
  Source repositories: git {github, bitbucket, sourceforge, more info}, 
 svn {sourceforge}
  So if we want to get latest UDK code, we should use git tool instead?

You can use github to access the tree with nearly all commits before
sourceforge svn went offline.

Additionally, you might consider to just use git to access the tree
going forward. It will continue to get changes sync'd in from svn once
sourceforge svn comes back online.

We are in the middle of planning to migrate from svn to git, but it
has not happened yet:

http://www.tianocore.org/news/2015/05/01/UnderConst.html

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

Re: [edk2] Temporary git repo - Re: TianoCore Subversion down?

2015-07-26 Thread Jordan Justen

On 2015-07-24 05:00:58, Laszlo Ersek wrote:
 On 07/24/15 11:37, Zeng, Star wrote:
  I just pulled the edk2-svn-offline code and took a look.
  And I found Jordan had a commit for the attached patch which has
  been committed in SVN at 18031 and I also have git-svn r18031 in
  local. Is it still needed in this temporary git repo?
 
 Yes, it is, because the starting point for the temporary git repo is SVN
 r18030. The daemon that copies SVN commits to the git mirror runs
 periodically, and sourceforge crashed before the next cycle of the
 daemon would have found r18031 and later.
 
 So, once this git queue is flushed back to SVN, if there is a minimal
 overlap at the start of the git queue, it can be thrown away.
 
 It's a bit complex,

Now that svn is back online, we can add to the complex part the fact
that sourceforge's restore did not contain anything passed r18014.
Luckily git-svn allowed me to re-commit them failry easily.

 yes, but suspending commits for more than a week now
 would be unacceptable.

In the end we collected 31 commits that weren't in svn. Hopefully that
will cut down on the chances that we'll miss committing some patches.

Thanks for all your effort in collecting up patches to Laszlo.

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

Re: [edk2] TianoCore Subversion down?

2015-07-26 Thread Jordan Justen

On 2015-07-25 19:59:10, Bruce Cran wrote:
 On 7/24/15 5:40 PM, Jordan Justen wrote:
  Unfortunately, it looks like they are going to manage to get svn back
  up and running. ;)
 
 It looks like it's back: 
 http://sourceforge.net/blog/sourceforge-subversion-svn-service-online/
 
 SourceForge-hosted Allura-backed Subversion (SVN) repositories have 
 been restored to service as of 7/25.

Well, they certainly tried to make it difficult for us. The restored
repo was missing r18015-18032. Luckily thanks to git (and git-svn), I
was able to restore them fairly easily. :)

We also lucked out in that I was able to restore things before anyone
else tried to commit. So, basically we don't have two versions of
r18015-18032.

 Now the question is whether we switch back to SF or continue using
 Github :)

Well ... I still think we're going to have to go back for now. I think
the question has moved from *if* we'll move to git, to *when* will we
move. Considering I've been running the git-svn mirror since 2009,
I'll take this as a great step forward. :)

Hopefully this incident will highlight how much more stable git is
based on its distributed nature.

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

[edk2] Fwd: edk2[18072] Fixed OS software shutdown when reporting actual processor temperature

2015-07-27 Thread Jordan Justen

Should this be included on master too? (Not just the UDK branch)

For future patches:

Could it be posted to edk2-devel for code review?

How about including the package name in the first line of the commit message?

https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format

Thanks,

-Jordan

-- Forwarded message --
From:  ti...@users.sourceforge.net
Date: Sun, Jul 26, 2015 at 8:14 PM
Subject: edk2[18072] Fixed OS software shutdown when reporting actual
processor temperature
To: edk2-comm...@lists.sourceforge.net


Revision: 18072
  http://sourceforge.net/p/edk2/code/18072
Author:   timhe
Date: 2015-07-27 03:14:33 + (Mon, 27 Jul 2015)
Log Message:
---
Fixed OS software shutdown when reporting actual processor temperature

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lu ShifeiX A shifeix.a...@intel.com
Reviewed-by: Tim He tim...@intel.com

Modified Paths:
--
branches/UDK2014.SP1/Vlv2TbltDevicePkg/PlatformDxe/Platform.c
branches/UDK2014.SP1/Vlv2TbltDevicePkg/PlatformSetupDxe/Thermal.vfi
branches/UDK2014.SP1/Vlv2TbltDevicePkg/PlatformSetupDxe/VfrStrings.uni

Modified: branches/UDK2014.SP1/Vlv2TbltDevicePkg/PlatformDxe/Platform.c
===
--- branches/UDK2014.SP1/Vlv2TbltDevicePkg/PlatformDxe/Platform.c
 2015-07-27 03:10:37 UTC (rev 18071)
+++ branches/UDK2014.SP1/Vlv2TbltDevicePkg/PlatformDxe/Platform.c
 2015-07-27 03:14:33 UTC (rev 18072)
@@ -564,6 +564,32 @@
   }
 }

+VOID
+EFIAPI
+InitThermalZone (
+  EFI_EVENT  Event,
+  VOID   *Context
+  )
+{
+  UINTN  VarSize;
+  EFI_STATUS Status;
+  EFI_GLOBAL_NVS_AREA_PROTOCOL   *GlobalNvsArea;
+  VarSize = sizeof(SYSTEM_CONFIGURATION);
+  Status = gRT-GetVariable(
+  NORMAL_SETUP_NAME,
+  gEfiNormalSetupGuid,
+  NULL,
+  VarSize,
+  mSystemConfiguration
+  );
+  Status = gBS-LocateProtocol (
+  gEfiGlobalNvsAreaProtocolGuid,
+  NULL,
+  (void **)GlobalNvsArea
+  );
+  GlobalNvsArea-Area-CriticalThermalTripPoint =
mSystemConfiguration.CriticalThermalTripPoint;
+  GlobalNvsArea-Area-PassiveThermalTripPoint =
mSystemConfiguration.PassiveThermalTripPoint;
+}
 #if defined SUPPORT_LVDS_DISPLAY  SUPPORT_LVDS_DISPLAY

 #endif
@@ -818,7 +844,16 @@
mReadyToBootEvent
);
   }
-
+  //
+  // Create a ReadyToBoot Event to run the thermalzone init process
+  //
+  Status = EfiCreateEventReadyToBootEx (
+ TPL_CALLBACK,
+ InitThermalZone,
+ NULL,
+ mReadyToBootEvent
+ );
+
   ReportStatusCodeEx (
 EFI_PROGRESS_CODE,
 EFI_COMPUTING_UNIT_CHIPSET | EFI_CU_PLATFORM_DXE_STEP1,

Modified: branches/UDK2014.SP1/Vlv2TbltDevicePkg/PlatformSetupDxe/Thermal.vfi
===
--- branches/UDK2014.SP1/Vlv2TbltDevicePkg/PlatformSetupDxe/Thermal.vfi
2015-07-27 03:10:37 UTC (rev 18071)
+++ branches/UDK2014.SP1/Vlv2TbltDevicePkg/PlatformSetupDxe/Thermal.vfi
2015-07-27 03:14:33 UTC (rev 18072)
@@ -42,8 +42,27 @@
   title  = STRING_TOKEN(STR_THERMAL_TITLE);

   subtitle text = STRING_TOKEN(STR_THERMAL_CONFIGURATION);
+  oneof   varid   = Setup.CriticalThermalTripPoint,
+prompt  = STRING_TOKEN(STR_ACPI_CRITICAL_THERMAL_TRIP_POINT),
+help= STRING_TOKEN(STR_ACPI_CRITICAL_THERMAL_TRIP_POINT_HELP),
+option text = STRING_TOKEN (STR_85_C), value = 85, flags=0 |
RESET_REQUIRED;
+option text = STRING_TOKEN (STR_87_C), value = 87, flags=0 |
RESET_REQUIRED;
+option text = STRING_TOKEN (STR_90_C), value = 90, flags=0 |
RESET_REQUIRED;
+option text = STRING_TOKEN (STR_105_C), value = 105, flags=0 |
RESET_REQUIRED;
+option text = STRING_TOKEN (STR_110_C), value = 110, flags=0 |
RESET_REQUIRED;
+option text = STRING_TOKEN (STR_200_C), value = 200,
flags=DEFAULT | MANUFACTURING | RESET_REQUIRED;
+  endoneof;
+  oneof   varid   = Setup.PassiveThermalTripPoint,
+prompt  = STRING_TOKEN (STR_ACPI_PASSIVE_THERMAL_TRIP_POINT),
+help= STRING_TOKEN (STR_ACPI_PASSIVE_THERMAL_TRIP_POINT_HELP),
+option text = STRING_TOKEN (STR_85_C), value = 85, flags=0 |
RESET_REQUIRED;
+option text = STRING_TOKEN (STR_87_C), value = 87, flags=0 |
RESET_REQUIRED;
+option text = STRING_TOKEN (STR_90_C), value = 90, flags=0 |
RESET_REQUIRED;
+option text = STRING_TOKEN (STR_100_C), value = 100, flags=0 |
RESET_REQUIRED;
+option text = STRING_TOKEN (STR_105_C), value = 105, flags=0 |
RESET_REQUIRED;
+option text = STRING_TOKEN (STR_180_C), value = 180,
flags=DEFAULT | MANUFACTURING | RESET_REQUIRED;
+  endoneof;

-
   suppressif TRUE;
 numeric varid = Setup.PassiveTc1Value,
   prompt  = STRING_TOKEN (STR_ACPI_PASSIVE_TC1_VALUE),

Modified:

Re: [edk2] [PATCH v2] MdeModulePkg:Add ESC key support in setup browser pop-up message box

2015-07-27 Thread Jordan Justen

On 2015-07-26 22:19:04, Dandan Bi wrote:
 When load default value or save changes will pop up message box to let user
 confirm,Y means confirm and N means ignore,now add Esc key with the
 same function of N key.And change the context of pop up message in .uni file,
 now will display Press 'Y' to confirm, 'N'/'ESC' to ignore.

What changed from v1? I find it is good to add a list of changes to
the commit message here, just before the signatures. For example:

v2:
 * Add your text here telling what changed in v2

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Dandan Bi dandan...@intel.com
 ---
  .../Universal/DisplayEngineDxe/FormDisplay.c|   3 ++-
  .../Universal/DisplayEngineDxe/FormDisplayStr.uni   | Bin 17032 - 17056 
 bytes

What about making 2 patches? The first patch can convert
FormDisplayStr.uni to UTF-8 without changing the text, and then this
patch can be the second patch. Then we will be able to see the diff in
the FormDisplayStr.uni file.

-Jordan

  2 files changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c 
 b/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
 index ae3038b..aba149f 100644
 --- a/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
 +++ b/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
 @@ -2257,11 +2257,12 @@ FxConfirmPopup (
StrCatS (CfmStr, MaxLen, gConfirmMsgEnd);
  
do {
  CreateDialog (Key, gEmptyString, CfmStr, gConfirmOpt, gEmptyString, 
 NULL);
} while (((Key.UnicodeChar | UPPER_LOWER_CASE_OFFSET) != 
 (gConfirmOptYes[0] | UPPER_LOWER_CASE_OFFSET)) 
 -   ((Key.UnicodeChar | UPPER_LOWER_CASE_OFFSET) != (gConfirmOptNo[0] 
 | UPPER_LOWER_CASE_OFFSET)));
 +   ((Key.UnicodeChar | UPPER_LOWER_CASE_OFFSET) != (gConfirmOptNo[0] 
 | UPPER_LOWER_CASE_OFFSET)) 
 +   (Key.ScanCode != SCAN_ESC));
  
if ((Key.UnicodeChar | UPPER_LOWER_CASE_OFFSET) == (gConfirmOptYes[0] | 
 UPPER_LOWER_CASE_OFFSET)) {
  RetVal = TRUE;
} else {
  RetVal = FALSE;
 diff --git a/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplayStr.uni 
 b/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplayStr.uni
 index 
 5c6ad48433b2c6f50016dc27a5801da90930e76f..ff94518b06d3294c3f581d9d18a19c28d8399730
  100644
 GIT binary patch
 delta 38
 lcmeBZWn9q8xZ#2+r#^!^gDXQYgY)FGriT%{An#7xdGnb3o-xz
 
 delta 26
 hcmZ3`%GlA$xZ#57U6JZfLLbo33I*8pUlA0|2L}3}OHP
 
 -- 
 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] TianoCore Subversion down?

2015-07-24 Thread Jordan Justen

On 2015-07-19 09:56:11, Jordan Justen wrote:
 On 2015-07-19 04:08:50, Laszlo Ersek wrote:
  On 07/19/15 12:01, Ard Biesheuvel wrote:
   
   I'd suggest that we just promote the GitHub repository to primary
   repository, and deprecate the public SVN right away.
 
 I don't think this would be a good idea, unless something even worse
 happens, like sourceforge determined that they can't restore svn. I
 suppose that would really force the issue, but otherwise, I think it'd
 be better to continue with a pre-planned transition.

Unfortunately, it looks like they are going to manage to get svn back
up and running. ;)

http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-724/

Latest news: 

  SourceForge Allura Subversion (SVN) service – offline, filesystem
  checks complete, data restoration has completed 22 letters (4
  remain). This is our current restore priority. We project restore of
  data to complete by 7/25, to be followed by data validation and
  restore of service. ETA to follow once I/O performance calculated
  during data validation.



I guess this means = July 25.

Here's the current set of patches from

https://github.com/tianocore/edk2-svn-offline master

which I intend to commit to svn after it returns:

610c371 OvmfPkg: AcpiS3SaveDxe: prepare for End-of-Dxe callback
ebe285a OvmfPkg: AcpiS3SaveDxe: call S3Ready() at End-of-Dxe
dde6fee OvmfPkg: PlatformBdsLib: signal End-of-Dxe event group
a111424 IntelFrameworkModulePkg/GenericBdsLib: remove AcpiS3-S3Save() call
e65d7a9 OvmfPkg: install DxeSmmReadyToLock in PlatformBdsLib
7daafee OvmfPkg: AcpiS3SaveDxe: drop EFI_ACPI_S3_SAVE_PROTOCOL
7a36354 OvmfPkg: SmbiosPlatformDxe: move IsEntryPointStructureValid() to Xen.c
8cb1e0d OvmfPkg: SmbiosPlatformDxe: restrict current Xen code to IA32/X64
4cba8d2 MdeModulePkg: SmbiosDxe: ARM and AARCH64 are VALID_ARCHITECTURES
298b559 ArmVirtPkg: add QemuFwCfgToPcdDxe
ca4c892 ArmVirtPkg: QemuFwCfgToPcdDxe: set SMBIOS entry point version 
dynamically
729669f ArmVirtPkg/ArmVirtQemu: support SMBIOS
cc7f295 NetworkPkg: Fix bug in IpSecImpl.c caused by missing parentheses
90add4e Maintainers.txt: ARM packages maintainer update
8324914 BaseTools/Common: fix heap overrun in ReadMemoryFileLine ()
95ca863 MdeModulePkg: Remove TransmitReceive() and ActiveChild dependency
0e33841 NetworkPkg: Fix the issue EfiPxeBcDhcp() may return wrong status.
ef23b6f MdeModulePkg: Fix the issue EfiPxeBcDhcp() may return wrong status.
95d8762 ShellPkg: Fix bad TimeZone (TZ) conversion.
58bd17c MdeModulePkg: Correct the parameter order in match2 sample opcode
8d10837 MdeModulePkg: Check the case caused by mismatch
7f9f303 MdeModulePkg VariableDxe: Correct address pointers from AuthVariableLib
3b69e18 SecurityPkg AuthVariableLib: Correct address pointers data
3f6e6dd NetworkPkg: Add old IPv4_DEVICE_PATH and IPv6_DEVICE_PATH support
436f2c1 MdeModulePkg: Add old IPv4_DEVICE_PATH support for new IScsiDxe
dc428f3 BaseTools: Make AutoGen.h array declaration match AutoGen.c definition
2eb8300 ShellPkg: Fix the ASSERT issue in Shell 'for' loop
a931302 Maintainers.txt: Add Daryl's new email address
085a914 IntelFrameworkModulePkg: GenericBdsLib: set Status before use
fcacecd MdeModulePkg: Make boot option description unique

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

Re: [edk2] [Patch] MdeModulePkg: Make boot option description unique

2015-07-24 Thread Jordan Justen

On 2015-07-24 09:37:49, Laszlo Ersek wrote:
 Jordan,
 
 On 07/24/15 06:37, Dong, Eric wrote:
  Reviewed-by:  Eric Dong eric.d...@intel.com
  
  -Original Message-
  From: Ni, Ruiyu 
  Sent: Thursday, July 23, 2015 5:15 PM
  To: edk2-devel@lists.01.org
  Cc: Ni, Ruiyu; Dong, Eric
  Subject: [Patch] MdeModulePkg: Make boot option description unique
  
  When there are multiple network boot options, user will see multiple UEFI 
  Network boot options. It's hard to distinguish them using the description.
  The patch enhances the boot option generation logic to append  2
  / 3/ 4/... number suffix to the non-first network boot options.
  So the 2nd one becomes UEFI Network 2.
  
  Contributed-under: TianoCore Contribution Agreement 1.0
  Signed-off-by: Ruiyu Ni ruiyu...@intel.com
  Cc: Eric Dong eric.d...@intel.com
  ---
   MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 61 
  
   1 file changed, 61 insertions(+)
 
 can you please queue this patch?

Merged onto:

https://github.com/tianocore/edk2-svn-offline master

  
  diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
  b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
  index 2c38aa8..f68c25e 100644
  --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
  +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
  @@ -1869,6 +1869,66 @@ BmMatchPartitionDevicePathNode (  }
   
   /**
  +  Enumerate all boot option descriptions and append  2/ 3/... to 
  + make  unique description.
  +
  +  @param BootOptionsArray of boot options.
  +  @param BootOptionCountCount of boot options.
  +**/
  +VOID
  +BmMakeBootOptionDescriptionUnique (
  +  EFI_BOOT_MANAGER_LOAD_OPTION *BootOptions,
  +  UINTNBootOptionCount
  +  )
  +{
  +  UINTNBase;
  +  UINTNIndex;
  +  UINTNDescriptionSize;
  +  UINTNMaxSuffixSize;
  +  BOOLEAN  *Visited;
  +  UINTNMatchCount;
  +
  +  if (BootOptionCount == 0) {
  +return;
  +  }
  +
  +  //
  +  // Calculate the maximum buffer size for the number suffix.
  +  // The initial sizeof (CHAR16) is for the blank space before the number.
  +  //
  +  MaxSuffixSize = sizeof (CHAR16);
  +  for (Index = BootOptionCount; Index != 0; Index = Index / 10) {
  +MaxSuffixSize += sizeof (CHAR16);
  +  }
  +
  +  Visited = AllocateZeroPool (sizeof (BOOLEAN) * BootOptionCount);  
  + ASSERT (Visited != NULL);
  +
  +  for (Base = 0; Base  BootOptionCount; Base++) {
  +if (!Visited[Base]) {
  +  MatchCount  = 1;
  +  Visited[Base]   = TRUE;
  +  DescriptionSize = StrSize (BootOptions[Base].Description);
  +  for (Index = Base + 1; Index  BootOptionCount; Index++) {
  +if (!Visited[Index]  StrCmp (BootOptions[Base].Description, 
  BootOptions[Index].Description) == 0) {
  +  Visited[Index] = TRUE;
  +  MatchCount++;
  +  FreePool (BootOptions[Index].Description);
  +  BootOptions[Index].Description = AllocatePool (DescriptionSize + 
  MaxSuffixSize);
  +  UnicodeSPrint (
  +BootOptions[Index].Description, DescriptionSize + 
  MaxSuffixSize,
  +L%s %d,
  +BootOptions[Base].Description, MatchCount
  +);
  +}
  +  }
  +}
  +  }
  +
  +  FreePool (Visited);
  +}
  +
  +/**
 Emuerate all possible bootable medias in the following order:
 1. Removable BlockIo- The boot option only points to the 
  removable media
   device, like USB key, DVD, Floppy etc.
  @@ -2054,6 +2114,7 @@ BmEnumerateBootOptions (
   FreePool (Handles);
 }
   
  +  BmMakeBootOptionDescriptionUnique (BootOptions, *BootOptionCount);
 return BootOptions;
   }
   
  --
  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] IntelFrameworkModulePkg: GenericBdsLib: set Status before use

2015-07-24 Thread Jordan Justen

On 2015-07-24 09:39:34, Laszlo Ersek wrote:
 Jordan,
 
 On 07/24/15 14:41, Fan, Jeff wrote:
  Reviewed-by: Jeff Fan jeff@intel.com
  
  -Original Message-
  From: Laszlo Ersek [mailto:ler...@redhat.com] 
  Sent: Friday, July 24, 2015 7:36 AM
  To: edk2-de...@ml01.01.org
  Cc: Yao, Jiewen; Fan, Jeff
  Subject: [PATCH] IntelFrameworkModulePkg: GenericBdsLib: set Status before 
  use
  
  The recent patch titled
  
IntelFrameworkModulePkg/GenericBdsLib: remove AcpiS3-S3Save() call
  
  has exposed a preexistent bug in the BdsLibBootViaBootOption() function, 
  and now the IA32 build of OVMF fails with:
  
In function 'BdsLibBootViaBootOption':
error: 'Status' may be used uninitialized in this function
  
  Namely, we have the following (simplified) data flow:
  
//
// Status and ImageHandle both start out uninitialized
//
  
/* ... */
ImageHandle = BdsExpandUsbShortFormDevicePath (DevicePath);
/* ... */
  
if (ImageHandle == NULL) {
  /* ... */
}
if ((ImageHandle == NULL) || (EFI_ERROR(Status))) {
  /* ... */
*/
  
  If BdsExpandUsbShortFormDevicePath() returns a non-NULL value, then the 
  second if statement will check Status without the function having 
  initialized or assigned it.
  
  When BdsExpandUsbShortFormDevicePath() returns non-NULL, Status should be 
  EFI_SUCCESS; so let us assign it that value up-front.
  
  Note that the bug existed before the patch
  
IntelFrameworkModulePkg/GenericBdsLib: remove AcpiS3-S3Save() call
  
  That is, the bug was not introduced, only exposed, by the patch -- in the 
  pre-patch state, although the Status variable was set early and 
  unconditionally, the error code that it may have carried from the failed 
  gEfiAcpiS3SaveProtocolGuid lookup had nothing to do with the second if
  statement above.
  
  Cc: Jiewen Yao jiewen@intel.com
  Cc: Jeff Fan jeff@intel.com
  Contributed-under: TianoCore Contribution Agreement 1.0
  Signed-off-by: Laszlo Ersek ler...@redhat.com
  ---
  
  Notes:
  This is the rare example when a gcc warning catches an actual bug :)
  
   IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c | 1 +
   1 file changed, 1 insertion(+)
 
 can you please queue this one too?

Merged onto:

https://github.com/tianocore/edk2-svn-offline master

-Jordan

 (If you'd like I can pick up and push these two patches to my private
 repo, like the rest yesterday. If that helps.)
 
 Thanks
 Laszlo
 
  
  diff --git a/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c 
  b/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c
  index 4b7eca7..68b32f3 100644
  --- a/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c
  +++ b/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c
  @@ -2236,6 +2236,7 @@ BdsLibBootViaBootOption (
 LIST_ENTRYTempBootLists;
 EFI_BOOT_LOGO_PROTOCOL*BootLogo;
   
  +  Status= EFI_SUCCESS;
 *ExitDataSize = 0;
 *ExitData = NULL;
   
  --
  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] Temporary git repo - Re: TianoCore Subversion down?

2015-07-23 Thread Jordan Justen

On 2015-07-23 10:04:26, Laszlo Ersek wrote:
 On 07/23/15 02:06, Jordan Justen wrote:
  Okay. Based on Laszlo's request, I setup a temporary git repo to
  collect up the changes that should have been committed to svn the past
  week.
 
  https://github.com/tianocore/edk2-svn-offline
 
  So far, I added the 2 commits that made it to svn but didn't get
  mirrored to the git-svn mirror. Let me know if I should add something
  to the branch.
 
  Here's the git commands to setup a new svn-offline remote:
 
  git remote add svn-offline https://github.com/tianocore/edk2-svn-offline.git
 
 ... This was *hard*.
 
 I reached back to the past on the list (actually, on both lists, old and
 new), to a few days before the SF outage started. (Outage start: 16th, I
 reached back to the 13th or so.)
 
 I collected *all* patches from that timeframe that are now ready for
 merging (and would already have been merged, if not for the SF outage).
 
 In total, that's 27 patches. I verified maintainer and/or key package
 contributor Reviewed-by tags as the criterion for including a patch or a
 series. I also picked up all tags posted as feedback. Sometimes the
 maintainer requested trivial changes but gave his R-b immediately; I
 effected those changes. Finally, I reformatted a few blatantly
 misformatted commit messages, fixed a gcc build error (discussed and
 approved on the list), noted my minimal changes, and then added my S-o-b
 at the bottom of all patches I rounded up.

Thanks Laszlo!

One request, can you change the commit message on:
IntelFrameworkModulePkg/GenericBdsLib: remove AcpiS3-S3Save() call

Cc: Yao, Jiewen jiewen@intel.com

  =

Cc: Yao, Jiewen jiewen@intel.com

  or

Cc: Jiewen Yao jiewen@intel.com

Actually, my personal opinion is that Cc entries can be dropped when
merging upstream, but I don't have a strong feeling on it. Is there an
argument for leaving them?

-Jordan

 You can find the patches in:
 
 https://github.com/lersek/edk2/commits/merge_this_please
 
 They are based on top of your svn-offline/master branch (currently at
 53c8704060e9fb4ba5ec2e92a5e6f188a3237ab0, Daryl has changed positions
 and I am taking over maintaining for now.).
 
 Please *merge* this branch into svn-offline/master -- it will be a
 fast-forward, and no merge commit will be created.
 
 After that, everyone should pull from your svn-offline/master, and
 resume working off that.
 
 Here's a summary of the patches that I picked up, in order. Any
 (trivial) changes I did are marked with --.
 
   [edk2] [PATCH v2 0/6] OvmfPkg: save S3 state at EndOfDxe
   http://thread.gmane.org/gmane.comp.bios.tianocore.devel/17384
   Message-Id: 1436892487-17202-1-git-send-email-ler...@redhat.com
 
   [edk2] [PATCH v2 0/6] ArmVirtPkg/ArmVirtQemu: support SMBIOS
   http://thread.gmane.org/gmane.comp.bios.edk2.devel/144
   Message-Id: 1437477015-31200-1-git-send-email-ler...@redhat.com
 
   [edk2] [PATCH] NetworkPkg: Fix bug in IpSecImpl.c caused by missing 
 parentheses
   http://thread.gmane.org/gmane.comp.bios.edk2.devel/23
   Message-Id: 1437109652-26456-1-git-send-email-br...@cran.org.uk
   -- incorporating trivial changes suggested by Siyuan
 
   [edk2] [PATCH] Maintainers.txt: ARM packages maintainer update
   http://thread.gmane.org/gmane.comp.bios.edk2.devel/52
   Message-Id: 1437148284-16942-1-git-send-email-leif.lindh...@linaro.org
 
   [edk2] [PATCH] BaseTools/Common: fix heap overrun in ReadMemoryFileLine ()
   http://thread.gmane.org/gmane.comp.bios.edk2.devel/56
   Message-Id: 1437157378-31683-1-git-send-email-ard.biesheu...@linaro.org
 
   [edk2] [PATCH v2] MdeModulePkg: Remove TransmitReceive() and ActiveChild 
 dependency
   http://thread.gmane.org/gmane.comp.bios.tianocore.devel/17417/focus=94
   Message-Id: 1437359434-11592-1-git-send-email-jiaxin...@intel.com
 
   [edk2] [patch] NetworkPkg: Fix the issue EfiPxeBcDhcp()may return wrong 
 status.
   http://thread.gmane.org/gmane.comp.bios.edk2.devel/102
   Message-Id: 6c40a76c-8fd3-454d-87c1-809b086afb94@LUBOZHAN-MOBL.local
   -- updated copyright year as Siyuan asked
 
   [edk2] [patch] MdeModulePkg: Fix the issue EfiPxeBcDhcp()may return wrong 
 status.
   http://thread.gmane.org/gmane.comp.bios.edk2.devel/101
   Message-Id: b1f41f78-e42a-46e8-8a10-af9f095f542a@LUBOZHAN-MOBL.local
   -- updated copyright year as Siyuan asked
 
   [edk2] [Patch] ShellPkg: Fix bad TimeZone (TZ) conversion.
   http://thread.gmane.org/gmane.comp.bios.edk2.devel/57
   Message-Id: 0755eef5-682f-454e-a24f-2cc7ca040...@apple.com
   -- synthetized Jaben's R-b from his response in the thread
 
   [edk2] [patch] MdeModulePkg:Correct the parameter order in match2 sample 
 opcode
   http://thread.gmane.org/gmane.comp.bios.edk2.devel/118
   Message-Id: 1437383587-10968-1-git-send-email-dandan...@intel.com
 
   [edk2] [patch] MdeModulePkg:Check the case caused by mismatch
   http://thread.gmane.org/gmane.comp.bios.edk2.devel/127
   Message-Id: 1437446204-10520-1-git-send-email-dandan...@intel.com

Re: [edk2] Temporary git repo - Re: TianoCore Subversion down?

2015-07-23 Thread Jordan Justen

I queued up the patches you collected:

https://github.com/tianocore/edk2-svn-offline/commits/master

Thanks again for collecting them up!

-Jordan

On 2015-07-23 10:50:14, Laszlo Ersek wrote:
 On 07/23/15 19:31, Jordan Justen wrote:
  On 2015-07-23 10:04:26, Laszlo Ersek wrote:
  On 07/23/15 02:06, Jordan Justen wrote:
  Okay. Based on Laszlo's request, I setup a temporary git repo to
  collect up the changes that should have been committed to svn the past
  week.
 
  https://github.com/tianocore/edk2-svn-offline
 
  So far, I added the 2 commits that made it to svn but didn't get
  mirrored to the git-svn mirror. Let me know if I should add something
  to the branch.
 
  Here's the git commands to setup a new svn-offline remote:
 
  git remote add svn-offline 
  https://github.com/tianocore/edk2-svn-offline.git
 
  ... This was *hard*.
 
  I reached back to the past on the list (actually, on both lists, old and
  new), to a few days before the SF outage started. (Outage start: 16th, I
  reached back to the 13th or so.)
 
  I collected *all* patches from that timeframe that are now ready for
  merging (and would already have been merged, if not for the SF outage).
 
  In total, that's 27 patches. I verified maintainer and/or key package
  contributor Reviewed-by tags as the criterion for including a patch or a
  series. I also picked up all tags posted as feedback. Sometimes the
  maintainer requested trivial changes but gave his R-b immediately; I
  effected those changes. Finally, I reformatted a few blatantly
  misformatted commit messages, fixed a gcc build error (discussed and
  approved on the list), noted my minimal changes, and then added my S-o-b
  at the bottom of all patches I rounded up.
  
  Thanks Laszlo!
  
  One request, can you change the commit message on:
  IntelFrameworkModulePkg/GenericBdsLib: remove AcpiS3-S3Save() call
  
  Cc: Yao, Jiewen jiewen@intel.com
  
=
  
  Cc: Yao, Jiewen jiewen@intel.com
  
or
  
  Cc: Jiewen Yao jiewen@intel.com
  
 
 Aaargh. You noted this earlier, and I fixed it up, actually -- in
 another branch that I did not end up posting, after all. If you recall,
 there was a short interval when this specific patch appeared to be
 rejected, so I prepared a v3 locally, dropping this patch, and slightly
 updating the commit messages of those coming after it. (No other
 changes.) And, I fixed the above Cc on that v3, local branch.
 
 Now, after Jeff discussed the question with Jiewen, Jeff agreed that
 this patch was okay ultimately. So I returned to v2, picked up the tags
 again from the list -- and forgot to redo the CC fix.
 
 In any case, I corrected it now, and force-pushed the rebased branch
 (with no other changes) to the same location. Its head changed from
 dfa837e to 2eb8300. Please re-fetch it.
 
  Actually, my personal opinion is that Cc entries can be dropped when
  merging upstream, but I don't have a strong feeling on it. Is there an
  argument for leaving them?
 
 Yes, I quite like them. It's nice to see who was originally on CC. Also,
 removing them is too much work. :)
 
 And, in the Linux kernel at least, when a patch is cherry-picked to a
 stable branch (or tree), the original participants (author, reviewers,
 Cc's etc) get fresh emails about that fact. That's also nice.
 
 Thanks!
 Laszlo
 
  
  -Jordan
  
  You can find the patches in:
 
  https://github.com/lersek/edk2/commits/merge_this_please
 
  They are based on top of your svn-offline/master branch (currently at
  53c8704060e9fb4ba5ec2e92a5e6f188a3237ab0, Daryl has changed positions
  and I am taking over maintaining for now.).
 
  Please *merge* this branch into svn-offline/master -- it will be a
  fast-forward, and no merge commit will be created.
 
  After that, everyone should pull from your svn-offline/master, and
  resume working off that.
 
  Here's a summary of the patches that I picked up, in order. Any
  (trivial) changes I did are marked with --.
 
[edk2] [PATCH v2 0/6] OvmfPkg: save S3 state at EndOfDxe
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/17384
Message-Id: 1436892487-17202-1-git-send-email-ler...@redhat.com
 
[edk2] [PATCH v2 0/6] ArmVirtPkg/ArmVirtQemu: support SMBIOS
http://thread.gmane.org/gmane.comp.bios.edk2.devel/144
Message-Id: 1437477015-31200-1-git-send-email-ler...@redhat.com
 
[edk2] [PATCH] NetworkPkg: Fix bug in IpSecImpl.c caused by missing 
  parentheses
http://thread.gmane.org/gmane.comp.bios.edk2.devel/23
Message-Id: 1437109652-26456-1-git-send-email-br...@cran.org.uk
-- incorporating trivial changes suggested by Siyuan
 
[edk2] [PATCH] Maintainers.txt: ARM packages maintainer update
http://thread.gmane.org/gmane.comp.bios.edk2.devel/52
Message-Id: 1437148284-16942-1-git-send-email-leif.lindh...@linaro.org
 
[edk2] [PATCH] BaseTools/Common: fix heap overrun in ReadMemoryFileLine 
  ()
http://thread.gmane.org/gmane.comp.bios.edk2.devel/56
Message-Id

Re: [edk2] [PATCH] StdLib: Do not define memcpy for AARCH64 builds

2015-07-24 Thread Jordan Justen

On 2015-07-24 16:15:57, Daryl McDaniel wrote:
 Reviewed by: Daryl McDaniel edk2-li...@mc2research.org

I added Daryl's Reviewed-by and added the patch to the svn-offline
branch:

https://github.com/tianocore/edk2-svn-offline master

-Jordan

 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Scott
 Duplichan
 Sent: Thursday, July 23, 2015 1:19 PM
 To: edk2-devel@lists.01.org
 Cc: 'Daryl Mcdaniel' daryl.mcdan...@intel.com
 Subject: [edk2] [PATCH] StdLib: Do not define memcpy for AARCH64 builds
 
 For AARCH64, do not define a memcpy function in stdlib because it is
 already defined in CompilerIntrinsicsLib.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Scott Duplichan sc...@notabs.org
 ---
 
 StdLib/LibC/String/Copying.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/StdLib/LibC/String/Copying.c b/StdLib/LibC/String/Copying.c
 index e27519e..96be24b 100644
 --- a/StdLib/LibC/String/Copying.c
 +++ b/StdLib/LibC/String/Copying.c
 @@ -19,12 +19,12 @@
  #include  stdlib.h
  #include  string.h
  
 -/** Do not define memcpy for IPF+GCC or ARM+GCC builds.
 +/** Do not define memcpy for IPF+GCC or ARM/AARCH64+GCC builds.
  For IPF, using a GCC compiler, the memcpy function is converted to
  CopyMem by objcpy during build.
 -For ARM, the memcpy function is provided by the CompilerIntrinsics
 library.
 +For ARM/AARCH64, the memcpy function is provided by the
 CompilerIntrinsics library.
  **/
 -#if !((defined(MDE_CPU_IPF) || defined(MDE_CPU_ARM))  defined(__GNUC__))
 +#if !((defined(MDE_CPU_IPF) || defined(MDE_CPU_ARM) ||
 defined(MDE_CPU_AARCH64))  defined(__GNUC__))
  /** The memcpy function copies n characters from the object pointed to by
 s2
  into the object pointed to by s1.
 
 
 ___
 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]: CorebootPayloadPkg: Remove data alignment restriction to support GCC49

2015-07-17 Thread Jordan Justen

On 2015-07-17 21:23:16, Scott Duplichan wrote:
 Gcc 4.9 produces data alignments of up to 64 bytes. Previous gcc
 versions align data at up to 32 bytes. With GCC49, this difference
 causes CorebootPayloadPkg to hang after PeCoffLoaderLoadImage() sets
 ImageError to IMAGE_ERROR_INVALID_SECTION_ALIGNMENT and returns an
 error. This change removes the restriction. Testing with
 __attribute__((aligned ())) passes for data alignments of up to 256
 bytes.

I think I prefer Ray's commit message in r17902.

Nevertheless, Reviewed-by: Jordan Justen jordan.l.jus...@intel.com

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Scott Duplichan sc...@notabs.org

Consider Cc'ing Maurice and Prince (and others) here in the commit
message. (Just a tip to make your life easier in the future.)

-Jordan

 ---
 
  CorebootPayloadPkg/CorebootPayloadPkg.fdf | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/CorebootPayloadPkg/CorebootPayloadPkg.fdf 
 b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
 index 810dcb1..198c150 100644
 --- a/CorebootPayloadPkg/CorebootPayloadPkg.fdf
 +++ b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
 @@ -189,12 +189,12 @@ INF CorebootPayloadPkg/FbGop/FbGop.inf
  
  [Rule.Common.SEC]
FILE SEC = $(NAMED_GUID) {
 -PE32 PE32   Align=32$(INF_OUTPUT)/$(MODULE_NAME).efi
 +PE32 PE32   Align=Auto  $(INF_OUTPUT)/$(MODULE_NAME).efi
}
  
  [Rule.Common.PEI_CORE]
FILE PEI_CORE = $(NAMED_GUID) {
 -PE32 PE32   Align=32$(INF_OUTPUT)/$(MODULE_NAME).efi
 +PE32 PE32   Align=Auto  $(INF_OUTPUT)/$(MODULE_NAME).efi
  UI   STRING =$(MODULE_NAME) Optional
  VERSION  STRING =$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 @@ -202,7 +202,7 @@ INF CorebootPayloadPkg/FbGop/FbGop.inf
  [Rule.Common.PEIM]
FILE PEIM = $(NAMED_GUID) {
   PEI_DEPEX PEI_DEPEX Optional$(INF_OUTPUT)/$(MODULE_NAME).depex
 - PE32  PE32   Align=32   $(INF_OUTPUT)/$(MODULE_NAME).efi
 + PE32  PE32   Align=Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
   UI   STRING=$(MODULE_NAME) Optional
   VERSION  STRING=$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Boot fail with gcc 4.9

2015-07-17 Thread Jordan Justen

There are recent related BaseTools commits:

edd7249/r18016 BaseTools: Fixed incorrect alignment bug.

0c5645e/r17728 BaseTools: Update GenFw to support 4K alignment.
f384efd/r17727 BaseTools: Updated tool_def to support 4K alignment.

These were make for 4k alignment support, but maybe they could have
helped, or caused the breakage you are seeing? What BaseTools are you
using? If you are building BaseTools executables, then do you need to
rebuild?

-Jordan

On 2015-07-17 13:36:44, Scott Duplichan wrote:
 I am seeing a boot hang after building CorebootPayloadPkg using gcc 4.9.
 Gcc 4.8 and gcc5 don't have this problem. The hang is because of a sanity
 check in BasePeCoff.c:
 
   //
   // Make sure the allocated space has the proper section alignment
   //
   if (!(ImageContext-IsTeImage)) {
 if ((ImageContext-ImageAddress  (CheckContext.SectionAlignment - 1)) != 
 0) {
   ImageContext-ImageError = IMAGE_ERROR_INVALID_SECTION_ALIGNMENT;
   return RETURN_INVALID_PARAMETER;
 }
 
 The reason gcc 4.9 triggers the problem and 4.8 doesn't is because gcc 4.9
 generates some '.align 64' statements in the asm code it generates. Gcc 4.8
 uses a maximum of '.align 32' as far as I can find.
 
 Jordan noticed this last year:
 https://gcc.gnu.org/ml/gcc-help/2014-07/msg00075.html
 
 Jordan added a linker script change for gcc 4.9 to avoid a related problem
 where the build fails with:
GenFw: ERROR 3000: Invalid, Unsupported section alignment.
 The new problem that I am seeing is a boot time problem. It is caused by
 the alignment of the images that are placed into the .FD file that loads
 into memory. This alignment can be traced to the genfw tool. The image is
 written to the FD file by the GenFvInternalLib.c AddFile function. If has
 an AddPadFile function for meeting FvAlignment, but FvAlignment does not
 apply to the .FD itself. From what I can see, there is no alignment control
 for the images in the FD file. It just happens to work most of the time.
 
 It turns out this problem is not really new to gcc 4.9. If you force data
 alignment to a value above 32, then older gcc compilers and even Microsoft
 compilers trigger the problem. For gcc 4.8, adding this to a function will
 trigger the problem:
 
 static int foo __attribute__((aligned (64)));
 
 For Microsoft compilers,
 
 static int __declspec(align(64)) foo;
 
 (to build the Microsoft test case, change dlink_flag /ALIGN:32 to /ALIGN:64)
 
 Has anyone else encountered this problem?
 
 Thanks,
 Scott
 
 
 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

2015-10-26 Thread Jordan Justen

47-50 Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>

But, I think only 49/52: "OvmfPkg: consolidate variable driver stack
in DSC and FDF files" should be committed now.

I think the others should wait for the rest of the SMM pieces to fall
in place. (Maybe... I guess we can discuss this.)

-Jordan

On 2015-10-14 15:26:46, Laszlo Ersek wrote:
> 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 <ler...@redhat.com>
> ---
> 
> Notes:
> v2:
> - hook VarCheckUefiLib into VariableSmm
>   
> <http://news.gmane.org/find-root.php?message_id=55dfc960.6070...@intel.com>
> 
>  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

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

2015-10-26 Thread Jordan Justen

On 2015-10-25 19:53:23, Paolo Bonzini wrote:
> On 23/10/2015 17:29, Laszlo Ersek wrote:
> > I plan to drop this patch, dependent on testing, and on how a new QEMU
> > patch I've written will be received on qemu-devel.
> 
> I'm not sure why it can't be fixed within the firmware.  Your patch
> to QEMU to use current_cpu obviously makes sense (that's why it
> has been merged already :)), but otherwise the firmware should
> adjust to the hardware, not the other way round.

In general I agree with that. But QEMU, at least loosely, attempts to
emulate actual hardware. A discrepancy has been noted in that
emulation, so it seems worth discussing whether it could be addressed.

Yes this would change the QEMU emulated "hardware" behavior, but it
still seems like something QEMU could change in pc-q35-2.5 and newer,
while maintaining the older behavior for <= 2.4.

Laszlo's patch did change the hardware behavior, but I guess since it
doesn't impact seabios there is no need to maintain the old behavior
on older q35 machines?

-Jordan

> Perhaps we can use a new sync mode (a new PCD would be neater, but
> you'd have to pass it to BSPHandler and APHandler) to send the
> IPI from SMM.  A simple implementation of the former would be this:
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index dd333a1..1be1a4d 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -377,7 +377,7 @@
>  !endif
>  
>  !if $(SMM_REQUIRE) == TRUE
> -  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
> +  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x02
>gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|1
>  !endif
>  
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 9f1ed34..430f1f4 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -383,7 +383,7 @@
>  
>  [PcdsFixedAtBuild.X64]
>  !if $(SMM_REQUIRE) == TRUE
> -  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
> +  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x02
>gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|2
>  !endif
>  
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index c0cc92b..b052806 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -382,7 +382,7 @@
>  !endif
>  
>  !if $(SMM_REQUIRE) == TRUE
> -  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
> +  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x02
>gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|2
>  !endif
>  
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index b0191cb..7b20e27 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -191,6 +191,29 @@ AllCpusInSmmWithExceptions (
>  }
>  
>  
> +VOID
> +SmmSendSmiToAPs (
> +  VOID
> +  )
> +{
> +  UINTN Index;
> +
> +  ASSERT (mSmmMpSyncData->Counter <= mNumberOfCpus);
> +
> +  if (mSmmMpSyncData->Counter < mNumberOfCpus) {
> +//
> +// Send SMI IPIs to bring outside processors in
> +//
> +for (Index = mMaxNumberOfCpus; Index-- > 0;) {
> +  if (!mSmmMpSyncData->CpuData[Index].Present && 
> gSmmCpuPrivate->ProcessorInfo[Index].ProcessorId != INVALID_APIC_ID) {
> +SendSmiIpi 
> ((UINT32)gSmmCpuPrivate->ProcessorInfo[Index].ProcessorId);
> +  }
> +}
> +  }
> +
> +  return;
> +}
> +
>  /**
>Given timeout constraint, wait for all APs to arrive, and insure when this 
> function returns, no AP will execute normal mode code before
>entering SMM, except SMI disabled APs.
> @@ -344,6 +367,16 @@ BSPHandler (
>//
>gSmmCpuPrivate->SmmCoreEntryContext.CurrentlyExecutingCpu = CpuIndex;
>
> +  //
> +  // Manual AP Sync Mode: SmmControl2DxeTrigger only triggers an SMI
> +  // on the processor that executed it, call all other APs.  Otherwise
> +  // this is the same as Relaxed mode.
> +  //
> +  if (SyncMode == SmmCpuSyncModeManualAp) {
> +SmmSendSmiToAPs();
> +  }
> +
>//
>// If Traditional Sync Mode or need to configure MTRRs: gather all 
> available APs.
>//
> @@ -450,12 +482,11 @@ BSPHandler (
>ClearSmi();
>  
>//
> -  // If Relaxed-AP Sync Mode: gather all available APs after BSP SMM 
> handlers are done, and
> -  // make those APs to exit SMI synchronously. APs which arrive later will 
> be excluded and 
> +  // If Relaxed-AP or Manual-AP Sync Mode: gather all available APs after 
> BSP SMM handlers
> +  // are done, and make those APs to exit SMI synchronously. APs which 
> arrive later will be
>// will run through freely.
>//
>if (SyncMode != SmmCpuSyncModeTradition && 
> !SmmCpuFeaturesNeedConfigureMtrrs()) {
> -
>  //
>  // Lock the counter down and retrieve the number of APs
>  //
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> index 71f9b1b..a631811 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> @@

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

2015-10-29 Thread Jordan Justen

On 2015-10-29 04:45:37, Laszlo Ersek wrote:
> On 10/29/15 02:32, Jordan Justen wrote:
> > +ASSERT (MaxProcessors > 0);
> > +PcdSet32 (PcdCpuMaxLogicalProcessorNumber, MaxProcessors);
> 
> I think that when this branch is active, then
> PcdCpuApInitTimeOutInMicroSeconds should *also* be set, namely to
> MAX_UINT32 (~71 minutes, the closest we can get to "infinity"). When
> this hint is available from QEMU, then we should practically disable the
> timeout option in CpuDxe's AP counting.

I think this is a good idea, but I don't think 71 minutes is useful.
Perhaps 30 seconds? This seems more than adequate for hundreds of
processors to startup. Or perhaps some timeout based on the number of
processors?

Janusz and I were discussing
https://github.com/tianocore/edk2/issues/21 on irc. We increased the
timeout to 10 seconds, and with only 8 processors it was still timing
out.

Obviously we are somehow failing to start the processors correctly, or
QEMU/KVM is doing something wrong.

Have you been able to reproduce this issue? It seems like we need to
set the timeout to 71 minutes, and then debug QEMU/KVM to see what
state the APs are in...

Unfortunately I haven't yet been able to reproduce the bug on my
system. :(

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

[edk2] [PATCH 2/6] UefiCpuPkg/CpuDxe: Ignore extra APs in the system

2015-10-28 Thread Jordan Justen

The PcdCpuMaxLogicalProcessorNumber specifies the maximum number of
logical processors which are expected to be seen by the system. If
more APs actually are available in the system, we should prevent them
from being used.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Jeff Fan <jeff@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
---
 UefiCpuPkg/CpuDxe/CpuMp.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
index 98fdfdf..e80835f 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -1196,6 +1196,17 @@ WhoAmI (
 }
   }
 
+  if (Index >= mMpSystemData.NumberOfProcessors) {
+//
+// This is not a valid error for the WhoAmI function, but it should never
+// happen from outside the driver. It could only happen if more APs
+// started than the PcdCpuMaxLogicalProcessorNumber was set to. This call
+// would come from ApEntryPointInC, and we use this error to prevent the
+// AP from being used by MP services.
+//
+return EFI_DEVICE_ERROR;
+  }
+
   *ProcessorNumber = Index;
   return EFI_SUCCESS;
 }
@@ -1446,10 +1457,15 @@ ApEntryPointInC (
   VOID
   )
 {
+  EFI_STATUS  Status;
   VOID*   TopOfApStack;
   UINTN   ProcessorNumber;
 
   if (!mAPsAlreadyInitFinished) {
+if (mMpSystemData.NumberOfProcessors >= gMaxLogicalProcessorNumber) {
+  return;
+}
+
 FillInProcessorInformation (FALSE, mMpSystemData.NumberOfProcessors);
 TopOfApStack  = (UINT8*)mApStackStart + gApStackSize;
 mApStackStart = TopOfApStack;
@@ -1461,7 +1477,11 @@ ApEntryPointInC (
 mMpSystemData.NumberOfProcessors++;
 mMpSystemData.NumberOfEnabledProcessors++;
   } else {
-WhoAmI (, );
+Status = WhoAmI (, );
+if (EFI_ERROR (Status)) {
+  return;
+}
+
 //
 // Get the original stack address.
 //
-- 
2.5.1

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

[edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

2015-10-28 Thread Jordan Justen

By setting this PCD, we allow the CpuDxe driver to proceed earlier
after all of the processors have started.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Jeff Fan <jeff@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
---
 OvmfPkg/OvmfPkgIa32.dsc |  2 ++
 OvmfPkg/OvmfPkgIa32X64.dsc  |  2 ++
 OvmfPkg/OvmfPkgX64.dsc  |  2 ++
 OvmfPkg/PlatformPei/Platform.c  | 17 +
 OvmfPkg/PlatformPei/PlatformPei.inf |  1 +
 5 files changed, 24 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 77fd21c..43b02ae 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -379,6 +379,8 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE
 
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber|64
+
 

 #
 # Components Section - list of all EDK II Modules needed by this Platform.
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 47cc311..f6360a6 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -385,6 +385,8 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE
 
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber|64
+
 

 #
 # Components Section - list of all EDK II Modules needed by this Platform.
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 44b9c79..e851df9 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -384,6 +384,8 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE
 
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber|64
+
 

 #
 # Components Section - list of all EDK II Modules needed by this Platform.
diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index a6d9616..f465f44 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -306,6 +306,21 @@ NoexecDxeInitialization (
 }
 
 VOID
+UpdateMaxNumberOfProcessors (
+  VOID
+  )
+{
+  UINT32 MaxProcessors;
+
+  if (QemuFwCfgIsAvailable ()) {
+QemuFwCfgSelectItem (QemuFwCfgItemSmpCpuCount);
+MaxProcessors = (UINT32) QemuFwCfgRead16 ();
+ASSERT (MaxProcessors > 0);
+PcdSet32 (PcdCpuMaxLogicalProcessorNumber, MaxProcessors);
+  }
+}
+
+VOID
 MiscInitialization (
   VOID
   )
@@ -327,6 +342,8 @@ MiscInitialization (
   //
   BuildCpuHob (mPhysMemAddressWidth, 16);
 
+  UpdateMaxNumberOfProcessors ();
+
   //
   // Determine platform type and save Host Bridge DID to PCD
   //
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index c2c7da9..da23141 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -86,6 +86,7 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable
   gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
 
 [Ppis]
   gEfiPeiMasterBootModePpiGuid
-- 
2.5.1

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

[edk2] [PATCH 5/6] UefiCpuPkg: Allow PcdCpuMaxLogicalProcessorNumber to be dynamic

2015-10-28 Thread Jordan Justen

Move from [PcdsFixedAtBuild, PcdsPatchableInModule] to
[PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx].

This will allow a platform to set this PCD dynamically if it knows how
many logical processors the system has. The CpuDxe driver can then use
this information during multiprocessor initialization to know that all
of the application processors have started.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Jeff Fan <jeff@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
---
 UefiCpuPkg/UefiCpuPkg.dec | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index e783a7b..e16780e 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -128,10 +128,6 @@
   # @Prompt Configure delay value after send an INIT IPI
   
gUefiCpuPkgTokenSpaceGuid.PcdCpuInitIpiDelayInMicroSeconds|1|UINT32|0x3002
 
-  ## Specifies max supported number of Logical Processors.
-  # @Prompt Configure max supported number of Logical Processors
-  
gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber|64|UINT32|0x0002
-
   ## This value specifies the Application Processor (AP) stack size, used for 
Mp Service, which must
   ## aligns the address on a 4-KByte boundary.
   # @Prompt Configure stack size for Application Processor (AP)
@@ -178,6 +174,10 @@
   # @Prompt Microcode Region size.
   
gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchRegionSize|0x0|UINT64|0x0006
 
+  ## Specifies max supported number of Logical Processors.
+  # @Prompt Configure max supported number of Logical Processors
+  
gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber|64|UINT32|0x0002
+
 [PcdsDynamic, PcdsDynamicEx]
   ## Contains the pointer to a CPU S3 data buffer of structure ACPI_CPU_DATA.
   # @Prompt The pointer to a CPU S3 data buffer.
-- 
2.5.1

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

[edk2] [PATCH 0/6] UefiCpuPkg/CpuDxe MP Startup Fixes / Optimizations

2015-10-28 Thread Jordan Justen

web: https://github.com/jljusten/edk2/tree/mp-startup-early-exit

git: https://github.com/jljusten/edk2.git mp-startup-early-exit

Patches 1 & 2 are fixes to the CpuDxe MP support.

Patches 3 & 4 allow the MP support initialization to proceed ealier if
the maximum number of APs have been started.

Patches 5 & 6 allow OVMF to dynamically set the
PcdCpuMaxLogicalProcessorNumber so CpuDxe's MP initialization can
complete as soon as all processors have started.

Jordan Justen (6):
  UefiCpuPkg/CpuDxe: Don't use gBS->Stall
  UefiCpuPkg/CpuDxe: Ignore extra APs in the system
  UefiCpuPkg/CpuDxe: Move AP startup delay out of StartupApsStackless
  UefiCpuPkg/CpuDxe: Allow BSP to continue once max APs are awake
  UefiCpuPkg: Allow PcdCpuMaxLogicalProcessorNumber to be dynamic
  OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU
fw_cfg

 OvmfPkg/OvmfPkgIa32.dsc |  2 ++
 OvmfPkg/OvmfPkgIa32X64.dsc  |  2 ++
 OvmfPkg/OvmfPkgX64.dsc  |  2 ++
 OvmfPkg/PlatformPei/Platform.c  | 17 ++
 OvmfPkg/PlatformPei/PlatformPei.inf |  1 +
 UefiCpuPkg/CpuDxe/ApStartup.c   |  4 
 UefiCpuPkg/CpuDxe/CpuMp.c   | 44 -
 UefiCpuPkg/CpuDxe/CpuMp.h   |  2 +-
 UefiCpuPkg/UefiCpuPkg.dec   |  8 +++
 9 files changed, 68 insertions(+), 14 deletions(-)

-- 
2.5.1

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

[edk2] [PATCH 1/6] UefiCpuPkg/CpuDxe: Don't use gBS->Stall

2015-10-28 Thread Jordan Justen

The CpuDxe driver may run before the gEfiMetronomeArchProtocolGuid
protocol is installed. gBS->Stall does not work until this arch
protocol is installed.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Jeff Fan <jeff@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
---
 UefiCpuPkg/CpuDxe/CpuMp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
index 04c2f1f..98fdfdf 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -801,7 +801,7 @@ StartupAllAPs (
   goto Done;
 }
 
-gBS->Stall (gPollInterval);
+MicroSecondDelay (gPollInterval);
 mMpSystemData.Timeout -= gPollInterval;
   }
 
@@ -987,7 +987,7 @@ StartupThisAP (
   return EFI_TIMEOUT;
 }
 
-gBS->Stall (gPollInterval);
+MicroSecondDelay (gPollInterval);
 CpuData->Timeout -= gPollInterval;
   }
 
@@ -1755,7 +1755,7 @@ InitializeMpSupport (
 if (CheckAllAPsSleeping ()) {
   break;
 }
-gBS->Stall (gPollInterval);
+MicroSecondDelay (gPollInterval);
 Timeout += gPollInterval;
   } while (Timeout <= PcdGet32 (PcdCpuApInitTimeOutInMicroSeconds));
   ASSERT (Timeout <= PcdGet32 (PcdCpuApInitTimeOutInMicroSeconds));
-- 
2.5.1

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

[edk2] [PATCH 4/6] UefiCpuPkg/CpuDxe: Allow BSP to continue once max APs are awake

2015-10-28 Thread Jordan Justen

Since the CpuDxe has a fixed maximum number of APs that are controlled
with PcdCpuMaxLogicalProcessorNumber, if the maximum number of APs are
awake, then the BSP should be able to continue.

Since the APs may be updating the mMpSystemData.NumberOfProcessors
during this early init phase, we use SynchronizationLib to update this
variable on the AP and to read it on the BSP.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Jeff Fan <jeff@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
---
 UefiCpuPkg/CpuDxe/CpuMp.c | 15 ---
 UefiCpuPkg/CpuDxe/CpuMp.h |  2 +-
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
index 6a22b9d..1094292 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -1474,7 +1474,7 @@ ApEntryPointInC (
 // Store the Stack address, when reset the AP, We can found the original 
address.
 //
 mMpSystemData.CpuDatas[mMpSystemData.NumberOfProcessors].TopOfStack = 
TopOfApStack;
-mMpSystemData.NumberOfProcessors++;
+InterlockedIncrement ();
 mMpSystemData.NumberOfEnabledProcessors++;
   } else {
 Status = WhoAmI (, );
@@ -1749,9 +1749,18 @@ InitializeMpSupport (
 StartApsStackless ();
 
 //
-// Wait for APs to arrive at the ApEntryPoint routine
+// Wait for all APs to start
 //
-MicroSecondDelay (PcdGet32 (PcdCpuApInitTimeOutInMicroSeconds));
+Timeout = 0;
+do {
+  if (InterlockedCompareExchange32 (
+, 0, 0) >=
+  gMaxLogicalProcessorNumber) {
+break;
+  }
+  MicroSecondDelay (gPollInterval);
+  Timeout += gPollInterval;
+} while (Timeout <= PcdGet32 (PcdCpuApInitTimeOutInMicroSeconds));
   }
 
   DEBUG ((DEBUG_INFO, "Detect CPU count: %d\n", 
mMpSystemData.NumberOfProcessors));
diff --git a/UefiCpuPkg/CpuDxe/CpuMp.h b/UefiCpuPkg/CpuDxe/CpuMp.h
index 503f3ae..ab7a7f5 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.h
+++ b/UefiCpuPkg/CpuDxe/CpuMp.h
@@ -114,7 +114,7 @@ typedef struct {
 **/
 typedef struct {
   CPU_DATA_BLOCK  *CpuDatas;
-  UINTN   NumberOfProcessors;
+  UINT32  NumberOfProcessors;
   UINTN   NumberOfEnabledProcessors;
 
   EFI_AP_PROCEDUREProcedure;
-- 
2.5.1

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

Re: [edk2] [PATCH] OvmfPkg: increase MP services startup timeout

2015-10-21 Thread Jordan Justen

On 2015-10-21 14:19:40, Kinney, Michael D wrote:
> Laszlo,
> 
> We have the PCD that specifies the max CPUs.
> 
>   ## Specifies max supported number of Logical Processors.
>   # @Prompt Configure max supported number of Logical Processors
>   
> gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber|64|UINT32|0x0002

It would need to be changed to a dynamic PCD.

In terms of determining the number of logical processors, can't the
cpuid function help? I'm not sure how QEMU handles that though.
(Vaguely I remember something like cpuid only help with a single
core... So, if QEMU presents as multiple cores, then maybe it can't
help.)

We'd need a reliable way to set the PCD before CpuDxe runs.

-Jordan

> We could exit the wait loop as soon as the number of detected CPUs
> matches PcdCpuMaxLogicalProcessorNumber.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch V2 1/5] MdeModulePkg: Add EdkiiPlatformLogo protocol definition.

2015-11-09 Thread Jordan Justen

In the subject, can you change EdkiiPlatformLogo => PlatformLogo?

On 2015-11-08 21:23:40, Ruiyu Ni wrote:
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Feng Tian 
> ---
>  MdeModulePkg/Include/Protocol/PlatformLogo.h | 86 
> 
>  MdeModulePkg/MdeModulePkg.dec|  3 +
>  2 files changed, 89 insertions(+)
>  create mode 100644 MdeModulePkg/Include/Protocol/PlatformLogo.h
> 
> diff --git a/MdeModulePkg/Include/Protocol/PlatformLogo.h 
> b/MdeModulePkg/Include/Protocol/PlatformLogo.h
> new file mode 100644
> index 000..aa8b398
> --- /dev/null
> +++ b/MdeModulePkg/Include/Protocol/PlatformLogo.h
> @@ -0,0 +1,86 @@
> +/** @file
> +  The Platform Logo Protocol defines the interface to get the Platform logo
> +  image with the display attribute.
> +
> +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 that 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 __EDKII_PLATFORM_LOGO__
> +#define __EDKII_PLATFORM_LOGO__

Can you remove EDKII from the various places in the patch? It seems
better as 'platform logo'.

> +
> +//
> +// GUID for EDKII Platform Logo Protocol
> +//
> +#define EDKII_PLATFORM_LOGO_PROTOCOL_GUID \
> +  { 0x9b517978, 0xeba1, 0x44e7, { 0xba, 0x65, 0x7c, 0x2c, 0xd0, 0x8b, 0xf8, 
> 0xe9 } }
> +
> +typedef struct _EDKII_PLATFORM_LOGO_PROTOCOL EDKII_PLATFORM_LOGO_PROTOCOL;
> +
> +typedef enum {
> +  ImageFormatBmp,
> +  ImageFormatJpeg,
> +  ImageFormatTiff,
> +  ImageFormatGif,
> +  ImageFormatUnknown

Can we set ImageFormatUnknown = MAX_INT32? (So, we can add other
formats in the middle.)

> +} IMAGE_FORMAT;
> +
> +typedef enum {
> +  EdkiiPlatformLogoDisplayAttributeLeftTop,
> +  EdkiiPlatformLogoDisplayAttributeCenterTop,
> +  EdkiiPlatformLogoDisplayAttributeRightTop,
> +  EdkiiPlatformLogoDisplayAttributeCenterRight,
> +  EdkiiPlatformLogoDisplayAttributeRightBottom,
> +  EdkiiPlatformLogoDisplayAttributeCenterBottom,
> +  EdkiiPlatformLogoDisplayAttributeLeftBottom,
> +  EdkiiPlatformLogoDisplayAttributeCenterLeft,
> +  EdkiiPlatformLogoDisplayAttributeCenter
> +} EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE;
> +
> +/**
> +
> +  Load a platform logo image and return its data and attributes.
> +
> +  @param This  The pointer to this protocol instance.
> +  @param Instance  The visible image instance is found.
> +  @param FormatThe format of the image. Examples: BMP, JPEG.
> +  @param ImageData The image data for the badge file. Currently only 
> +   supports the .bmp file format. 
> +  @param ImageSize The size of the image returned.
> +  @param Attribute The display attributes of the image returned.
> +  @param CoordinateX   The X coordinate of the image.
> +  @param CoordinateY   The Y coordinate of the image.
> +
> +  @retval EFI_SUCCESS  The image was fetched successfully.
> +  @retval EFI_NOT_FOUNDThe specified image could not be found.
> +
> +**/
> +typedef
> +EFI_STATUS
> +(EFIAPI *EDKII_PLATFORM_LOGO_GET_IMAGE)(
> +  IN EDKII_PLATFORM_LOGO_PROTOCOL  *This,
> +  IN OUT UINT32*Instance,
> + OUT IMAGE_FORMAT  *Format,
> + OUT UINT8 **ImageData,
> + OUT UINTN *ImageSize,
> + OUT EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE *Attribute,
> + OUT UINTN *CoordinateX,
> + OUT UINTN *CoordinateY
> +);
> +
> +
> +struct _EDKII_PLATFORM_LOGO_PROTOCOL {
> +  EDKII_PLATFORM_LOGO_GET_IMAGE GetImage;
> +};
> +
> +
> +extern EFI_GUID gEdkiiPlatformLogoProtocolGuid;
> +
> +#endif
> diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> index 3dfcd6a..08148e3 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -449,6 +449,9 @@
>## Include/Protocol/SmmReadyToBoot.h
>gEdkiiSmmReadyToBootProtocolGuid = { 0x6e057ecf, 0xfa99, 0x4f39, { 0x95, 
> 0xbc, 0x59, 0xf9, 0x92, 0x1d, 0x17, 0xe4 } }
>  
> +  ## Include/Protocol/PlatformLogo.h
> +  gEdkiiPlatformLogoProtocolGuid = { 0x9b517978, 0xeba1, 0x44e7, { 0xba, 
> 0x65, 0x7c, 0x2c, 0xd0, 0x8b, 0xf8, 0xe9 } }
> +
>  #
>  # [Error.gEfiMdeModulePkgTokenSpaceGuid]
>  #   0x8001 | Invalid value provided.
> -- 
> 1.9.5.msysgit.1
> 
> ___
> edk2-devel mailing

Re: [edk2] [Patch V2 2/5] MdeModulePkg: Add ImageDecoderLib to provide image decoding service.

2015-11-09 Thread Jordan Justen

Patches 2-5 Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>

On 2015-11-08 21:23:41, Ruiyu Ni wrote:
> The library itself doesn't provide any image decoding capabilities but
> manages the different image decoders.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Feng Tian <feng.t...@intel.com>
> ---
>  MdeModulePkg/Include/Library/ImageDecoderLib.h |  76 +
>  .../Library/ImageDecoderLib/ImageDecoderLib.c  | 121 
> +
>  .../Library/ImageDecoderLib/ImageDecoderLib.inf|  42 +++
>  MdeModulePkg/MdeModulePkg.dec  |   4 +
>  MdeModulePkg/MdeModulePkg.dsc  |   2 +
>  5 files changed, 245 insertions(+)
>  create mode 100644 MdeModulePkg/Include/Library/ImageDecoderLib.h
>  create mode 100644 MdeModulePkg/Library/ImageDecoderLib/ImageDecoderLib.c
>  create mode 100644 MdeModulePkg/Library/ImageDecoderLib/ImageDecoderLib.inf
> 
> diff --git a/MdeModulePkg/Include/Library/ImageDecoderLib.h 
> b/MdeModulePkg/Include/Library/ImageDecoderLib.h
> new file mode 100644
> index 000..928a094
> --- /dev/null
> +++ b/MdeModulePkg/Include/Library/ImageDecoderLib.h
> @@ -0,0 +1,76 @@
> +/** @file
> +  This library provides image decoding service by managing the different
> +  image decoding libraries.
> +
> +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 that 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 __IMAGE_DECODER_LIB_H__
> +#define __IMAGE_DECODER_LIB_H__
> +#include 
> +
> +typedef
> +EFI_STATUS
> +(EFIAPI *DECODE_IMAGE)(
> +  IN  IMAGE_FORMAT  ImageFormat,
> +  IN  UINT8 *Image,
> +  IN  UINTN ImageSize,
> +  OUT EFI_GRAPHICS_OUTPUT_BLT_PIXEL **GopBlt,
> +  OUT UINTN *GopBltSize,
> +  OUT UINTN *PixelWidth,
> +  OUT UINTN *PixelHeight
> +  );
> +
> +/**
> +  Convert a graphics image to a callee allocated GOP blt buffer.
> +
> +  @param  ImageFormat   Format of the image file.
> +  @param  Image Pointer to image file.
> +  @param  ImageSize Number of bytes in Image.
> +  @param  GopBltBuffer containing GOP version of Image.
> +  @param  GopBltSizeSize of GopBlt in bytes.
> +  @param  PixelWidthWidth of GopBlt/Image in pixels.
> +  @param  PixelHeight   Height of GopBlt/Image in pixels.
> +
> +  @retval EFI_SUCCESS   GopBlt and GopBltSize are returned.
> +  @retval EFI_INVALID_PARAMETER GopBlt or GopBltSize is NULL.
> +  @retval EFI_INVALID_PARAMETER Image is NULL or ImageSize is 0.
> +  @retval EFI_UNSUPPORTED   Image is not supported.
> +  @retval EFI_OUT_OF_RESOURCES  No enough buffer to allocate.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +DecodeImage (
> +  IN  IMAGE_FORMAT  ImageFormat,
> +  IN  UINT8 *Image,
> +  IN  UINTN ImageSize,
> +  OUT EFI_GRAPHICS_OUTPUT_BLT_PIXEL **GopBlt,
> +  OUT UINTN *GopBltSize,
> +  OUT UINTN *PixelWidth,
> +  OUT UINTN *PixelHeight
> +  );
> +
> +/**
> +  Register an image decoder.
> +
> +  @param Decoder  An image decoder.
> +
> +  @retval EFI_SUCCESS  The decoder was successfully registered.
> +  @retval EFI_OUT_OF_RESOURCES No enough resource to register the decoder.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +RegisterImageDecoder (
> +  IN  DECODE_IMAGE Decoder
> +  );
> +
> +#endif
> diff --git a/MdeModulePkg/Library/ImageDecoderLib/ImageDecoderLib.c 
> b/MdeModulePkg/Library/ImageDecoderLib/ImageDecoderLib.c
> new file mode 100644
> index 000..4a6219b
> --- /dev/null
> +++ b/MdeModulePkg/Library/ImageDecoderLib/ImageDecoderLib.c
> @@ -0,0 +1,121 @@
> +/** @file
> +  This library provides image decoding service by managing the different
> +  image decoding libraries.
> +
> +Copyright (c) 2011 - 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 that accompanies this 
> distribution.

Re: [edk2] [Patch V2 1/5] MdeModulePkg: Add EdkiiPlatformLogo protocol definition.

2015-11-09 Thread Jordan Justen

On 2015-11-09 19:22:58, Ni, Ruiyu wrote:
> Sure I will modify the commit message to remove "Edkii".

I had more comments further down on the patch.

-Jordan

> -Original Message-
> From: Justen, Jordan L 
> Sent: Tuesday, November 10, 2015 11:14 AM
> To: Ni, Ruiyu ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Tian, Feng 
> Subject: Re: [edk2] [Patch V2 1/5] MdeModulePkg: Add EdkiiPlatformLogo 
> protocol definition.
> 
> In the subject, can you change EdkiiPlatformLogo => PlatformLogo?
> 
> On 2015-11-08 21:23:40, Ruiyu Ni wrote:
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Ruiyu Ni 
> > Cc: Feng Tian 
> > ---
> >  MdeModulePkg/Include/Protocol/PlatformLogo.h | 86 
> > 
> >  MdeModulePkg/MdeModulePkg.dec|  3 +
> >  2 files changed, 89 insertions(+)
> >  create mode 100644 MdeModulePkg/Include/Protocol/PlatformLogo.h
> > 
> > diff --git a/MdeModulePkg/Include/Protocol/PlatformLogo.h 
> > b/MdeModulePkg/Include/Protocol/PlatformLogo.h
> > new file mode 100644
> > index 000..aa8b398
> > --- /dev/null
> > +++ b/MdeModulePkg/Include/Protocol/PlatformLogo.h
> > @@ -0,0 +1,86 @@
> > +/** @file
> > +  The Platform Logo Protocol defines the interface to get the Platform logo
> > +  image with the display attribute.
> > +
> > +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 that 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 __EDKII_PLATFORM_LOGO__
> > +#define __EDKII_PLATFORM_LOGO__
> 
> Can you remove EDKII from the various places in the patch? It seems
> better as 'platform logo'.
> 
> > +
> > +//
> > +// GUID for EDKII Platform Logo Protocol
> > +//
> > +#define EDKII_PLATFORM_LOGO_PROTOCOL_GUID \
> > +  { 0x9b517978, 0xeba1, 0x44e7, { 0xba, 0x65, 0x7c, 0x2c, 0xd0, 0x8b, 
> > 0xf8, 0xe9 } }
> > +
> > +typedef struct _EDKII_PLATFORM_LOGO_PROTOCOL EDKII_PLATFORM_LOGO_PROTOCOL;
> > +
> > +typedef enum {
> > +  ImageFormatBmp,
> > +  ImageFormatJpeg,
> > +  ImageFormatTiff,
> > +  ImageFormatGif,
> > +  ImageFormatUnknown
> 
> Can we set ImageFormatUnknown = MAX_INT32? (So, we can add other
> formats in the middle.)
> 
> > +} IMAGE_FORMAT;
> > +
> > +typedef enum {
> > +  EdkiiPlatformLogoDisplayAttributeLeftTop,
> > +  EdkiiPlatformLogoDisplayAttributeCenterTop,
> > +  EdkiiPlatformLogoDisplayAttributeRightTop,
> > +  EdkiiPlatformLogoDisplayAttributeCenterRight,
> > +  EdkiiPlatformLogoDisplayAttributeRightBottom,
> > +  EdkiiPlatformLogoDisplayAttributeCenterBottom,
> > +  EdkiiPlatformLogoDisplayAttributeLeftBottom,
> > +  EdkiiPlatformLogoDisplayAttributeCenterLeft,
> > +  EdkiiPlatformLogoDisplayAttributeCenter
> > +} EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE;
> > +
> > +/**
> > +
> > +  Load a platform logo image and return its data and attributes.
> > +
> > +  @param This  The pointer to this protocol instance.
> > +  @param Instance  The visible image instance is found.
> > +  @param FormatThe format of the image. Examples: BMP, JPEG.
> > +  @param ImageData The image data for the badge file. Currently 
> > only 
> > +   supports the .bmp file format. 
> > +  @param ImageSize The size of the image returned.
> > +  @param Attribute The display attributes of the image returned.
> > +  @param CoordinateX   The X coordinate of the image.
> > +  @param CoordinateY   The Y coordinate of the image.
> > +
> > +  @retval EFI_SUCCESS  The image was fetched successfully.
> > +  @retval EFI_NOT_FOUNDThe specified image could not be found.
> > +
> > +**/
> > +typedef
> > +EFI_STATUS
> > +(EFIAPI *EDKII_PLATFORM_LOGO_GET_IMAGE)(
> > +  IN EDKII_PLATFORM_LOGO_PROTOCOL  *This,
> > +  IN OUT UINT32*Instance,
> > + OUT IMAGE_FORMAT  *Format,
> > + OUT UINT8 **ImageData,
> > + OUT UINTN *ImageSize,
> > + OUT EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE *Attribute,
> > + OUT UINTN *CoordinateX,
> > + OUT UINTN *CoordinateY
> > +);
> > +
> > +
> > +struct _EDKII_PLATFORM_LOGO_PROTOCOL {
> > +  EDKII_PLATFORM_LOGO_GET_IMAGE GetImage;
> > +};
> > +
> > +
> > +extern EFI_GUID gEdkiiPlatformLogoProtocolGuid;
> > +
> > +#endif

Re: [edk2] [Patch V2 1/5] MdeModulePkg: Add EdkiiPlatformLogo protocol definition.

2015-11-09 Thread Jordan Justen

On 2015-11-09 22:13:18, Ni, Ruiyu wrote:
> How about define:
> typedef enum {
>   ImageFormatUnknown,
>   ImageFormatBmp,
>   ...
>   ImageFormatGif
> } IMAGE_FORMAT
> ?
> 
> So that extending the image format doesn't have binary compatibility
> issue.

Ok. That works too.

I did have one other question about the names. Do you think they
should be PlatformLogoFormat* rather than ImageFormat*?

My suggestion would have been:

  PlatformLogoFormatUnknown,
  PlatformLogoFormatImageBmp,
  PlatformLogoFormatImageJpeg,
  PlatformLogoFormatImageTiff,
  PlatformLogoFormatImageGif,

Because these look close to the mime-types. image/jpeg, etc...
https://www.iana.org/assignments/media-types/media-types.xhtml#image

I don't have a big concern about this, so I'll leave that decision up
to you.

> Edkii prefix was added to indicate that this protocol is not defined
> by UEFI spec but a EDKII implementation specific one. We had
> EdkiiVariableLock protocol defined in
> MdeModulePkg/Include/Protocol/VariableLock.h. I agree to remove
> Edkii prefix from the commit message, #ifdef macro, but will keep
> the prefix in the protocol name, enum name.

Ok.

Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>

> 
> -Original Message-
> From: Justen, Jordan L 
> Sent: Tuesday, November 10, 2015 11:14 AM
> To: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Tian, Feng <feng.t...@intel.com>
> Subject: Re: [edk2] [Patch V2 1/5] MdeModulePkg: Add EdkiiPlatformLogo 
> protocol definition.
> 
> In the subject, can you change EdkiiPlatformLogo => PlatformLogo?
> 
> On 2015-11-08 21:23:40, Ruiyu Ni wrote:
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> > Cc: Feng Tian <feng.t...@intel.com>
> > ---
> >  MdeModulePkg/Include/Protocol/PlatformLogo.h | 86 
> > 
> >  MdeModulePkg/MdeModulePkg.dec|  3 +
> >  2 files changed, 89 insertions(+)
> >  create mode 100644 MdeModulePkg/Include/Protocol/PlatformLogo.h
> > 
> > diff --git a/MdeModulePkg/Include/Protocol/PlatformLogo.h 
> > b/MdeModulePkg/Include/Protocol/PlatformLogo.h
> > new file mode 100644
> > index 000..aa8b398
> > --- /dev/null
> > +++ b/MdeModulePkg/Include/Protocol/PlatformLogo.h
> > @@ -0,0 +1,86 @@
> > +/** @file
> > +  The Platform Logo Protocol defines the interface to get the Platform logo
> > +  image with the display attribute.
> > +
> > +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 that 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 __EDKII_PLATFORM_LOGO__
> > +#define __EDKII_PLATFORM_LOGO__
> 
> Can you remove EDKII from the various places in the patch? It seems
> better as 'platform logo'.
> 
> > +
> > +//
> > +// GUID for EDKII Platform Logo Protocol
> > +//
> > +#define EDKII_PLATFORM_LOGO_PROTOCOL_GUID \
> > +  { 0x9b517978, 0xeba1, 0x44e7, { 0xba, 0x65, 0x7c, 0x2c, 0xd0, 0x8b, 
> > 0xf8, 0xe9 } }
> > +
> > +typedef struct _EDKII_PLATFORM_LOGO_PROTOCOL EDKII_PLATFORM_LOGO_PROTOCOL;
> > +
> > +typedef enum {
> > +  ImageFormatBmp,
> > +  ImageFormatJpeg,
> > +  ImageFormatTiff,
> > +  ImageFormatGif,
> > +  ImageFormatUnknown
> 
> Can we set ImageFormatUnknown = MAX_INT32? (So, we can add other
> formats in the middle.)
> 
> > +} IMAGE_FORMAT;
> > +
> > +typedef enum {
> > +  EdkiiPlatformLogoDisplayAttributeLeftTop,
> > +  EdkiiPlatformLogoDisplayAttributeCenterTop,
> > +  EdkiiPlatformLogoDisplayAttributeRightTop,
> > +  EdkiiPlatformLogoDisplayAttributeCenterRight,
> > +  EdkiiPlatformLogoDisplayAttributeRightBottom,
> > +  EdkiiPlatformLogoDisplayAttributeCenterBottom,
> > +  EdkiiPlatformLogoDisplayAttributeLeftBottom,
> > +  EdkiiPlatformLogoDisplayAttributeCenterLeft,
> > +  EdkiiPlatformLogoDisplayAttributeCenter
> > +} EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE;
> > +
> > +/**
> > +
> > +  Lo

Re: [edk2] [PATCH v4 02/41] OvmfPkg: Sec: force reinit of BaseExtractGuidedSectionLib handler table

2015-11-11 Thread Jordan Justen

On 2015-11-03 13:00:38, Laszlo Ersek wrote:
> BaseExtractGuidedSectionLib uses a table at the static physical address
> PcdGuidedExtractHandlerTableAddress, and modules that are linked against
> BaseExtractGuidedSectionLib are expected to work together on that table.
> Namely, some modules can register handlers for GUIDed sections, some other
> modules can decode such sections with the pre-registered handlers. The
> table carries persistent information between these modules.
> 
> BaseExtractGuidedSectionLib checks a table signature whenever it is used
> (by whichever module that is linked against it), and at the first use
> (identified by a signature mismatch) it initializes the table.
> 
> One of the module types that BaseExtractGuidedSectionLib can be used with
> is SEC, if the SEC module in question runs with the platform's RAM already
> available.
> 
> In such cases the question emerges whether the initial contents of the RAM
> (ie. contents that predate the very first signature check) can be trusted.
> Normally RAM starts out with all zeroes (leading to a signature mismatch
> on the first check); however a malicious runtime OS can populate the area
> with some payload, then force a warm platform reset or an S3
> suspend-and-resume. In such cases the signature check in the SEC module
> might not fire, and ExtractGuidedSectionDecode() might run code injected
> by the runtime OS, as part of SEC (ie. with high privileges).
> 
> -D SMM_REQUIRE signals that the firmware should be secure against
> tampering from a malicious OS, therefore we clear the handler table in
> SEC, in such builds.
> 
> See also git commit ad43bc6b2e (SVN rev 15433) -- this patch secures the
> (d) and (e) code paths examined in that commit. Furthermore, a
> non-malicious runtime OS will observe no change in behavior; see case (c)
> in said commit.
> 
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <ler...@redhat.com>
> [michael.d.kin...@intel.com: prevent VS20xx loop intrinsic with volatile]
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
> ---
> 
> Notes:
> v3:
> - volatile-qualify the Table pointer to prevent VS20xx from turning the
>   zeroing loop into a compiler intrinsic [Mike]
> 
> v2:
> - This implements option #2 from Jordan's feedback at
>   <http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=1995>.
>   Liming was okay with that option:
>   <http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=2009>.
> 
> - This patch replaces the following patches from the v1 series:
> 
>   [PATCH 03/58] MdePkg: BaseExtractGuidedSectionLib: allow forced reinit
> of handler table
>   <http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=328>
> 
>   [PATCH 04/58] OvmfPkg: set PcdBaseExtractGuidedSectionLibForceInit for
> SEC on SMM_REQUIRE
>   <http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=330>
> 
>  OvmfPkg/Sec/SecMain.inf |  5 
>  OvmfPkg/Sec/SecMain.c   | 28 
>  2 files changed, 33 insertions(+)
> 
> diff --git a/OvmfPkg/Sec/SecMain.inf b/OvmfPkg/Sec/SecMain.inf
> index 2f78f3c..8f4d86c 100644
> --- a/OvmfPkg/Sec/SecMain.inf
> +++ b/OvmfPkg/Sec/SecMain.inf
> @@ -68,3 +68,8 @@ [Pcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
> +  gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
> +  gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
> +
> +[FeaturePcd]
> +  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
> diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
> index 4f87059..1556032 100644
> --- a/OvmfPkg/Sec/SecMain.c
> +++ b/OvmfPkg/Sec/SecMain.c
> @@ -699,8 +699,36 @@ SecCoreStartupWithStack (
>IA32_DESCRIPTOR IdtDescriptor;
>UINT32  Index;
>  
> +  //
> +  // This code may be running on the S3 resume boot path, where RAM has been
> +  // populated by the runtime guest OS. Guarantee the reinitialization of the
> +  // BaseExtractGuidedSectionLib handler table, before the constructor of
> +  // LzmaCustomDecompressLib calls into BaseExtractGuidedSectionLib, due to 
> our
> +  // explicit ProcessLibraryConstructorList() call below.
> +  //
> +  // We must not rely on any libraries before calling
> +  // ProcessLibraryConstructorList()

Re: [edk2] [PATCH v4 15/41] OvmfPkg: resolve ReportStatusCodeLib for DXE_SMM_DRIVER modules

2015-11-11 Thread Jordan Justen

Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>

On 2015-11-03 13:00:51, Laszlo Ersek wrote:
> 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 <ler...@redhat.com>
> ---
>  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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 11/41] OvmfPkg: pull in CpuIo2Smm driver

2015-11-11 Thread Jordan Justen

Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>

On 2015-11-03 13:00:47, Laszlo Ersek wrote:
> 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 <ler...@redhat.com>
> ---
>  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) {
> +SM

Re: [edk2] [PATCH v4 16/41] OvmfPkg: resolve CpuExceptionHandlerLib for DXE_SMM_DRIVER modules

2015-11-11 Thread Jordan Justen

Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>

On 2015-11-03 13:00:52, Laszlo Ersek wrote:
> 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 <ler...@redhat.com>
> ---
> 
> 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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 10/41] OvmfPkg: pull in the SMM IPL and SMM core

2015-11-11 Thread Jordan Justen

Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>

On 2015-11-03 13:00:46, Laszlo Ersek wrote:
> "MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf" (a DXE_RUNTIME_DRIVER)
> implements the SMM Initial Program Loader. It produces
> EFI_SMM_BASE2_PROTOCOL and EFI_SMM_COMMUNICATION_PROTOCOL, relying on:
> - EFI_SMM_ACCESS2_PROTOCOL
>   (provided by OvmfPkg/SmmAccess/SmmAccess2Dxe.inf),
> - EFI_SMM_CONTROL2_PROTOCOL
>   (provided by OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf).
> 
> (The SMM IPL also depends on EFI_SMM_CONFIGURATION_PROTOCOL_GUID, but this
> dependency is not enforced in the entry point. A protocol notify callback
> is registered instead, hence we can delay providing that protocol via the
> PiSmmCpuDxeSmm driver that is (to be) imported from
> Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/.)
> 
> The SMM IPL loads the SMM core into SMRAM and executes it from there.
> Therefore we add the SMM core to the build as well.
> 
> For the SMM core, a number of library classes need to be resolved.
> Furthermore, each FDF file must provide the GenFds.py BaseTools utility
> with a build rule for SMM_CORE; we copy the DXE_CORE's rule.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <ler...@redhat.com>
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 21 
>  OvmfPkg/OvmfPkgIa32X64.dsc | 21 
>  OvmfPkg/OvmfPkgX64.dsc | 21 
>  OvmfPkg/OvmfPkgIa32.fdf|  9 +
>  OvmfPkg/OvmfPkgIa32X64.fdf |  9 +
>  OvmfPkg/OvmfPkgX64.fdf |  9 +
>  6 files changed, 90 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index c71a2f4..ca3be30 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -296,6 +296,17 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
>  [LibraryClasses.common.SMM_CORE]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> +  
> SmmCorePlatformHookLib|MdeModulePkg/Library/SmmCorePlatformHookLibNull/SmmCorePlatformHookLibNull.inf
> +  
> MemoryAllocationLib|MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryAllocationLib.inf
> +  
> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
> +  HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> +  SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
> +  
> SmmServicesTableLib|MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.inf
> +!ifdef $(DEBUG_ON_SERIAL_PORT)
> +  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> +!else
> +  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
> +!endif
>  
>  
> 
>  #
> @@ -676,4 +687,14 @@ [Components]
>  !if $(SMM_REQUIRE) == TRUE
>OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
>OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
> +
> +  #
> +  # SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
> +  #
> +  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
> +
> +  #
> +  # SMM_CORE
> +  #
> +  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
>  !endif
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index a1e8f0d..60f085a 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -301,6 +301,17 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
>  [LibraryClasses.common.SMM_CORE]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> +  
> SmmCorePlatformHookLib|MdeModulePkg/Library/SmmCorePlatformHookLibNull/SmmCorePlatformHookLibNull.inf
> +  
> MemoryAllocationLib|MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryAllocationLib.inf
> +  
> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
> +  HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> +  SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
> +  
> SmmServicesTableLib|MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.inf
> +!ifdef $(DEBUG_ON_SERIAL_PORT)
> +  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> +!else
> +  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
> +!endif
>  
>  
> 
>  #
> @@ -683,4 +694,14 @@ [Components.X64]
>  !if $(SMM_REQUIRE) == TRUE
>OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
>OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
> +
> +  #
> +  # SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
> +  #
>

Re: [edk2] [PATCH v4 12/41] OvmfPkg: AcpiS3SaveDxe: don't fake LockBox protocol if SMM_REQUIRE

2015-11-11 Thread Jordan Justen

Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>

On 2015-11-03 13:00:48, Laszlo Ersek wrote:
> 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 <ler...@redhat.com>
> ---
>  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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI

2015-11-11 Thread Jordan Justen

s actually the *only* possibility
> >to make SmmLockboxLib work in OVMF (see above).
> >
> >I would like to stick with this approach.
> >
> >Thanks
> >Laszlo
> >
> >>
> >> Thanks,
> >>
> >> Mike
> >>
> >>> -Original Message-
> >>> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >>> Sent: Tuesday, November 03, 2015 1:01 PM
> >>> To: edk2-de...@ml01.01.org
> >>> Cc: Kinney, Michael D; Justen, Jordan L
> >>> Subject: [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-
> >SMRAM
> >>> during PEI
> >>>
> >>> "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" is the
> >library
> >>> instance that implements the LockBoxLib library class with SMRAM access
> >>> for the PEI phase.
> >>>
> >>> Introduce a PEIM that produces the EFI_PEI_SMM_COMMUNICATION_PPI
> >and
> >>> PEI_SMM_ACCESS_PPI interfaces, enabling SmmLockBoxPeiLib to work.
> >>>
> >>> Said library instance can parse and access LockBox data itself (without
> >>> additional LockBox drivers) if the
> >>> EFI_PEI_SMM_COMMUNICATION_PPI.Communicate() function returns
> >>> EFI_NOT_STARTED to it. However it requires that
> >>> EFI_PEI_SMM_COMMUNICATION_PPI exist at least. Also,
> >>> PEI_SMM_ACCESS_PPI
> >>> must exist and work.
> >>>
> >>> The load / installation order of S3Resume2Pei and SmmAccessPei is
> >>> indifferent. SmmAccessPei produces the GUIDed HOB during its installation
> >>> (which happens during PEI), but S3Resume2Pei accesses the HOB only
> >when
> >>> the DXE IPL calls its S3RestoreConfig2 PPI member, as last act of PEI.
> >>>
> >>> MCH_SMRAM_D_LCK and MCH_ESMRAMC_T_EN are masked out the way
> >>> they are, in
> >>> SmmAccessPeiEntryPoint() and SmramAccessOpen() respectively, in order
> >to
> >>> prevent VS20xx from warning about the (otherwise fully intentional)
> >>> truncation in the UINT8 casts. (Warnings reported by Michael Kinney.)
> >>>
> >>> Cc: Michael Kinney <michael.d.kin...@intel.com>
> >>> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> >>> Contributed-under: TianoCore Contribution Agreement 1.0
> >>> Signed-off-by: Laszlo Ersek <ler...@redhat.com>
> >>> ---
> >>>
> >>> Notes:
> >>>v3:
> >>>- update bit-neg expressions to silence VS20xx warnings [Mike]
> >>>
> >>> OvmfPkg/OvmfPkgIa32.dsc|   6 +
> >>> OvmfPkg/OvmfPkgIa32X64.dsc |   6 +
> >>> OvmfPkg/OvmfPkgX64.dsc |   6 +
> >>> OvmfPkg/OvmfPkgIa32.fdf|   3 +
> >>> OvmfPkg/OvmfPkgIa32X64.fdf |   3 +
> >>> OvmfPkg/OvmfPkgX64.fdf |   3 +
> >>> OvmfPkg/SmmAccess/SmmAccessPei.inf |  70 +++
> >>> OvmfPkg/SmmAccess/SmramInternal.h  |  89 
> >>> OvmfPkg/SmmAccess/SmmAccessPei.c   | 446 
> >>> OvmfPkg/SmmAccess/SmramInternal.c  | 188 +
> >>> 10 files changed, 820 insertions(+)
> >>>
> >>> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> >>> index c6850ff..0b729ca 100644
> >>> --- a/OvmfPkg/OvmfPkgIa32.dsc
> >>> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> >>> @@ -445,6 +445,12 @@ [Components]
> >>> 
> >>>   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
> >>>   }
> >>> +!if $(SMM_REQUIRE) == TRUE
> >>> +  OvmfPkg/SmmAccess/SmmAccessPei.inf {
> >>> +
> >>> +  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
> >>> +  }
> >>> +!endif
> >>>
> >>>   #
> >>>   # DXE Phase modules
> >>> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> >>> index dd65bf9..7f672d9 100644
> >>> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> >>> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> >>> @@ -451,6 +451,12 @@ [Components.IA32]
> >>> 
> >>>   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
> >>>   }
> >>> +!if $(SMM_REQUIRE) == TRUE
> >>> +  OvmfPkg/SmmAccess/SmmAccessPei.inf {
> >>> +
> >>> +  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
> >>> +  }
> >>> +!endif
> >>>
> &g

Re: [edk2] MdePkg: Enable Xcode build of BaseLib without

2015-11-10 Thread Jordan Justen

Liming, Andrew,

Wasn't BUILDRULEORDER supposed to help with this?

-Jordan

On 2015-11-10 18:30:39, Gao, Liming wrote:
> This patch is committed at r18766.
> 
> Thanks
> Liming
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Tuesday, November 10, 2015 11:31 PM
> To: Gao, Liming
> Cc: edk2-devel; Kinney, Michael D
> Subject: Re: MdePkg: Enable Xcode build of BaseLib without
> 
> 
> On Nov 10, 2015, at 12:22 AM, Gao, Liming 
> > wrote:
> 
> Reviewed-by: Liming Gao >
> 
> Liming,
> 
> Can you commit the patch?
> 
> Thanks,
> 
> Andrew Fsih
> 
> >cat 0004-MdePkg-BaseLib-don-t-require-NASM-with-Xcode.patch
> From 8f4666bc80d6d4844e73b3a221e50d587ef09cec Mon Sep 17 00:00:00 2001
> From: andrew fish >
> Date: Mon, 9 Nov 2015 22:46:32 -0800
> Subject: [PATCH 4/4] MdePkg: BaseLib don't require NASM with Xcode
> 
> Don't require NASM for simple edk2 Xcode projects.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Andrew Fish >
> Reviewed-by: Liming Gao >
> ---
>  MdePkg/Library/BaseLib/BaseLib.inf | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
> b/MdePkg/Library/BaseLib/BaseLib.inf
> index 4cc86d7..e83a569 100644
> --- a/MdePkg/Library/BaseLib/BaseLib.inf
> +++ b/MdePkg/Library/BaseLib/BaseLib.inf
> @@ -257,6 +257,7 @@
> 
>Ia32/GccInline.c | GCC
>Ia32/Thunk16.nasm | GCC
> +  Ia32/Thunk16.S | XCODE
>Ia32/EnableDisableInterrupts.S | GCC
>Ia32/EnablePaging64.S | GCC
>Ia32/DisablePaging32.S | GCC
> @@ -413,6 +414,7 @@
>X86DisablePaging32.c
>X64/GccInline.c | GCC
>X64/Thunk16.nasm | GCC
> +  X64/Thunk16.S | XCODE
>X64/SwitchStack.S | GCC
>X64/SetJump.S | GCC
>X64/LongJump.S | GCC
> --
> 2.3.2 (Apple Git-55)
> 
> ___
> 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 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

2015-11-02 Thread Jordan Justen

On 2015-11-02 17:14:12, Laszlo Ersek wrote:
> On 11/02/15 23:49, Laszlo Ersek wrote:
> > On 11/02/15 23:29, Jordan Justen wrote:
> >> On 2015-11-02 12:16:12, Laszlo Ersek wrote:
> >>> On 11/02/15 19:53, Alex Williamson wrote:
> >>>> On Mon, 2015-11-02 at 19:31 +0100, Laszlo Ersek wrote:
> >>>>> On 10/31/15 18:50, Laszlo Ersek wrote:
> >>>>>
> >>>>>> I'm very sorry, but I don't think I can spend time on this,
> >>>>>> unless someone gives me ssh and/or console access to a host that
> >>>>>> readily reproduces the bug, with the latest kvm/master, qemu, and
> >>>>>> ekd2 builds.
> >>>>>
> >>>>> We just got lucky, the problem reproduces on my oldie workstation
> >>>>> (HP Z400, (R) Xeon(R) CPU W3550 @ 3.07GHz,
> >>>>> family/model/stepping/microcode = 6/26/5/0x19).
> >>>>>
> >>>>> OVMF works fine with the most recent Fedora 21 host kernel,
> >>>>> "kernel-4.1.10-100.fc21.x86_64", and it breaks on the crispy new
> >>>>> upstream Linux 4.3 release.
> >>>>>
> >>>>> The OVMF log contains a number of failed ASSERT()s, printed by the
> >>>>> APs, in a way that is very characteristic of multi-threading bugs:
> >>>>>
> >>>>> --*--
> >>>>>
> >>>>> Detect CPU count: 2
> >>>>> AAEERRTT  
> >>>>> //hhoomem/el/alcaocso/ss/rscr/cu/pusptsrteraema/me/dekd2k-2g-igti-ts-vsnv/nM/dMedPekPgk/gL/iLbirbarrayr/yB/aBsaesSeySnycnhcrhornoiznatiizoantLiiobn/LSiybn/cShyrnocnhirzoantiizoantGicocn.Gcc(c1.9c8()1:9
> >>>>>  8L)o:c kLVoaclkuVea l=u=e  (=(=U I(N(TUNI)N T2N))  |2|)  L|o|c 
> >>>>> kLVoaclkuVea l=u=e  (=(=U I(N(TUNI)N T1N))^M
> >>>>> 1)
> >>>>> ASSERT 
> >>>>> /home/lacos/src/upstream/edk2-git-svn/MdePkg/Library/BaseSynchronizationLib/SynchronizationGcc.c(198):
> >>>>>  LockValue == ((UINTN) 2) || LockValue == ((UINTN) 1)
> >>>>>
> >>>>> --*--
> >>>>>
> >>>>> (Note that the above is for a 8 VCPU guest. Cf. "Detect CPU count:
> >>>>> 2".)
> >>>>>
> >>>>>
> >>>>> Maybe important, maybe not: my workstation's IOMMU does *not* have
> >>>>> snoop control:
> >>>>>
> >>>>> [3.043297] DMAR: dmar0: reg_base_addr fed9 ver 1:0 cap 
> >>>>> c90780106f0462 ecap f02076
> >>>>>
> >>>>> Where 0xf02076 & 0x80 == 0.
> >>>>>
> >>>>> Whereas my laptop *does* have Snoop Control:
> >>>>>
> >>>>> [0.030486] DMAR: dmar0: reg_base_addr fed9 ver 1:0 cap 
> >>>>> c020660462 ecap f0101a
> >>>>> [0.030491] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap 
> >>>>> d2008020660462 ecap f010da
> >>>>>
> >>>>> The first IOMMU doesn't have Snoop Control, but its scope only
> >>>>> extends to the integrated Intel Graphics Device. The second IOMMU,
> >>>>> which covers the SD card reader I used for testing (and all other
> >>>>> PCI devices), *does* have Snoop Control. 0xf010da & 0x80 = 0x80.
> >>>>>
> >>>>> However, SC support should not matter, due to kernel commit
> >>>>> fb279950ba02e3210a16b11ecfa8871f3ee0ca49, so I think we might be
> >>>>> looking an independent issue. (Possibly in CpuDxe, only exposed by
> >>>>> the new host
> >>>>> kernel.)
> >>>>
> >>>> Snoop Control is what I immediately jumped to as well, but I've
> >>>> never seen the problem on my desktop, which reports the following
> >>>> ecaps: f0101a & f0105a.  Thanks,
> >>>
> >>> This issue is actually very easy to reproduce on my workstation. It
> >>> has 1 socket, 4 cores, 2 threads/core. If I start a guest with 32
> >>> VCPUs (i.e., heavily over-subscribing the host), then the issue hits
> >>> immediately. Device assignment is not necessary.
> >>>
> >>> But, it also reproduces fairly regularly with just 8 VCPUs (even
> >>> with VCPUs pinned to separate logical processors on the host).
> >>>
> >>> Judging purely from the KVM tr

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: fix ExitBootServices() callback in the presence of SMIs

2015-11-02 Thread Jordan Justen

On 2015-10-28 01:59:09, Fan, Jeff wrote:
> Jordan,
> 
> Sending NMI to wake up AP had been discussed later year. It prevents
> platform to provide own real NMI handler.
> 
> For current implementation, after finished AP task, AP will check if
> it is in Idle state or not. If yes, place itself into Sleep state.
>  
> On most cast, AP will place itself into Sleep state just after no
> more than 2 times loop. But to handle such seldom case (improve
> performance), MP service need to check AP state to decide how to
> wakeup it.
> 
> It introduces some complex sync implementation between BSP/Aps. You
> could refer to my fix on this sync.
> 
> So, I think this solution is expensive than the benefit we got.

I'm still not sure what you are suggesting as an alternative.

One simpler design I could see was to always run the APs and never
CpuSleep/hlt them. This would be bad for VMs, because the APs will
steal all of the CPU time doing nothing.

Another simplier design would be to always put the CPUs to sleep, but
I don't think that will be much different than the current design, and
it would just force the relatively expensive wake with init-sipi-sipi
for every AP operation.

I think what we have is on the right track towards where we would want
to end up, and we should just optimize and shake the bugs out of the
current design.

-Jordan

> 
> -Original Message-
> From: Justen, Jordan L 
> Sent: Wednesday, October 28, 2015 3:51 PM
> To: Fan, Jeff; Laszlo Ersek; edk2-devel@lists.01.org
> Cc: Chen Fan; Kinney, Michael D
> Subject: RE: [edk2] [PATCH] UefiCpuPkg/CpuDxe: fix ExitBootServices() 
> callback in the presence of SMIs
> 
> On 2015-10-27 22:24:08, Fan, Jeff wrote:
> > Jordan,
> > 
> > Sending Fixed Interrupt IPI to wakeup AP required set EFLAGS.IF bit on 
> > AP from my experience. (Please correct me if I am wrong.) As a result, 
> > system timer interrupt maybe handled by AP instead of BSP.
> 
> The APs would have to be set up to use a different "nop" interrupt handler 
> table. So, the APs wouldn't run any interrupt handling code.
> 
> I don't think this would interfere with the BSP getting the interrupts and 
> handling them.
> 
> Another idea to investigate is sending an NMI to wake the AP.
> 
> > Most of cases, AP will be in hlt state and require INIT-SIPI-SIPI to 
> > be wakeup and work on many real platform. I don’t think 1S is 
> > reasonable data. (Do you remember where 1S comes from?)
> 
> See Laszlo's patch "OvmfPkg: increase MP services startup timeout"
> 
> > Using MP service in my original patch need to take care some MP 
> > service local sync data. That's why I think Laszlo's patch is simpler 
> > and better.
> 
> I think Laszlo's patch is fine. I think he should prepare it, get it 
> reviewed, and then add it to his SMM series, and then it'll be ready if 
> nothing better comes along.
> 
> > Another point: Dynamically to change the AP state (CpuSleep and 
> > software loop) makes the code complex. I find some dead lock issue 
> > between BSP/AP, I will send the fix later. Long term, I also suggest 
> > to drop this logic. Anyway, I need others' input on it before dropping 
> > it.
> 
> Could you give an overview of what your idea would be? I don't agree that the 
> current code is too complex. But, I'm sure there could be bugs. :)
> 
> -Jordan
> 
> > -Original Message-
> > From: Justen, Jordan L
> > Sent: Wednesday, October 28, 2015 6:55 AM
> > To: Laszlo Ersek; edk2-devel@lists.01.org
> > Cc: Chen Fan; Kinney, Michael D; Fan, Jeff
> > Subject: Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: fix ExitBootServices() 
> > callback in the presence of SMIs
> > 
> > On 2015-10-27 05:20:12, Laszlo Ersek wrote:
> > > On 10/27/15 07:48, Jordan Justen wrote:
> > > > What about adding this code to mStartupCodeTemplate and sending 
> > > > the APs there using the MP services?
> > > 
> > > That was the idea in Jeff's earlier series, but it comes with a 
> > > number of complications. The main one is that the HLT loop is 
> > > entered as a "normal" StartupAllAPs() callback function. That 
> > > necessitates tearing down parts of the environment that the MP 
> > > services implementation builds up carefully at initialization. Other 
> > > parts of that laborously constructed environment are plain irrelevant.
> > 
> > Hmm. I assumed that starting an AP task should be much lower latency than 
> > running INIT-SIPI-SIPI. Yet, examining the current code, it looks like we 
> > generally call CpuSleep on the AP, and we only currently support resuming 
>

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

2015-11-03 Thread Jordan Justen

On 2015-11-03 05:45:52, Paolo Bonzini wrote:
> 
> 
> On 03/11/2015 14:25, Laszlo Ersek wrote:
> >   - Agreement between Paolo, Jordan and Mike about implementing
> > broadcast SMIs. I am willing to code up whatever design is
> > agreed upon. Can everyone involved please prioritize this
> > discussion a little?

Obviously we'll have to follow what QEMU decides, so I'm not sure how
much we can actually influence this.

Aside from the desire to better emulate chipset/platform designs of
the actual hardware, I do have a related question.

If we use the local apic to initiate IPIs to other processors, what
impact might that have on the state of the local apic if the OS is
also trying to use it? For example, what if the OS is in the middle of
trying to send an IPI?

I think real platforms get to nicely avoid this by having the chipset
assert SMI to the hardware pins of all processors in the system. It
looks like our code has a provision for having one processor send the
others into SMM, but I wonder under which scenarios this is used, and
how they deal with the local apic state in that case.

> Actually, I was *de*prioritizing it because things _more or less_ work
> without it, especially if the timeout is temporarily reduced.  We
> probably agree that timeouts are evil in a virt setting, but even
> without this issue you can commit the ~70 patches that bring us to 99%
> of the way.
> 
> Once the slate is clean and everybody is focused on the few remaining
> problems, we can tackle them---including broadcast SMIs.
> 
> In fact, the rest of your email lists some more pressing problems than
> broadcast SMIs, which I'm quoting below to further remind other readers. :)

Since it involves multiple projects, could it take longer to
coordinate a change?

-Jordan

> 
> Paolo
> 
> >   - Solving the MP-related ExitBootServices() handler bug in CpuDxe.
> > Patches have been on the list for almost a week. While I've been
> > breaking my back testing and reviewing patches for others (not
> > just on edk2-devel, mind you), nobody has batted an eye about
> > that series.
> > 
> > [edk2] [PATCH v2 0/4] UefiCpuPkg/CpuDxe: Fix ExitBootServices()
> >   callback in the presence of SMIs
> > http://thread.gmane.org/gmane.comp.bios.edk2.devel/3518
> > 
> > Please review it, so that I can include it at the front of my
> > upcoming v4 SMM series.
> > 
> >   - Thirty (30) patches from the SMM series still need reviews. Once
> > all of the above is covered, I'll update the OvmfPkg/README
> > patch about the status, and post version 4. I wouldn't mind if
> > we could commit the series still in 2015, but I'm getting less
> > and less hopeful.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] C Coding Standards Specification disappeared

2015-11-05 Thread Jordan Justen

On 2015-11-05 08:05:03, Laszlo Ersek wrote:
> On 11/05/15 16:52, Kinney, Michael D wrote:
> > Laszlo,
> > 
> > The semi-formal way is to discuss these types of change requests
> > on this mailing list and get agreement.
> > 
> > I think your suggestion to add a new horizontal spacing rule that
> > there should be no space between cast operator and cast operand is
> > good.
> > 
> > I will collect results of these discussions and get new versions
> > of the document released.
> 
> Awesome! :) Thanks!

It doesn't sound awesome to me. It sounds like the bare minimum
responsibility for owning the document. :)

What I think would be awesome would be to move this (and other EDK II
documents) into a public source control system.

My first choice would be for us to use something markdown based. For
instance, python seems to produce great documents with sphinx
(http://sphinx-doc.org/).

But, better than nothing would be something like docbook. (It is just
not nearly as nice for patches.)

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

Re: [edk2] [Patch 0/4] AppPkg/Python: Port Python 2.7.10 to EDK II

2015-11-05 Thread Jordan Justen

Have you considered using git?

For one, EDK II is moving to git.

It would have enabled you to easily generate and send the patch files
for your patch series. (I am guessing you spend considerable time
generating these emails, and yet, I don't think they are usable to
actually apply to a tree.)

I think Outlook may have munged some of the lines in your file. Some
of the lines seem to have been wrapped.

You also could easily post a branch of your patches (for example, on
github).

Also, git send-email nicely uses the In-Reply-To email header to
thread all the patches of your series together.

-Jordan

On 2015-11-05 14:28:01, Daryl McDaniel wrote:
> AppPkg/Python-2.7.10: Patch 0 of 4 -- Introduction
> 
> The following series of four patches detail the changes necessary to port
> cPython 2.7.10 to the EDK II implementation of UEFI.
> 
> In order to easily coexist with the Python 2.7.2 port, all files for
> Python 2.7.10 are contained within
> AppPkg/Applications/Python/Python-2.7.10
> Within this directory the Ia32, X64, and PyMod-2.7.10 directories along with
> the Py2710ReadMe.txt, Python2710.inf, libprep.bat, and srcprep.bat files are
> specific to the EDK II port.  All other files and directories are from the
> cPython 2.7.10 distribution.
> 
> Files from the cPython distribution, that were not modified, are not listed.
> Some files were copied from the cPython 2.7.2 port then modified for 2.7.10.
> The diffs for these files are between the 2.7.2 and 2.7.10 versions.  They
> are:
> Python-2.7.10/Ia32/pyconfig.h
> PyMod-2.7.10/Modules/edk2module.c
> Python-2.7.10/X64/pyconfig.h
> All other diffs are between the distribution and final files.
> 
> Because of the large number of changes, both the diff as well as the full
> file
> are included for:
> Python-2.7.10/Py2710ReadMe.txt
> Python-2.7.10/PyMod-2.7.10/Modules/edk2module.c
> Python-2.7.10/Python2710.inf
> 
> Because they are new and small, the full file is included instead of diffs
> for:
> Python-2.7.10/libprep.bat
> Python-2.7.10/srcprep.bat
> 
> 
>  AppPkg/AppPkg.dsc  |5 +-
>  .../Python/Python-2.7.10/Ia32/pyconfig.h   |   93 +-
>  .../Python/Python-2.7.10/Py2710ReadMe.txt  |  124 +-
>  .../Python-2.7.10/PyMod-2.7.10/Lib/ntpath.py   |   30 +-
>  .../Python/Python-2.7.10/PyMod-2.7.10/Lib/os.py|   35 +-
>  .../Python/Python-2.7.10/PyMod-2.7.10/Lib/pydoc.py |   17 +
>  .../Python/Python-2.7.10/PyMod-2.7.10/Lib/site.py  |  165 +-
>  .../Python-2.7.10/PyMod-2.7.10/Modules/_sre.c  |  150 +-
>  .../Python-2.7.10/PyMod-2.7.10/Modules/addrinfo.h  |  101 +-
>  .../PyMod-2.7.10/Modules/edk2module.c  | 5698
> +---
>  .../PyMod-2.7.10/Modules/errnomodule.c |   57 +-
>  .../PyMod-2.7.10/Modules/expat/expat_external.h|4 +-
>  .../Python-2.7.10/PyMod-2.7.10/Modules/getpath.c   |  143 +-
>  .../Python-2.7.10/PyMod-2.7.10/Modules/main.c  |   61 +-
>  .../PyMod-2.7.10/Modules/selectmodule.c|   43 +-
>  .../PyMod-2.7.10/Modules/zlib/gzguts.h |   10 +-
>  .../PyMod-2.7.10/Modules/zlib/zutil.h  |   11 +-
>  .../PyMod-2.7.10/Objects/longobject.c  |   14 +-
>  .../PyMod-2.7.10/Objects/stringlib/localeutil.h|   17 +-
>  .../PyMod-2.7.10/Python/getcopyright.c |   24 +-
>  .../Python-2.7.10/PyMod-2.7.10/Python/marshal.c|   21 +-
>  .../Python-2.7.10/PyMod-2.7.10/Python/random.c |   32 +-
>  .../Python/Python-2.7.10/Python2710.inf|  367 +-
>  .../Python/Python-2.7.10/X64/pyconfig.h|   63 +-
>  .../Applications/Python/Python-2.7.10/libprep.bat  |   20 +
>  .../Applications/Python/Python-2.7.10/srcprep.bat  |   13 +
>  26 files changed, 2202 insertions(+), 5116 deletions(-)
> 
> 
> In order to reduce space and download times, only a subset of Python library
> files, from the distribution, will be included.  These are:
> ---
> 
> encodings/importlib/  json/ pydoc_data/
> xml/
> 
> _abcoll.py_weakrefset.py  abc.pyargparse.py
> ast.pyatexit.py   BaseHTTPServer.py binhex.py
> bisect.py calendar.py cmd.pycodecs.py
> collections.pycompileall.py   copy.py   copy_reg.py
> csv.pydis.py  dummy_thread.py   fnmatch.py
> fileinput.py  formatter.pyfunctools.py  genericpath.py
> getopt.py gettext.py  hashlib.pyheapq.py
> HTMLParser.py inspect.py  io.py keyword.py
> linecache.py  locale.py   md5.pymodulefinder.py
> ntpath.py numbers.py  optparse.py   os.py
> pkgutil.pyplatform.py pydoc.py  random.py
> re.py repr.py runpy.py  sha.py
> shutil.py

[edk2] [PATCH] BaseTools/Scripts: Add PatchCheck.py script

2015-10-07 Thread Jordan Justen

This script can be used to check some expected rules for EDK II
patches. It only works on git formatted patches.

It checks both the commit message and the lines that are added in the
patch diff.

In the commit message it verifies line lengths, signature formats, and
the Contributed-under tag.

In the patch, it checks that line endings are CRLF for all files that
don't have a .sh extension. It verifies that no trailing whitespace is
present and that tab characters are not used.

Patch contributors should use this script prior to submitting their
patches. Package maintainers can also use it to verify incoming
patches.

It can also be run by specifying a git revision list, so actual patch
files are not always required.

For example, to checkout this last 5 patches in your git branch you
can run:

  python PatchCheck.py HEAD~5..

Or, a shortcut (like git log):

  python PatchCheck.py -5

The --oneline option works similar to git log --oneline.

The --silent option enables silent operation.

The script supports python 2.7 and python 3.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Erik Bjorge <erik.c.bjo...@intel.com>
Cc: Yonghong Zhu <yonghong@intel.com>
Cc: Liming Gao <liming@intel.com>
---
 BaseTools/Scripts/PatchCheck.py | 607 
 1 file changed, 607 insertions(+)
 create mode 100644 BaseTools/Scripts/PatchCheck.py

diff --git a/BaseTools/Scripts/PatchCheck.py b/BaseTools/Scripts/PatchCheck.py
new file mode 100644
index 000..340a997
--- /dev/null
+++ b/BaseTools/Scripts/PatchCheck.py
@@ -0,0 +1,607 @@
+## @file
+#  Check a patch for various format issues
+#
+#  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.
+#
+
+from __future__ import print_function
+
+VersionNumber = '0.1'
+__copyright__ = "Copyright (c) 2015, Intel Corporation  All rights reserved."
+
+import email
+import argparse
+import os
+import re
+import subprocess
+import sys
+
+class Verbose:
+SILENT, ONELINE, NORMAL = range(3)
+level = NORMAL
+
+class CommitMessageCheck:
+"""Checks the contents of a git commit message."""
+
+def __init__(self, subject, message):
+self.ok = True
+
+if subject is None and  message is None:
+self.error('Commit message is missing!')
+return
+
+self.subject = subject
+self.msg = message
+
+self.check_contributed_under()
+self.check_signed_off_by()
+self.check_misc_signatures()
+self.check_overall_format()
+self.report_message_result()
+
+url = 
'https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format'
+
+def report_message_result(self):
+if Verbose.level < Verbose.NORMAL:
+return
+if self.ok:
+# All checks passed
+return_code = 0
+print('The commit message format passed all checks.')
+else:
+return_code = 1
+if not self.ok:
+print(self.url)
+
+def error(self, *err):
+if self.ok and Verbose.level > Verbose.ONELINE:
+print('The commit message format is not valid:')
+self.ok = False
+if Verbose.level < Verbose.NORMAL:
+return
+count = 0
+for line in err:
+prefix = (' *', '  ')[count > 0]
+print(prefix, line)
+count += 1
+
+def check_contributed_under(self):
+cu_msg='Contributed-under: TianoCore Contribution Agreement 1.0'
+if self.msg.find(cu_msg) < 0:
+self.error('Missing Contributed-under! (Note: this must be ' +
+   'added by the code contributor!)')
+
+@staticmethod
+def make_signature_re(sig, re_input=False):
+if re_input:
+sub_re = sig
+else:
+sub_re = sig.replace('-', r'[-\s]+')
+re_str = (r'^(?P' + sub_re +
+  r')(\s*):(\s*)(?P\S.*?)(?:\s*)$')
+try:
+return re.compile(re_str, re.MULTILINE|re.IGNORECASE)
+except Exception:
+print("Tried to compile re:", re_str)
+raise
+
+sig_block_re = \
+re.compile(r'''^
+(?: (?P[^:]+) \s* : \s*
+(?P\S.*?) )
+|
+(?: \[ (?P[^:]+) \s* : \s*
+   (?P.+?

Re: [edk2] [PATCH v3] Pkg-Module: Integrate new RngLib into RngDxe

2015-10-07 Thread Jordan Justen

In the subject line, 'Pkg-Module' should be something like 'MdePkg:'
or 'SecurityPkg/RandomNumberGenerator:'.

On 2015-10-07 18:55:42, Thomas Palmer wrote:
> Use the new RngLib to provide the IA32/X64 random data for RngDxe.
> Remove x86 specific functions from RdRand files.
> Clean up files in RngDxe/IA32 and RngDxe/X64 that are subsumed by files in 
> BaseRngLib.
> Simplify RngDxe by using WriteUnaligned64 for both IA32 and X64 platforms.
> Create and use GetRandomNumber128 in RngDxe to leverage 128 bit support found 
> in some HW RNG devices

It sounds like you are doing about 5 things here. How about 5 patches?

Each patch should only touch one package whenever possiable.

Also, consider adding 'Cc:' near your Signed-off-by for the
maintainers of a package. (see Maintainers.txt)

-Jordan

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Thomas Palmer 
> ---
>  MdePkg/Include/Library/RngLib.h|   17 ++
>  MdePkg/Library/BaseRngLib/BaseRng.c|   32 +++
>  .../RngDxe/IA32/AsmRdRand.asm  |   67 -
>  .../RandomNumberGenerator/RngDxe/IA32/GccRdRand.c  |   69 --
>  .../RandomNumberGenerator/RngDxe/IA32/RdRandWord.c |  104 
>  SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.c  |  256 
> ++--
>  SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.h  |  151 +---
>  SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.c  |9 +-
>  .../RandomNumberGenerator/RngDxe/RngDxe.inf|   14 +-
>  .../RandomNumberGenerator/RngDxe/X64/AsmRdRand.asm |   83 ---
>  .../RandomNumberGenerator/RngDxe/X64/GccRdRand.c   |   95 
>  .../RandomNumberGenerator/RngDxe/X64/RdRandWord.c  |   70 --
>  SecurityPkg/SecurityPkg.dsc|3 +
>  13 files changed, 75 insertions(+), 895 deletions(-)
>  delete mode 100644 
> SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
>  delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/IA32/GccRdRand.c
>  delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/IA32/RdRandWord.c
>  delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/X64/AsmRdRand.asm
>  delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/X64/GccRdRand.c
>  delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/X64/RdRandWord.c
> 
> diff --git a/MdePkg/Include/Library/RngLib.h b/MdePkg/Include/Library/RngLib.h
> index 157a931..ece4394 100644
> --- a/MdePkg/Include/Library/RngLib.h
> +++ b/MdePkg/Include/Library/RngLib.h
> @@ -66,4 +66,21 @@ GetRandomNumber64 (
>OUT UINT64*Rand
>);
>  
> +/**
> +  Generates a 128-bit random number.
> +
> +  if Rand is NULL, then ASSERT().
> +
> +  @param[out] Rand Buffer pointer to store the 128-bit random value.
> +
> +  @retval TRUE Random number generated successfully.
> +  @retval FALSEFailed to generate the random number.
> +
> +**/
> +BOOLEAN
> +EFIAPI
> +GetRandomNumber128 (
> +  OUT UINT64*Rand
> +  );
> +
>  #endif  // __RNG_LIB_H__
> diff --git a/MdePkg/Library/BaseRngLib/BaseRng.c 
> b/MdePkg/Library/BaseRngLib/BaseRng.c
> index 279df30..2c8df56 100644
> --- a/MdePkg/Library/BaseRngLib/BaseRng.c
> +++ b/MdePkg/Library/BaseRngLib/BaseRng.c
> @@ -155,3 +155,35 @@ GetRandomNumber64 (
>  
>return FALSE;
>  }
> +
> +/**
> +  Generates a 128-bit random number.
> +
> +  if Rand is NULL, then ASSERT().
> +
> +  @param[out] Rand Buffer pointer to store the 128-bit random value.
> +
> +  @retval TRUE Random number generated successfully.
> +  @retval FALSEFailed to generate the random number.
> +
> +**/
> +BOOLEAN
> +EFIAPI
> +GetRandomNumber128 (
> +  OUT UINT64*Rand
> +  )
> +{
> +  ASSERT (Rand != NULL);
> +
> +  //
> +  // Read first 64 bits
> +  //
> +  if (!GetRandomNumber64 (Rand)) {
> +return FALSE;
> +  }
> +
> +  //
> +  // Read second 64 bits
> +  //
> +  return GetRandomNumber64 (++Rand);
> +}
> diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm 
> b/SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
> deleted file mode 100644
> index 37b3830..000
> --- a/SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
> +++ /dev/null
> @@ -1,67 +0,0 @@
> -;--
> -;
> -; Copyright (c) 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.
> -;
> -; Module Name:
> -;
> -;   AsmRdRand.Asm
> -;
> -; Abstract:
> -;
>

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

2015-10-18 Thread Jordan Justen

I can't find a fault with your argument, but something tells me it
might be good to get some input from Mike or Andrew (or others on the
list) in the form of a history lesson to know why the two modes might
have been supported.

I've always seen it done this way, but likely this has been due to a
lot of "copy the old version and modify."

-Jordan

On 2015-10-14 15:26:40, Laszlo Ersek wrote:
> 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
> ---

Re: [edk2] [PATCH 1/4] OvmfPkg: import SmmCpuFeaturesLib from UefiCpuPkg

2015-10-13 Thread Jordan Justen

On 2015-10-13 05:57:17, Paolo Bonzini wrote:
> 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 
> ---
>  .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c   |   0
>  .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf |   6 +++---
>  .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.uni | Bin

Can you convert this .uni to UTF-8? See 8ad8a1fa.

-Jordan

>  OvmfPkg/OvmfPkgIa32.dsc |   2 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc  |   2 +-
>  OvmfPkg/OvmfPkgX64.dsc  |   2 +-
>  6 files changed, 6 insertions(+), 6 deletions(-)
>  copy {UefiCpuPkg => OvmfPkg}/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c 
> (100%)
>  copy {UefiCpuPkg => OvmfPkg}/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf 
> (99%)
>  copy {UefiCpuPkg => OvmfPkg}/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.uni 
> (100%)
> 
> diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c 
> b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> similarity index 100%
> copy from UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> copy to OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf 
> b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> similarity index 99%
> copy from UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> copy to OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> index 78bb8b9..0a19c75 100644
> --- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> +++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> @@ -6,10 +6,10 @@
>  #  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]
> @@ -28,7 +28,7 @@
>  [Packages]
>MdePkg/MdePkg.dec
>UefiCpuPkg/UefiCpuPkg.dec
> -  
> +
>  [LibraryClasses]
>BaseLib
>PcdLib
> diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.uni 
> b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.uni
> similarity index 100%
> copy from UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.uni
> copy to OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.uni
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 18740b8..81adb31 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -693,7 +693,7 @@
>  
>
> SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
>SmmLib|MdePkg/Library/SmmLibNull/SmmLibNull.inf
> -  
> SmmCpuFeaturesLib|UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> +  
> SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
>}
>  
>#
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index f12161a..1a8bfd2 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -700,7 +700,7 @@
>  
>
> SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
>SmmLib|MdePkg/Library/SmmLibNull/SmmLibNull.inf
> -  
> SmmCpuFeaturesLib|UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> +  
> SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
>}
>  
>#
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 5375869..9bf720a 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -698,7 +698,7 @@
>  
>
> SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
>SmmLib|MdePkg/Library/SmmLibNull/SmmLibNull.inf
> -  
> SmmCpuFeaturesLib|UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> +  
> SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
>}
>  
>#
> -- 
> 2.5.0
> 
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/3] OvmfPkg: Add SMM DebugAgentLib mapping to DSC

2015-10-13 Thread Jordan Justen

On 2015-10-13 10:49:22, Michael Kinney wrote:
> Add mappings to DebugAgentLib for SMM modules
> to fix b uild breaks when SMM_REQUIRE and

'b uild' => 'build'

> SOURCE_DEBUG_ENABLE are both set

How about adding a period to the end of the sentence?

Your line wrapping seems to be excessively small. (~50 characters).
Too short of wrapping is better than too long, but I think 70~75
characters is about the best. (Git log adds 4 characters, so 75+4
still keeps that under 80 characters.)

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 3 +++
>  OvmfPkg/OvmfPkgIa32X64.dsc | 3 +++

Why did you not update the X64 build? My process for updating the dsc
involves a 3-way diff of OvmfPkg/*.dsc, and I try to keep the
differences minimal.

If you update the X64 dsc, then

Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>

>  2 files changed, 6 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 18740b8..af02080 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -309,6 +309,9 @@
>  !endif
>
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.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 f12161a..2d9ba2f 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -314,6 +314,9 @@
>  !endif
>
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
> +!ifdef $(SOURCE_DEBUG_ENABLE)
> +  DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
> +!endif
>  
>  [LibraryClasses.common.SMM_CORE]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> -- 
> 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] BaseTools/Scripts: Add PatchCheck.py script

2015-10-09 Thread Jordan Justen

On 2015-10-08 15:22:08, Laszlo Ersek wrote:
> On 10/08/15 04:53, Jordan Justen wrote:
> > This script can be used to check some expected rules for EDK II
> > patches. It only works on git formatted patches.
> > 
> > It checks both the commit message and the lines that are added in the
> > patch diff.
> > 
> > In the commit message it verifies line lengths, signature formats, and
> > the Contributed-under tag.
> > 
> > In the patch, it checks that line endings are CRLF for all files that
> > don't have a .sh extension. It verifies that no trailing whitespace is
> > present and that tab characters are not used.
> 
> Yay! :)
> 
> Immediate RFE: can it enforce a line length of 79 characters for lines
> that a patch adds, to C or assembly source code (based on filename
> suffix)? ;)

I would also like to add this. But, I thought it might be too
controversial for a first pass. (Despite the fact that it is part of
the coding standard.)

> And reject non-ASCII characters in the same?

This one I'd like to hold off on just because I don't want to spend
the time implement it just now. :)

-Jordan

> Anyway, those are just ideas, and ideas are a dime a dozen. :)
> 
> Thanks
> Laszlo
> 
> > 
> > Patch contributors should use this script prior to submitting their
> > patches. Package maintainers can also use it to verify incoming
> > patches.
> > 
> > It can also be run by specifying a git revision list, so actual patch
> > files are not always required.
> > 
> > For example, to checkout this last 5 patches in your git branch you
> > can run:
> > 
> >   python PatchCheck.py HEAD~5..
> > 
> > Or, a shortcut (like git log):
> > 
> >   python PatchCheck.py -5
> > 
> > The --oneline option works similar to git log --oneline.
> > 
> > The --silent option enables silent operation.
> > 
> > The script supports python 2.7 and python 3.
> > 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
> > Cc: Erik Bjorge <erik.c.bjo...@intel.com>
> > Cc: Yonghong Zhu <yonghong@intel.com>
> > Cc: Liming Gao <liming@intel.com>
> > ---
> >  BaseTools/Scripts/PatchCheck.py | 607 
> > 
> >  1 file changed, 607 insertions(+)
> >  create mode 100644 BaseTools/Scripts/PatchCheck.py
> > 
> > diff --git a/BaseTools/Scripts/PatchCheck.py 
> > b/BaseTools/Scripts/PatchCheck.py
> > new file mode 100644
> > index 000..340a997
> > --- /dev/null
> > +++ b/BaseTools/Scripts/PatchCheck.py
> > @@ -0,0 +1,607 @@
> > +## @file
> > +#  Check a patch for various format issues
> > +#
> > +#  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.
> > +#
> > +
> > +from __future__ import print_function
> > +
> > +VersionNumber = '0.1'
> > +__copyright__ = "Copyright (c) 2015, Intel Corporation  All rights 
> > reserved."
> > +
> > +import email
> > +import argparse
> > +import os
> > +import re
> > +import subprocess
> > +import sys
> > +
> > +class Verbose:
> > +SILENT, ONELINE, NORMAL = range(3)
> > +level = NORMAL
> > +
> > +class CommitMessageCheck:
> > +"""Checks the contents of a git commit message."""
> > +
> > +def __init__(self, subject, message):
> > +self.ok = True
> > +
> > +if subject is None and  message is None:
> > +self.error('Commit message is missing!')
> > +return
> > +
> > +self.subject = subject
> > +self.msg = message
> > +
> > +self.check_contributed_under()
> > +self.check_signed_off_by()
> > +self.check_misc_signatures()
> > +self.check_overall_format()
> > +self.report_message_result()
> > +
> > +url = 
> > 'https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format'
> > +
&g

Re: [edk2] [PATCH] OvmfPkg: AcpiTables: serialize control methods that create named objects

2015-09-02 Thread Jordan Justen

Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>

On 2015-08-28 02:16:29, Laszlo Ersek wrote:
> Bruce Cran reported the following issue:
> 
>   With iasl version 20150410-64 building OvmfX64 (using OvmfPkg/build.sh
>   -a X64 -t GCC49 -b RELEASE) results in a couple of warnings about
>   methods that should be serialized:
> 
>   .../OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Dsdt.
>   95:   Method (_CRS, 0) {
>   Remark   2120 - Control Method should be made Serialized ^  (due to
>   creation of named objects within)
> 
>   .../OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Dsdt.
>   235: Method (PCRS, 1, NotSerialized) {
>   Remark   2120 - Control Method should be made Serialized ^  (due to
>   creation of named objects within)
> 
> The ACPI 6.0 spec justifies the above warnings in "19.6.82 Method (Declare
> Control Method)":
> 
>   [...] The serialize rule can be used to prevent reentering of a method.
>   This is especially useful if the method creates namespace objects.
>   Without the serialize rule, the reentering of a method will fail when it
>   attempts to create the same namespace object. [...]
> 
> Cc: Bruce Cran <br...@cran.org.uk>
> Reported-by: Bruce Cran <br...@cran.org.uk>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <ler...@redhat.com>
> ---
>  OvmfPkg/AcpiTables/Dsdt.asl | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/AcpiTables/Dsdt.asl b/OvmfPkg/AcpiTables/Dsdt.asl
> index 519a312..2c3a314 100644
> --- a/OvmfPkg/AcpiTables/Dsdt.asl
> +++ b/OvmfPkg/AcpiTables/Dsdt.asl
> @@ -130,7 +130,7 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 1, "INTEL ", "OVMF   
>  ", 4) {
>  )
>})
>  
> -  Method (_CRS, 0) {
> +  Method (_CRS, 0, Serialized) {
>  //
>  // see the FIRMWARE_DATA structure in 
> "OvmfPkg/AcpiPlatformDxe/Qemu.c"
>  //
> @@ -360,7 +360,7 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 1, "INTEL ", "OVMF   
>  ", 4) {
>  // _CRS method for LNKA, LNKB, LNKC, LNKD
>  // Arg0[in]: value of PIRA / PIRB / PIRC / PIRD
>  //
> -Method (PCRS, 1, NotSerialized) {
> +Method (PCRS, 1, Serialized) {
>//
>// create temporary buffer with an Extended Interrupt Descriptor
>// whose single vector defaults to zero
> -- 
> 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 08/58] OvmfPkg: PlatformPei: account for TSEG size with PcdSmmSmramRequire set

2015-09-06 Thread Jordan Justen

Patches 7 & 8 Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>

On 2015-07-24 16:00:14, Laszlo Ersek wrote:
> 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 <ler...@redhat.com>
> ---
>  OvmfPkg/PlatformPei/PlatformPei.inf |  1 +
>  OvmfPkg/PlatformPei/MemDetect.c | 34 +++-
>  OvmfPkg/OvmfPkg.dec |  7 
>  3 files changed, 41 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
> b/OvmfPkg/PlatformPei/PlatformPei.inf
> index b9b0b20..0bf4c38 100644
> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
> @@ -76,6 +76,7 @@ [Pcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecomprScratchEnd
> +  gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
>gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize
>gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
>gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
> diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
> index 649b484..cb3f3dd 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 TsegSize;
> +
> +  //
> +  // Make sure the TSEG area that we reported as a reserved memory 
> resource
> +  // cannot be used for reserved memory allocations.
> +  //
> +  Tse

Re: [edk2] [PATCH 05/58] OvmfPkg: Sec: assert the build-time calculated end of the scratch buffer

2015-09-06 Thread Jordan Justen

size 124 (0x7C) and
> +#  type 0x19 (EFI_SECTION_RAW). The purpose of this 
> section
> +#  is to pad the start of PEIFV to 128 bytes.
> +# 120  Zero bytes (padding).
> +#
> +#   4  EFI_COMMON_SECTION_HEADER, stating size
> +#  (PcdOvmfPeiMemFvSize + 4), and type 0x17
> +#  (EFI_SECTION_FIRMWARE_VOLUME_IMAGE).
> +# PcdOvmfPeiMemFvSize  PEIFV. Note that the above sizes pad the offset of 
> this
> +#  object to 128 bytes. See also the "guided.dummy.txt"
> +#  file in the same directory.
> +#
> +#   4  EFI_COMMON_SECTION_HEADER, stating size 12 (0xC) and
> +#  type 0x19 (EFI_SECTION_RAW). The purpose of this 
> section
> +#  is to pad the start of DXEFV to 16 bytes.
> +#   8  Zero bytes (padding).
> +#
> +#   4  EFI_COMMON_SECTION_HEADER, stating size
> +#  (PcdOvmfDxeMemFvSize + 4), and type 0x17
> +#  (EFI_SECTION_FIRMWARE_VOLUME_IMAGE).
> +# PcdOvmfDxeMemFvSize  DXEFV. Note that the above sizes pad the offset of 
> this
> +#  object to 16 bytes. See also the "guided.dummy.txt" 
> file
> +#  in the same directory.
> +#
> +# The total size after decompression is (128 + PcdOvmfPeiMemFvSize + 16 +
> +# PcdOvmfDxeMemFvSize).
> +
> +DEFINE OUTPUT_SIZE = (128 + gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize + 
> 16 + gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize)
> +
> +# LzmaCustomDecompressLib uses a constant scratch buffer size of 64KB; see
> +# SCRATCH_BUFFER_REQUEST_SIZE in
> +# "MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaDecompress.c".
> +
> +DEFINE SCRATCH_SIZE = 0x0001
> +
> +# Note: when we use PcdOvmfDxeMemFvBase in this context, BaseTools have not 
> yet
> +# offset it with MEMFD's base address. For that reason we have to do it 
> manually.
> +#
> +# The calculation below mirrors DecompressMemFvs() [OvmfPkg/Sec/SecMain.c].
> +
> +DEFINE OUTPUT_BASE= ($(MEMFD_BASE_ADDRESS) + 
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase + 0x0010)
> +DEFINE SCRATCH_BASE_UNALIGNED = ($(OUTPUT_BASE) + $(OUTPUT_SIZE))
> +DEFINE SCRATCH_BASE_ALIGNMENT = 0x000F
> +DEFINE SCRATCH_BASE_MASK  = 0xFFF0
> +DEFINE SCRATCH_BASE   = (($(SCRATCH_BASE_UNALIGNED) + 
> $(SCRATCH_BASE_ALIGNMENT)) & $(SCRATCH_BASE_MASK))

This 'SCRATCH' name usage is pretty localized, but it is a pretty
generic name. Maybe DECOMP_SCRATCH could be used instead. I think the
shorter 'DECOMP' is okay here since it is the only file where these
defines will be used. Once again, not really a big deal.

Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>

> +
> +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecomprScratchEnd = $(SCRATCH_BASE) + 
> $(SCRATCH_SIZE)
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index 54df0ef..f9422f0 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.PcdOvmfDecomprScratchEnd|0x0|UINT32|0x1f
>  
>  [PcdsDynamic, PcdsDynamicEx]
>gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
> diff --git a/OvmfPkg/OvmfPkg.fdf.inc b/OvmfPkg/OvmfPkg.fdf.inc
> index 486bbc6..441c35a 100644
> --- a/OvmfPkg/OvmfPkg.fdf.inc
> +++ b/OvmfPkg/OvmfPkg.fdf.inc
> @@ -60,3 +60,5 @@
>  
>  SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwSpareBase = 
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase + 
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
>  SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize = 0x1
> +
> +DEFINE MEMFD_BASE_ADDRESS = 0x80
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index 16675f8..efb4a4f 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  = 0x90
>  ErasePolarity = 1
>  BlockSize = 0x1
> @@ -377,6 +377,8 @@ [FV.FVMAIN_COMPACT]
> }
>   }
>  
> +!include DecomprScratchEnd.fdf.inc
> +
>  
> 
>  
>  [Rule.Co

Re: [edk2] [PATCH 06/58] OvmfPkg: decompress FVs on S3 resume if SMM_REQUIRE is set

2015-09-06 Thread Jordan Justen

aid 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 (PcdOvmfDecomprScratchEnd) - 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..649b484 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 
> (PcdOvmfDxeMemFvSize);
> +// Technically we could lay the permanent PEI RAM over SEC's temporary
> +// decompression and scratch buffer even if "secure S3" is needed, since
> +// their lifetimes don't overlap. However, PeiFvInitialization() will 
> cover
> +// RAM up to PcdOvmfDecomprScratchEnd with an EfiACPIMemoryNVS memory
> +// allocation HOB, and other allocations served from the permanent PEI 
> RAM
> +// shouldn't overlap with that HOB.
> +//
> +MemoryBase = mS3Supported && FeaturePcdGet (PcdSmmSmramRequire) ?
> +  PcdGet32 (PcdOvmfDecomprScratchEnd) :
> +  PcdGet32 (PcdOvmfDxeMemFvBase) + PcdGet32 (PcdOvmfDxeMemFvSize);
>  MemorySize = LowerMemorySize - MemoryBase;
>  if (MemorySize > PeiMemoryCap) {
>MemoryBase = LowerMemorySize - PeiMemoryCap;
> diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
> index 348d2b3..99dd6db 100644
> --- a/OvmfPkg/Sec/SecMain.c
> +++ b/OvmfPkg/Sec/SecMain.c
> @@ -538,13 +538,25 @@ FindPeiCoreImageBase (
>   OUT  EFI_PHYSICAL_ADDRESS *PeiCoreImageBase
>)
>  {
> +  BOOLEAN S3Resume;
> +
>*PeiCoreImageBase = 0;
>  
> -  if (IsS3Resume ()) {
> -    DEBUG ((EFI_D_VERBOSE, "SEC: S3 resume\n"));
> +  S3Resume = IsS3Resume ();
> +  if (S3Resume && !FeaturePcdGet (PcdSmmSmramRequire)) {
> +//
> +// A malicious runtime OS may have injected something into our previously
> +// decoded PEI FV, but we don't care about that unless SMM/SMRAM is 
> required.
> +//
> +DEBUG ((EFI_D_VERBOSE, "SEC: S3 resume (insecure)\n"));

How about instead:
DEBUG ((EFI_D_VERBOSE, "SEC: S3 resume\n"));
and
DEBUG ((EFI_D_VERBOSE, "SEC: S3 resume (with PEI decompression)\n"));

Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>

>  GetS3ResumePeiFv (BootFv);
>} else {
> -DEBUG ((EFI_D_VERBOSE, "SEC: Normal boot\n"));
> +//
> +// We're either not resuming, or resuming "securely" -- we'll decompress
> +// both PEI FV and DXE FV from pristine flash.
> +//
> +DEBUG ((EFI_D_VERBOSE, "SEC: %a\n",
> +  S3Resume ? "S3 resume (hopefully secure)" : "Normal boot"));
>  FindMainFv (BootFv);
>  
>  DecompressMemFvs (BootFv);
> -- 
> 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] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

2015-09-09 Thread Jordan Justen

On 2015-09-09 01:57:51, Laszlo Ersek wrote:
> On 08/10/15 18:24, Laszlo Ersek wrote:
> > Hi.
> > 
> > Let's do an OVMF BoF at this year's KVM Forum too.
> 
> Here's a preliminary task list, after some off-list discussion (I tried
> to incorporate comments):
> 
> - create GPL'd fork called "ovmf" for expediting virt development
>   (OvmfPkg, ArmVirtPkg)
>   - maybe leverage the feature under
>  for
> setting up a separate "tianocore/edk2-gpl" repo, for GPL'd
> contributions [Jordan]
> - repo separation by license could make things harder for packagers
>   and QEMU bundling [Laszlo]

I would like OVMF to follow a plan for GPL that the whole EDK II
community decides on.

I would also like to see EDK II add a (permissively licensed; BSD,
MIT, etc) DriverPkg (DriversPkg?). We discussed this on the list
recently:

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/17544/focus=676

So, related to this, I wonder how the community would feel about a
GplDriverPkg. Would the community allow it as a new package in EDK II
directly, or would a separate repo be required?

With regards to adding it directly into the EDK II tree, here are some
potential concerns that I might anticipate hearing from the community:

* It will make it easier for contributors to choose GPL compared to a
  permissive license, thereby limiting some users of the contribution

* GPL code will more easily be copied into the permissively licensed
  packages

* Some might refuse to look at EDK II entirely if it has a directory
  with GPL source code in it

Of these, I personally only sympathize with the first.

Regarding the separate OVMF repo, my hope is that it is more of a OVMF
specific working area, rather than a 'GPL OVMF'. For example, patches
or features that we've not yet figured out how to upstream, but we
hopefully plan to.

Additionally, it makes sense to use it as needed for OVMF specific
releases. (Ie, OVMF release tags)

-Jordan

> - document the rules / justification for "ovmf" (licensing
>   conflicts, non-technical blockage on edk2 etc).
> - No new mailing list needed
> - push RH's downstream-only patches to "ovmf", wherever that makes
>   sense
> - remove encumbered FAT driver
> - import Peter Batard's GPL r/o FAT driver port of GRUB's
> - secure OpenSSL linking exception for the former from the copyright
>   holders (Peter Batard, GRUB project)
> - "ovmf" should be periodically rebased / should fetch+merge edk2 as
>   master (arguments both for and against merging); distros should
>   then track "ovmf" as their upstream, not edk2
> - get OVMF into Fedora (as pkg) and QEMU (as bundled binary)
> - do OVMF releases, maybe in sync with QEMU's releases
>   - we can probably build from known good revisions from git [Alex]
> - revive Q35 SATA driver work / poke Reza
>   - Hannes and Gabriel have refreshed patches, but their versions differ
> 
> ___
> 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 4/4] OvmfPkg: PlatformPei: take no-exec DXE settings from the QEMU command line

2015-09-14 Thread Jordan Justen

On 2015-09-11 08:15:53, Laszlo Ersek wrote:
> Control them with:
> 
>   -fw_cfg name=opt/ovmf/PcdPropertiesTableEnable,file=no.txt \
>   -fw_cfg name=opt/ovmf/PcdSetNxForStack,file=yes.txt

It seems like a -fw_cfg name=foo,content=string form could be useful
in these cases. Is this 'opt/*' method used by other fw_cfg code?

For all 5 patches:

Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>

> where the contents of the text files can be
> 
>   [0nN1yY](\n|\r\n)?
> 
> The macro trickery is not optimal, but it is caused by PcdSetBool(), which
> is itself a macro, and can only take open-coded PCD names (ie. no
> variables, like function parameters).
> 
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <ler...@redhat.com>
> ---
>  OvmfPkg/PlatformPei/PlatformPei.inf |  2 +
>  OvmfPkg/PlatformPei/Platform.c  | 65 +++-
>  2 files changed, 65 insertions(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
> b/OvmfPkg/PlatformPei/PlatformPei.inf
> index 81335a9..c2c7da9 100644
> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
> @@ -83,6 +83,8 @@ [Pcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
>gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
>gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable
>gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
>  
>  [Ppis]
> diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
> index 6a7bc52..a6d9616 100644
> --- a/OvmfPkg/PlatformPei/Platform.c
> +++ b/OvmfPkg/PlatformPei/Platform.c
> @@ -242,6 +242,68 @@ MemMapInitialization (
>}
>  }
>  
> +EFI_STATUS
> +GetNamedFwCfgBoolean (
> +  IN  CHAR8   *FwCfgFileName,
> +  OUT BOOLEAN *Setting
> +  )
> +{
> +  EFI_STATUS   Status;
> +  FIRMWARE_CONFIG_ITEM FwCfgItem;
> +  UINTNFwCfgSize;
> +  UINT8Value[3];
> +
> +  Status = QemuFwCfgFindFile (FwCfgFileName, , );
> +  if (EFI_ERROR (Status)) {
> +return Status;
> +  }
> +  if (FwCfgSize > sizeof Value) {
> +return EFI_BAD_BUFFER_SIZE;
> +  }
> +  QemuFwCfgSelectItem (FwCfgItem);
> +  QemuFwCfgReadBytes (FwCfgSize, Value);
> +
> +  if ((FwCfgSize == 1) ||
> +  (FwCfgSize == 2 && Value[1] == '\n') ||
> +  (FwCfgSize == 3 && Value[1] == '\r' && Value[2] == '\n')) {
> +switch (Value[0]) {
> +  case '0':
> +  case 'n':
> +  case 'N':
> +*Setting = FALSE;
> +return EFI_SUCCESS;
> +
> +  case '1':
> +  case 'y':
> +  case 'Y':
> +*Setting = TRUE;
> +return EFI_SUCCESS;
> +
> +  default:
> +break;
> +}
> +  }
> +  return EFI_PROTOCOL_ERROR;
> +}
> +
> +#define UPDATE_BOOLEAN_PCD_FROM_FW_CFG(TokenName)   \
> +  do {  \
> +BOOLEAN Setting;\
> +\
> +if (!EFI_ERROR (GetNamedFwCfgBoolean (  \
> +  "opt/ovmf/" #TokenName, ))) { \
> +  PcdSetBool (TokenName, Setting);  \
> +}   \
> +  } while (0)
> +
> +VOID
> +NoexecDxeInitialization (
> +  VOID
> +  )
> +{
> +  UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdPropertiesTableEnable);
> +  UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdSetNxForStack);
> +}
>  
>  VOID
>  MiscInitialization (
> @@ -438,10 +500,9 @@ InitializePlatform (
>  
>if (mBootMode != BOOT_ON_S3_RESUME) {
>  ReserveEmuVariableNvStore ();
> -
>  PeiFvInitialization ();
> -
>  MemMapInitialization ();
> +NoexecDxeInitialization ();
>}
>  
>MiscInitialization ();
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

2015-09-09 Thread Jordan Justen

On 2015-09-09 20:26:54, Andrew Fish wrote:
> > On Sep 9, 2015, at 5:41 PM, Jordan Justen <jordan.l.jus...@intel.com> wrote:
> > On 2015-09-09 16:05:20, Andrew Fish wrote:
> >> So you have a legal degree and are speaking on behalf of your
> >> employer on this subject?
> > 
> > No and no. How about you? :)
> 
> No but I have to review any code contributed to the open source
> project to make sure it follows the corporate polices.

Is Apple corporate policy that you could never contribute to a project
that has a GPL directory in the tree?

> > Nevertheless, I have not heard the interpretation that just having GPL
> > in a source tree would impact your code, even if you do not include,
> > nor link to it. Is this Apple's interpretation of how GPL works?
> 
> No but thanks for making my point for me. 1st off the rules are made
> by lawyers and managers so you trying to argue logic is kind of
> funny. What does logic have to do with it.

Whoa! What's next in this crazy world? Dogs and cats living together!
Mass hysteria! How can we be sure that the lawyers won't decide that
BSD means GPL and vice versa? ;)

> Your company started this edk2 project as a BSD project, and I
> assume there was a reason for that.

And then more licenses were added.

> The reasons rules like this end up getting made is that developers
> like you are confused about the company policy regarding open
> source, closed source and protecting intellectual property rights.
> So your very smart and well versed and you are confused, so

I don't think I'm confused (or smart :), but you are trying hard to
make it seem confusing and scary.

Anyway, you are correct. We do have rules. But, I don't think those
rules prevent us from discussing *possible* changes to those rules.

> some more jr. engineer has no hope of getting it right and would
> copy the GPL code and be clueless to what he just did. As I always
> say a development process exists to slow down the best developer, at
> the price of preventing the most jr. developers from doing something
> stupid.

If we have another repo with GplDriverPkg, then I guess the same jr.
developer might just go find the code over there and copy it.

> > I would be more worried about the GPL based drivers becoming too
> > featureful over time, and the permissively licensed code not being
> > very useful. For example, I'm worried that the non-GPL OVMF may end up
> > missing a lot of features.
> 
> Then logically you should just make OVMF a GPL project?

Not if you are someone that prefers permissive source licenses, such
as myself.

I'm basically trying to argue the other side of this to not let the
GPL FUD go by unimpeded.

Laszlo's email raised the GPL question, but I was not sure what the
EDK II community would accept with regards to GPL. Thus ... I asked. I
guess I'm getting a better idea with regards to Apple and HP. :)

In your opinion, would we be able to discuss patches for a *separate*
repo with GplDriverPkg on edk2-devel?

Thanks,

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

[edk2] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

2015-09-14 Thread Jordan Justen

Forwarded message from Laszlo Ersek (2015-09-14 03:57:01):
> On 09/12/15 01:06, Josh Triplett wrote:
> > On Fri, Sep 11, 2015 at 11:27:32PM +0200, Laszlo Ersek wrote:
> >> On 09/11/15 21:30, Josh Triplett wrote:
> >>> On a vaguely related note, what's the canonical place to report bugs in
> >>> OVMF?
> >>
> >> (Bugs? What bugs? :))
> >>
> >> It's this list, .
> > 
> > There isn't a tracker of some kind?  That's unfortunate.
> 
> I won't disagree with you, but I'll note three things:
> 
> (1) There isn't much use to a bug tracker if there aren't enough human
> resources to actually monitor that tracker, and work hard on the bugs. I
> can offer to monitor this list and work on bugs reported here the best I
> can. Bug fixing is hard and taxing; for *official* long-term bug
> tracking, some form of legal relationship is usually necessary. I do
> take my RHBZs very seriously.
> 
> (2) OvmfPkg is one platform in edk2. I don't think OVMF / OvmfPkg should
> have its own separate tracker. And regarding a tracker for the entirety
> of edk2, there used to be one (still on sf.net), and nobody (no

I think the bug tracker on sf got shut down when sf stopped supporting
their 'hosted services'. (Ie, for example, when they shut down the
hosted mediawiki service.)

> contributor or maintainer) cared. Goto (1).
> 
> (3) I've seen first hand how Fedora bug tracker entries, Debian bug
> tracker entries, and upstream QEMU bug tracker entries are handled. Goto
> (1). As I said, I try to do my best with bugs reported on the list, both
> in tracking them and in fixing them, as my load allows.
> 
> > But thanks; I'll send mail to the list when we discover an issue while
> > experimenting with BITS.
> 
> Yes, please do that. And thank you. In my experience, other package
> maintainers (not just us in OvmfPkg) are pretty responsive if you report
> bugs for their packages on the list, especially if you can narrow it
> down (bisection, good reproducer etc).
> 
> > 
> > (Also, if you don't intend to use github's issue tracker, you might want
> > to turn it off so people don't file things there and expect a response.)
> 
> That's a very good point. Jordan, can you please disable the issue
> tracker on github?

Well, there has been discussion on this topic at Intel. It is a
mentioned goal:

http://www.tianocore.org/news/2015/05/01/UnderConst.html

Some want to try to somehow run a bugzilla server. Personally, I think
the path of least resistence is to just use github's issues system. It
seems to go along with moving the source tree to git on github, and I
think their system works reasonably.

I wish github had a better system for exporting the bug data. For
example, the wiki system is a clonable git tree, and it would be great
if the issues system worked the same way.

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

Re: [edk2] [Patch 2/5] MdeModulePkg: Add ImageDecoderLib to provide image decoding service.

2015-09-28 Thread Jordan Justen

On 2015-09-28 19:35:07, Ni, Ruiyu wrote:
> Jordan,
> The NULL class library which provides real image decoding capability
> should be able to detect the image format and decide to decode it or
> not.

I don't know that every format we'll ever want to support can be
autodetected. Why not add a parameter of EFI_BADGING_FORMAT? If
EfiBadgingFormatUnknown is provided, then the decode library can
optionally support auto-detecting the image type.

-Jordan

> And it can also work with LogoLib::EnableQuietBoot() which supports
> caller supply a PCD pointing to an image file.
> 
> Thanks,
> Ray
> 
> -Original Message-
> From: Justen, Jordan L 
> Sent: Tuesday, September 29, 2015 2:11 AM
> To: Ni, Ruiyu ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Tian, Feng 
> Subject: Re: [edk2] [Patch 2/5] MdeModulePkg: Add ImageDecoderLib to provide 
> image decoding service.
> 
> On 2015-09-24 23:49:32, Ruiyu Ni wrote:
> > The library itself doesn't provide any image decoding capabilities but
> > manages the different image decoders.
> > 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Ruiyu Ni 
> > Cc: Feng Tian 
> > ---
> >  MdeModulePkg/Include/Library/ImageDecoderLib.h |  72 +
> >  .../Library/ImageDecoderLib/ImageDecoderLib.c  | 119 
> > +
> >  .../Library/ImageDecoderLib/ImageDecoderLib.inf|  42 
> >  MdeModulePkg/MdeModulePkg.dec  |   4 +
> >  MdeModulePkg/MdeModulePkg.dsc  |   2 +
> >  5 files changed, 239 insertions(+)
> >  create mode 100644 MdeModulePkg/Include/Library/ImageDecoderLib.h
> >  create mode 100644 MdeModulePkg/Library/ImageDecoderLib/ImageDecoderLib.c
> >  create mode 100644 MdeModulePkg/Library/ImageDecoderLib/ImageDecoderLib.inf
> > 
> > diff --git a/MdeModulePkg/Include/Library/ImageDecoderLib.h 
> > b/MdeModulePkg/Include/Library/ImageDecoderLib.h
> > new file mode 100644
> > index 000..522e3cf
> > --- /dev/null
> > +++ b/MdeModulePkg/Include/Library/ImageDecoderLib.h
> > @@ -0,0 +1,72 @@
> > +/** @file
> > +  This library provides image decoding service by managing the different
> > +  image decoding libraries.
> > +
> > +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 that 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 __IMAGE_DECODER_LIB_H__
> > +#define __IMAGE_DECODER_LIB_H__
> > +
> > +typedef
> > +EFI_STATUS
> > +(EFIAPI *DECODE_IMAGE)(
> > +  IN  UINT8 *Image,
> > +  IN  UINTN ImageSize,
> > +  OUT EFI_GRAPHICS_OUTPUT_BLT_PIXEL **GopBlt,
> > +  OUT UINTN *GopBltSize,
> > +  OUT UINTN *PixelWidth,
> > +  OUT UINTN *PixelHeight
> > +  );
> 
> Shouldn't the image format be an input?
> 
> > +/**
> > +  Convert a graphics image to a callee allocated GOP blt buffer.
> > +
> > +  @param  Image Pointer to image file
> > +  @param  ImageSize Number of bytes in Image
> > +  @param  GopBltBuffer containing GOP version of Image.
> > +  @param  GopBltSizeSize of GopBlt in bytes.
> > +  @param  PixelWidthWidth of GopBlt/Image in pixels.
> > +  @param  PixelHeight   Height of GopBlt/Image in pixels.
> > +
> > +  @retval EFI_SUCCESS   GopBlt and GopBltSize are returned.
> > +  @retval EFI_INVALID_PARAMETER GopBlt or GopBltSize is NULL.
> > +  @retval EFI_INVALID_PARAMETER Image is NULL or ImageSize is 0.
> > +  @retval EFI_UNSUPPORTED   Image is not supported.
> > +  @retval EFI_OUT_OF_RESOURCES  No enough buffer to allocate.
> > +
> > +**/
> > +EFI_STATUS
> > +EFIAPI
> > +DecodeImage (
> > +  IN  UINT8 *Image,
> > +  IN  UINTN ImageSize,
> > +  OUT EFI_GRAPHICS_OUTPUT_BLT_PIXEL **GopBlt,
> > +  OUT UINTN *GopBltSize,
> > +  OUT UINTN *PixelWidth,
> > +  OUT UINTN *PixelHeight
> > +  );
> 
> And here too.
> 
> -Jordan
> 
> > +/**
> > +  Register an image decoder.
> > +
> > +  @param Decoder  An image decoder.
> > +
> > +  @retval EFI_SUCCESS  The decoder was successfully registered.
> > +  @retval EFI_OUT_OF_RESOURCES No enough resource to register the decoder.
> > +
> > +**/
> > +EFI_STATUS
> > +EFIAPI
> > +RegisterImageDecoder (
> > +  IN  DECODE_IMAGE Decoder
> > +  );
> > +
> > +#endif
> > diff --git

Re: [edk2] [Patch 1/5] MdeModulePkg: Move OEMBadging protocol from IntelFrameworkModulePkg

2015-09-29 Thread Jordan Justen

On 2015-09-28 21:30:46, Ni, Ruiyu wrote:
> Jordan,
> I see lots of comments raised from you. Can you list all of your
> concerns which may result changing the patch?

* How about PlatformLogoProtocol rather than OEMBadgingProtocol?

* How about adding the image format to the ImageDecoderLib interface?

* I think EfiBadgingFormatUnknown should be set to a large number so
  new image types can be added.

* Another idea I had was that maybe instead of EFI_BADGING_FORMAT, we
  could just use mime type string?

https://www.iana.org/assignments/media-types/media-types.xhtml#image

For example:
 - "image/jpeg"
 - "image/png"

https://msdn.microsoft.com/en-us/library/windows/desktop/gg430020(v=vs.85).aspx

 - "image/bmp"

I guess a NULL would have to be used for unknown...

> Because I do not have any idea what your intention is for the
> following words.
> " Those existing drivers also have the IntelFrameworkModulePkg.dec
> listed, so they can easily continue to use the OEMBadging protocol
> until they are updated for the MdeModulePkg version."

I meant, we also have backward compatibility if we make a new
protocol. The code using the old OEMBadgingProtocol will still be
able to use the old protocol until it gets upgraded.

> " I never know the rules for MdePkg and MdeModulePkg. They seem to
> be arbitrarily applied anyhow."

This was a question to Mike and Liming. MdePkg and MdeModulePkg seem
to have some rules about what can be added. Sometimes things are
rejected if they don't connect to a spec. But, I don't know exactly
how those rules work.

-Jordan

> -Original Message-
> From: Justen, Jordan L 
> Sent: Tuesday, September 29, 2015 12:08 PM
> To: Ni, Ruiyu ; edk2-devel@lists.01.org
> Cc: Tian, Feng ; Fan, Jeff ; Kinney, 
> Michael D ; Gao, Liming 
> Subject: RE: [edk2] [Patch 1/5] MdeModulePkg: Move OEMBadging protocol from 
> IntelFrameworkModulePkg
> 
> On 2015-09-28 19:32:25, Ni, Ruiyu wrote:
> > Jordan,
> > I forgot to include the OEMBadging.h in the patch. But yes the file
> > will be moved to MdeModulePkg/Include/Protocol/OEMBadging.h.
> 
> I think the patch should be resubmitted to correct this.
> 
> > I didn't change the name in order to maintain the best backward
> > compatibililty.
> 
> Why is this required, or desirable?
> 
> This seems like an opportunity to clean it up.
> 
> > Those existing drivers which produce the protocol doesn't need to
> > change. (most of them already have MdeModulePkg.dec dependency in
> > the INF file).
> 
> Those existing drivers also have the IntelFrameworkModulePkg.dec
> listed, so they can easily continue to use the OEMBadging protocol
> until they are updated for the MdeModulePkg version.
> 
> > No it's not a spec defined protocol. so it's in MdeModulePkg. What's
> > your concerns for this?
> 
> I never know the rules for MdePkg and MdeModulePkg. They seem to be
> arbitrarily applied anyhow.
> 
> -Jordan
> 
> > -Original Message-
> > From: Justen, Jordan L 
> > Sent: Tuesday, September 29, 2015 2:01 AM
> > To: Ni, Ruiyu ; edk2-devel@lists.01.org
> > Cc: Ni, Ruiyu ; Tian, Feng ; Fan, 
> > Jeff ; Kinney, Michael D ; 
> > Gao, Liming 
> > Subject: Re: [edk2] [Patch 1/5] MdeModulePkg: Move OEMBadging protocol from 
> > IntelFrameworkModulePkg
> > 
> > It doesn't look like you actually moved
> > IntelFrameworkModulePkg/Include/Protocol/OEMBadging.h.
> > 
> > Is the name 'OEMBadging' appropriate?
> > 
> > For one, I think the code style would indicate OemBadging should be
> > used instead.
> > 
> > Second, I don't think 'OEM' should be used in the name.
> > 
> > Third, I guess this doesn't have to be a spec'd protocol because it is
> > in MdeModulePkg? (As opposed to MdePkg?)
> > 
> > -Jordan
> > 
> > On 2015-09-24 23:49:31, Ruiyu Ni wrote:
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Ruiyu Ni 
> > > Cc: Feng Tian 
> > > Cc: Jeff Fan 
> > > ---
> > >  IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec | 4 
> > >  MdeModulePkg/MdeModulePkg.dec   | 4 
> > >  2 files changed, 4 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec 
> > > b/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
> > > index 8bbde8e..3d6c46e 100644
> > > --- a/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
> > > +++ b/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
> > > @@ -95,10 +95,6 @@
> > >#  Include/Protocol/Ps2Policy.h
> > >gEfiPs2PolicyProtocolGuid  = { 0x4DF19259, 0xDC71, 0x4D46, { 0xBE, 
> > > 0xF1, 0x35, 0x7B, 0xB5, 0x78, 0xC4, 0x18 }}
> > >  
> > > -  ## OEM Badging Protocol defines the interface to get the OEM badging 
> > > image

Re: [edk2] [Patch 1/5] MdeModulePkg: Move OEMBadging protocol from IntelFrameworkModulePkg

2015-09-28 Thread Jordan Justen

On 2015-09-28 19:32:25, Ni, Ruiyu wrote:
> Jordan,
> I forgot to include the OEMBadging.h in the patch. But yes the file
> will be moved to MdeModulePkg/Include/Protocol/OEMBadging.h.

I think the patch should be resubmitted to correct this.

> I didn't change the name in order to maintain the best backward
> compatibililty.

Why is this required, or desirable?

This seems like an opportunity to clean it up.

> Those existing drivers which produce the protocol doesn't need to
> change. (most of them already have MdeModulePkg.dec dependency in
> the INF file).

Those existing drivers also have the IntelFrameworkModulePkg.dec
listed, so they can easily continue to use the OEMBadging protocol
until they are updated for the MdeModulePkg version.

> No it's not a spec defined protocol. so it's in MdeModulePkg. What's
> your concerns for this?

I never know the rules for MdePkg and MdeModulePkg. They seem to be
arbitrarily applied anyhow.

-Jordan

> -Original Message-
> From: Justen, Jordan L 
> Sent: Tuesday, September 29, 2015 2:01 AM
> To: Ni, Ruiyu ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Tian, Feng ; Fan, 
> Jeff ; Kinney, Michael D ; 
> Gao, Liming 
> Subject: Re: [edk2] [Patch 1/5] MdeModulePkg: Move OEMBadging protocol from 
> IntelFrameworkModulePkg
> 
> It doesn't look like you actually moved
> IntelFrameworkModulePkg/Include/Protocol/OEMBadging.h.
> 
> Is the name 'OEMBadging' appropriate?
> 
> For one, I think the code style would indicate OemBadging should be
> used instead.
> 
> Second, I don't think 'OEM' should be used in the name.
> 
> Third, I guess this doesn't have to be a spec'd protocol because it is
> in MdeModulePkg? (As opposed to MdePkg?)
> 
> -Jordan
> 
> On 2015-09-24 23:49:31, Ruiyu Ni wrote:
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Ruiyu Ni 
> > Cc: Feng Tian 
> > Cc: Jeff Fan 
> > ---
> >  IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec | 4 
> >  MdeModulePkg/MdeModulePkg.dec   | 4 
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec 
> > b/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
> > index 8bbde8e..3d6c46e 100644
> > --- a/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
> > +++ b/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
> > @@ -95,10 +95,6 @@
> >#  Include/Protocol/Ps2Policy.h
> >gEfiPs2PolicyProtocolGuid  = { 0x4DF19259, 0xDC71, 0x4D46, { 0xBE, 
> > 0xF1, 0x35, 0x7B, 0xB5, 0x78, 0xC4, 0x18 }}
> >  
> > -  ## OEM Badging Protocol defines the interface to get the OEM badging 
> > image with the dispaly attribute.
> > -  #  Include/Protocol/OEMBadging.h
> > -  gEfiOEMBadgingProtocolGuid = { 0x170E13C0, 0xBF1B, 0x4218, { 0x87, 
> > 0x1D, 0x2A, 0xBD, 0xC6, 0xF8, 0x87, 0xBC }}
> > -
> >## Include/Protocol/ExitPmAuth.h
> >gExitPmAuthProtocolGuid= { 0xd088a413, 0xa70, 0x4217, { 0xba, 
> > 0x55, 0x9a, 0x3c, 0xb6, 0x5c, 0x41, 0xb3 }}
> >  
> > diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> > index 3dfcd6a..862b993 100644
> > --- a/MdeModulePkg/MdeModulePkg.dec
> > +++ b/MdeModulePkg/MdeModulePkg.dec
> > @@ -449,6 +449,10 @@
> >## Include/Protocol/SmmReadyToBoot.h
> >gEdkiiSmmReadyToBootProtocolGuid = { 0x6e057ecf, 0xfa99, 0x4f39, { 0x95, 
> > 0xbc, 0x59, 0xf9, 0x92, 0x1d, 0x17, 0xe4 } }
> >  
> > +  ## OEM Badging Protocol defines the interface to get the OEM badging 
> > image with the dispaly attribute.
> > +  #  Include/Protocol/OEMBadging.h
> > +  gEfiOEMBadgingProtocolGuid = { 0x170E13C0, 0xBF1B, 0x4218, { 0x87, 
> > 0x1D, 0x2A, 0xBD, 0xC6, 0xF8, 0x87, 0xBC }}
> > +
> >  #
> >  # [Error.gEfiMdeModulePkgTokenSpaceGuid]
> >  #   0x8001 | Invalid value provided.
> > -- 
> > 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 4/5] MdeModulePkg: Add LogoLib to provide interfaces about LOGO display.

2015-09-30 Thread Jordan Justen

On 2015-09-24 23:49:34, Ruiyu Ni wrote:
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Feng Tian 
> ---
>  MdeModulePkg/Include/Library/LogoLib.h   |  80 +
>  MdeModulePkg/Library/LogoLib/LogoLib.c   | 584 
> +++
>  MdeModulePkg/Library/LogoLib/LogoLib.inf |  59 
>  MdeModulePkg/MdeModulePkg.dec|   4 +
>  MdeModulePkg/MdeModulePkg.dsc|   1 +
>  5 files changed, 728 insertions(+)
>  create mode 100644 MdeModulePkg/Include/Library/LogoLib.h
>  create mode 100644 MdeModulePkg/Library/LogoLib/LogoLib.c
>  create mode 100644 MdeModulePkg/Library/LogoLib/LogoLib.inf
> 
> diff --git a/MdeModulePkg/Include/Library/LogoLib.h 
> b/MdeModulePkg/Include/Library/LogoLib.h
> new file mode 100644
> index 000..a2af449
> --- /dev/null
> +++ b/MdeModulePkg/Include/Library/LogoLib.h
> @@ -0,0 +1,80 @@
> +/** @file
> +  This library is only intended to be used by PlatformBootManagerLib
> +  to show progress bar and LOGO.
> +
> +Copyright (c) 2011 - 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 that 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 _LOGO_LIB_H_
> +#define _LOGO_LIB_H_
> +
> +#include 
> +
> +/**
> +  Show LOGO on all consoles.
> +
> +  @param[in]  LogoFileThe file name of logo to display.
> +  @param[in]  Attribute   The display attributes of the image returned.
> +  @param[in]  CoordinateX The X coordinate of the image.
> +  @param[in]  CoordinateY The Y coordinate of the image.
> +
> +  @retval EFI_SUCCESS Logo was displayed.
> +  @retval EFI_UNSUPPORTED Logo was not found or cannot be displayed.
> +**/
> +EFI_STATUS
> +EFIAPI
> +EnableQuietBoot (
> +  IN  EFI_GUID  *Logo,
> +  IN  EFI_BADGING_DISPLAY_ATTRIBUTE Attribute,
> +  IN  UINTN CoordinateX,
> +  IN  UINTN CoordinateY
> +  );
> +
> +
> +/**
> +  Use SystemTable ConOut to turn on video based Simple Text Out consoles. 
> The 
> +  Simple Text Out screens will now be synced up with all non-video output 
> devices.
> +
> +  @retval EFI_SUCCESS UGA devices are back in text mode and synced up.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +DisableQuietBoot (
> +  VOID
> +  );
> +
> +/**
> +
> +  Show progress bar with title above it. It only works in Graphics mode.
> +
> +  @param TitleForeground Foreground color for Title.
> +  @param TitleBackground Background color for Title.
> +  @param Title   Title above progress bar.
> +  @param ProgressColor   Progress bar color.
> +  @param ProgressProgress (0-100)
> +  @param PreviousValue   The previous value of the progress.
> +
> +  @retval  EFI_STATUSSuccessly update the progress bar
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +ShowProgress (
> +  IN EFI_GRAPHICS_OUTPUT_BLT_PIXEL TitleForeground,
> +  IN EFI_GRAPHICS_OUTPUT_BLT_PIXEL TitleBackground,
> +  IN CHAR16*Title,
> +  IN EFI_GRAPHICS_OUTPUT_BLT_PIXEL ProgressColor,
> +  IN UINTN Progress,
> +  IN UINTN PreviousValue
> +  );

Don't we usually want to have the library interface name somewhere in
the function names?

For example, maybe LogoShowProgress? Same for functions above...

-Jordan

> +#endif
> +
> diff --git a/MdeModulePkg/Library/LogoLib/LogoLib.c 
> b/MdeModulePkg/Library/LogoLib/LogoLib.c
> new file mode 100644
> index 000..e73df45
> --- /dev/null
> +++ b/MdeModulePkg/Library/LogoLib/LogoLib.c
> @@ -0,0 +1,584 @@
> +/** @file
> +  This library is only intended to be used by PlatformBootManagerLib
> +  to show progress bar and LOGO.
> +
> +Copyright (c) 2011 - 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 that 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 
> +
> +/**
> +  Show LOGO on all consoles.
> +
> +  @param[in]  LogoFileThe file name of logo to display.
> +  @param[in]  Attribute   The display attributes of the image returned.
> +  @param[in]  CoordinateX

Re: [edk2] [PATCH] OvmfPkg: set 4 KB section alignment for DXE_RUNTIME modules

2015-09-29 Thread Jordan Justen

On 2015-09-29 09:59:48, Ard Biesheuvel wrote:
> On 29 September 2015 at 18:48, Laszlo Ersek <ler...@redhat.com> wrote:
> > On 09/29/15 18:05, Ard Biesheuvel wrote:
> >>
> >> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> >> index 5d651e30cdff..77fd21cd5968 100644
> >> --- a/OvmfPkg/OvmfPkgIa32.dsc
> >> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> >> @@ -44,6 +44,9 @@ [BuildOptions]
> >>MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
> >>GCC:*_*_*_CC_FLAGS   = -mno-mmx -mno-sse
> >>
> >> +[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> >> +  GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000

Not a comment on your patch, but I still think this enabling process
seems odd. It seems like something that EDK II should support better.
A platform should enable by a switch that then causes BaseTools to do
the right thing, rather than requiring every platform to override
toolchain flags.

Also, what does "EDKII" mean here? It seems to serve no good purpose.
I guess we could just throw "EDKII" as a field into every option in
every file. :)

Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>

> >
> > ... In addition, that's going to happen only when building OVMF with
> > gcc.
> 
> Liming mentioned this as well when he reviewed a predecessor patch here:
> http://thread.gmane.org/gmane.comp.bios.edk2.devel/1355

Yeah, I think we should add it for VS as well. I guess the syntax is
known:

http://permalink.gmane.org/gmane.comp.bios.tianocore.devel/16623

Maybe Liming can identify someone that can help test & patch it?

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

Re: [edk2] [Patch 1/5] MdeModulePkg: Move OEMBadging protocol from IntelFrameworkModulePkg

2015-09-29 Thread Jordan Justen

On 2015-09-29 01:53:38, Gao, Liming wrote:
> -Original Message-
> From: Justen, Jordan L 
> Sent: Tuesday, September 29, 2015 2:40 PM
> To: Ni, Ruiyu; edk2-devel@lists.01.org
> Cc: Tian, Feng; Fan, Jeff; Kinney, Michael D; Gao, Liming
> Subject: RE: [edk2] [Patch 1/5] MdeModulePkg: Move OEMBadging protocol from 
> IntelFrameworkModulePkg
> 
> On 2015-09-28 21:30:46, Ni, Ruiyu wrote:
> > Jordan,
> > I see lots of comments raised from you. Can you list all of your 
> > concerns which may result changing the patch?
> 
> * How about PlatformLogoProtocol rather than OEMBadgingProtocol?
> Liming: I prefer to keep old name if no special reason. 

The special reason is that we should take the opportunity to clean
things up before adding them to MdeModulePkg.

I see two problems with OEMBadging.

1. It doesn't match the coding style. (OemBadging would)

2. The feature is not directly related to an 'OEM'. It is really just
   a way for the platform to provide a logo to use on the screen
   during boot.

Another option might be PlatformBadging. I think the 'badging'
terminology is little odd, but that is not as odd as including 'OEM'
in the name.

> * How about adding the image format to the ImageDecoderLib interface?
> Liming: agree.
> 
> * I think EfiBadgingFormatUnknown should be set to a large number so
>   new image types can be added.
> Liming: agree
> 
> * Another idea I had was that maybe instead of EFI_BADGING_FORMAT, we
>   could just use mime type string?
> Liming: I think it is easier to compare value instead of string.

I agree. I just thought it could be good to leverage pre-existing
industry terminology.

At a minimum, EfiBadgingFormatBMP really should be renamed to
EfiBadgingFormatBmp.

We could also use:

EfiLogoFormatImageBmp, EfiLogoFormatImageJpeg, EfiLogoFormatImagePng,
EfiLogoFormatImageTiff

-Jordan

> 
> https://www.iana.org/assignments/media-types/media-types.xhtml#image
> 
> For example:
>  - "image/jpeg"
>  - "image/png"
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/gg430020(v=vs.85).aspx
> 
>  - "image/bmp"
> 
> I guess a NULL would have to be used for unknown...
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

2015-09-09 Thread Jordan Justen

On 2015-09-09 10:04:50, Andrew Fish wrote:
> 
> > On Sep 9, 2015, at 9:17 AM, Jordan Justen <jordan.l.jus...@intel.com> wrote:
> > 
> > So, related to this, I wonder how the community would feel about a
> > GplDriverPkg. Would the community allow it as a new package in EDK II
> > directly, or would a separate repo be required?
> > 
> 
> I think we would need a separate repo, like the FAT driver. That is
> the only way to deal with the license issues.

There doesn't seem to be any guiding rules here. For example, I think
some people are not comfortable with the FatBinPkg being in the tree
due to the license. Why is that okay?

> > With regards to adding it directly into the EDK II tree, here are some
> > potential concerns that I might anticipate hearing from the community:
> > 
> > * It will make it easier for contributors to choose GPL compared to a
> >  permissive license, thereby limiting some users of the contribution
> > 
> > * GPL code will more easily be copied into the permissively licensed
> >  packages
> > 
> > * Some might refuse to look at EDK II entirely if it has a directory
> >  with GPL source code in it
> > 
> 
> Or have their rights to contribute revoked since this is a
> fundamental change, and would require employees to get reauthorized
> by their legal departments to contribute.

We've recently expanded beyond just allowing BSD code into the tree,
and that appeared to be no big deal. No one brought this up as a
fundamental change.

Just to be clear, are you saying Apple probably won't be able to
contribute to EDK II if there is any GPL licensed code in the tree?
(Even if it is contained in a clearly indicated package.) I guess
using dual-licensed BSD/GPL is okay though?
(EmbeddedPkg/Library/FdtLib)

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

Re: [edk2] [PATCH v4 00/10] OvmfPkg: support for Q35 SATA

2015-09-18 Thread Jordan Justen

Laszlo, thanks for both resurrecting and cleaning up this series. :)

And Reza, thanks for getting it working originally!

I had a minor note on 06/10, but series

Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>

On 2015-09-15 19:57:20, Laszlo Ersek wrote:
> I've gone through Reza's v3 posting with extreme care, and also through
> the feedback that series elicited.
> 
> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10545
> 
> Ultimately I've preserved the mostly uncontested patches (v3 1/5, v3
> 2/5, v3 5/5), although I placed them in a more logical / bisectable
> order, plus I updated the commit messages extensively, and squashed in a
> fix from Feng where it was appropriate.
> 
> The controversial patches (v3 3/5, v3 4/5) I've simply dropped, and
> instead of those I implemented Feng's recommendations the best I could
> (see the precise references broken out in the patches). This allowed me
> to avoid touching AhciModeInitialization().
> 
> I also sprinkled a few fixes (cosmetic or otherwise) over DuetPkg and
> PcAtChipsetPkg, plus extended QemuBootOrderLib so that it covers Q35
> SATA disks and CD-ROMs.
> 
> Reza: in
> <http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10545/focus=10818>
> you mentioned an OVMF "lock up"; on 2014-10-29. I think that *might*
> have been an issue that Hannes fixed later in QEMU; see commit 702c8c8b
> ("ahci: Fix CD-ROM signature").
> 
> Hannes, Gabriel: I've determined that the patches you've been using
> correspond to Reza's v1 and v2 postings. (I forget which one of you has
> been using which one of v1 vs. v2; the point is, none of those were v3.
> In any case, grab v4.)
> 
> Public branch: <https://github.com/lersek/edk2/commits/sata_v4>.
> 
> NOTE: You will also need the following QEMU bugfix for this to work:
> <http://thread.gmane.org/gmane.comp.emulators.qemu.block/4327>.

What's the impact without the QEMU fix?

-Jordan

> Testing with various guest OSes is welcome. I tested Fedora (installer
> CD-ROM and installed disk). I also did some light-weight regression
> testing with i440fx IDE devices.
> 
> "Enjoy", I guess. :)
> 
> Cc: Alexander Graf <ag...@suse.de>
> Cc: Reza Jelveh <reza.jel...@tuhh.de>
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Hannes Reinecke <h...@suse.de>
> Cc: Gabriel L. Somlo <so...@cmu.edu>
> Cc: Feng Tian <feng.t...@intel.com>
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (7):
>   DuetPkg: SataControllerDxe: fix typo in "DisqulifiedModes"
>   DuetPkg: SataControllerDxe: fix private array subscripting
>   OvmfPkg: SataControllerDxe: add cascading error handling to Start()
>   OvmfPkg: SataControllerDxe: enable IO / mem access and DMA when
> binding
>   OvmfPkg: SataControllerDxe: enable AHCI mode if IS_PCI_SATADPA()
>   PcAtChipsetPkg: IdeControllerDxe: fix protocol usage hints in the INF
> file
>   OvmfPkg: QemuBootOrderLib: recognize Q35 SATA disks / CD-ROMs
> 
> Reza Jelveh (3):
>   OvmfPkg: copy SataControllerDxe from DuetPkg
>   MdeModulePkg: AtaAtapiPassThru: select master/slave around DIAG
> command
>   OvmfPkg: enable SATA controller
> 
>  {DuetPkg => OvmfPkg}/SataControllerDxe/SataControllerDxe.inf |   2 +-
>  PcAtChipsetPkg/Bus/Pci/IdeControllerDxe/IdeControllerDxe.inf |   4 +-
>  DuetPkg/SataControllerDxe/SataController.h   |   2 +-
>  {DuetPkg => OvmfPkg}/SataControllerDxe/SataController.h  |   9 +-
>  DuetPkg/SataControllerDxe/SataController.c   |  74 +++--
>  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c  |   5 +
>  OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c  |  43 +
>  {DuetPkg => OvmfPkg}/SataControllerDxe/ComponentName.c   |   0
>  {DuetPkg => OvmfPkg}/SataControllerDxe/SataController.c  | 172 
> +++-
>  OvmfPkg/OvmfPkgIa32.dsc  |   5 +-
>  OvmfPkg/OvmfPkgIa32.fdf  |   5 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc   |   5 +-
>  OvmfPkg/OvmfPkgIa32X64.fdf   |   5 +-
>  OvmfPkg/OvmfPkgX64.dsc   |   5 +-
>  OvmfPkg/OvmfPkgX64.fdf   |   5 +-
>  15 files changed, 267 insertions(+), 74 deletions(-)
>  copy {DuetPkg => OvmfPkg}/SataControllerDxe/SataControllerDxe.inf (91%)
>  copy {DuetPkg => OvmfPkg}/SataControllerDxe/SataController.h (96%)
>  copy {DuetPkg => OvmfPkg}/SataControllerDxe/ComponentName.c (100%)
>  copy {DuetPkg => OvmfPkg}/SataControllerDxe/SataController.c (85%)
> 
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 06/10] OvmfPkg: SataControllerDxe: enable AHCI mode if IS_PCI_SATADPA()

2015-09-18 Thread Jordan Justen

On 2015-09-15 19:57:26, Laszlo Ersek wrote:
> The location of the Global HBA Control register, and the AHCI Enable bit
> value come from the AHCI 1.3.1 spec. They are kept together with the
> existing macros in the header file.
> 
> This patch completes the implementation of the ideas that Feng shared in
> <http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10545/focus=10659>.
> 
> Cc: Alexander Graf <ag...@suse.de>
> Cc: Reza Jelveh <reza.jel...@tuhh.de>
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Cc: Hannes Reinecke <h...@suse.de>
> Cc: Gabriel L. Somlo <so...@cmu.edu>
> Cc: Feng Tian <feng.t...@intel.com>
> Suggested-by: Feng Tian <feng.t...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <ler...@redhat.com>
> ---
>  OvmfPkg/SataControllerDxe/SataController.h | 2 ++
>  OvmfPkg/SataControllerDxe/SataController.c | 6 ++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/OvmfPkg/SataControllerDxe/SataController.h 
> b/OvmfPkg/SataControllerDxe/SataController.h
> index e5b719e..96589ea 100644
> --- a/OvmfPkg/SataControllerDxe/SataController.h
> +++ b/OvmfPkg/SataControllerDxe/SataController.h
> @@ -40,6 +40,8 @@ extern EFI_COMPONENT_NAME2_PROTOCOL 
> gSataControllerComponentName2;
>  #define R_AHCI_CAP 0x0
>  #define   B_AHCI_CAP_NPS (BIT4 | BIT3 | BIT2 | BIT1 | BIT0) // Number of 
> Ports
>  #define   B_AHCI_CAP_SPM BIT17 // Supports Port Multiplier
> +#define R_AHCI_GHC 0x4
> +#define   B_AHCI_GHC_AE BIT31

Maybe use the same #define names as:

MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.h

Or, why not create MdePkg/Include/IndustryStandard/Ahci.h?

-Jordan

>  ///
>  /// AHCI each channel can have up to 1 device
> diff --git a/OvmfPkg/SataControllerDxe/SataController.c 
> b/OvmfPkg/SataControllerDxe/SataController.c
> index 275b527..6a4971d 100644
> --- a/OvmfPkg/SataControllerDxe/SataController.c
> +++ b/OvmfPkg/SataControllerDxe/SataController.c
> @@ -475,6 +475,12 @@ SataControllerStart (
>  SataPrivateData->DeviceCount = IDE_MAX_DEVICES;
>} else if (IS_PCI_SATADPA ()) {
>  //
> +// Enable AHCI mode.
> +//
> +AhciWriteReg (PciIo, R_AHCI_GHC,
> +  AhciReadReg (PciIo, R_AHCI_GHC) | B_AHCI_GHC_AE);
> +
> +//
>  // Read Host Capability Register(CAP) to get Number of Ports(NPS) and 
> Supports Port Multiplier(SPM)
>  //   NPS is 0's based value indicating the maximum number of ports 
> supported by the HBA silicon.
>  //   A maximum of 32 ports can be supported. A value of '0h', indicating 
> one port, is the minimum requirement.
> -- 
> 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 2/2] EmulatorPkg/build.sh: Use GCC49 toolchain with GCC 5.*

2015-09-18 Thread Jordan Justen

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Andrew Fish <af...@apple.com>
---
 EmulatorPkg/build.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmulatorPkg/build.sh b/EmulatorPkg/build.sh
index 5b3992c..c59c6b1 100755
--- a/EmulatorPkg/build.sh
+++ b/EmulatorPkg/build.sh
@@ -105,7 +105,7 @@ case `uname` in
   4.8.*)
 TARGET_TOOLS=GCC48
 ;;
-  4.9.*|4.1[0-9].*)
+  4.9.*|4.1[0-9].*|5.*.*)
 TARGET_TOOLS=GCC49
 ;;
   *)
-- 
2.5.0

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

Re: [edk2] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

2015-09-23 Thread Jordan Justen

On 2015-09-23 15:40:03,  wrote:
> On Wed, Sep 23, 2015 at 11:37:54AM -0600, Bruce Cran wrote:
> > On 9/14/15 11:15 PM, Bruce Cran wrote:
> > >On 9/14/15 11:13 PM, Josh Triplett wrote:
> > >
> > >>Whether running a standalone system or a hosted service, I don't think
> > >>it makes sense to use one completely separate from code hosting.  If
> > >>you're using github for code, it makes sense to use github for issues;
> > >>if you were using Phabricator for code review and maintenance, then
> > >>using it for issues makes sense.
> > >
> > >Agreed. For me, the nice thing about Phabricator is that it can either
> > >host or mirror both Git and SVN repositories.
> > >
> > >But if people would prefer to use Github then I'd be happy with that
> > >too, just as long as there's *some* way to track bugs that isn't an
> > >email archive!
> > 
> > Ping? Should we set up test systems of either/both and see which
> > people prefer? Or do we need a "benevolent dictator" to just make a
> > decision and have people implement it?
> 
> The latter, I suspect, if we want it to happen.  But I think the more
> important decision is "what's the canonical code hosting and
> review/merge tool?", and issue tracking should follow.  If the canonical
> home of the code is on Github, use Github issues;

I think there is about a good chance that
https://github.com/tianocore/edk2 will become the primary upstream
location for EDK II by the end of the year.

I agree with you that we should just take the easy/obvious path and
use https://github.com/tianocore/edk2/issues for issues once we are
sure that we are moving to github hosting.

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

Re: [edk2] [PATCH] BaseTools: GCC: drop "asm" suffixes from BUILDRULEORDER

2015-12-07 Thread Jordan Justen

On 2015-12-07 07:03:47, Laszlo Ersek wrote:
> After SVN r17510 ("BaseTools: Add default BuildRuleOrder in
> tools_def.template") and SVN r17544 ("BaseTools/Conf: Don't support upper
> case nasm extensions"), the following suffix priorities were in place:
> 
> - For XCODE32, XCLANG, XCODE5: S s nasm
> - Other toolchains: nasm asm Asm ASM S s
> 
> When building assembly files with the GCC toolchains, the priority order
> on the second line above was active.
> 
> Due to SVN r19143 ("BaseTools: process the files by the priority in
> BUILDRULEORDER"), AutoGen.py now only selects the source file for building
> whose suffix matches BUILDRULEORDER first, regardless of whether the
> toolchain has a utility to build files with that suffix.
> 
> This has regressed the build of at least
> "UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf":
> 
>   [Sources.IA32]
> Ia32/InitializeFpu.asm
> Ia32/InitializeFpu.S
> 
>   [Sources.X64]
> X64/InitializeFpu.asm
> X64/InitializeFpu.S
> 
> In this case, AutoGen.py selects the *.asm files for building:
> - the INF file associates no toolchain families with the source files,
> - there is no assembly file with "nasm" suffix,
> - the "asm" suffix comes before "S" in the priority order (see near the
>   top).
> 
> Specialize the build rule order for GCC toolchains by removing the "asm"
> suffixes from between "nasm" and "S".

I think this is a bug in the BUILDRULEORDER implementation. It should
still ignore .asm for toolchain families that don't have a build rule
for that extension.

But, in the commit message for r17509 / fe4bf2f9, it says:

"Note that the build_rule.txt file also impacts the decision, because,
 for instance there is no build rule for .asm files on GCC
 toolchains."

Which sounds like .asm files should be ignored for GCC families.

-Jordan

> 
> Cc: Yonghong Zhu <yonghong@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <ler...@redhat.com>
> ---
>  BaseTools/Conf/tools_def.template | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index 1a44fbd..e5e89f1 100644
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -4540,6 +4540,7 @@ DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = 
> DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
>  #
>  
> 
>  *_GCC44_*_*_FAMILY   = GCC
> +*_GCC44_*_*_BUILDRULEORDER   = nasm S s
>  
>  *_GCC44_*_MAKE_PATH= DEF(GCC44_IA32_PREFIX)make
>  *_GCC44_*_*_DLL= ENV(GCC44_DLL)
> @@ -4610,6 +4611,7 @@ DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = 
> DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
>  #
>  
> 
>  *_GCC45_*_*_FAMILY   = GCC
> +*_GCC45_*_*_BUILDRULEORDER   = nasm S s
>  
>  *_GCC45_*_MAKE_PATH= DEF(GCC45_IA32_PREFIX)make
>  *_GCC45_*_*_DLL= ENV(GCC45_DLL)
> @@ -4680,6 +4682,7 @@ DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = 
> DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
>  #
>  
> 
>  *_GCC46_*_*_FAMILY   = GCC
> +*_GCC46_*_*_BUILDRULEORDER   = nasm S s
>  
>  *_GCC46_*_MAKE_PATH= DEF(GCC46_IA32_PREFIX)make
>  *_GCC46_*_*_DLL= ENV(GCC46_DLL)
> @@ -4781,6 +4784,7 @@ RELEASE_GCC46_ARM_CC_FLAGS   = 
> DEF(GCC46_ARM_CC_FLAGS) -D__ARM_FEATURE_UNALI
>  #
>  
> 
>  *_GCC47_*_*_FAMILY   = GCC
> +*_GCC47_*_*_BUILDRULEORDER   = nasm S s
>  
>  *_GCC47_*_MAKE_PATH= DEF(GCC47_IA32_PREFIX)make
>  *_GCC47_*_*_DLL= ENV(GCC47_DLL)
> @@ -4908,6 +4912,7 @@ RELEASE_GCC47_AARCH64_CC_FLAGS   = 
> DEF(GCC47_AARCH64_CC_FLAGS) -Wno-unused-but-s
>  #
>  
> 
>  *_GCC48_*_*_FAMILY   = GCC
> +*_GCC48_*_*_BUILDRULEORDER   = nasm S s
>  
>  *_GCC48_*_MAKE_PATH= DEF(GCC48_IA32_PREFIX)make
>  *_GCC48_*_*_DLL= ENV(GCC48_DLL)
&g

Re: [edk2] [Patch] BaseTools: process the files by the priority in BUILDRULEORDER

2015-12-07 Thread Jordan Justen

On 2015-12-07 05:52:42, Laszlo Ersek wrote:
> On 12/02/15 09:45, Yonghong Zhu wrote:
> > By the BUILDRULEORDER feature to process files listed in INF [Sources]
> > sections in priority order, if a filename is listed with multiple
> > extensions, the tools will use only the file that matches the first
> > extension in the space separated list.
> > 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Yonghong Zhu 
> > ---
> >  Source/Python/AutoGen/AutoGen.py | 27 +++
> >  1 file changed, 27 insertions(+)
> > 
> > diff --git a/Source/Python/AutoGen/AutoGen.py 
> > b/Source/Python/AutoGen/AutoGen.py
> > index fe56574..263224b 100644
> > --- a/Source/Python/AutoGen/AutoGen.py
> > +++ b/Source/Python/AutoGen/AutoGen.py
> > @@ -2711,13 +2711,40 @@ class ModuleAutoGen(AutoGen):
> >  
> >  # add the file path into search path list for file 
> > including
> >  if F.Dir not in self.IncludePathList and 
> > self.AutoGenVersion >= 0x00010005:
> >  self.IncludePathList.insert(0, F.Dir)
> >  self._SourceFileList.append(F)
> > +
> > +self._MatchBuildRuleOrder(self._SourceFileList)
> > +
> > +for F in self._SourceFileList:
> >  self._ApplyBuildRule(F, TAB_UNKNOWN_FILE)
> >  return self._SourceFileList
> >  
> > +def _MatchBuildRuleOrder(self, FileList):
> > +Order_Dict = {}
> > +self._GetModuleBuildOption()
> > +for SingleFile in FileList:
> > +if self.BuildRuleOrder and SingleFile.Ext in 
> > self.BuildRuleOrder:
> > +key = SingleFile.Path.split(SingleFile.Ext)[0]
> > +if key in Order_Dict:
> > +Order_Dict[key].append(SingleFile.Ext)
> > +else:
> > +Order_Dict[key] = [SingleFile.Ext]
> > +
> > +RemoveList = []
> > +for F in Order_Dict:
> > +if len(Order_Dict[F]) > 1:
> > +Order_Dict[F].sort(key=lambda i: 
> > self.BuildRuleOrder.index(i))
> > +for Ext in Order_Dict[F][1:]:
> > +RemoveList.append(F + Ext)
> > +   
> > +for item in RemoveList:
> > +FileList.remove(item)
> > +
> > +return FileList
> > +
> >  ## Return the list of unicode files
> >  def _GetUnicodeFileList(self):
> >  if self._UnicodeFileList == None:
> >  if TAB_UNICODE_FILE in self.FileTypes:
> >  self._UnicodeFileList = self.FileTypes[TAB_UNICODE_FILE]
> > 
> 
> This patch breaks the OVMF build.
> 
> $ build \
> -a X64 \
> -p OvmfPkg/OvmfPkgX64.dsc \
> -t GCC48 \
> -n 8 \
> --report-file=.../build.ovmf.report \
> --log=.../build.ovmf.log \
> -b DEBUG \
> -D HTTP_BOOT_ENABLE
> 
> The result I get is:
> 
> Processing meta-data 
> 
> build.py...
>  : error F000: Nothing to build
> 
> [/home/lacos/src/upstream/edk2-git-svn/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf]

Yonghong, Liming, can we revert this change until this can be fixed?
Laszlo investigated, and he thinks BUILDRULEORDER is causing a .asm
file to be used for the source on GCC builds. But, .asm should always
be ignored for GCC builds.

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

[edk2] [PATCH] BaseTools PatchCheck.py: Support binary diff

2015-12-01 Thread Jordan Justen

This allows a patch with binary data that is generated with --binary
to be parsed by the PatchCheck.py script.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Yonghong Zhu <yonghong@intel.com>
Cc: Liming Gao <liming@intel.com>
---
 BaseTools/Scripts/PatchCheck.py | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/BaseTools/Scripts/PatchCheck.py b/BaseTools/Scripts/PatchCheck.py
index 340a997..455c130 100755
--- a/BaseTools/Scripts/PatchCheck.py
+++ b/BaseTools/Scripts/PatchCheck.py
@@ -285,6 +285,10 @@ class GitDiffCheck:
 self.set_filename(line[6:].rstrip())
 if line.startswith('@@ '):
 self.state = PATCH
+self.binary = False
+elif line.startswith('GIT binary patch'):
+self.state = PATCH
+self.binary = True
 else:
 ok = False
 for pfx in self.pre_patch_prefixes:
@@ -294,6 +298,8 @@ class GitDiffCheck:
 self.format_error("didn't find diff hunk marker (@@)")
 self.line_num += 1
 elif self.state == PATCH:
+if self.binary:
+pass
 if line.startswith('-'):
 pass
 elif line.startswith('+'):
-- 
2.6.2

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

[edk2] [PATCH 1/3] BaseTools/Scripts: Add ConvertUtf16ToUtf8.py script

2015-12-02 Thread Jordan Justen

This script uses python codecs to convert .uni string files from
utf-16 to utf-8.

The advantages of utf-8 data:
 * Generally smaller files
 * More commonly supported by editors
 * Not treated as binary data in patch files

Cc: Yonghong Zhu <yonghong@intel.com>
Cc: Liming Gao <liming@intel.com>
Cc: Jaben Carsey <jaben.car...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
---
 BaseTools/Scripts/ConvertUtf16ToUtf8.py | 123 
 1 file changed, 123 insertions(+)
 create mode 100755 BaseTools/Scripts/ConvertUtf16ToUtf8.py

diff --git a/BaseTools/Scripts/ConvertUtf16ToUtf8.py 
b/BaseTools/Scripts/ConvertUtf16ToUtf8.py
new file mode 100755
index 000..5f54603
--- /dev/null
+++ b/BaseTools/Scripts/ConvertUtf16ToUtf8.py
@@ -0,0 +1,123 @@
+## @file
+#  Check a patch for various format issues
+#
+#  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.
+#
+
+from __future__ import print_function
+
+VersionNumber = '0.1'
+__copyright__ = "Copyright (c) 2015, Intel Corporation  All rights reserved."
+
+import argparse
+import codecs
+import os
+import sys
+
+try:
+from io import StringIO
+except ImportError:
+from StringIO import StringIO
+
+class ConvertOneArg:
+"""Converts utf-16 to utf-8 for one command line argument.
+
+   This could be a single file, or a directory.
+"""
+
+def __init__(self, source):
+self.source = source
+
+self.ok = True
+
+if not os.path.exists(source):
+self.ok = False
+elif os.path.isdir(source):
+for (root, dirs, files) in os.walk(source):
+files = filter(lambda a: a.endswith('.uni'), files)
+for filename in files:
+path = os.path.join(root, filename)
+self.ok &= self.convert_one_file(path)
+if not self.ok:
+break
+
+if not self.ok:
+break
+else:
+self.ok &= self.convert_one_file(source)
+
+def convert_one_file(self, source):
+#
+# Read file
+#
+utf16_file = open(source, mode='rb')
+file_content = utf16_file.read()
+utf16_file.close()
+
+#
+# Detect UTF-16 Byte Order Mark at beginning of file.
+#
+if not (file_content.startswith(codecs.BOM_UTF16_BE) or
+file_content.startswith(codecs.BOM_UTF16_LE)):
+print(source + ": already utf-8")
+return True
+
+#
+# Decode utf-16 string data
+#
+str_content = file_content.decode('utf-16', 'ignore')
+
+#
+# Encode string data to utf-8
+#
+utf8_content = str_content.encode('utf-8', 'ignore')
+
+#
+# Write converted utf-8 data back to file
+#
+utf8_file = open(source, mode='wb')
+utf8_file.write(utf8_content)
+utf8_file.close()
+
+print(source + ": converted, size", len(file_content), '=>', 
len(utf8_content))
+return True
+
+
+class ConvertUtf16ToUtf8App:
+"""Converts files to utf-8 based on the command line arguments."""
+
+def __init__(self):
+self.parse_options()
+sources = self.args.source
+
+self.ok = True
+for patch in sources:
+self.process_one_arg(patch)
+
+if self.ok:
+self.retval = 0
+else:
+self.retval = -1
+
+def process_one_arg(self, arg):
+self.ok &= ConvertOneArg(arg).ok
+
+def parse_options(self):
+parser = argparse.ArgumentParser(description=__copyright__)
+parser.add_argument('--version', action='version',
+version='%(prog)s ' + VersionNumber)
+parser.add_argument('source', nargs='+',
+help='[uni file | directory]')
+self.args = parser.parse_args()
+
+if __name__ == "__main__":
+sys.exit(ConvertUtf16ToUtf8App().retval)
-- 
2.6.2

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

[edk2] [PATCH 3/3] MdePkg: Example diff with utf-8 data

2015-12-02 Thread Jordan Justen

This patch is not intended to be checked in.

Cc: Jaben Carsey <jaben.car...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
---
 MdePkg/MdePkg.uni | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MdePkg/MdePkg.uni b/MdePkg/MdePkg.uni
index 6c9ddad..ace9949 100644
--- a/MdePkg/MdePkg.uni
+++ b/MdePkg/MdePkg.uni
@@ -18,6 +18,11 @@
 // **/
 
 
+//
+// Example diff with utf-8 data. (Will not be checked in.)
+//
+// Unicode char 0x2200: ∀
+//
 #string STR_PACKAGE_ABSTRACT#language en-US "This Package provides 
all definitions, library classes and libraries instances."
 
 #string STR_PACKAGE_DESCRIPTION #language en-US "It also provides the 
definitions(including PPIs/PROTOCOLs/GUIDs) of EFI1.10/UEFI2.4/PI1.3 and some 
Industry Standards."
-- 
2.6.2

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

1 2 3 4 5 6 >

1 - 100 of 597 matches

Mail list logo