Re: [edk2] [PATCH 0/3] OvmfPkg: enable 64-bit PCI MMIO

[Thomas Lamprecht]

On 03/10/2016 10:05 PM, Laszlo Ersek wrote:
> This is the last wave(-let) I have for now.
>
> Public branch:
> .
>
> Thomas, it would be great if you could test it.

Cool stuff, thanks Laszlo!

I'll build and test it, although I'm not sure if I get to that test
hardware today, but I'll report back.

Anyway, thanks for the work, appreciate it!

cheers,
Thomas

>
> Cc: Gerd Hoffmann 
> Cc: Jordan Justen 
> Cc: Marcel Apfelbaum 
> Cc: Thomas Lamprecht 
> Ref: https://github.com/tianocore/edk2/issues/59
>
> Thanks
> Laszlo
>
> Laszlo Ersek (3):
>   OvmfPkg: PlatformPei: factor out GetFirstNonAddress()
>   OvmfPkg: PlatformPei: determine the 64-bit PCI host aperture for X64
> DXE
>   OvmfPkg: PciHostBridgeLib: install 64-bit PCI host aperture
>
>  OvmfPkg/OvmfPkg.dec   |   5 +
>  OvmfPkg/OvmfPkgIa32X64.dsc|   2 +
>  OvmfPkg/OvmfPkgX64.dsc|   2 +
>  OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf |   2 +
>  OvmfPkg/PlatformPei/PlatformPei.inf   |   2 +
>  OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c   |   7 ++
>  OvmfPkg/PlatformPei/MemDetect.c   | 128 
> +++-
>  7 files changed, 147 insertions(+), 1 deletion(-)
>


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

[edk2] [Patch] CryptoPkg: Fix the potential system hang issue

[Jiaxin Wu]

This patch is used to fix the potential system hang
caused by the NULL 'time' parameter usage.

Cc: David Woodhouse 
Cc: Long Qin 
Cc: Ye Ting 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 .../Library/BaseCryptLib/SysCall/TimerWrapper.c| 29 +-
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c 
b/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
index 6422d61..93e487d 100644
--- a/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
+++ b/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
@@ -1,10 +1,10 @@
 /** @file
   C Run-Time Libraries (CRT) Time Management Routines Wrapper Implementation
   for OpenSSL-based Cryptographic Library (used in DXE & RUNTIME).
 
-Copyright (c) 2010 - 2011, Intel Corporation. All rights reserved.
+Copyright (c) 2010 - 2016, 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
 
@@ -71,10 +71,11 @@ UINTN CumulativeDays[2][14] = {
 //  INTN *timer
 //  )
 time_t time (time_t *timer)
 {
   EFI_TIME  Time;
+  time_tCalTime;
   UINTN Year;
 
   //
   // Get the current time and date information
   //
@@ -82,26 +83,30 @@ time_t time (time_t *timer)
 
   //
   // Years Handling
   // UTime should now be set to 00:00:00 on Jan 1 of the current year.
   //
-  for (Year = 1970, *timer = 0; Year != Time.Year; Year++) {
-*timer = *timer + (time_t)(CumulativeDays[IsLeap(Year)][13] * SECSPERDAY);
+  for (Year = 1970, CalTime = 0; Year != Time.Year; Year++) {
+CalTime = CalTime + (time_t)(CumulativeDays[IsLeap(Year)][13] * 
SECSPERDAY);
   }
 
   //
   // Add in number of seconds for current Month, Day, Hour, Minute, Seconds, 
and TimeZone adjustment
   //
-  *timer = *timer + 
-   (time_t)((Time.TimeZone != EFI_UNSPECIFIED_TIMEZONE) ? 
(Time.TimeZone * 60) : 0) +
-   (time_t)(CumulativeDays[IsLeap(Time.Year)][Time.Month] * 
SECSPERDAY) + 
-   (time_t)(((Time.Day > 0) ? Time.Day - 1 : 0) * SECSPERDAY) + 
-   (time_t)(Time.Hour * SECSPERHOUR) + 
-   (time_t)(Time.Minute * 60) + 
-   (time_t)Time.Second;
-
-  return *timer;
+  CalTime = CalTime + 
+(time_t)((Time.TimeZone != EFI_UNSPECIFIED_TIMEZONE) ? 
(Time.TimeZone * 60) : 0) +
+(time_t)(CumulativeDays[IsLeap(Time.Year)][Time.Month] * 
SECSPERDAY) + 
+(time_t)(((Time.Day > 0) ? Time.Day - 1 : 0) * SECSPERDAY) + 
+(time_t)(Time.Hour * SECSPERHOUR) + 
+(time_t)(Time.Minute * 60) + 
+(time_t)Time.Second;
+
+  if (timer != NULL) {
+*timer = CalTime;
+  }
+
+  return CalTime;
 }
 
 //
 // Convert a time value from type time_t to struct tm.
 //
-- 
1.9.5.msysgit.1

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

Re: [edk2] [PATCH v3] NetworkPkg: Add URI configuration form to HTTP boot driver.

[Gary Lin]

On Thu, Mar 10, 2016 at 12:31:18PM +0100, Laszlo Ersek wrote:
> On 03/10/16 11:02, Gary Lin wrote:
> > On Thu, Mar 10, 2016 at 10:20:12AM +0100, Laszlo Ersek wrote:
> >> On 03/10/16 08:49, Gary Lin wrote:
> 
> >>> I found that it's related to iPXE. If I disable iPXE with
> >>>
> >>> "-netdev user,id=hostnet0 -device virtio-net-pci,romfile=,netdev=hostnet0"
> >>>
> >>> then everything works as expected. I'll try to dig deeper to find more
> >>> information.
> >>
> >> How fresh is your ipxe? And did you build it with CONFIG=qemu?
> >>
> > It comes from the qemu 2.5.0 tarball and I just installed it from
> > openSUSE Virtualization repo.
> > https://build.opensuse.org/package/show/Virtualization/qemu
> 
> QEMU 2.5 bundles iPXE binaries built with CONFIG=qemu, but that
> configuration doesn't enable IPv6 for the moment.
> 
> Apparently, combining iPXE (CONFIG=qemu) with NETWORK_IP6_ENABLE (set in
> OVMF) causes problems. I don't understand how this causes side effects,
> because CONFIG=qemu instructs iPXE to provide SNP drivers only. SNP is
> independent of IP version.
> 
> With this combination, IPv6 PXE should work (not be absent), and IPv6
> HTTP Boot should work too (not blow up).
> 
> Can you perhaps remove grub2 from the equation? What if you play with
> disconnect / reconnect / connect in the UEFI shell?
> 
hmmm I found another way to crash the system with a different assert.

Just disconnect/reconnect the handle providing HttpServiceBinding, and
OVMF crashed with/without iPXE:

ASSERT /home/gary/git/edk2/NetworkPkg/HttpBootDxe/HttpBootDxe.c(796): CR has 
Bad Signature

Here is the function that issues the assert.

EFIAPI HttpBootIp6DxeDriverBindingStart ()
  ...
  if (!EFI_ERROR (Status)) {
Private = HTTP_BOOT_PRIVATE_DATA_FROM_ID(Id); < CRASH
  } else {
  ...

This also only happens after fa848a4048943251fc057fe8d6c5a82e01d2ffb6.

Thanks,

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

Re: [edk2] [Patch] NetworkPkg: fix function comments in HttpBootDxe.

[Wu, Jiaxin]

Reviewed-by: Jiaxin Wu 


> -Original Message-
> From: Fu, Siyuan
> Sent: Thursday, March 10, 2016 10:10 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin ; Zhang, Lubo 
> Subject: [Patch] NetworkPkg: fix function comments in HttpBootDxe.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Fu Siyuan 
> Cc: Wu Jiaxin 
> Cc: Zhang Lubo 
> ---
>  NetworkPkg/HttpBootDxe/HttpBootDxe.inf   | 2 ++
>  NetworkPkg/HttpBootDxe/HttpBootSupport.c | 2 +-
> NetworkPkg/HttpBootDxe/HttpBootSupport.h | 2 +-
>  3 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootDxe.inf
> b/NetworkPkg/HttpBootDxe/HttpBootDxe.inf
> index 8b4219c..7393ecd 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootDxe.inf
> +++ b/NetworkPkg/HttpBootDxe/HttpBootDxe.inf
> @@ -28,8 +28,10 @@
>NetworkPkg/NetworkPkg.dec
> 
>  [Sources]
> +  HttpBootConfigNVDataStruc.h
>HttpBootDxe.h
>HttpBootDxe.c
> +  HttpBootConfig.h
>HttpBootConfig.c
>HttpBootComponentName.h
>HttpBootComponentName.c
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootSupport.c
> b/NetworkPkg/HttpBootDxe/HttpBootSupport.c
> index e678379..758c49b 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootSupport.c
> +++ b/NetworkPkg/HttpBootDxe/HttpBootSupport.c
> @@ -951,7 +951,7 @@ HttpIoRecvResponse (
>Caller need to free the buffer in the UriAddress pointer.
> 
>@param[in]   FilePath Pointer to the device path which contains a 
> URI
> device path node.
> -  @param[in]   UriAddress   The URI address string extract from the 
> device
> path.
> +  @param[out]  UriAddress   The URI address string extract from the
> device path.
> 
>@retval EFI_SUCCESSThe URI string is returned.
>@retval EFI_OUT_OF_RESOURCES   Failed to allocate memory.
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootSupport.h
> b/NetworkPkg/HttpBootDxe/HttpBootSupport.h
> index 3edea61..f382d63 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootSupport.h
> +++ b/NetworkPkg/HttpBootDxe/HttpBootSupport.h
> @@ -335,7 +335,7 @@ HttpIoRecvResponse (
>Caller need to free the buffer in the UriAddress pointer.
> 
>@param[in]   FilePath Pointer to the device path which contains a 
> URI
> device path node.
> -  @param[in]   UriAddress   The URI address string extract from the 
> device
> path.
> +  @param[out]  UriAddress   The URI address string extract from the
> device path.
> 
>@retval EFI_SUCCESSThe URI string is returned.
>@retval EFI_OUT_OF_RESOURCES   Failed to allocate memory.
> --
> 2.7.0.windows.2

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

Re: [edk2] [PATCH v6] MdePkg: Add UEFI2.6 HII Image Ex and Image Decoder protocol definition.

[Gao, Liming]

Cecil:
  Please run BaseTools\Scripts\PatchCheck.py for your patch and fix the invalid 
coding format. And, please create this patch based on the latest edk2 trunk. I 
also meet with the issue to apply this patch. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Cecil Sheng
> Sent: Tuesday, March 08, 2016 3:56 PM
> To: edk2-devel@lists.01.org
> Cc: Cecil Sheng
> Subject: [edk2] [PATCH v6] MdePkg: Add UEFI2.6 HII Image Ex and Image
> Decoder protocol definition.
> 
> Add the definition for the new UEFI 2.6 EFI_HII_IMAGE_EX_PROTOCOL and
> EFI_IMAGE_DECODER_PROTOCOL.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Cecil Sheng 
> Reviewed-by: Samer El-Haj-Mahmoud 
> Reviewed-by: Abner Chang 
> ---
>  MdePkg/Include/Protocol/HiiImageEx.h   | 245
> +
>  MdePkg/Include/Protocol/ImageDecoder.h | 192
> ++
>  MdePkg/MdePkg.dec  |  14 ++
>  3 files changed, 451 insertions(+)
>  create mode 100644 MdePkg/Include/Protocol/HiiImageEx.h
>  create mode 100644 MdePkg/Include/Protocol/ImageDecoder.h
> 
> diff --git a/MdePkg/Include/Protocol/HiiImageEx.h
> b/MdePkg/Include/Protocol/HiiImageEx.h
> new file mode 100644
> index 000..9393a53
> --- /dev/null
> +++ b/MdePkg/Include/Protocol/HiiImageEx.h
> @@ -0,0 +1,245 @@
> +/** @file
> +  Protocol which allows access to the images in the images database.
> +
> +(C) Copyright 2016 Hewlett Packard Enterprise Development LP
> +
> +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 EFI_HII_IMAGE_EX_H
> +#define EFI_HII_IMAGE_EX_H
> +
> +#include 
> +
> +//
> +// Global ID for the Hii Image Ex Protocol.
> +//
> +#define EFI_HII_IMAGE_EX_PROTOCOL_GUID \
> +  {0x1a1241e6, 0x8f19, 0x41a9,  { 0xbc, 0xe, 0xe8, 0xef, 0x39, 0xe0, 0x65,
> 0x46 }}
> +
> +typedef struct _EFI_HII_IMAGE_EX_PROTOCOL
> EFI_HII_IMAGE_EX_PROTOCOL;
> +
> +/**
> +  The prototype of this extension function is the same with
> EFI_HII_IMAGE_PROTOCOL.NewImage().
> +  Same with EFI_HII_IMAGE_PROTOCOL.NewImage().This protocol invokes
> +EFI_HII_IMAGE_PROTOCOL.NewImage() implicitly.
> +
> +  @param  This   A pointer to the EFI_HII_IMAGE_EX_PROTOCOL
> instance.
> +  @param  PackageListHandle of the package list where this image 
> will
> + be added.
> +  @param  ImageIdOn return, contains the new image id, which 
> is
> + unique within PackageList.
> +  @param  Image  Points to the image.
> +
> +  @retval EFI_SUCCESSThe new image was added successfully.
> +  @retval EFI_NOT_FOUND  The specified PackageList could not be
> found in
> + database.
> +  @retval EFI_OUT_OF_RESOURCES   Could not add the image due to lack of
> resources.
> +  @retval EFI_INVALID_PARAMETER  Image is NULL or ImageId is NULL.
> +
> +**/
> +typedef
> +EFI_STATUS
> +(EFIAPI *EFI_HII_NEW_IMAGE_EX)(
> +  IN CONST  EFI_HII_IMAGE_EX_PROTOCOL  *This,
> +  INEFI_HII_HANDLE  PackageList,
> +  OUT   EFI_IMAGE_ID*ImageId,
> +  IN CONST  EFI_IMAGE_INPUT *Image
> +  );
> +
> +/**
> +  Return the information about the image, associated with the package list.
> +  The prototype of this extension function is the same with
> EFI_HII_IMAGE_PROTOCOL.GetImage().
> +  Same with EFI_HII_IMAGE_PROTOCOL.SetImage(),this protocol invokes
> EFI_HII_IMAGE_PROTOCOL.SetImage() implicitly.
> +
> +  @param  This   A pointer to the EFI_HII_IMAGE_EX_PROTOCOL
> instance.
> +  @param  PackageListHandle of the package list where this image 
> will
> + be searched.
> +  @param  ImageIdThe image's id,, which is unique within
> + PackageList.
> +  @param  Image  Points to the image.
> +
> +  @retval EFI_SUCCESSThe new image was returned successfully.
> +  @retval EFI_NOT_FOUND  The image specified by ImageId is not in the
> + database. The specified PackageList is not 
> in
> + the database.
> +  @retval EFI_BUFFER_TOO_SMALL   The buffer specified by ImageSize is
> too small to
> + hold the image.
> +  @retval EFI_INVALID_PARAMETER  The Image or ImageSize was NULL.
> +  @retval EFI_OUT_OF_RESOURCES   

Re: [edk2] [PATCH v6] MdePkg: Add UEFI2.6 HII Image Ex and Image Decoder protocol definition.

[Tian, Feng]

Hi, Cecil & Eric

I can't apply this git patch at all. what code revision are you using to 
create/review the patch?

I want to emphasize the review path should be based on latest git revision. 
Please follow it.

Thanks
Feng

-Original Message-
From: Dong, Eric 
Sent: Wednesday, March 9, 2016 8:44 AM
To: Cecil Sheng ; edk2-devel@lists.01.org; Tian, Feng 

Subject: RE: [edk2] [PATCH v6] MdePkg: Add UEFI2.6 HII Image Ex and Image 
Decoder protocol definition.

Reviewed-by: Eric Dong 


Feng,

Please help to check in this code.

Thanks,
Eric

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Cecil Sheng
> Sent: Tuesday, March 08, 2016 3:56 PM
> To: edk2-devel@lists.01.org
> Cc: Cecil Sheng
> Subject: [edk2] [PATCH v6] MdePkg: Add UEFI2.6 HII Image Ex and Image Decoder 
> protocol definition.
> 
> Add the definition for the new UEFI 2.6 EFI_HII_IMAGE_EX_PROTOCOL and 
> EFI_IMAGE_DECODER_PROTOCOL.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Cecil Sheng 
> Reviewed-by: Samer El-Haj-Mahmoud 
> Reviewed-by: Abner Chang 
> ---
>  MdePkg/Include/Protocol/HiiImageEx.h   | 245 
> +
>  MdePkg/Include/Protocol/ImageDecoder.h | 192 ++
>  MdePkg/MdePkg.dec  |  14 ++
>  3 files changed, 451 insertions(+)
>  create mode 100644 MdePkg/Include/Protocol/HiiImageEx.h
>  create mode 100644 MdePkg/Include/Protocol/ImageDecoder.h
> 
> diff --git a/MdePkg/Include/Protocol/HiiImageEx.h 
> b/MdePkg/Include/Protocol/HiiImageEx.h
> new file mode 100644
> index 000..9393a53
> --- /dev/null
> +++ b/MdePkg/Include/Protocol/HiiImageEx.h
> @@ -0,0 +1,245 @@
> +/** @file
> +  Protocol which allows access to the images in the images database.
> +
> +(C) Copyright 2016 Hewlett Packard Enterprise Development LP
> +
> +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 EFI_HII_IMAGE_EX_H
> +#define EFI_HII_IMAGE_EX_H
> +
> +#include 
> +
> +//
> +// Global ID for the Hii Image Ex Protocol.
> +//
> +#define EFI_HII_IMAGE_EX_PROTOCOL_GUID \
> +  {0x1a1241e6, 0x8f19, 0x41a9,  { 0xbc, 0xe, 0xe8, 0xef, 0x39, 0xe0, 
> +0x65, 0x46 }}
> +
> +typedef struct _EFI_HII_IMAGE_EX_PROTOCOL EFI_HII_IMAGE_EX_PROTOCOL;
> +
> +/**
> +  The prototype of this extension function is the same with 
> EFI_HII_IMAGE_PROTOCOL.NewImage().
> +  Same with EFI_HII_IMAGE_PROTOCOL.NewImage().This protocol invokes
> +EFI_HII_IMAGE_PROTOCOL.NewImage() implicitly.
> +
> +  @param  This   A pointer to the EFI_HII_IMAGE_EX_PROTOCOL 
> instance.
> +  @param  PackageListHandle of the package list where this image 
> will
> + be added.
> +  @param  ImageIdOn return, contains the new image id, which 
> is
> + unique within PackageList.
> +  @param  Image  Points to the image.
> +
> +  @retval EFI_SUCCESSThe new image was added successfully.
> +  @retval EFI_NOT_FOUND  The specified PackageList could not be 
> found in
> + database.
> +  @retval EFI_OUT_OF_RESOURCES   Could not add the image due to lack of 
> resources.
> +  @retval EFI_INVALID_PARAMETER  Image is NULL or ImageId is NULL.
> +
> +**/
> +typedef
> +EFI_STATUS
> +(EFIAPI *EFI_HII_NEW_IMAGE_EX)(
> +  IN CONST  EFI_HII_IMAGE_EX_PROTOCOL  *This,
> +  INEFI_HII_HANDLE  PackageList,
> +  OUT   EFI_IMAGE_ID*ImageId,
> +  IN CONST  EFI_IMAGE_INPUT *Image
> +  );
> +
> +/**
> +  Return the information about the image, associated with the package list.
> +  The prototype of this extension function is the same with 
> EFI_HII_IMAGE_PROTOCOL.GetImage().
> +  Same with EFI_HII_IMAGE_PROTOCOL.SetImage(),this protocol invokes 
> EFI_HII_IMAGE_PROTOCOL.SetImage() implicitly.
> +
> +  @param  This   A pointer to the EFI_HII_IMAGE_EX_PROTOCOL 
> instance.
> +  @param  PackageListHandle of the package list where this image 
> will
> + be searched.
> +  @param  ImageIdThe image's id,, which is unique within
> + PackageList.
> +  @param  Image  Points to the image.
> +
> +  @retval EFI_SUCCESSThe new image was returned successfully.
> +  @retval EFI_NOT_FOUND  The image specified by ImageId 

[edk2] [PATCH] ArmVirtPkg/VirtFdtDxe: set /chosen/linux, pci-probe-only to 1 in DTB

[Ard Biesheuvel]

Unlike Linux on x86, which typically honors the PCI configuration performed
by the firmware, Linux on ARM assumes that the PCI subsystem needs to be
configured from scratch. This is not entirely unreasonable given the
historical background of embedded systems using very basic bootloaders,
but is no longer tenable with Linux on arm64 moving to UEFI and ACPI in the
server space. For this reason, PCI support in the arm64 kernel running under
ACPI is likely to move to the x86 model of honoring the PCI configuration
done by the firmware.

So let's align with that in our DT based configuration as well, and set the
/chosen/linux,pci-probe-only property to 1 in the Device Tree before we
hand it to the OS.

In case we are exposing an emulated VGA PCI device to the guest, which may
subsequently get exposed via the Graphics Output protocol and driven as an
efifb by the OS, this ensures the PCI resource allocations for the framebuffer
are not overridden, since that would cause the framebuffer to stop working.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c | 23 +++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c 
b/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c
index 74f80d1d2b78..36484a0bbb7e 100644
--- a/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c
+++ b/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c
@@ -286,6 +286,7 @@ InitializeVirtFdtDxe (
   VOID   *DeviceTreeBase;
   INT32  Node, Prev;
   INT32  RtcNode;
+  INT32  ChosenNode;
   EFI_STATUS Status;
   CONST CHAR8*Type;
   INT32  Len;
@@ -356,8 +357,28 @@ InitializeVirtFdtDxe (
   ASSERT (Len == 2 * sizeof (UINT64));
   Status = ProcessPciHost (DeviceTreeBase, Node, RegProp);
   ASSERT_EFI_ERROR (Status);
-  break;
 
+  //
+  // Set the /chosen/linux,pci-probe-only property to 1, so that the PCI
+  // setup we will perform in the firmware is honored by the Linux OS,
+  // rather than torn down and done from scratch. This is generally a more
+  // sensible approach, and aligns with what ACPI based OSes do in general.
+  //
+  // In case we are exposing an emulated VGA PCI device to the guest, which
+  // may subsequently get exposed via the Graphics Output protocol and
+  // driven as an efifb by Linux, we need this setting to prevent the
+  // framebuffer from becoming unresponsive.
+  //
+  ChosenNode = fdt_path_offset (DeviceTreeBase, "/chosen");
+  if (ChosenNode < 0) {
+ChosenNode = fdt_add_subnode (DeviceTreeBase, 0, "/chosen");
+  }
+  if (ChosenNode < 0) {
+DEBUG ((EFI_D_WARN, "Failed to set /chosen/linux,pci-probe-only 
property"));
+break;
+  }
+  fdt_setprop_u32 (DeviceTreeBase, ChosenNode, "linux,pci-probe-only", 1);
+  break;
 case PropertyTypeFwCfg:
   ASSERT (Len == 2 * sizeof (UINT64));
 
-- 
1.9.1

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

Re: [edk2] [Patch] NetworkPkg: fix function comments in HttpBootDxe.

[Zhang, Lubo]

Reviewed-by: Zhang, Lubo 

-Original Message-
From: Fu, Siyuan 
Sent: Thursday, March 10, 2016 10:10 AM
To: edk2-devel@lists.01.org
Cc: Wu, Jiaxin ; Zhang, Lubo 
Subject: [Patch] NetworkPkg: fix function comments in HttpBootDxe.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
Cc: Wu Jiaxin 
Cc: Zhang Lubo 
---
 NetworkPkg/HttpBootDxe/HttpBootDxe.inf   | 2 ++
 NetworkPkg/HttpBootDxe/HttpBootSupport.c | 2 +-  
NetworkPkg/HttpBootDxe/HttpBootSupport.h | 2 +-
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootDxe.inf 
b/NetworkPkg/HttpBootDxe/HttpBootDxe.inf
index 8b4219c..7393ecd 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootDxe.inf
+++ b/NetworkPkg/HttpBootDxe/HttpBootDxe.inf
@@ -28,8 +28,10 @@
   NetworkPkg/NetworkPkg.dec
 
 [Sources]
+  HttpBootConfigNVDataStruc.h
   HttpBootDxe.h
   HttpBootDxe.c
+  HttpBootConfig.h
   HttpBootConfig.c
   HttpBootComponentName.h
   HttpBootComponentName.c
diff --git a/NetworkPkg/HttpBootDxe/HttpBootSupport.c 
b/NetworkPkg/HttpBootDxe/HttpBootSupport.c
index e678379..758c49b 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootSupport.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootSupport.c
@@ -951,7 +951,7 @@ HttpIoRecvResponse (
   Caller need to free the buffer in the UriAddress pointer.
   
   @param[in]   FilePath Pointer to the device path which contains a 
URI device path node.
-  @param[in]   UriAddress   The URI address string extract from the device 
path.
+  @param[out]  UriAddress   The URI address string extract from the device 
path.
   
   @retval EFI_SUCCESSThe URI string is returned.
   @retval EFI_OUT_OF_RESOURCES   Failed to allocate memory.
diff --git a/NetworkPkg/HttpBootDxe/HttpBootSupport.h 
b/NetworkPkg/HttpBootDxe/HttpBootSupport.h
index 3edea61..f382d63 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootSupport.h
+++ b/NetworkPkg/HttpBootDxe/HttpBootSupport.h
@@ -335,7 +335,7 @@ HttpIoRecvResponse (
   Caller need to free the buffer in the UriAddress pointer.
   
   @param[in]   FilePath Pointer to the device path which contains a 
URI device path node.
-  @param[in]   UriAddress   The URI address string extract from the device 
path.
+  @param[out]  UriAddress   The URI address string extract from the device 
path.
   
   @retval EFI_SUCCESSThe URI string is returned.
   @retval EFI_OUT_OF_RESOURCES   Failed to allocate memory.
--
2.7.0.windows.2

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

Re: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to enable 'openssl\ssl'

[Wu, Jiaxin]

Thanks for comments. /Jiaxin

> -Original Message-
> From: Wu, Jiaxin
> Sent: Friday, March 11, 2016 10:09 AM
> To: David Woodhouse ; edk2-de...@ml01.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Long,
> Qin 
> Subject: RE: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to
> enable 'openssl\ssl'
> 
> 
> 
> > -Original Message-
> > From: David Woodhouse [mailto:dw...@infradead.org]
> > Sent: Thursday, March 10, 2016 7:31 PM
> > To: Wu, Jiaxin ; edk2-de...@ml01.01.org
> > Cc: Ye, Ting ; Fu, Siyuan ;
> > Long, Qin 
> > Subject: Re: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to
> > enable 'openssl\ssl'
> >
> > On Wed, 2016-02-24 at 16:15 +0800, Jiaxin Wu wrote:
> > > diff --git a/CryptoPkg/Library/OpensslLib/OpensslTlsLib.uni
> > b/CryptoPkg/Library/OpensslLib/OpensslTlsLib.uni
> > > new file mode 100644
> > > index
> >
> ..384f0245db8d1d3a1d758f6db
> > 58f85f5fc155211
> > > GIT binary patch
> > > literal 1792
> > > zcmd6oNpBND5QXcE#D5q$7eI*(95^6^u<-yRLdNo
> > > z1hRUq>Q}F-Uyr|ity#?y+9Q66y|RhTY;I$_Z}-
> > @ht!o$TZI~@=Wh1+Edtz%VSZ}e7
> > >
> >
> z@RvPjZ){8J@H=H4#u^Bx%oF;V4LH@OU9+BnxOTLKpDVGH?5@D5?il=!OkTr
> > rO%4TY
> > >
> >
> zr_`q;n+G > P69L
> >
> > These should be UTF-8 now, shouldn't they? It seems wrong to be adding
> > new UTF-16 files while other people are submitting patches to convert
> > *from* UTF-16 to UTF-8.
> >
> > --
> > David WoodhouseOpen Source Technology Centre
> > david.woodho...@intel.com  Intel Corporation

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

Re: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to enable 'openssl\ssl'

[Wu, Jiaxin]

> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: Thursday, March 10, 2016 7:31 PM
> To: Wu, Jiaxin ; edk2-de...@ml01.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Long,
> Qin 
> Subject: Re: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to
> enable 'openssl\ssl'
> 
> On Wed, 2016-02-24 at 16:15 +0800, Jiaxin Wu wrote:
> > diff --git a/CryptoPkg/Library/OpensslLib/OpensslTlsLib.uni
> b/CryptoPkg/Library/OpensslLib/OpensslTlsLib.uni
> > new file mode 100644
> > index
> ..384f0245db8d1d3a1d758f6db
> 58f85f5fc155211
> > GIT binary patch
> > literal 1792
> > zcmd6oNpBND5QXcE#D5q$7eI*(95^6^u<-yRLdNo
> > z1hRUq>Q}F-Uyr|ity#?y+9Q66y|RhTY;I$_Z}-
> @ht!o$TZI~@=Wh1+Edtz%VSZ}e7
> >
> z@RvPjZ){8J@H=H4#u^Bx%oF;V4LH@OU9+BnxOTLKpDVGH?5@D5?il=!OkTr
> rO%4TY
> >
> zr_`q;n+G P69L
> 
> These should be UTF-8 now, shouldn't they? It seems wrong to be adding
> new UTF-16 files while other people are submitting patches to convert
> *from* UTF-16 to UTF-8.
> 
> --
> David WoodhouseOpen Source Technology Centre
> david.woodho...@intel.com  Intel Corporation

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

Re: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to enable 'openssl\ssl'

[Wu, Jiaxin]

You are right. The change for EDKII_openssl patch is unreasonable. 

Actually, this change was based on the openssl version 1.0.2e. The issue has 
been fixed in the later openssl version. So, just ignore it. I will create 
another patch for whole 'openssl\ssl' feature requirement to resolve this patch 
conflict issue.

Thanks.
Jiaxin

> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: Thursday, March 10, 2016 6:43 PM
> To: Wu, Jiaxin ; edk2-de...@ml01.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Long,
> Qin 
> Subject: Re: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to
> enable 'openssl\ssl'
> 
> On Wed, 2016-02-24 at 16:15 +0800, Jiaxin Wu wrote:
> >
> > diff --git a/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2f.patch
> b/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2f.patch
> > index c42b776..f2d8f1a 100644
> > --- a/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2f.patch
> > +++ b/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2f.patch
> > @@ -11,10 +11,19 @@ diff U3 crypto/bio/bio.h crypto/bio/bio.h
> >   BIO *BIO_new_fp(FILE *stream, int close_flag);
> >  +# ifndef OPENSSL_NO_FP_API
> >   #  define BIO_s_file_internal    BIO_s_file
> >   # endif
> >   BIO *BIO_new(BIO_METHOD *type);
> > +@@ -655,6 +655,8 @@
> > + BIO *BIO_new_file(const char *filename, const char *mode);
> > + BIO *BIO_new_fp(FILE *stream, int close_flag);
> > + #  define BIO_s_file_internal    BIO_s_file
> > ++# else
> > ++#  define BIO_s_file_internal()  NULL
> > + # endif
> > + BIO *BIO_new(BIO_METHOD *type);
> > + int BIO_set(BIO *a, BIO_METHOD *type);
> >  diff U3 crypto/bio/bss_file.c crypto/bio/bss_file.c
> >  --- crypto/bio/bss_file.c  Thu Jan 28 21:38:30 2016
> >  +++ crypto/bio/bss_file.c  Wed Feb 17 16:01:02 2016
> >  @@ -467,6 +467,23 @@
> >   return (ret);
> 
> As a general rule, you should never make have been making changes to
> this OpenSSL patch without ensuring that a ticket is filed upstream.
> 
> As of this week, there is *nothing* in the EDKII_openssl patch which
> isn't a backport of a commit from OpenSSL 1.1. The patch is
> autogenerated from a 1.0.2+backports git tree.
> 
> Adding to it like this was *never* acceptable. Sure, you were only
> making it a little bit worse at a time, but please don't. It just isn't
> the way to do things.
> 
> In this case, perhaps the *only* thing missing was the fact that this
> should have been in its own separate commit, with a commit comment
> *identifying* the upstream ticket (and OpenSSL 1.1 commit) in which it
> was fixed. But that's important to get right too.
> 
> --
> David WoodhouseOpen Source Technology Centre
> david.woodho...@intel.com  Intel Corporation

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

Re: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to enable 'openssl\ssl'

[Wu, Jiaxin]

Hi David,

Good point. I agree the change for 'time' should be standalone commit. 

This change is to avoid the potential system hang caused by the NULL 'time' 
parameter usage.

Thanks.
Jiaxin

> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: Thursday, March 10, 2016 6:39 PM
> To: Wu, Jiaxin ; edk2-de...@ml01.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Long,
> Qin 
> Subject: Re: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to
> enable 'openssl\ssl'
> 
> On Wed, 2016-02-24 at 16:15 +0800, Jiaxin Wu wrote:
> >
> > diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
> b/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
> > index 6422d61..93e487d 100644
> > --- a/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
> > +++ b/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
> > @@ -1,10 +1,10 @@
> >  /** @file
> >    C Run-Time Libraries (CRT) Time Management Routines Wrapper
> Implementation
> >    for OpenSSL-based Cryptographic Library (used in DXE & RUNTIME).
> >
> > -Copyright (c) 2010 - 2011, Intel Corporation. All rights reserved.
> > +Copyright (c) 2010 - 2016, 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
> >
> > @@ -71,10 +71,11 @@ UINTN CumulativeDays[2][14] = {
> >  //  INTN *timer
> >  //  )
> >  time_t time (time_t *timer)
> >  {
> >    EFI_TIME  Time;
> > +  time_t    CalTime;
> >    UINTN Year;
> >
> >    //
> >    // Get the current time and date information
> >    //
> > @@ -82,26 +83,30 @@ time_t time (time_t *timer)
> >
> >    //
> >    // Years Handling
> >    // UTime should now be set to 00:00:00 on Jan 1 of the current year.
> >    //
> > -  for (Year = 1970, *timer = 0; Year != Time.Year; Year++) {
> > -    *timer = *timer + (time_t)(CumulativeDays[IsLeap(Year)][13] *
> SECSPERDAY);
> > +  for (Year = 1970, CalTime = 0; Year != Time.Year; Year++) {
> > +    CalTime = CalTime + (time_t)(CumulativeDays[IsLeap(Year)][13] *
> SECSPERDAY);
> >    }
> >
> >    //
> >    // Add in number of seconds for current Month, Day, Hour, Minute,
> Seconds, and TimeZone adjustment
> >    //
> > -  *timer = *timer +
> > -   (time_t)((Time.TimeZone != EFI_UNSPECIFIED_TIMEZONE) ?
> (Time.TimeZone * 60) : 0) +
> > -   (time_t)(CumulativeDays[IsLeap(Time.Year)][Time.Month] *
> SECSPERDAY) +
> > -   (time_t)(((Time.Day > 0) ? Time.Day - 1 : 0) * SECSPERDAY) +
> > -   (time_t)(Time.Hour * SECSPERHOUR) +
> > -   (time_t)(Time.Minute * 60) +
> > -   (time_t)Time.Second;
> > -
> > -  return *timer;
> > +  CalTime = CalTime +
> > +    (time_t)((Time.TimeZone != EFI_UNSPECIFIED_TIMEZONE) ?
> (Time.TimeZone * 60) : 0) +
> > +    (time_t)(CumulativeDays[IsLeap(Time.Year)][Time.Month] *
> SECSPERDAY) +
> > +    (time_t)(((Time.Day > 0) ? Time.Day - 1 : 0) * SECSPERDAY) +
> > +    (time_t)(Time.Hour * SECSPERHOUR) +
> > +    (time_t)(Time.Minute * 60) +
> > +    (time_t)Time.Second;
> > +
> > +  if (timer != NULL) {
> > +    *timer = CalTime;
> > +  }
> > +
> > +  return CalTime;
> >  }
> >
> >  //
> >  // Convert a time value from type time_t to struct tm.
> >  //
> 
> It looks like this should be a single standalone commit, with its own
> commit comment explaining the change.
> 
> --
> David WoodhouseOpen Source Technology Centre
> david.woodho...@intel.com  Intel Corporation

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

[edk2] [PATCH 0/3] OvmfPkg: enable 64-bit PCI MMIO

[Laszlo Ersek]

This is the last wave(-let) I have for now.

Public branch:
.

Thomas, it would be great if you could test it.

Cc: Gerd Hoffmann 
Cc: Jordan Justen 
Cc: Marcel Apfelbaum 
Cc: Thomas Lamprecht 
Ref: https://github.com/tianocore/edk2/issues/59

Thanks
Laszlo

Laszlo Ersek (3):
  OvmfPkg: PlatformPei: factor out GetFirstNonAddress()
  OvmfPkg: PlatformPei: determine the 64-bit PCI host aperture for X64
DXE
  OvmfPkg: PciHostBridgeLib: install 64-bit PCI host aperture

 OvmfPkg/OvmfPkg.dec   |   5 +
 OvmfPkg/OvmfPkgIa32X64.dsc|   2 +
 OvmfPkg/OvmfPkgX64.dsc|   2 +
 OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf |   2 +
 OvmfPkg/PlatformPei/PlatformPei.inf   |   2 +
 OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c   |   7 ++
 OvmfPkg/PlatformPei/MemDetect.c   | 128 
+++-
 7 files changed, 147 insertions(+), 1 deletion(-)

-- 
1.8.3.1

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

[edk2] [PATCH 3/3] OvmfPkg: PciHostBridgeLib: install 64-bit PCI host aperture

[Laszlo Ersek]

On the normal boot path (which is when PciHostBridgeDxe runs), the PCDs
have been calculated; report the 64-bit PCI host aperture to
PciHostBridgeDxe.

In the Ia32 build, the PCD values (zeros) come directly from the DEC file,
and this patch makes no difference.

Cc: Gerd Hoffmann 
Cc: Jordan Justen 
Cc: Marcel Apfelbaum 
Cc: Thomas Lamprecht 
Ref: https://github.com/tianocore/edk2/issues/59
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf | 2 ++
 OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c   | 7 +++
 2 files changed, 9 insertions(+)

diff --git a/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf 
b/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf
index bbec74645c83..7a964c74c6cc 100644
--- a/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf
+++ b/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf
@@ -51,4 +51,6 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdPciIoSize
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size
+  gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base
+  gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
diff --git a/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c 
b/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c
index 3e02778492a8..1d3d10ad7379 100644
--- a/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c
+++ b/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c
@@ -132,6 +132,13 @@ InitRootBridge (
   RootBus->MemAbove4G.Base  = 0;
   RootBus->MemAbove4G.Limit = 0;
 
+  if (PcdGet64 (PcdPciMmio64Size) > 0) {
+RootBus->AllocationAttributes |= EFI_PCI_HOST_BRIDGE_MEM64_DECODE;
+RootBus->MemAbove4G.Base   = PcdGet64 (PcdPciMmio64Base);
+RootBus->MemAbove4G.Limit  = PcdGet64 (PcdPciMmio64Base) +
+ (PcdGet64 (PcdPciMmio64Size) - 1);
+  }
+
   RootBus->Bus.Base  = RootBusNumber;
   RootBus->Bus.Limit = MaxSubBusNumber;
   RootBus->Io.Base   = PcdGet64 (PcdPciIoBase);
-- 
1.8.3.1

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

[edk2] [PATCH 2/3] OvmfPkg: PlatformPei: determine the 64-bit PCI host aperture for X64 DXE

[Laszlo Ersek]

The main observation about the 64-bit PCI host aperture is that it is the
highest part of the useful address space. It impacts the top of the GCD
memory space map, and, consequently, our maximum address width calculation
for the CPU HOB too.

Thus, modify the GetFirstNonAddress() function to consider the following
areas above the high RAM, while calculating the first non-address (i.e.,
the highest inclusive address, plus one):

- the memory hotplug area (optional, the size comes from QEMU),

- the 64-bit PCI host aperture (we set a default size).

While computing the first non-address, capture the base and the size of
the 64-bit PCI host aperture at once in PCDs, since they are natural parts
of the calculation.

(Similarly to how PcdPciMmio32* are not rewritten on the S3 resume path
(see the InitializePlatform() -> MemMapInitialization() condition), nor
are PcdPciMmio64*. Only the core PciHostBridgeDxe driver consumes them,
through our PciHostBridgeLib instance.)

Set 32GB as the default size for the aperture. Issue#59 mentions the
NVIDIA Tesla K80 as an assignable device. According to nvidia.com, these
cards may have 24GB of memory (probably 16GB + 8GB BARs).

As a strictly experimental feature, the user can specify the size of the
aperture (in MB) as well, with the QEMU option

  -fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536

The "X-" prefix follows the QEMU tradition (spelled "x-" there), meaning
that the property is experimental, unstable, and might go away any time.
Gerd has proposed heuristics for sizing the aperture automatically (based
on 1GB page support and PCPU address width), but such should be delayed to
a later patch (which may very well back out "X-PciMmio64Mb" then).

For "everyday" guests, the 32GB default for the aperture size shouldn't
impact the PEI memory demand (the size of the page tables that the DXE IPL
PEIM builds). Namely, we've never reported narrower than 36-bit addresses;
the DXE IPL PEIM has always built page tables for 64GB at least.

For the aperture to bump the address width above 36 bits, either the guest
must have quite a bit of memory itself (in which case the additional PEI
memory demand shouldn't matter), or the user must specify a large aperture
manually with "X-PciMmio64Mb" (and then he or she is also responsible for
giving enough RAM to the VM, to satisfy the PEI memory demand).

Cc: Gerd Hoffmann 
Cc: Jordan Justen 
Cc: Marcel Apfelbaum 
Cc: Thomas Lamprecht 
Ref: https://github.com/tianocore/edk2/issues/59
Ref: http://www.nvidia.com/object/tesla-servers.html
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkg.dec |   5 +
 OvmfPkg/OvmfPkgIa32X64.dsc  |   2 +
 OvmfPkg/OvmfPkgX64.dsc  |   2 +
 OvmfPkg/PlatformPei/PlatformPei.inf |   2 +
 OvmfPkg/PlatformPei/MemDetect.c | 110 
 5 files changed, 121 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 784542f62368..3ad7621d13c9 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -130,6 +130,11 @@ [PcdsDynamic, PcdsDynamicEx]
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base|0x0|UINT64|0x24
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size|0x0|UINT64|0x25
 
+  ## The 64-bit MMIO aperture shared by all PCI root bridges.
+  #
+  gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0|UINT64|0x26
+  gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x0|UINT64|0x27
+
 [PcdsFeatureFlag]
   gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable|FALSE|BOOLEAN|3
   gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderPciTranslation|TRUE|BOOLEAN|0x1c
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index e9ffcb418522..eb16b9fb82ee 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -467,6 +467,8 @@ [PcdsDynamicDefault]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId|0
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base|0x0
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size|0x0
+  gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0
+  gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x8
 
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
 
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index c983a544d5f3..2d955b3df5f5 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -466,6 +466,8 @@ [PcdsDynamicDefault]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId|0
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base|0x0
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size|0x0
+  gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0
+  gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x8
 
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
 
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 6dc5ff079f53..5b643a358f1f 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ 

[edk2] [PATCH 1/3] OvmfPkg: PlatformPei: factor out GetFirstNonAddress()

[Laszlo Ersek]

Factor out the expression that is currently the basis of the address width
calculation into a standalone function. In the next patches we'll raise
the return value under certain circumstances.

Cc: Gerd Hoffmann 
Cc: Jordan Justen 
Cc: Marcel Apfelbaum 
Cc: Thomas Lamprecht 
Ref: https://github.com/tianocore/edk2/issues/59
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformPei/MemDetect.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 455fcbb49d13..286f6914a702 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -88,6 +88,22 @@ GetSystemMemorySizeAbove4gb (
 
 
 /**
+  Return the highest address that DXE could possibly use, plus one.
+**/
+STATIC
+UINT64
+GetFirstNonAddress (
+  VOID
+  )
+{
+  UINT64   FirstNonAddress;
+
+  FirstNonAddress = BASE_4GB + GetSystemMemorySizeAbove4gb ();
+  return FirstNonAddress;
+}
+
+
+/**
   Initialize the mPhysMemAddressWidth variable, based on guest RAM size.
 **/
 VOID
@@ -103,7 +119,7 @@ AddressWidthInitialization (
   // The DXL IPL keys off of the physical address bits advertized in the CPU
   // HOB. To conserve memory, we calculate the minimum address width here.
   //
-  FirstNonAddress  = BASE_4GB + GetSystemMemorySizeAbove4gb ();
+  FirstNonAddress  = GetFirstNonAddress ();
   mPhysMemAddressWidth = (UINT8)HighBitSet64 (FirstNonAddress);
 
   //
-- 
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 0/6] OvmfPkg: enable PCIe on Q35

[Laszlo Ersek]

On 03/10/16 19:20, Jordan Justen wrote:
> On 2016-03-10 02:34:58, Laszlo Ersek wrote:
>> Hi Jordan,
>>
>> On 03/08/16 15:19, Laszlo Ersek wrote:
>>> Version 2 of .
>>>
>>> News for v2: following Gerd's advice, I inserted a new patch (as #2),
>>> and reworked parts of patch #3. The changes are marked in detail on
>>> those patches.
>>>
>>> Review & testing feedback: Jordan should please review patches #2 and
>>> #3, and Gabriel and Michał should please retest the series in their
>>> usual environments. I also ran my own routine, successfully.
>>>
>>> Public branch: .
>>>
>>> Cc: Gabriel Somlo 
>>> Cc: Gerd Hoffmann 
>>> Cc: Jordan Justen 
>>> Cc: Marcel Apfelbaum 
>>> Cc: Michał Zegan 
>>
>> would you like to receive further feedback from people on the CC list?
>> (Michał and Gabriel have tested the series -- thank you guys.)
>>
> 
> I'm okay with it. You can extend my r-b for v2 of the series.

Sorry, this thread veered off-list; it's my fault. Bringing it back
on-list; I hope it's okay.

Thanks for all the reviews and testing. The series is now upstream,
range 7e869eeb15b0..7daf2401d420.

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

Re: [edk2] EDK2 Staging Repository

[Laszlo Ersek]

On 03/10/16 19:29, Kinney, Michael D wrote:
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]

>> Keeping work-in-progress modules in a separate repo has a critical
>> drawback: those modules will not share the commit history of the main
>> edk2 repo.
> 
> The issue with a single staging directory in edk2 is that we can not work on
> different features that touch the same module/lib.  This is where branching
> provides helps.  One purpose of edk2-staging is complex features that touch
> several modules, likely across multiple packages.
> 
> Maybe there are 2 concepts here.  One is feature branches for active 
> Design/dev/test.  Another is content that is functional and stable and 
> synced with the edk2 trunk, but has some number of "known" issues.
> 
>>
>> Consider the following example: a new release or erratum of the UEFI or
>> PI spec is published, and a developer contributes the implementation of
>> a new feature (or bugfix) to one of the core packages: MdePkg,
>> MdeModulePkg, NetworkPkg, etc. Then a platform developer would like to
>> rely on this UEFI or PI change in his or her work-in-progress module. If
>> that module lives outside of the main edk2 repo, it will cause a
>> dependency nightmare.
> 
> I the proposal, step (4e) says the feature branch maintainer needs to 
> keep the feature branch synced with the edk2 trunk.  The proposal uses
> the term "rebase", but that may not be the right operation to track
> changes from edk2 into an edk2-staging branch.  Maybe it is a "merge" 
> operation.
> 
> Also, for some new features, we may want to use a stable tag from edk2,
> so the feature development work can progress without having to track
> edk2.  Then as the feature matures and preparation for commit back to 
> edk2 begins, sync with edk2 is required.

Thank you for the clarification. I re-read the proposal. It seems to me
that the staging repo (with its feature branches) would enable several
people to collaborate on a longer term development, without disturbing
the master branch in edk2, and also without creating those feature
branches in edk2.

If several people (collaborators) intend to fetch those topic branches
periodically, then the "sync" operations will indeed have to be pulls
from edk2's master branch (otherwise everyone who fetches will have to
rebase locally).

However, I don't know what a good strategy is for deciding *when* to
pull. In another discussion, David linked

yesterday. In that message the suggestion seems to be: pull from master
only when master sees an important milestone; for example it satisfies a
new dependency of the feature branch, or reaches a release, or something
like that.

Also, in this case, when the feature is finally accepted, it will also
have to be a pull (in the opposite direction). Clearly, this will make
David's recent proposal (about accepting pull requests) unavoidable.

> I agree that not every development task should use a feature branch.  We 
> need clear criteria for using feature branches.  Please feel free to 
> provide additional guidelines on when you think a feature branch is 
> required or not required.

In QEMU and Linux, subsystems (and their maintainers) are the units of
separation, I think.

I also think that the main motivation for such separation is primarily
scalability -- the patch influx is just too high for a single (set) of
maintainers to handle. (Occasionally they have separate mailing lists
too.) For a counter-example, libvirt has a mostly linear history,
perhaps enabled by a lower patch load.

Edk2 doesn't have a huge patch influx. I guess the only guideline I can
come up with is: request a branch if you have to take turns with other
people at developing a large feature, and the feature really cannot be
committed in smaller waves to the main repo.

However, this also hides dangers. What if the feature grows too large
and too risky to pull at once? In Linux and QEMU this is mitigated by
time-based development cycles and frequent releases, and everyone does
their best to fit into such a cycle with their next feature -- or at
least plan and break up the feature into such milestones. Edk2 doesn't
have frequent time-based development cycles and releases. And conflict
resolution is decidedly un-fun.

... I'd like to defer to people who have experience with multi-level
distributed development from the maintainer side.

Laszlo

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

Re: [edk2] EDK2 Staging Repository

[Kinney, Michael D]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, March 10, 2016 2:03 AM
> To: Kinney, Michael D ; Justen, Jordan L
> ; Mangefeste, Tony ; 
> edk2-
> de...@lists.01.org 
> Subject: Re: [edk2] EDK2 Staging Repository
> 
> On 03/10/16 00:02, Kinney, Michael D wrote:
> > Jordan,
> >
> > Responses included below.
> >
> > Mike
> >
> >
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> >> Jordan Justen
> >> Sent: Wednesday, March 9, 2016 1:47 PM
> >> To: Mangefeste, Tony ; edk2-devel@lists.01.org
> >> Subject: Re: [edk2] EDK2 Staging Repository
> >>
> >> On 2016-03-09 10:53:38, Mangefeste, Tony wrote:
> >>> Below are the details of the proposal for a staging branch, please review 
> >>> and
> >> comment.
> >>>
> >>> 
> >>>
> >>> Problem statement
> >>> =
> >>> Need place on tianocore.org where new features that are not ready for 
> >>> product
> >>> integration can be checked in for evaluation by the EDK II community 
> >>> prior to
> >>> adding to the edk2 trunk.  This serves several purposes:
> >>>
> >>> * Encourage source code to be shared earlier in the development process
> >>> * Allow source code to be shared that does not yet meet all edk2 required 
> >>> quality
> >> criteria
> >>> * Allow source code to be shared so the EDK II community can help finish 
> >>> and
> validate
> >> new features
> >>> * Provide a location to hold new features until they are deemed ready for 
> >>> product
> >> integration
> >>> * Provide a location to hold new features until there is a natural point 
> >>> in edk2
> >> release cycle to fully validate the new feature.
> >>> * Not intended to be used for bug fixes.
> >>> * Not intended to be used for small, simple, or low risk features.
> >>>
> >>
> >> I think the parts about making a central place for big feature
> >> branches seems good. I think Laszlo might have appreciated having a
> >> well defined central location for his OVMF SMM enabling branch.
> >>
> >> I think the processes around allowing the code to be merged seems too
> >> heavyweight. In the cases of big patchsets, it can be burdensome
> >> enough just to get code review. To insert another process step (and
> >> set of approvers) to actually merge the feature seems perhaps
> >> unneccesary.
> >>
> >>> Proposal
> >>> 
> >>> 1) Create a new repo called edk2-staging
> >>> a) edk2-staging is a fork of edk
> >>> b) edk2-staging/master tracks edk2/master
> >>>
> >>
> >> For branches maintained by package maintainers, could we have them
> >> under the edk2 repo and named staging/*?
> >
> > Do you mean a directory in the edk2 repo called staging?  I did think about 
> > this
> option,
> > but I am concerned about code that is not ready for product integration 
> > being in the
> edk2
> > repo and I am also concerned about the size of the edk2 repo.  Creating a 
> > new repo
> that is
> > a fork of edk2 addressed both of those issues.
> 
> I disagree.
> 
> I have now re-read our private discussion from last year, when we were
> working on SMM (the core infrastructure and the OVMF platform enablement
> in parallel). The message ID of the root of the sub-thread is
> <564f50b9.6040...@redhat.com>, if someone on CC at that time would like
> to re-read it now.
> 
> At that time, the consensus seemed to be to create a top-level Staging/
> directory, with packages under it (with their DEC files and modules).
> So, we would have:
> 
> ArmVirtPkg/...
> EmulatorPkg/...
> OvmfPkg/...
> Staging/ArmVirtPkg/...
> Staging/EmulatorPkg/...
> Staging/OvmfPkg/...
> 
> This matches how Linux works, and the naming makes it very clear that
> modules (drivers, applications, library instances) under Staging are
> work in progress. It is not possible to include a module from under
> Staging as an oversight.
> 
> Keeping work-in-progress modules in a separate repo has a critical
> drawback: those modules will not share the commit history of the main
> edk2 repo.

The issue with a single staging directory in edk2 is that we can not work on
different features that touch the same module/lib.  This is where branching
provides helps.  One purpose of edk2-staging is complex features that touch
several modules, likely across multiple packages.

Maybe there are 2 concepts here.  One is feature branches for active 
Design/dev/test.  Another is content that is functional and stable and 
synced with the edk2 trunk, but has some number of "known" issues.

> 
> Consider the following example: a new release or erratum of the UEFI or
> PI spec is published, and a developer contributes the implementation of
> a new feature (or bugfix) to one of the core packages: MdePkg,
> MdeModulePkg, NetworkPkg, etc. Then a platform developer would like to
> rely on this UEFI or PI change in his 

Re: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to enable 'openssl\ssl'

[Long, Qin]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of David 
> Woodhouse
> Sent: Thursday, March 10, 2016 10:01 AM
> To: Long, Qin ; Wu, Jiaxin ; 
> edk2-de...@ml01.01.org
> Cc: Ye, Ting ; Fu, Siyuan 
> Subject: Re: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to enable 
> 'openssl\ssl'
> 
> On Thu, 2016-03-10 at 17:12 +, Long, Qin wrote:
> >
> > This patch series should be based on the old version, before the
> > back-porting of upstreaming patch was done.
> > We should have no need to add the extra patches on OpenSSL now for
> > OpensslTlsLib build now.
> 
> Do you have a simple test case for OpensslTlsLib? I have it building
> the library against 1.0.2, and I'll make sure it builds for 1.1 too
> (although today was the last day for making significant changes in 1.1
> so I hope we aren't missing anything!).
> 
> However, a simple UEFI application which can make a TLS connection
> would be useful... or at least a git tree I can pull the HTTPS work
> from; applying patches is kind of painful until we get the CRLF
> nonsense fixed.
> 

Exactly. 
Unfortunately, we have no this kind of app (like Cryptest) in hand. I ever did 
one app to validate the SSL handshaking by leveraging the memory BIO (no 
socket) mechanism to make sure which is workable in UEFI environment. OK, 
Jiaxin and I will summary some steps for HTTPS validations. 
And will also work out one simple validation application (such as Tlstest.efi) 
for this case later, which should be helpful. 

> --
> dwmw2

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

[edk2] KVM Forum 2016: Call For Participation

[Paolo Bonzini]

=
KVM Forum 2016: Call For Participation
August 24-26, 2016 - Westin Harbor Castle - Toronto, Canada

(All submissions must be received before midnight May 1, 2016)
=

KVM Forum is an annual event that presents a rare opportunity
for developers and users to meet, discuss the state of Linux
virtualization technology, and plan for the challenges ahead. 
We invite you to lead part of the discussion by submitting a speaking
proposal for KVM Forum 2016.

At this highly technical conference, developers driving innovation
in the KVM virtualization stack (Linux, KVM, QEMU, libvirt) can
meet users who depend on KVM as part of their offerings, or to
power their data centers and clouds.

KVM Forum will include sessions on the state of the KVM
virtualization stack, planning for the future, and many
opportunities for attendees to collaborate. As we celebrate ten years
of KVM development in the Linux kernel, KVM continues to be a
critical part of the FOSS cloud infrastructure.

This year, KVM Forum is joining LinuxCon and ContainerCon in Toronto, 
Canada. Selected talks from KVM Forum will be presented on Wednesday
August 24 to the full audience of LinuxCon and ContainerCon. Also,
attendees of KVM Forum will have access to all of the LinuxCon and
ContainerCon talks on Wednesday.

http://events.linuxfoundation.org/cfp

Suggested topics:

KVM and Linux
* Scaling and optimizations
* Nested virtualization
* Linux kernel performance improvements
* Resource management (CPU, I/O, memory)
* Hardening and security
* VFIO: SR-IOV, GPU, platform device assignment
* Architecture ports

QEMU
* Management interfaces: QOM and QMP
* New devices, new boards, new architectures
* Scaling and optimizations
* Desktop virtualization and SPICE
* Virtual GPU
* virtio and vhost, including non-Linux or non-virtualized uses
* Hardening and security
* New storage features
* Live migration and fault tolerance
* High availability and continuous backup
* Real-time guest support
* Emulation and TCG
* Firmware: ACPI, UEFI, coreboot, u-Boot, etc.
* Testing

Management and infrastructure
* Managing KVM: Libvirt, OpenStack, oVirt, etc.
* Storage: glusterfs, Ceph, etc.
* Software defined networking: Open vSwitch, OpenDaylight, etc.
* Network Function Virtualization
* Security
* Provisioning
* Performance tuning


===
SUBMITTING YOUR PROPOSAL
===
Abstracts due: May 1, 2016

Please submit a short abstract (~150 words) describing your presentation
proposal. Slots vary in length up to 45 minutes. Also include the proposal
type -- one of:
- technical talk
- end-user talk

Submit your proposal here:
http://events.linuxfoundation.org/cfp
Please only use the categories "presentation" and "panel discussion"

You will receive a notification whether or not your presentation proposal
was accepted by May 27, 2016.

Speakers will receive a complimentary pass for the event. In the instance
that your submission has multiple presenters, only the primary speaker for a
proposal will receive a complementary event pass. For panel discussions, all
panelists will receive a complimentary event pass.

TECHNICAL TALKS

A good technical talk should not just report on what has happened over
the last year; it should present a concrete problem and how it impacts
the user and/or developer community. Whenever applicable, focus on
work that needs to be done, difficulties that haven't yet been solved,
and on decisions that other developers should be aware of. Summarizing
recent developments is okay but it should not be more than a small
portion of the overall talk.

END-USER TALKS

One of the big challenges as developers is to know what, where and how
people actually use our software. We will reserve a few slots for end
users talking about their deployment challenges and achievements.

If you are using KVM in production you are encouraged submit a speaking
proposal. Simply mark it as an end-user talk. As an end user, this is a
unique opportunity to get your input to developers.

HANDS-ON / BOF SESSIONS

We will reserve some time for people to get together and discuss
strategic decisions as well as other topics that are best solved within
smaller groups.

These sessions will be announced during the event. If you are interested
in organizing such a session, please add it to the list at

  http://www.linux-kvm.org/page/KVM_Forum_2016_BOF

Let people you think might be interested know about it, and encourage
them to add their names to the wiki page as well. Please try to
add your ideas to the list before KVM Forum starts.


PANEL DISCUSSIONS

If you are proposing a panel discussion, please make sure that you list
all of your potential panelists in your abstract. We will request full
biographies if a panel is accepted.


===
HOTEL / TRAVEL
===

This year's event will take place at the Westin Harbour Castle Toronto.
For 

Re: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to enable 'openssl\ssl'

[David Woodhouse]

On Thu, 2016-03-10 at 17:12 +, Long, Qin wrote:
> 
> This patch series should be based on the old version, before the
> back-porting of upstreaming patch was done.
> We should have no need to add the extra patches on OpenSSL now for
> OpensslTlsLib build now.

Do you have a simple test case for OpensslTlsLib? I have it building
the library against 1.0.2, and I'll make sure it builds for 1.1 too
(although today was the last day for making significant changes in 1.1
so I hope we aren't missing anything!).

However, a simple UEFI application which can make a TLS connection
would be useful... or at least a git tree I can pull the HTTPS work
from; applying patches is kind of painful until we get the CRLF
nonsense fixed.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] EDK2 Staging Repository

[Mangefeste, Tony]

Yep, I've heard that loud and clear.  It must not be only web UI, but can be 
over email _if_ we move with Gerrit or something similar.



-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, March 10, 2016 9:34 AM
To: Mangefeste, Tony ; Gerd Hoffmann 
; Bruce Cran 
Cc: Justen, Jordan L ; edk2-devel@lists.01.org 

Subject: Re: [edk2] EDK2 Staging Repository

On 03/10/16 17:55, Mangefeste, Tony wrote:
> This is fantastic, because the other two things I would like for us all to 
> consider is Gerrit+Jenkins support.

Sorry for repeating myself :(, but:

Please make sure that all reviews done on the web are forwarded to the mailing 
list, and that I can chime in using only my MUA.

Thanks
Laszlo

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

Re: [edk2] [PATCH v2] BaseTools ConvertMasmToNasm: Support Python 3

[Bjorge, Erik C]

Reviewed-by: Erik Bjorge 

> -Original Message-
> From: Justen, Jordan L
> Sent: Wednesday, March 9, 2016 5:46 PM
> To: edk2-devel@lists.01.org
> Cc: Justen, Jordan L ; Zhu, Yonghong
> ; Gao, Liming ; Bjorge,
> Erik C 
> Subject: [PATCH v2] BaseTools ConvertMasmToNasm: Support Python 3
> 
> The script is updated to support both python 2.7 and python 3.
> 
> v2:
>  * Use io.open() rather than open() (Jaben)
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jordan Justen 
> Cc: Yonghong Zhu 
> Cc: Liming Gao 
> Cc: Erik Bjorge 
> ---
>  BaseTools/Scripts/ConvertMasmToNasm.py | 90 ++-
> ---
>  1 file changed, 47 insertions(+), 43 deletions(-)
> 
> diff --git a/BaseTools/Scripts/ConvertMasmToNasm.py
> b/BaseTools/Scripts/ConvertMasmToNasm.py
> index 8288972..6a0d27d 100755
> --- a/BaseTools/Scripts/ConvertMasmToNasm.py
> +++ b/BaseTools/Scripts/ConvertMasmToNasm.py
> @@ -12,13 +12,15 @@
>  #  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> IMPLIED.
>  #
> 
> +from __future__ import print_function
> +
>  #
>  # Import Modules
>  #
>  import argparse
> +import io
>  import os.path
>  import re
> -import StringIO
>  import subprocess
>  import sys
> 
> @@ -152,12 +154,12 @@ class CommonUtils:
>  (stdout, stderr) = p.communicate(pipeIn)
>  if checkExitCode:
>  if p.returncode != 0:
> -print 'command:', ' '.join(cmd)
> -print 'stdout:', stdout
> -print 'stderr:', stderr
> -print 'return:', p.returncode
> +print('command:', ' '.join(cmd))
> +print('stdout:', stdout)
> +print('stderr:', stderr)
> +print('return:', p.returncode)
>  assert p.returncode == 0
> -return stdout
> +return stdout.decode('utf-8', 'ignore')
> 
>  def FileUpdated(self, path):
>  if not self.git or not self.gitdir:
> @@ -181,7 +183,7 @@ class CommonUtils:
>  return
> 
>  if not self.args.quiet:
> -print 'Committing: Conversion of', dst
> +print('Committing: Conversion of', dst)
> 
>  prefix = ' '.join(filter(lambda a: a, [pkg, module]))
>  message = ''
> @@ -195,6 +197,7 @@ class CommonUtils:
>  message += 'Contributed-under: TianoCore Contribution Agreement
> 1.0\n'
>  assert(self.gitemail is not None)
>  message += 'Signed-off-by: %s\n' % self.gitemail
> +message = message.encode('utf-8', 'ignore')
> 
>  cmd = ('git', 'commit', '-F', '-')
>  self.RunAndCaptureOutput(cmd, pipeIn=message)
> @@ -226,23 +229,22 @@ class ConvertAsmFile(CommonUtils):
> 
>  self.inputFileBase = os.path.basename(self.inputFilename)
>  self.outputFileBase = os.path.basename(self.outputFilename)
> -if self.outputFilename == '-' and not self.diff:
> -self.output = sys.stdout
> -else:
> -self.output = StringIO.StringIO()
> +self.output = io.BytesIO()
>  if not self.args.quiet:
>  dirpath, src = os.path.split(self.inputFilename)
>  dirpath = self.RootRelative(dirpath)
>  dst = os.path.basename(self.outputFilename)
> -print 'Converting:', dirpath, src, '->', dst
> -lines = open(self.inputFilename).readlines()
> +print('Converting:', dirpath, src, '->', dst)
> +lines = io.open(self.inputFilename).readlines()
>  self.Convert(lines)
> -if self.outputFilename == '-':
> -if self.diff:
> -sys.stdout.write(self.output.getvalue())
> -self.output.close()
> +if self.outputFilename == '-' and not self.diff:
> +output_data = self.output.getvalue()
> +if sys.version_info >= (3, 0):
> +output_data = output_data.decode('utf-8', 'ignore')
> +sys.stdout.write(output_data)
> +self.output.close()
>  else:
> -f = open(self.outputFilename, 'wb')
> +f = io.open(self.outputFilename, 'wb')
>  f.write(self.output.getvalue())
>  f.close()
>  self.output.close()
> @@ -521,18 +523,18 @@ class ConvertAsmFile(CommonUtils):
>  return '.%d' % count
> 
>  def EmitString(self, string):
> -self.output.write(string)
> +self.output.write(string.encode('utf-8', 'ignore'))
> 
>  def EmitLineWithDiff(self, old, new):
>  newLine = (self.indent + new).rstrip()
>  if self.diff:
>  if old is None:
> -print '+%s' % newLine
> +print('+%s' % newLine)
>  elif newLine != old:
> 

Re: [edk2] EDK2 Staging Repository

[Laszlo Ersek]

On 03/10/16 17:55, Mangefeste, Tony wrote:
> This is fantastic, because the other two things I would like for us all to 
> consider is Gerrit+Jenkins support.

Sorry for repeating myself :(, but:

Please make sure that all reviews done on the web are forwarded to the
mailing list, and that I can chime in using only my MUA.

Thanks
Laszlo

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

Re: [edk2] Tianocore Community Update 2016 #1

[Laszlo Ersek]

On 03/10/16 18:20, Mangefeste, Tony wrote:
> Very good thoughts, Laszlo.
> 
> The more I think about GitHub integration, the more I'm leaning
> against it.  Another reason is that we can assign groups to certain
> organizational emails to allow/grant special rights to specific
> classes of issues.  For example, it's plausible that we would give
> anyone from *@redhat.com for instance a group that identified them as
> part of that organization and then grant tha ability to perform
> special triage tasks or other organization specific tasks, while
> keeping the content visible to the community.

Sounds great. I think it also matches David's idea.

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

Re: [edk2] [PATCH] CryptoPkg/OpensslLib: Convert saved opensslconf.h to DOS line endings

[Long, Qin]

Reviewed-by: Qin Long 


Best Regards & Thanks,
LONG, Qin

> -Original Message-
> From: David Woodhouse [mailto:david.woodho...@intel.com]
> Sent: Thursday, March 10, 2016 3:15 AM
> To: edk2-de...@ml01.01.org
> Cc: Long, Qin 
> Subject: [PATCH] CryptoPkg/OpensslLib: Convert saved opensslconf.h to DOS 
> line endings
> 
> Until we fix the git repository to store line endings properly and then
> just check them out in the appropriate form for the platform, let's make
> process_files.sh convert the opensslconf.h to DOS line endings when it
> creates it.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: David Woodhouse 
> ---
>  CryptoPkg/Library/OpensslLib/process_files.sh | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/CryptoPkg/Library/OpensslLib/process_files.sh 
> b/CryptoPkg/Library/OpensslLib/process_files.sh
> index bb33c8a..1094fd4 100755
> --- a/CryptoPkg/Library/OpensslLib/process_files.sh
> +++ b/CryptoPkg/Library/OpensslLib/process_files.sh
> @@ -93,5 +93,6 @@ function filelist ()
>  filelist < "${OPENSSL_PATH}/MINFO" |  sed -n -f - -i OpensslLib.inf
> 
>  # We can tell Windows users to put this back manually if they can't run
> -# Configure.
> -cp "${OPENSSL_PATH}/crypto/opensslconf.h" .
> +# Configure. For now, until the git repository is fixed to store things
> +# sanely, also convert to DOS line-endings
> +unix2dos "${OPENSSL_PATH}/crypto/opensslconf.h" opensslconf.h
> --
> 2.5.0
> 
> --
> David WoodhouseOpen Source Technology Centre
> david.woodho...@intel.com  Intel Corporation

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

Re: [edk2] Tianocore Community Update 2016 #1

[Mangefeste, Tony]

Very good thoughts, Laszlo.

The more I think about GitHub integration, the more I'm leaning against it.  
Another reason is that we can assign groups to certain organizational emails to 
allow/grant special rights to specific classes of issues.  For example, it's 
plausible that we would give anyone from *@redhat.com for instance a group that 
identified them as part of that organization and then grant tha ability to 
perform special triage tasks or other organization specific tasks, while 
keeping the content visible to the community. 

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, March 10, 2016 2:33 AM
To: Mangefeste, Tony 
Cc: edk2-devel@lists.01.org 
Subject: Re: [edk2] Tianocore Community Update 2016 #1

On 03/09/16 19:49, Mangefeste, Tony wrote:

> I. Defect & Issue Tracking

> There are several topics we're investigating, and your input is appreciated:

First of all, thank you very much for going forward with Bugzilla!

> * Considering tying the Bugzilla login to GitHub using GitHub as the 
> provider.  This would mean that anyone wishing to submit an item into 
> BZ would require a GitHub account.

I vote against this. I find 3rd party authentication providers insecure.
While I find Single Sign On extremely useful (and also secure) in a single, 
centrally managed organization, GitHub and the edk2 Bugzilla (to be operated by 
Intel) are separate entities.

A breach of GitHub could lead to a breach of the Bugzilla, and leakage of 
sensitive data (private comments, private bugs, private attachments).

Downtime of GitHub would prevent us from logging into Bugzilla.

Modern browsers have built-in password managers. The practice I generally 
follow is to have a unique, complex, machine-generated password for every 
public-facing website, and to store those in a reliable password manager 
(behind a very strong master password of coruse).

--*--

Another practical remark: I insist on having access to the personal email 
addresses of people who report bugs, for two reasons.

Less importantly, I want to be able to contact them in email, outside of 
bugzilla (they might have some files I need for debugging, but their data is 
too sensitive or too big to attach to the bug).

More importantly, if I write patches for a BZ entry (bug or feature request), I 
always CC the reporter on the patches. Now, purely for informing the reporter 
about the patches, my "other" best practice would suffice in itself -- that 
best practice being: I link every patch submisson from the mailing list archive 
immediately into the bug --, but the main goal is that I want his/her testing 
feedback. For that the reporter should be able to build my patches, hence I CC 
him/her directly. Therefore I need his/her email address on the bug.

Fishing the emails of reporters out of GitHub's issue tracker has been a pain. 
One clicks the "@reporter_nick" style link in the discussion, and hopes that 
the reporter's profile page lists his/her email address publicly. If it 
doesn't, then I have to ask for it in the tracker entry explicitly, or I can 
try googling it.

Bugzilla normally gives me the email addresses of all commenters on the bug 
automatically, and so it should be.

(Example: my profile page  does not list my email 
address either. Why? Because I don't like spam, and my email is trivially 
googleable for humans, from my name & employer. The point with Bugzilla is that 
it only exposes email addresses to logged in users (no bots), but then logged 
in users do get all the addresses without further
obstacles.)

I'm worried that if GitHub provided the authentication for Bugzilla, it could 
withhold email addresses from Bugzilla, and break the above use case.

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

Re: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to enable 'openssl\ssl'

[Long, Qin]

David,

This patch series should be based on the old version, before the back-porting 
of upstreaming patch was done.
We should have no need to add the extra patches on OpenSSL now for 
OpensslTlsLib build now.


Best Regards & Thanks,
LONG, Qin

> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: Thursday, March 10, 2016 2:47 AM
> To: Wu, Jiaxin ; edk2-de...@ml01.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Long, Qin 
> 
> Subject: Re: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to enable 
> 'openssl\ssl'
> 
> On Wed, 2016-02-24 at 16:15 +0800, Jiaxin Wu wrote:
> > diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
> > b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
> > index c0ccc0e..e68bfb8 100644
> > --- a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
> > +++ b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
> > @@ -446,5 +446,10 @@ void syslog (int a, const char *c, ...)
> >
> >  ssize_t write (int f, const void *b, size_t l)
> >  {
> >    return 0;
> >  }
> > +
> > +int printf (char const *fmt, ...)
> > +{
> > +  return 0;
> > +}
> 
> I'm assuming this is to work around a stray printf() in OpenSSL code
> that we weren't building before?
> 
> The correct fix is to file a ticket upstream, submit a *fix* upstream
> to be included in OpenSSL, and then to add the corresponding backported
> patch to our EDKII_openssl patch.
> 
> Please don't add more workarounds like the above; we're trying to clean
> those up not accumulate more.
> 
> And again... even if this was the right thing to do, it lives in a
> *separate* standalone commit. It's OK if it's gratuitous, and the
> commit comment simply says "we *will* want this because...".
> 
> See some of the OpenSSL API cleanups, for example, which make things
> *ready* for OpenSSL 1.1 even while we're still using 1.0.2.
> 
> --
> David WoodhouseOpen Source Technology Centre
> david.woodho...@intel.com  Intel Corporation

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

Re: [edk2] EDK2 Staging Repository

[Bruce Cran]

On 3/10/16 9:55 AM, Mangefeste, Tony wrote:

This is fantastic, because the other two things I would like for us all to 
consider is Gerrit+Jenkins support.


Why Gerrit?  Everyone I've seen talk about it hate its UI.

FWIW I seem to be leading a bit of a rebellion at $work, since I setup a 
demo Phabricator instance (for the repo browser and code review) and 
most people love it, to the extent that they're saying they wish we'd 
used it from the start and wondering if any engineers were involved in 
the decision to use the tool that we're supposed to be using.


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

Re: [edk2] EDK2 Staging Repository

[Mangefeste, Tony]

This is fantastic, because the other two things I would like for us all to 
consider is Gerrit+Jenkins support.

I'll be talking to you to get more details. 

-Original Message-
From: Gerd Hoffmann [mailto:kra...@redhat.com] 
Sent: Thursday, March 10, 2016 12:39 AM
To: Bruce Cran 
Cc: Justen, Jordan L ; Mangefeste, Tony 
; edk2-devel@lists.01.org 
Subject: Re: [edk2] EDK2 Staging Repository

On Mi, 2016-03-09 at 16:57 -0700, Bruce Cran wrote:
> On 3/9/16 2:59 PM, Jordan Justen wrote:
> 
> > So far I have a setup that can test building BaseTools and OVMF on 
> > Linux. The Windows setup is a little more complicated, but I don't 
> > think it should be too difficult.
> 
> I guess that's Linux x86_64? Any solution we come up with should also 
> be extendable to AARCH64.

I do have jenkins running, doing the builds for https://www.kraxel.org/repos/, 
including aarch64 and arm builds (using a cross compiler).

If there is interest I configure jenkins to send build failures to the list 
too.  There are some drawbacks though:

  (1) There are false positives now and then for various reasons:
  * Now and then manual invention is needed to keep things going
(for example on openssl updates).
  * The rpm package has patches which need a rebase now and then.
  * Occasionally infrastructure hickups.
  (2) Sometimes it takes me a few days to deal with those issues,
  jenkins will keep on reporting the build failures until I did.
  (3) The system runs on a private network behind a NAT router, so you
  wouldn't be able to click on the links for build logs etc, all you
  get is the mail reporting the failure.
  (4) It's designed to provide rpms for the master branch, that it
  test-builds the master branch is more a side-effect.  I most
  likely wouldn't extend this to also build staging branches.

If you ever wondered how Laszlo notices quickly if someone breaks the build, he 
gets the jenkins reports ;)

cheers,
  Gerd

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

Re: [edk2] Tianocore Community Update 2016 #1

[Laszlo Ersek]

On 03/10/16 14:11, David Woodhouse wrote:
> On Thu, 2016-03-10 at 13:58 +0100, Laszlo Ersek wrote:
>>
>>> Sure, actually getting vendor buy-in for that is a completely different
>>> story. But let's not design the system to make it hard :)
>>
>> I couldn't buy in.
> 
> That's fine. I'm not asking you to. I'm just asking that we don't make
> it *harder*.
> 

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

Re: [edk2] [patch] SecurityPkg: Fix Tcg2 SubmitRequestToPreOSFunction() fail in second times.

[Yao, Jiewen]

No, not for TPM1.2, because TPM1.2 PP does not have RequestParameter field.

Thank you
Yao Jiewen

-Original Message-
From: Zhang, Chao B 
Sent: Thursday, March 10, 2016 6:07 AM
To: Yao, Jiewen; edk2-de...@ml01.01.org
Subject: RE: [patch] SecurityPkg: Fix Tcg2 SubmitRequestToPreOSFunction() fail 
in second times.


Jiewen:
   The patch is good to me. Do we have the same issue for TPM1.2 ?
   




Thanks & Best regards
Chao Zhang


-Original Message-
From: Yao, Jiewen 
Sent: Thursday, March 10, 2016 1:47 PM
To: edk2-de...@ml01.01.org
Cc: Yao, Jiewen; Zhang, Chao B
Subject: [patch] SecurityPkg: Fix Tcg2 SubmitRequestToPreOSFunction() fail in 
second times.

Tcg2PhysicalPresenceLibSubmitRequestToPreOSFunction()
has check if current request is same as previous.
But it forget check RequestParameter, which causes second request fail to 
process, if RequestParameter is different.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
Cc: "Zhang, Chao B" 
---
 .../Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.c  | 5 +++-- 
 .../Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresenceLib.c  | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git 
a/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.c 
b/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.c
index 46fc616..8912ee4 100644
--- 
a/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.c
+++ b/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPres
+++ enceLib.c
@@ -7,7 +7,7 @@
 
   Tpm2ExecutePendingTpmRequest() will receive untrusted input and do 
validation.
 
-Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2013 - 2016, 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 @@ -1208,7 +1208,8 
@@ Tcg2PhysicalPresenceLibSubmitRequestToPreOSFunction (
 return TCG_PP_SUBMIT_REQUEST_TO_PREOS_NOT_IMPLEMENTED;
   }
 
-  if (PpData.PPRequest != OperationRequest) {
+  if ((PpData.PPRequest != OperationRequest) ||
+  (PpData.PPRequestParameter != RequestParameter)) {
 PpData.PPRequest = (UINT8)OperationRequest;
 PpData.PPRequestParameter = RequestParameter;
 DataSize = sizeof (EFI_TCG2_PHYSICAL_PRESENCE); diff --git 
a/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresenceLib.c 
b/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresenceLib.c
index 360df72..081ec6c 100644
--- 
a/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresenceLib.c
+++ b/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPres
+++ enceLib.c
@@ -10,7 +10,7 @@
   Tcg2PhysicalPresenceLibSubmitRequestToPreOSFunction() and 
Tcg2PhysicalPresenceLibGetUserConfirmationStatusFunction()
   will receive untrusted input and do validation.
 
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2016, 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 @@ -134,7 +134,8 @@ 
Tcg2PhysicalPresenceLibSubmitRequestToPreOSFunction (
 return TCG_PP_SUBMIT_REQUEST_TO_PREOS_NOT_IMPLEMENTED;
   }
 
-  if (PpData.PPRequest != OperationRequest) {
+  if ((PpData.PPRequest != OperationRequest) ||
+  (PpData.PPRequestParameter != RequestParameter)) {
 PpData.PPRequest = (UINT8)OperationRequest;
 PpData.PPRequestParameter = RequestParameter;
 DataSize = sizeof (EFI_TCG2_PHYSICAL_PRESENCE);
--
1.9.5.msysgit.0

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

Re: [edk2] [patch] SecurityPkg: Clear LocalAuthSession content after use.

[Zhang, Chao B]

Reviewed-by: Chao Zhang 





Thanks & Best regards
Chao Zhang


-Original Message-
From: Yao, Jiewen 
Sent: Thursday, March 10, 2016 1:53 PM
To: edk2-de...@ml01.01.org
Cc: Yao, Jiewen; Zhang, Chao B
Subject: [patch] SecurityPkg: Clear LocalAuthSession content after use.

Some commands in DxeTcg2PhysicalPresenceLib accept AuthSession as input 
parameter and copy to local command buffer. After use, this AuthSession content 
should be zeroed, because there might be some secrete there.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
Cc: "Zhang, Chao B" 
---
 .../DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.c   | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git 
a/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.c 
b/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.c
index 8912ee4..e34fd8d 100644
--- 
a/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.c
+++ b/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPres
+++ enceLib.c
@@ -225,7 +225,7 @@ Tpm2CommandAllocPcr (
  );
   DEBUG ((EFI_D_INFO, "Tpm2PcrAllocate - %r\n", Status));
   if (EFI_ERROR (Status)) {
-return Status;
+goto Done;
   }
 
   DEBUG ((EFI_D_INFO, "AllocationSuccess - %02x\n", AllocationSuccess)); @@ 
-233,7 +233,9 @@ Tpm2CommandAllocPcr (
   DEBUG ((EFI_D_INFO, "SizeNeeded- %08x\n", SizeNeeded));
   DEBUG ((EFI_D_INFO, "SizeAvailable - %08x\n", SizeAvailable));
 
-  return EFI_SUCCESS;
+Done:
+  ZeroMem(, sizeof(LocalAuthSession.hmac));
+  return Status;
 }
 
 /**
@@ -264,6 +266,8 @@ Tpm2CommandChangeEps (
 
   Status = Tpm2ChangeEPS (TPM_RH_PLATFORM, AuthSession);
   DEBUG ((EFI_D_INFO, "Tpm2ChangeEPS - %r\n", Status));
+
+  ZeroMem(, sizeof(LocalAuthSession.hmac));
   return Status;
 }
 
--
1.9.5.msysgit.0

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

Re: [edk2] [patch] SecurityPkg: Fix Tcg2 SubmitRequestToPreOSFunction() fail in second times.

[Zhang, Chao B]

Jiewen:
   The patch is good to me. Do we have the same issue for TPM1.2 ?
   




Thanks & Best regards
Chao Zhang


-Original Message-
From: Yao, Jiewen 
Sent: Thursday, March 10, 2016 1:47 PM
To: edk2-de...@ml01.01.org
Cc: Yao, Jiewen; Zhang, Chao B
Subject: [patch] SecurityPkg: Fix Tcg2 SubmitRequestToPreOSFunction() fail in 
second times.

Tcg2PhysicalPresenceLibSubmitRequestToPreOSFunction()
has check if current request is same as previous.
But it forget check RequestParameter, which causes second request fail to 
process, if RequestParameter is different.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
Cc: "Zhang, Chao B" 
---
 .../Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.c  | 5 +++-- 
 .../Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresenceLib.c  | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git 
a/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.c 
b/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.c
index 46fc616..8912ee4 100644
--- 
a/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.c
+++ b/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPres
+++ enceLib.c
@@ -7,7 +7,7 @@
 
   Tpm2ExecutePendingTpmRequest() will receive untrusted input and do 
validation.
 
-Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2013 - 2016, 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 @@ -1208,7 +1208,8 
@@ Tcg2PhysicalPresenceLibSubmitRequestToPreOSFunction (
 return TCG_PP_SUBMIT_REQUEST_TO_PREOS_NOT_IMPLEMENTED;
   }
 
-  if (PpData.PPRequest != OperationRequest) {
+  if ((PpData.PPRequest != OperationRequest) ||
+  (PpData.PPRequestParameter != RequestParameter)) {
 PpData.PPRequest = (UINT8)OperationRequest;
 PpData.PPRequestParameter = RequestParameter;
 DataSize = sizeof (EFI_TCG2_PHYSICAL_PRESENCE); diff --git 
a/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresenceLib.c 
b/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresenceLib.c
index 360df72..081ec6c 100644
--- 
a/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresenceLib.c
+++ b/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPres
+++ enceLib.c
@@ -10,7 +10,7 @@
   Tcg2PhysicalPresenceLibSubmitRequestToPreOSFunction() and 
Tcg2PhysicalPresenceLibGetUserConfirmationStatusFunction()
   will receive untrusted input and do validation.
 
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2016, 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 @@ -134,7 +134,8 @@ 
Tcg2PhysicalPresenceLibSubmitRequestToPreOSFunction (
 return TCG_PP_SUBMIT_REQUEST_TO_PREOS_NOT_IMPLEMENTED;
   }
 
-  if (PpData.PPRequest != OperationRequest) {
+  if ((PpData.PPRequest != OperationRequest) ||
+  (PpData.PPRequestParameter != RequestParameter)) {
 PpData.PPRequest = (UINT8)OperationRequest;
 PpData.PPRequestParameter = RequestParameter;
 DataSize = sizeof (EFI_TCG2_PHYSICAL_PRESENCE);
--
1.9.5.msysgit.0

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

Re: [edk2] Tianocore Community Update 2016 #1

[David Woodhouse]

On Thu, 2016-03-10 at 13:58 +0100, Laszlo Ersek wrote:
> 
> > Sure, actually getting vendor buy-in for that is a completely different
> > story. But let's not design the system to make it hard :)
> 
> I couldn't buy in.

That's fine. I'm not asking you to. I'm just asking that we don't make
it *harder*.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Tianocore Community Update 2016 #1

[Laszlo Ersek]

On 03/10/16 11:58, David Woodhouse wrote:
> On Thu, 2016-03-10 at 11:33 +0100, Laszlo Ersek wrote:
>>
>>> * Considering tying the Bugzilla login to GitHub using GitHub as the
>>> provider.  This would mean that anyone wishing to submit an item into
>>> BZ would require a GitHub account.
>>
>> I vote against this. I find 3rd party authentication providers insecure.
> 
> I concur.
> 
> The end goal should be a coherent bug tracking system where a user can
> file a bug, and it can be reassigned to TianoCore or to a specific
> vendor's "value subtract",

I think a cross-vendor tracker is too steep. Usually vendors (including
Red Hat) have their own public trackers already. For example, in Red Hat
Bugzilla you can report bugs for (downstream) OVMF today.

In Red Hat Bugzilla, bugs reported for downstream components that need
upstream fixes first are handled in two three ways:

- Sometimes the community decides to use Red Hat Bugzilla for upstream
tracking. (Example: libvirt.) In this case, RHBZ receives two bugs: one
for upstream, one for downstream. One is usually a clone of the other
(within a single BZ instance, you can clone bugs, and their dependencies
are set up automatically). They are also reported for separate products.

- If the upstream project has an independent tracker, then RHBZ offers
metadata fields for linking the upstream tracker entry. It even has some
ingrained knowledge about specific high-profile upstream trackers
(FreeDesktop.org Bugzilla, GCC Bugzilla, Kernel Bugzilla, and so on.)

- If the upstream project lacks a tracker completely, then the important
upstream mailing list threads are linked as comments in the RHBZ entry
(problem report message, patch submissions, and so on). The hashes of
the commits that fix the issue are also captured in a comment. (If the
upstream project has its own tracker, then the hashes are (should be)
listed there.)

> and its *whole* lifetime can be tracked
> until a fix is released for the specific instance that the user has
> reported it with.
> 
> For that, we *are* going to need the thing to live under the auspices
> of the UEFI Forum, and we are going to need to be able to mark things
> as private — using an account system that is *directly* under our
> control.

I don't think I'd be permitted to store data (private comments, for
example) related to product planning in an external tracker. Product
planning and many other managerial workflows can depend on bug metadata
that are specific to a company or a department.

I think a cross-vendor tracker is too much; my vote is an upstream-only
tracker.

> Sure, actually getting vendor buy-in for that is a completely different
> story. But let's not design the system to make it hard :)

I couldn't buy in.

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

[edk2] [PATCH] CryptoPkg/OpensslLib: Convert saved opensslconf.h to DOS line endings

[David Woodhouse]

Until we fix the git repository to store line endings properly and then
just check them out in the appropriate form for the platform, let's make
process_files.sh convert the opensslconf.h to DOS line endings when it
creates it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse 
---
(Resent from list-subscribed email address)

 CryptoPkg/Library/OpensslLib/process_files.sh | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/CryptoPkg/Library/OpensslLib/process_files.sh 
b/CryptoPkg/Library/OpensslLib/process_files.sh
index bb33c8a..1094fd4 100755
--- a/CryptoPkg/Library/OpensslLib/process_files.sh
+++ b/CryptoPkg/Library/OpensslLib/process_files.sh
@@ -93,5 +93,6 @@ function filelist ()
 filelist < "${OPENSSL_PATH}/MINFO" |  sed -n -f - -i OpensslLib.inf
 
 # We can tell Windows users to put this back manually if they can't run
-# Configure.
-cp "${OPENSSL_PATH}/crypto/opensslconf.h" .
+# Configure. For now, until the git repository is fixed to store things
+# sanely, also convert to DOS line-endings
+unix2dos "${OPENSSL_PATH}/crypto/opensslconf.h" opensslconf.h
-- 
2.5.0

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3] NetworkPkg: Add URI configuration form to HTTP boot driver.

[Laszlo Ersek]

On 03/10/16 11:02, Gary Lin wrote:
> On Thu, Mar 10, 2016 at 10:20:12AM +0100, Laszlo Ersek wrote:
>> On 03/10/16 08:49, Gary Lin wrote:

>>> I found that it's related to iPXE. If I disable iPXE with
>>>
>>> "-netdev user,id=hostnet0 -device virtio-net-pci,romfile=,netdev=hostnet0"
>>>
>>> then everything works as expected. I'll try to dig deeper to find more
>>> information.
>>
>> How fresh is your ipxe? And did you build it with CONFIG=qemu?
>>
> It comes from the qemu 2.5.0 tarball and I just installed it from
> openSUSE Virtualization repo.
> https://build.opensuse.org/package/show/Virtualization/qemu

QEMU 2.5 bundles iPXE binaries built with CONFIG=qemu, but that
configuration doesn't enable IPv6 for the moment.

Apparently, combining iPXE (CONFIG=qemu) with NETWORK_IP6_ENABLE (set in
OVMF) causes problems. I don't understand how this causes side effects,
because CONFIG=qemu instructs iPXE to provide SNP drivers only. SNP is
independent of IP version.

With this combination, IPv6 PXE should work (not be absent), and IPv6
HTTP Boot should work too (not blow up).

Can you perhaps remove grub2 from the equation? What if you play with
disconnect / reconnect / connect in the UEFI shell?

Thanks
Laszlo

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

Re: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to enable 'openssl\ssl'

[David Woodhouse]

On Wed, 2016-02-24 at 16:15 +0800, Jiaxin Wu wrote:
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslTlsLib.uni 
> b/CryptoPkg/Library/OpensslLib/OpensslTlsLib.uni
> new file mode 100644
> index 
> ..384f0245db8d1d3a1d758f6db58f85f5fc155211
> GIT binary patch
> literal 1792
> zcmd6oNpBND5QXcE#D5q$7eI*(95^6^u<-yRLdNo
> z1hRUq>Q}F-Uyr|ity#?y+9Q66y|RhTY;I$_Z}-@ht!o$TZI~@=Wh1+Edtz%VSZ}e7
> z@RvPjZ){8J@H=H4#u^Bx%oF;V4LH@OU9+BnxOTLKpDVGH?5@D5?il=!OkTrrO%4TY
> zr_`q;n+G

Re: [edk2] Tianocore Community Update 2016 #1

[David Woodhouse]

On Thu, 2016-03-10 at 11:33 +0100, Laszlo Ersek wrote:
> 
> > * Considering tying the Bugzilla login to GitHub using GitHub as the
> > provider.  This would mean that anyone wishing to submit an item into
> > BZ would require a GitHub account.
> 
> I vote against this. I find 3rd party authentication providers insecure.

I concur.

The end goal should be a coherent bug tracking system where a user can
file a bug, and it can be reassigned to TianoCore or to a specific
vendor's "value subtract", and its *whole* lifetime can be tracked
until a fix is released for the specific instance that the user has
reported it with.

For that, we *are* going to need the thing to live under the auspices
of the UEFI Forum, and we are going to need to be able to mark things
as private — using an account system that is *directly* under our
control.

Sure, actually getting vendor buy-in for that is a completely different
story. But let's not design the system to make it hard :)

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to enable 'openssl\ssl'

[David Woodhouse]

On Wed, 2016-02-24 at 16:15 +0800, Jiaxin Wu wrote:
> diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
> b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
> index c0ccc0e..e68bfb8 100644
> --- a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
> +++ b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
> @@ -446,5 +446,10 @@ void syslog (int a, const char *c, ...)
>  
>  ssize_t write (int f, const void *b, size_t l)
>  {
>    return 0;
>  }
> +
> +int printf (char const *fmt, ...)
> +{
> +  return 0;
> +}

I'm assuming this is to work around a stray printf() in OpenSSL code
that we weren't building before?

The correct fix is to file a ticket upstream, submit a *fix* upstream
to be included in OpenSSL, and then to add the corresponding backported
patch to our EDKII_openssl patch.

Please don't add more workarounds like the above; we're trying to clean
those up not accumulate more.

And again... even if this was the right thing to do, it lives in a
*separate* standalone commit. It's OK if it's gratuitous, and the
commit comment simply says "we *will* want this because...".

See some of the OpenSSL API cleanups, for example, which make things
*ready* for OpenSSL 1.1 even while we're still using 1.0.2.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to enable 'openssl\ssl'

[David Woodhouse]

On Wed, 2016-02-24 at 16:15 +0800, Jiaxin Wu wrote:
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslTlsLib.inf 
> b/CryptoPkg/Library/OpensslLib/OpensslTlsLib.inf
> new file mode 100644
> index 000..fbd2b08
> --- /dev/null
> +++ b/CryptoPkg/Library/OpensslLib/OpensslTlsLib.inf
> @@ -0,0 +1,110 @@
 ...
> +[Sources]
> +  $(OPENSSL_PATH)/e_os.h
> +  $(OPENSSL_PATH)/ssl/s2_meth.c
> +  $(OPENSSL_PATH)/ssl/s2_srvr.c
> +  $(OPENSSL_PATH)/ssl/s2_clnt.c
> +  $(OPENSSL_PATH)/ssl/s2_lib.c
> +  $(OPENSSL_PATH)/ssl/s2_enc.c

These file lists are auto-generated now. You'll need to extend the
process_files.sh script to do this for OpensslTlsLib.inf just like it
does for OpensslLib.inf.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 2/6] CryptoPkg: Add OpensslTlsLib module to enable 'openssl\ssl'

[David Woodhouse]

On Wed, 2016-02-24 at 16:15 +0800, Jiaxin Wu wrote:
> 
> diff --git a/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2f.patch 
> b/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2f.patch
> index c42b776..f2d8f1a 100644
> --- a/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2f.patch
> +++ b/CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2f.patch
> @@ -11,10 +11,19 @@ diff U3 crypto/bio/bio.h crypto/bio/bio.h
>   BIO *BIO_new_fp(FILE *stream, int close_flag);
>  +# ifndef OPENSSL_NO_FP_API
>   #  define BIO_s_file_internal    BIO_s_file
>   # endif
>   BIO *BIO_new(BIO_METHOD *type);
> +@@ -655,6 +655,8 @@
> + BIO *BIO_new_file(const char *filename, const char *mode);
> + BIO *BIO_new_fp(FILE *stream, int close_flag);
> + #  define BIO_s_file_internal    BIO_s_file
> ++# else
> ++#  define BIO_s_file_internal()  NULL
> + # endif
> + BIO *BIO_new(BIO_METHOD *type);
> + int BIO_set(BIO *a, BIO_METHOD *type);
>  diff U3 crypto/bio/bss_file.c crypto/bio/bss_file.c
>  --- crypto/bio/bss_file.c  Thu Jan 28 21:38:30 2016
>  +++ crypto/bio/bss_file.c  Wed Feb 17 16:01:02 2016
>  @@ -467,6 +467,23 @@
>   return (ret);

As a general rule, you should never make have been making changes to
this OpenSSL patch without ensuring that a ticket is filed upstream.

As of this week, there is *nothing* in the EDKII_openssl patch which
isn't a backport of a commit from OpenSSL 1.1. The patch is
autogenerated from a 1.0.2+backports git tree.

Adding to it like this was *never* acceptable. Sure, you were only
making it a little bit worse at a time, but please don't. It just isn't
the way to do things.

In this case, perhaps the *only* thing missing was the fact that this
should have been in its own separate commit, with a commit comment
*identifying* the upstream ticket (and OpenSSL 1.1 commit) in which it
was fixed. But that's important to get right too.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Tianocore Community Update 2016 #1

[Laszlo Ersek]

On 03/09/16 19:49, Mangefeste, Tony wrote:

> I. Defect & Issue Tracking

> There are several topics we're investigating, and your input is appreciated:

First of all, thank you very much for going forward with Bugzilla!

> * Considering tying the Bugzilla login to GitHub using GitHub as the
> provider.  This would mean that anyone wishing to submit an item into
> BZ would require a GitHub account.

I vote against this. I find 3rd party authentication providers insecure.
While I find Single Sign On extremely useful (and also secure) in a
single, centrally managed organization, GitHub and the edk2 Bugzilla (to
be operated by Intel) are separate entities.

A breach of GitHub could lead to a breach of the Bugzilla, and leakage
of sensitive data (private comments, private bugs, private attachments).

Downtime of GitHub would prevent us from logging into Bugzilla.

Modern browsers have built-in password managers. The practice I
generally follow is to have a unique, complex, machine-generated
password for every public-facing website, and to store those in a
reliable password manager (behind a very strong master password of coruse).

--*--

Another practical remark: I insist on having access to the personal
email addresses of people who report bugs, for two reasons.

Less importantly, I want to be able to contact them in email, outside of
bugzilla (they might have some files I need for debugging, but their
data is too sensitive or too big to attach to the bug).

More importantly, if I write patches for a BZ entry (bug or feature
request), I always CC the reporter on the patches. Now, purely for
informing the reporter about the patches, my "other" best practice would
suffice in itself -- that best practice being: I link every patch
submisson from the mailing list archive immediately into the bug --, but
the main goal is that I want his/her testing feedback. For that the
reporter should be able to build my patches, hence I CC him/her
directly. Therefore I need his/her email address on the bug.

Fishing the emails of reporters out of GitHub's issue tracker has been a
pain. One clicks the "@reporter_nick" style link in the discussion, and
hopes that the reporter's profile page lists his/her email address
publicly. If it doesn't, then I have to ask for it in the tracker entry
explicitly, or I can try googling it.

Bugzilla normally gives me the email addresses of all commenters on the
bug automatically, and so it should be.

(Example: my profile page  does not list my
email address either. Why? Because I don't like spam, and my email is
trivially googleable for humans, from my name & employer. The point with
Bugzilla is that it only exposes email addresses to logged in users (no
bots), but then logged in users do get all the addresses without further
obstacles.)

I'm worried that if GitHub provided the authentication for Bugzilla, it
could withhold email addresses from Bugzilla, and break the above use case.

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

Re: [edk2] [PATCH v3] NetworkPkg: Add URI configuration form to HTTP boot driver.

[Gary Lin]

On Thu, Mar 10, 2016 at 10:20:12AM +0100, Laszlo Ersek wrote:
> On 03/10/16 08:49, Gary Lin wrote:
> > On Wed, Mar 09, 2016 at 04:54:08PM +0800, Gary Lin wrote:
> >> On Fri, Mar 04, 2016 at 04:38:22PM +0800, Fu Siyuan wrote:
> >>> This patch updates the HTTP boot driver to produce a setup page for the 
> >>> boot
> >>> file URI configuration. A new boot option will be created for the manual
> >>> configured URI address. This change is made to support the HTTP boot usage
> >>> in home environment.
> >>>
> >> Hi Siyuan,
> >>
> >> After updating the latest git HEAD, my qemu spitted this after grub2
> >> loaded the linux kernel:
> >>
> >> ASSERT /home/gary/git/edk2/NetworkPkg/HttpDxe/HttpDriver.c(555): CR has 
> >> Bad Signature
> >>
> >> The result of bisect shows the first bad commit is 
> >>
> >> fa848a4048943251fc057fe8d6c5a82e01d2ffb6
> >> NetworkPkg: Add URI configuration form to HTTP boot driver.
> >>
> >> Would you mind to check this?
> >>
> > I found that it's related to iPXE. If I disable iPXE with
> > 
> > "-netdev user,id=hostnet0 -device virtio-net-pci,romfile=,netdev=hostnet0"
> > 
> > then everything works as expected. I'll try to dig deeper to find more
> > information.
> 
> How fresh is your ipxe? And did you build it with CONFIG=qemu?
> 
It comes from the qemu 2.5.0 tarball and I just installed it from
openSUSE Virtualization repo.
https://build.opensuse.org/package/show/Virtualization/qemu

I kind of suspect it's related to the IPv6 support in iPXE. A few more
things I observed:

1. The symptom disappeared after I removed "NETWORK_IP6_ENABLE" from
   my OVMF build config.

2. With iPXE, there is no IPv6 PXE entry in the BootManager menu, but
   HTTP Boot IPv6 showed.

3. I added a few more debug messages and here is the log:
   http://paste.opensuse.org/81288048

   In the end of the log, the parameters to HttpDxeStop were printed:

HttpDxeIp4DriverBindingStop
HttpDxeStop
This=3E878CC0, ControllerHandle=3EF28C58, NumberOfChildren=0, 
ChildHandleBuffer=0, IpVersion=4
HttpDxeStop NicHandle=3F0ABBD8, This->DriverBindingHandle=3F16A558, 
ServiceBinding=3EF25C60

HttpDxeIp6DriverBindingStop
HttpDxeStop
This=3E878D00, ControllerHandle=3EF2CCD8, NumberOfChildren=0, 
ChildHandleBuffer=0, IpVersion=6
HttpDxeStop NicHandle=3F0ABBD8, This->DriverBindingHandle=3F169858, 
ServiceBinding=3EF25C60

HttpDxeStart
This=3E878D00, ControllerHandle=3F0ABBD8, RemainingDevicePath=0, IpVersion=6
HttpDxeStart This->DriverBindingHandle=3F169858, ServiceBinding=3EF25C60

HttpDxeIp6DriverBindingStop
HttpDxeStop
This=3E878D00, ControllerHandle=3EF2CCD8, NumberOfChildren=0, 
ChildHandleBuffer=0, IpVersion=6
HttpDxeStop NicHandle=3F0ABBD8, This->DriverBindingHandle=3F169858, 
ServiceBinding=3EF25C60

ASSERT /home/gary/git/edk2/NetworkPkg/HttpDxe/HttpDriver.c(567): CR has Bad 
Signature

   HttpDxeStop was invoked twice with the same parameters, and this is
   probably why the assert was raised.

   Furthermore, without iPXE or NETWORK_IP6_ENABLE, HttpDxeStop was
   never invoked.

The HTTPBoot driver may need to detect IPv6 support from UNDI just like the
PXEBoot driver.

2bbe9553c495bb9024b4b51743142a0a50e0d370
Add IPV6 support from UNDI

Cheers,

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

Re: [edk2] EDK2 Staging Repository

[Laszlo Ersek]

On 03/10/16 00:02, Kinney, Michael D wrote:
> Jordan,
> 
> Responses included below.
> 
> Mike
> 
> 
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Jordan Justen
>> Sent: Wednesday, March 9, 2016 1:47 PM
>> To: Mangefeste, Tony ; edk2-devel@lists.01.org
>> Subject: Re: [edk2] EDK2 Staging Repository
>>
>> On 2016-03-09 10:53:38, Mangefeste, Tony wrote:
>>> Below are the details of the proposal for a staging branch, please review 
>>> and
>> comment.
>>>
>>> 
>>>
>>> Problem statement
>>> =
>>> Need place on tianocore.org where new features that are not ready for 
>>> product
>>> integration can be checked in for evaluation by the EDK II community prior 
>>> to
>>> adding to the edk2 trunk.  This serves several purposes:
>>>
>>> * Encourage source code to be shared earlier in the development process
>>> * Allow source code to be shared that does not yet meet all edk2 required 
>>> quality
>> criteria
>>> * Allow source code to be shared so the EDK II community can help finish 
>>> and validate
>> new features
>>> * Provide a location to hold new features until they are deemed ready for 
>>> product
>> integration
>>> * Provide a location to hold new features until there is a natural point in 
>>> edk2
>> release cycle to fully validate the new feature.
>>> * Not intended to be used for bug fixes.
>>> * Not intended to be used for small, simple, or low risk features.
>>>
>>
>> I think the parts about making a central place for big feature
>> branches seems good. I think Laszlo might have appreciated having a
>> well defined central location for his OVMF SMM enabling branch.
>>
>> I think the processes around allowing the code to be merged seems too
>> heavyweight. In the cases of big patchsets, it can be burdensome
>> enough just to get code review. To insert another process step (and
>> set of approvers) to actually merge the feature seems perhaps
>> unneccesary.
>>
>>> Proposal
>>> 
>>> 1) Create a new repo called edk2-staging
>>> a) edk2-staging is a fork of edk
>>> b) edk2-staging/master tracks edk2/master
>>>
>>
>> For branches maintained by package maintainers, could we have them
>> under the edk2 repo and named staging/*?
> 
> Do you mean a directory in the edk2 repo called staging?  I did think about 
> this option,
> but I am concerned about code that is not ready for product integration being 
> in the edk2
> repo and I am also concerned about the size of the edk2 repo.  Creating a new 
> repo that is
> a fork of edk2 addressed both of those issues.

I disagree.

I have now re-read our private discussion from last year, when we were
working on SMM (the core infrastructure and the OVMF platform enablement
in parallel). The message ID of the root of the sub-thread is
<564f50b9.6040...@redhat.com>, if someone on CC at that time would like
to re-read it now.

At that time, the consensus seemed to be to create a top-level Staging/
directory, with packages under it (with their DEC files and modules).
So, we would have:

ArmVirtPkg/...
EmulatorPkg/...
OvmfPkg/...
Staging/ArmVirtPkg/...
Staging/EmulatorPkg/...
Staging/OvmfPkg/...

This matches how Linux works, and the naming makes it very clear that
modules (drivers, applications, library instances) under Staging are
work in progress. It is not possible to include a module from under
Staging as an oversight.

Keeping work-in-progress modules in a separate repo has a critical
drawback: those modules will not share the commit history of the main
edk2 repo.

Consider the following example: a new release or erratum of the UEFI or
PI spec is published, and a developer contributes the implementation of
a new feature (or bugfix) to one of the core packages: MdePkg,
MdeModulePkg, NetworkPkg, etc. Then a platform developer would like to
rely on this UEFI or PI change in his or her work-in-progress module. If
that module lives outside of the main edk2 repo, it will cause a
dependency nightmare.

Proprietary downstreams of edk2 already manage this, but let that remain
only their problem.

For OvmfPkg and ArmVirtPkg minimally, a Staging/ directory only makes
sense to me if it lives in the main edk2 repository, and shares its
commit history. Staging/ doesn't stand for separate product, separate
maintainership, separate life cycle, etc -- the sole difference with
staging modules is that we publicly admit, "yeah these are not fully
polished yet". There's no other difference.

Size-wise, the edk2 repo is easily manageable. Here's a comparison
between up-to-date & clean checkouts of projects I work with (note that
the below doesn't include the .git subdirectory):

$ du -s -h --apparent-size --exclude=.git \
  edk2 qemu libvirt-upstream kernel \
  | sort -h
69M qemu
147Mlibvirt-upstream
202Medk2
845Mkernel

The .git subdirectory isn't large either:

$ du -s -h --apparent-size \
  {edk2,qemu,libvirt-upstream,kernel}/.git 

Re: [edk2] [PATCH v3] NetworkPkg: Add URI configuration form to HTTP boot driver.

[Laszlo Ersek]

On 03/10/16 08:49, Gary Lin wrote:
> On Wed, Mar 09, 2016 at 04:54:08PM +0800, Gary Lin wrote:
>> On Fri, Mar 04, 2016 at 04:38:22PM +0800, Fu Siyuan wrote:
>>> This patch updates the HTTP boot driver to produce a setup page for the boot
>>> file URI configuration. A new boot option will be created for the manual
>>> configured URI address. This change is made to support the HTTP boot usage
>>> in home environment.
>>>
>> Hi Siyuan,
>>
>> After updating the latest git HEAD, my qemu spitted this after grub2
>> loaded the linux kernel:
>>
>> ASSERT /home/gary/git/edk2/NetworkPkg/HttpDxe/HttpDriver.c(555): CR has Bad 
>> Signature
>>
>> The result of bisect shows the first bad commit is 
>>
>> fa848a4048943251fc057fe8d6c5a82e01d2ffb6
>> NetworkPkg: Add URI configuration form to HTTP boot driver.
>>
>> Would you mind to check this?
>>
> I found that it's related to iPXE. If I disable iPXE with
> 
> "-netdev user,id=hostnet0 -device virtio-net-pci,romfile=,netdev=hostnet0"
> 
> then everything works as expected. I'll try to dig deeper to find more
> information.

How fresh is your ipxe? And did you build it with CONFIG=qemu?

Thanks
Laszlo

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

Re: [edk2] EDK2 Staging Repository

[Gerd Hoffmann]

On Mi, 2016-03-09 at 16:57 -0700, Bruce Cran wrote:
> On 3/9/16 2:59 PM, Jordan Justen wrote:
> 
> > So far I have a setup that can test building BaseTools and OVMF on
> > Linux. The Windows setup is a little more complicated, but I don't
> > think it should be too difficult.
> 
> I guess that's Linux x86_64? Any solution we come up with should also be 
> extendable to AARCH64.

I do have jenkins running, doing the builds for
https://www.kraxel.org/repos/, including aarch64 and arm builds (using a
cross compiler).

If there is interest I configure jenkins to send build failures to the
list too.  There are some drawbacks though:

  (1) There are false positives now and then for various reasons:
  * Now and then manual invention is needed to keep things going
(for example on openssl updates).
  * The rpm package has patches which need a rebase now and then.
  * Occasionally infrastructure hickups.
  (2) Sometimes it takes me a few days to deal with those issues,
  jenkins will keep on reporting the build failures until I did.
  (3) The system runs on a private network behind a NAT router, so you
  wouldn't be able to click on the links for build logs etc, all you
  get is the mail reporting the failure.
  (4) It's designed to provide rpms for the master branch, that it
  test-builds the master branch is more a side-effect.  I most
  likely wouldn't extend this to also build staging branches.

If you ever wondered how Laszlo notices quickly if someone breaks the
build, he gets the jenkins reports ;)

cheers,
  Gerd

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