Re: [edk2] question about x2apic support

[Laszlo Ersek]

On 08/10/15 18:13, Brian J. Johnson wrote:
 On 08/10/2015 03:16 AM, tiger...@zhaoxin.com wrote:
 Hello, experts:

 I have a question about x2apic support in UEFI BIOS.

 Could UEFI BIOS determine switching to xapic or x2apic when handing off
 to OS loader?

 Some webpages said:

 If CPU number  255, BIOS should set to xapic mode.
 
 Yes, Intel's specs. say that if all threads' APIC IDs are  255, then 
 the system should start in xapic mode.  Otherwise it should start in 
 x2apic mode.
 
 BIOSes which I've seen make this decision in CpuMpDxe, when determining 
 the APIC IDs for all the CPUs.  I don't know how you'd do it later on, 
 during loader handoff... once the APs' APICs are initialized, you need 
 to be in x2apic mode in order to send interrupts to CPUs with APIC IDs 
  = 255.  So BIOS would have no way to wake up the high-numbered APs to 
 finish their initialization if CpuMpDxe didn't switch the BSP to x2apic 
 mode.
 
 I'm not sure if OVMF's CpuMpDxe handles booting in x2apic mode or not. 
 I haven't looked.

OVMF resolves LocalApicLib to

  UefiCpuPkg/Library/BaseXApicLib

not

  UefiCpuPkg/Library/BaseXApicX2ApicLib

The former's INF file says The Local Apic library supports xAPIC mode
only. The latter's says, The Local Apic library supports x2APIC
capable processors which have xAPIC and x2APIC modes.

FWIW,

- KVM guests on x86 don't seem to support more than 255:
  arch/x86/include/asm/kvm_host.h:#define KVM_MAX_VCPUS 255

- the count for fullvirt Xen guests on x86 appears to be 128:
  xen/include/public/hvm/hvm_info_table.h:#define HVM_MAX_VCPUS128

So I think OVMF should be alright with xAPIC only.

Thanks!
Laszlo

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] CryptoPkg: OpensslLib: reintroduce EFIAPI for ERR_add_error_data()

[Laszlo Ersek]

On 07/23/15 14:44, David Woodhouse wrote:
 On Thu, 2015-07-23 at 14:41 +0200, Laszlo Ersek wrote:

 Right. So what are the options?

  1. Push a patch into OpenSSL upstream that marks ERR_add_error_data() 
 and any other varargs functions with EFIAPI. (Ick, no. I can't
 imagine them accepting that requirement.)

  2. Maintain the same patch for ourselves in perpetuity. (Ick, we
 really don't *want* to be carrying patches, especially like that
 one.)

  3. Switch to -mabi=ms across the board (can we ditch GCC 4.4?)

  4. Fix PR#50818. (Doesn't help until we can require a fixed GCC, in 
 which case we might as well just go with option #3).

  5. Add -UNO_BUILTIN_VA_FUNCS to OpenSSL build flags or otherwise 
 tweak OpenSslSupport.h to avoid tripping up on it. (As with option
 #1 and #2, this might work for OpenSSL but I'd rather have a fix 
 for the *general* case of non-explicitly-EFIAPI varargs functions.
 Those are currently broken on x86_64 ELF builds *anywhere* in 
 Tianocore, right? Like in the PrintString function in 
 DuetPkg/DxeIpl/Debug.c, found with a very quick grep...)

 Anything I missed?

 I'm leaning towards a combination of #3 and #5. Switch to -mabi=ms
 where we can, so the whole mess can go away in time. And the minimal
 tweak to fix it for OpenSSL builds, although there *are* still issues
 elsewhere in the tree.

 I'd go with #3 (phase out gcc-4.4, hardcode -mabi=ms).
 
 That's viable for LLVM too, right? It should be.

Andrew?... :)


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] CryptoPkg: OpensslLib: reintroduce EFIAPI for ERR_add_error_data()

[Laszlo Ersek]

On 07/23/15 15:13, Andrew Fish wrote:
 
 On Jul 23, 2015, at 5:47 AM, Laszlo Ersek ler...@redhat.com wrote:

 On 07/23/15 14:44, David Woodhouse wrote:
 On Thu, 2015-07-23 at 14:41 +0200, Laszlo Ersek wrote:

 Right. So what are the options?

 1. Push a patch into OpenSSL upstream that marks ERR_add_error_data() 
and any other varargs functions with EFIAPI. (Ick, no. I can't
imagine them accepting that requirement.)

 2. Maintain the same patch for ourselves in perpetuity. (Ick, we
really don't *want* to be carrying patches, especially like that
one.)

 3. Switch to -mabi=ms across the board (can we ditch GCC 4.4?)

 4. Fix PR#50818. (Doesn't help until we can require a fixed GCC, in 
which case we might as well just go with option #3).

 5. Add -UNO_BUILTIN_VA_FUNCS to OpenSSL build flags or otherwise 
tweak OpenSslSupport.h to avoid tripping up on it. (As with option
#1 and #2, this might work for OpenSSL but I'd rather have a fix 
for the *general* case of non-explicitly-EFIAPI varargs functions.
Those are currently broken on x86_64 ELF builds *anywhere* in 
Tianocore, right? Like in the PrintString function in 
DuetPkg/DxeIpl/Debug.c, found with a very quick grep...)

 Anything I missed?

 I'm leaning towards a combination of #3 and #5. Switch to -mabi=ms
 where we can, so the whole mess can go away in time. And the minimal
 tweak to fix it for OpenSSL builds, although there *are* still issues
 elsewhere in the tree.

 I'd go with #3 (phase out gcc-4.4, hardcode -mabi=ms).

 That's viable for LLVM too, right? It should be.

 Andrew?... :)

 
 You can add targets to clang to support the ABI you care about. For example 
 the Xcode target for EFI X64 is -target x86_64-pc-win32-macho, as -arch 
 x86_64 implies the System V Application Binary Interface. I don’t think that 
 msabi is supported via the function attribute in clang, it was not a few 
 years ago when we checked. 
 
 So it is possible to add custom targets to LLVM to support the ABI/image 
 format you care about. Some one could add -target x86_64-pc-win32-elf for 
 example. Our firmware team added -target x86_64-pc-win32-macho to the open 
 source, so anything is possible. The nice thing about LLVM is you can build a 
 complier that supports the OS ABI and EFI ABI (via a custom target), and not 
 need a customer complier for EFI. 
 
 Sorry, so hardcoding abi=ms is how LLVM solves the problem. 

If I understand correctly, that's exactly what we'd have liked to hear.
Is that right, David? The -mabi=ms flag would be specific to the GCC
toolchains in tools_def.txt. LLVM can take another parameter (or nothing
new at all, actually), the point is, the method used with GCC would be
identical to the one used with LLVM (just the actual command line
options would differ).

Thanks!
Laszlo

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch v3] NetworkPkg: Add old IPv4_DEVICE_PATH and IPv6_DEVICE_PATH support

[Laszlo Ersek]

On 07/22/15 02:57, Wang Fan wrote:
 v3:
 * Update the macro of Ip4 device path node length and Ip6 device path node 
 length.
 
 GatewayIpAddress and SubnetMask do not exist in old IPv4_DEVICE_PATH, 
 IPAddressOrigin, PrefixLength and GatewayIPAddress do not exist in old 
 IPv6_DEVICE_PATH. This will lead new IScsiDxe to error without updating 
 IPv4_DEVICE_PATH and IPv6_DEVICE_PATH in system.
 Following UEFI2.5 spec of IPv4_DEVICE_PATH do a check before accessing fields 
 only defined in new version's IPv4_DEVICE_PATH, and revise the same issue for 
 IPv6_DEVICE_PATH in Iscsi driver.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: fanwang2 fan.w...@intel.com
 ---
  NetworkPkg/IScsiDxe/IScsiMisc.c | 62 
 +
  NetworkPkg/IScsiDxe/IScsiMisc.h | 18 +++-
  2 files changed, 67 insertions(+), 13 deletions(-)
 
 diff --git a/NetworkPkg/IScsiDxe/IScsiMisc.c b/NetworkPkg/IScsiDxe/IScsiMisc.c
 index aeb99e5..010d2a4 100644
 --- a/NetworkPkg/IScsiDxe/IScsiMisc.c
 +++ b/NetworkPkg/IScsiDxe/IScsiMisc.c
 @@ -1,9 +1,9 @@
  /** @file
Miscellaneous routines for iSCSI driver.
  
 -Copyright (c) 2004 - 2014, Intel Corporation. All rights reserved.BR
 +Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.BR
  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
  
 @@ -1350,10 +1350,11 @@ IScsiGetTcpConnDevicePath (
  {
ISCSI_CONNECTION  *Conn;
EFI_DEVICE_PATH_PROTOCOL  *DevicePath;
EFI_STATUSStatus;
EFI_DEV_PATH  *DPathNode;
 +  UINTN PathLen;
  
if (Session-State != SESSION_STATE_LOGGED_IN) {
  return NULL;
}
  
 @@ -1388,25 +1389,62 @@ IScsiGetTcpConnDevicePath (
  DPathNode-Ipv4.LocalPort   = 0;
  
  DPathNode-Ipv4.StaticIpAddress = 
(BOOLEAN) 
 (!Session-ConfigData-SessionConfigData.InitiatorInfoFromDhcp);
  
 -IP4_COPY_ADDRESS (
 -  DPathNode-Ipv4.GatewayIpAddress,
 -  Session-ConfigData-SessionConfigData.Gateway
 -  );
 +//
 +//  Add a judgement here to support previous versions of 
 IPv4_DEVICE_PATH.
 +//  In previous versions of IPv4_DEVICE_PATH, GatewayIpAddress and 
 SubnetMask
 +//  do not exist.
 +//  In new version of IPv4_DEVICE_PATH, structcure length is 27.
 +//
  
 -IP4_COPY_ADDRESS (
 -  DPathNode-Ipv4.SubnetMask,
 -  Session-ConfigData-SessionConfigData.SubnetMask
 -  );
 +PathLen = DevicePathNodeLength (DPathNode-Ipv4);
 +
 +if (PathLen == IPv4_NODE_LEN_NEW_VERSIONS) {  
 +
 +  IP4_COPY_ADDRESS (
 +DPathNode-Ipv4.GatewayIpAddress,
 +Session-ConfigData-SessionConfigData.Gateway
 +);
 +
 +  IP4_COPY_ADDRESS (
 +DPathNode-Ipv4.SubnetMask,
 +Session-ConfigData-SessionConfigData.SubnetMask
 +);
 +}
 +
  break;
} else if (Conn-Ipv6Flag  DevicePathSubType (DPathNode-DevPath) 
 == MSG_IPv6_DP) {
  DPathNode-Ipv6.LocalPort   = 0;
 -DPathNode-Ipv6.IpAddressOrigin = 0;
 -DPathNode-Ipv6.PrefixLength= IP6_PREFIX_LENGTH;
 -ZeroMem (DPathNode-Ipv6.GatewayIpAddress, sizeof 
 (EFI_IPv6_ADDRESS));
 +
 +//
 +//  Add a judgement here to support previous versions of 
 IPv6_DEVICE_PATH.
 +//  In previous versions of IPv6_DEVICE_PATH, IpAddressOrigin, 
 PrefixLength
 +//  and GatewayIpAddress do not exist.
 +//  In new version of IPv6_DEVICE_PATH, structure length is 60, 
 while in 
 +//  old versions, the length is 43.
 +//
 +
 +PathLen = DevicePathNodeLength (DPathNode-Ipv6);
 +
 +if (PathLen == IPv6_NODE_LEN_NEW_VERSIONS ) { 
 +
 +  DPathNode-Ipv6.IpAddressOrigin = 0;
 +  DPathNode-Ipv6.PrefixLength= IP6_PREFIX_LENGTH;
 +  ZeroMem (DPathNode-Ipv6.GatewayIpAddress, sizeof 
 (EFI_IPv6_ADDRESS));
 +}
 +else if (PathLen == IPv6_NODE_LEN_OLD_VERSIONS) { 
 +
 +  //
 +  //  StaticIPAddress is a field in old versions of 
 IPv6_DEVICE_PATH, while ignored in new 
 +  //  version. Set StaticIPAddress through its' offset in old 
 IPv6_DEVICE_PATH.
 +  //
 +  *((UINT8 *)(DPathNode-Ipv6) + IPv6_OLD_IPADDRESS_OFFSET) = 
 +(BOOLEAN) 
 (!Session-ConfigData-SessionConfigData.InitiatorInfoFromDhcp);
 +}
 +
  break;
}
  }
  
  DPathNode = (EFI_DEV_PATH *) NextDevicePathNode (DPathNode-DevPath);
 diff --git a/NetworkPkg/IScsiDxe/IScsiMisc.h b/NetworkPkg/IScsiDxe/IScsiMisc.h
 index fd9e3af..0a3b449 100644
 --- 

Re: [edk2] [PATCH] CryptoPkg: OpensslLib: reintroduce EFIAPI for ERR_add_error_data()

[Laszlo Ersek]

On 07/23/15 14:17, David Woodhouse wrote:
 On Thu, 2015-07-23 at 12:31 +0200, Laszlo Ersek wrote:
 I'm slightly confused. Why does it *only* matter for varargs functions?
 I thought that on some platforms, the difference between the ELF ABI
 and the MS ABI extended to putting arguments in *completely* different
 registers? Why doesn't that bite us?

 It does not bite us because the calling convention is part of the
 function's prototype (the declaration in the header file),
 
 Right, thanks. Sorry, I'd actually worked this out before I sent my
 email but forgot to remove the question.
 
 The problem is *solely* about choosing the right conventions for
 va_list handling, according to the ABI. It's *all* about GCC PR#50818.
 

 Any particular reason for disliking these hunks of
 EDKII_openssl-1.0.2d.patch (over the other hunks)?

 Oh, I dislike lots of other bits of that too. I'm just working through
 them all separately. Are you on the openssl-dev mailing list? :)

 Nope. :)
 
 Lucky you :)
 
 In any case, if there was such a gcc PR, we'd still have to stick with
 the compatibility cruft in edk2, for old gcc versions' sake.
 
 Right. So what are the options?
 
  1. Push a patch into OpenSSL upstream that marks ERR_add_error_data() 
 and any other varargs functions with EFIAPI. (Ick, no. I can't
 imagine them accepting that requirement.)
 
  2. Maintain the same patch for ourselves in perpetuity. (Ick, we
 really don't *want* to be carrying patches, especially like that
 one.)
 
  3. Switch to -mabi=ms across the board (can we ditch GCC 4.4?)
 
  4. Fix PR#50818. (Doesn't help until we can require a fixed GCC, in 
 which case we might as well just go with option #3).
 
  5. Add -UNO_BUILTIN_VA_FUNCS to OpenSSL build flags or otherwise 
 tweak OpenSslSupport.h to avoid tripping up on it. (As with option
 #1 and #2, this might work for OpenSSL but I'd rather have a fix 
 for the *general* case of non-explicitly-EFIAPI varargs functions.
 Those are currently broken on x86_64 ELF builds *anywhere* in 
 Tianocore, right? Like in the PrintString function in 
 DuetPkg/DxeIpl/Debug.c, found with a very quick grep...)
 
 Anything I missed?
 
 I'm leaning towards a combination of #3 and #5. Switch to -mabi=ms
 where we can, so the whole mess can go away in time. And the minimal
 tweak to fix it for OpenSSL builds, although there *are* still issues
 elsewhere in the tree.

I'd go with #3 (phase out gcc-4.4, hardcode -mabi=ms).

I recently experimented with setting up a minimal, local edk2 build
farm, for the gcc versions supported by edk2. Most of the details are
irrelevant, but I'll share how I picked the OS releases for the builder
virtual machines:
- I went to koji
- for each gcc version in 4.4 through 4.9, I located the *latest* fcXX
  distro tag that still shipped that gcc version

The following mapping resulted:
- gcc-4.4 - fc13
- gcc-4.5 - fc14
- gcc-4.6 - fc16
- gcc-4.7 - fc18
- gcc-4.8 - fc20
- gcc-4.9 - fc21

Now, according to wikipedia, Fedora 13 reached End-of-life on
2011-06-04. That's more than four years ago.

Yes, RHEL-6 too provides gcc-4.4. I don't care. The RHEL-6 host kernel
cannot run OVMF with pflash-based, persistent UEFI variables anyway. So
losing the capability to build OVMF wouldn't be such a big problem.

Jordan mentioned (IIRC) that he preferred EFIAPI to make an actual
difference in DEBUG builds, in order to maintain the EFIAPI-cleanness of
the tree. I believe I disagree with that; to me it seems to be a
circular argument.

The tree needs to be EFIAPI-clean *only* if EFIAPI actually makes a
difference, and if (consequently) there's a potential to break stuff by
getting EFIAPI wrong. However, if EFIAPI is a no-op, then this
possibility for breakage falls away, and we shouldn't have to care about
any such cleanness.

As Peter said, the EFIAPI requirement is not a source level (ie. API)
one, it's an ABI one. If we can ensure the ABI compatibility, with
whatever means possible, we're good. A global -mabi=ms setting would
suffice.

... I realize this might be a knee-jerk opinion, but it's mine :)

Thanks
Laszlo

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/6] OvmfPkg: save S3 state at EndOfDxe

[Laszlo Ersek]

On 07/14/15 18:48, Laszlo Ersek wrote:
 Version 2 of
 http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16304.
 
 Changes relative to v1:
 
 - Since I received no feedback for Vlv2TbltDevicePkg, and no answer to
   my explicit query about interest in Vlv2TbltDevicePkg, I dropped the
   following v1 patches:
 
   1/9 IntelFrameworkModulePkg: AcpiS3SaveDxe: prepare for End-of-Dxe
   callback
   2/9 IntelFrameworkModulePkg: AcpiS3SaveDxe: call S3Ready() at
   End-of-Dxe
   5/9 Vlv2TbltDevicePkg: replace AcpiS3Save-S3Save() with End-of-Dxe
   signal
   8/9 IntelFrameworkModulePkg: AcpiS3SaveDxe: drop
   EFI_ACPI_S3_SAVE_PROTOCOL
 
   The explanation is very simple: IntelFrameworkModulePkg/AcpiS3SaveDxe
   and Vlv2TbltDevicePkg must be modified *together*. Since
   Vlv2TbltDevicePkg is not being modified (see above), so can't
   IntelFrameworkModulePkg/AcpiS3SaveDxe.
 
   The resultant status is valid for the entire tree, and it is also
   explained in v2 4/6.
 
 - Incorporated v1 feedback; please see the notes section of each patch.
 
 Tested with S3 enabled and disabled, with Fedora and Windows Server 2012
 R2.
 
 The series compiles and works at each stage (including S3 suspend+resume
 when it is enabled).
 
 Public branch: none ATM. The github repo is lagging behind SVN, and
 without the most recent SVN commits, the series doesn't apply. It should
 be no problem; we discussed repeatedly how to apply edk2 patches from
 the mailing list.
 
 Thanks
 Laszlo
 
 Ard Biesheuvel (1):
   IntelFrameworkModulePkg/GenericBdsLib: remove AcpiS3-S3Save() call
 
 Laszlo Ersek (5):
   OvmfPkg: AcpiS3SaveDxe: prepare for End-of-Dxe callback
   OvmfPkg: AcpiS3SaveDxe: call S3Ready() at End-of-Dxe
   OvmfPkg: PlatformBdsLib: signal End-of-Dxe event group
   OvmfPkg: install DxeSmmReadyToLock in PlatformBdsLib
   OvmfPkg: AcpiS3SaveDxe: drop EFI_ACPI_S3_SAVE_PROTOCOL
 
  IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf |   1 -
  OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf |  13 +-
  OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf   |   5 +
  IntelFrameworkModulePkg/Library/GenericBdsLib/InternalBdsLib.h  |   1 -
  OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.h  |  59 ---
  OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h|   4 +
  IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c |  10 --
  OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c  | 168 
 +++-
  OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c|  86 
 ++
  9 files changed, 154 insertions(+), 193 deletions(-)
  delete mode 100644 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.h
 

Until the SVN outage at sourceforge.net gets resolved, we plan to commit
patches that are ready for merging to the master branch of the git
repository at https://github.com/tianocore/edk2-svn-offline.git.
Please see the announcement:

  http://thread.gmane.org/gmane.comp.bios.edk2.devel/227

This particular patch (or series) appears ready for merging, therefore
it is being picked up:

  http://thread.gmane.org/gmane.comp.bios.edk2.devel/227/focus=251

Further development should be based on edk2-svn-offline/master, until
the SVN outage is fixed. At that point the accumulated patches will be
mass-committed from edk2-svn-offline/master to SVN.

Thanks
Laszlo


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch v3] MdeModulePkg: Add old IPv4_DEVICE_PATH support for new IScsiDxe

[Laszlo Ersek]

On 07/22/15 02:57, Wang Fan wrote:
 v3:
 * Update the macro of Ip4 device path node length.
 
 GatewayIpAddress and SubnetMask do not exist in old IPv4_DEVICE_PATH, this 
 will lead new IScsiDxe to error if IPv4_DEVICE_PATH in system is not updated.
 Following UEFI2.5 spec of IPv4_DEVICE_PATH do a check before accessing fields 
 only defined in new version, add a judgement here to make old 
 IPv4_DEVICE_PATH and new IScsiDxe can cowork.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: fanwang2 fan.w...@intel.com
 ---
  .../Universal/Network/IScsiDxe/IScsiMisc.c | 27 
 ++
  .../Universal/Network/IScsiDxe/IScsiMisc.h |  7 +-
  2 files changed, 24 insertions(+), 10 deletions(-)
 
 diff --git a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c 
 b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
 index 61c407e..621fbc0 100644
 --- a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
 +++ b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
 @@ -1,9 +1,9 @@
  /** @file
Miscellaneous routines for iSCSI driver.
  
 -Copyright (c) 2004 - 2014, Intel Corporation. All rights reserved.BR
 +Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.BR
  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
  
 @@ -812,19 +812,28 @@ IScsiGetTcpConnDevicePath (
  
DPathNode-Ipv4.LocalPort   = 0;
DPathNode-Ipv4.StaticIpAddress = 
  (BOOLEAN) (!Session-ConfigData.NvData.InitiatorInfoFromDhcp);
  
 -  IP4_COPY_ADDRESS (
 -DPathNode-Ipv4.GatewayIpAddress,
 -Session-ConfigData.NvData.Gateway
 -);
 -
 -  IP4_COPY_ADDRESS (
 -DPathNode-Ipv4.SubnetMask,
 -Session-ConfigData.NvData.SubnetMask
 -);
 +  //
 +  //  Add a judgement here to support previous versions of 
 IPv4_DEVICE_PATH.
 +  //  In previous versions of IPv4_DEVICE_PATH, GatewayIpAddress and 
 SubnetMask
 +  //  do not exist.
 +  //  In new version of IPv4_DEVICE_PATH, structcure length is 27.
 +  //
 +  if (DevicePathNodeLength (DPathNode-Ipv4) == 
 IPv4_NODE_LEN_NEW_VERSIONS) {  
 +
 +IP4_COPY_ADDRESS (
 +  DPathNode-Ipv4.GatewayIpAddress,
 +  Session-ConfigData.NvData.Gateway
 +  );
 +
 +IP4_COPY_ADDRESS (
 +  DPathNode-Ipv4.SubnetMask,
 +  Session-ConfigData.NvData.SubnetMask
 +  );
 +  }
  
break;
  }
  
  DPathNode = (EFI_DEV_PATH *) NextDevicePathNode (DPathNode-DevPath);
 diff --git a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.h 
 b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.h
 index 052a90f..0bb7da0 100644
 --- a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.h
 +++ b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.h
 @@ -1,9 +1,9 @@
  /** @file
Miscellaneous definitions for iSCSI driver.
  
 -Copyright (c) 2004 - 2014, Intel Corporation. All rights reserved.BR
 +Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.BR
  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
  
 @@ -17,10 +17,15 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
 EXPRESS OR IMPLIED.
  
  #include Library/BaseLib.h
  
  typedef struct _ISCSI_SESSION_CONFIG_DATA ISCSI_SESSION_CONFIG_DATA;
  
 +///
 +/// IPv4 Device Path Node Length
 +///
 +#define IPv4_NODE_LEN_NEW_VERSIONS27
 +
  #pragma pack(1)
  typedef struct {
BOOLEAN   Enabled;
  
BOOLEAN   InitiatorInfoFromDhcp;
 

Until the SVN outage at sourceforge.net gets resolved, we plan to commit
patches that are ready for merging to the master branch of the git
repository at https://github.com/tianocore/edk2-svn-offline.git.
Please see the announcement:

  http://thread.gmane.org/gmane.comp.bios.edk2.devel/227

This particular patch (or series) appears ready for merging, therefore
it is being picked up:

  http://thread.gmane.org/gmane.comp.bios.edk2.devel/227/focus=251

Further development should be based on edk2-svn-offline/master, until
the SVN outage is fixed. At that point the accumulated patches will be
mass-committed from edk2-svn-offline/master to SVN.

Thanks
Laszlo


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] CryptoPkg: OpensslLib: reintroduce EFIAPI for ERR_add_error_data()

[Laszlo Ersek]

On 07/23/15 01:06, David Woodhouse wrote:
 On Thu, 2015-07-23 at 00:44 +0200, Laszlo Ersek wrote:
 I guess it should work at the moment (and -UNO_BUILTIN_VA_FUNCS would
 be easy enough to add under [BuildOptions] in
 CryptoPkg/Library/OpensslLib/OpensslLib.inf).

 But, as soon as a genuinely EFIAPI function with a variable argument
 list appeared in OpensslLib.inf, things would break again.
 
 I'm slightly confused. Why does it *only* matter for varargs functions?
 I thought that on some platforms, the difference between the ELF ABI
 and the MS ABI extended to putting arguments in *completely* different
 registers? Why doesn't that bite us?

It does not bite us because the calling convention is part of the
function's prototype (the declaration in the header file), and the compiler:
- adheres to the calling convention in callers -- arguments are
  marshalled accordingly,
- enforces that calling convention when it sees the definition of the
  function -- if the definition doesn't match the declaration, the
  build breaks with an error. If the definition matches the
  declaration, then the arguments are de-marshalled accoringly.

Difference with varargs functions:
- the compiler *does not* enforce in the function definition that the
  VA_* macros actually match the calling convention posited in the
  function declaration. Arguments are de-marshalled manually, and if we
  mess up, the compiler doesn't catch it, we just crash.

 Any particular reason for disliking these hunks of
 EDKII_openssl-1.0.2d.patch (over the other hunks)?
 
 Oh, I dislike lots of other bits of that too. I'm just working through
 them all separately. Are you on the openssl-dev mailing list? :)

Nope. :)

 
 So, this issue is not fixable globally under gcc. With gcc (compiling
 for x86_64), EFIAPI and non-EFIAPI differ from each other,.. 
 
 Well, why don't we just add -mabi=ms to the compiler flags? Then EFIAPI
 in the source code could be a no-op, right?

Yes, I think EFIAPI would be a no-op then. I don't know why we don't set
-mabi=ms globally.

Hm, wait, I do know. Because gcc-4.4 doesn't support it. See the docs:

https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/i386-and-x86_002d64-Options.html

The section Intel 386 and AMD x86-64 Options does not list -mabi=.
Apparently, the -mabi=(ms|sysv) option was introduced in gcc-4.5.

... Hm, that might be a glitch in the gcc-4.4 documentation. I just
checked my Fedora 13 VM (with gcc-4.4), and it does know about -mabi=ms.
So, I don't know.

 Alternatively, why in $DEITY's name doesn't GCC give us a set of
 builtin functions which actually DTRT according to whether *this*
 particular function is being built with the MS ABI or not?

Yes, exactly, why does it not? I agree with your sentiment 100%.

 Is there a
 PR for that already?

I don't know. I can only refer you (again) to:
https://bugzilla.redhat.com/show_bug.cgi?id=871889. Jakub and Kai said
(in 2012) that it was a user error to expect the same builtins (or
macros) to DTRT regardless of the calling convention. They said the
programmer had to choose the right builtins manually.

And, if I check the stdarg.h and cross-stdarg.h files on my RHEL-7.1
system, under /usr/lib/gcc/x86_64-redhat-linux/4.8.2/include, I still see:
- stdarg.h is bound to the SYSV ABI
- cross-stdarg.h is also bound to the SYSV ABI, for !__x86_64__
- cross-stdarg.h allows the programmer to manually choose between
  SYSV and MS ABI compatible builtins for __x86_64__

So, as far as RHEL-7.1 can be considered recent, I'd say those
bugzilla comments are the state of the art even today.

In any case, if there was such a gcc PR, we'd still have to stick with
the compatibility cruft in edk2, for old gcc versions' sake.

Thanks
Laszlo

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] CryptoPkg: OpensslLib: reintroduce EFIAPI for ERR_add_error_data()

[Laszlo Ersek]

On 07/23/15 12:31, Laszlo Ersek wrote:
 On 07/23/15 01:06, David Woodhouse wrote:

 Well, why don't we just add -mabi=ms to the compiler flags? Then EFIAPI
 in the source code could be a no-op, right?
 
 Yes, I think EFIAPI would be a no-op then. I don't know why we don't set
 -mabi=ms globally.
 
 Hm, wait, I do know. Because gcc-4.4 doesn't support it. See the docs:
 
 https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/i386-and-x86_002d64-Options.html
 
 The section Intel 386 and AMD x86-64 Options does not list -mabi=.
 Apparently, the -mabi=(ms|sysv) option was introduced in gcc-4.5.
 
 ... Hm, that might be a glitch in the gcc-4.4 documentation. I just
 checked my Fedora 13 VM (with gcc-4.4), and it does know about -mabi=ms.
 So, I don't know.

Sigh. My test was wrong. This is what I checked:

[root@edk2-gcc44-fc13 ~]# gcc -mabi=ms
gcc: no input files

That's a good result, right? Nope. Compare:

[root@edk2-gcc44-fc13 ~]# gcc -mabi=foobar
gcc: no input files

As I said, sigh. The diagnostic output cannot be trusted here; the
results are undistinguishable between ms and foobar. Compare on gcc-4.8:

$ gcc -mabi=ms
gcc: fatal error: no input files

$ gcc -mabi=foobar
gcc: error: unrecognized argument in option '-mabi=foobar'
gcc: note: valid arguments to '-mabi=' are: ms sysv

So, the documentation of gcc-4.4 is apparently correct, and -mabi is a
silently ignored switch.

Thanks
Laszlo

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] CryptoPkg: OpensslLib: reintroduce EFIAPI for ERR_add_error_data()

[Laszlo Ersek]

On 07/22/15 23:07, David Woodhouse wrote:
 On Tue, 2015-06-23 at 09:54 -0400, Peter Jones wrote:
 On Tue, Jun 23, 2015 at 03:34:25PM +0200, Laszlo Ersek wrote:
 Git commit f93f78ea70 (SVN r17633), with subject CryptoPkg: Update
 openssl patch file from 0.9.8zf to 1.0.2c, replaced the file

   CryptoPkg/Library/OpensslLib/EDKII_openssl-0.9.8zf.patch

 with

   CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2c.patch

 In the process, two hunks were lost that used to add EFIAPI to the
 declaration of the variadic function ERR_add_error_data().

 The VA_START() macro, from MdePkg/Include/Base.h, expands to an
 EFIAPI-dependent implementation when

   !defined(__CC_ARM)  (!defined(__GNUC__) ||
  defined(NO_BUILTIN_VA_FUNCS))

 Under such circumstances, the va_start() macro invocation in
 ERR_add_error_data() -- which is translated to VA_START() by
 CryptoPkg/Include/OpenSslSupport.h -- results in EFIAPI-dependent code,
 but callers of the function pass the arguments incorrectly, because the
 declaration doesn't state EFIAPI.

 This leads to crashes when ERR_add_error_vdata(), called by
 ERR_add_error_data(), tries to access the arguments forwarded to it.

 Restore the missing hunk from before SVN r17633.

 Cc: Qin Long qin.l...@intel.com
 Cc: Ard Biesheuvel ard.biesheu...@linaro.org
 Cc: Gary Ching-Pang Lin g...@suse.com
 Cc: Peter Jones pjo...@redhat.com
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Laszlo Ersek ler...@redhat.com

 Yeah, EFIAPI to get the right calling conventions on x86_64 is
 definitely the right thing here.  Is this what was breaking shim for
 you?

 It's mildly annoying that EFIAPI is pretty much 100% about ABI calling
 conventions and has nothing to do with actual API, but that ship has
 long past sailed.

 Acked-by: Peter Jones pjo...@redhat.com
 
 Alternatively (as I baulk at trying to send that particular one-liner
 upstream to OpenSSL), would it be possible to simply *avoid* defining
 NO_BUILTIN_VA_FUNCS for the OpenSSL part of the build?

I guess it should work at the moment (and -UNO_BUILTIN_VA_FUNCS would
be easy enough to add under [BuildOptions] in
CryptoPkg/Library/OpensslLib/OpensslLib.inf).

But, as soon as a genuinely EFIAPI function with a variable argument
list appeared in OpensslLib.inf, things would break again.

Any particular reason for disliking these hunks of
EDKII_openssl-1.0.2d.patch (over the other hunks)?

... The best thing would be to avoid NO_BUILTIN_VA_FUNCS *completely*.

If we did that, then the macros in question would be defined as:

 typedef __builtin_va_list VA_LIST;

 #define VA_START(Marker, Parameter) __builtin_va_start (Marker, Parameter)

 #define VA_ARG(Marker, TYPE) ((sizeof (TYPE)  sizeof (UINTN)) ? 
 (TYPE)(__builtin_va_arg (Marker, UINTN)) : (TYPE)(__builtin_va_arg (Marker, 
 TYPE)))

 #define VA_END(Marker) __builtin_va_end (Marker)

 #define VA_COPY(Dest, Start) __builtin_va_copy (Dest, Start)

Unfortunately, this is good for *non*-EFIAPI functions only. For EFIAPI
functions, you'd have to define them as __builtin_ms_va* (note the _ms).
Which, in turn, would be good only for EFIAPI functions. (See
/usr/lib/gcc/*/*/include/cross-stdarg.h. See also
https://bugzilla.redhat.com/show_bug.cgi?id=871889#c3.)

So, this issue is not fixable globally under gcc. With gcc (compiling
for x86_64), EFIAPI and non-EFIAPI differ from each other, and the VA_*
macros would have to expand to different gcc builtins dependent *on the
function*, not some global (or even source file level) #define. And,
since the UEFI spec declares a number of functions that take variable
arguments, like InstallMultipleProtocolInterfaces(), we are forced to
stick with EFIAPI as default, and that compels all other varargs
functions (that use the VA_* macros internally) to be EFIAPI too. This
could only be avoided if __builtin_va* considered the containing
function's calling convention automatically, but that's not going to
happen (see bug 871889 again).

... Rather than undefining NO_BUILTIN_VA_FUNCS for openssl, we should
instead remove

 //
 // Map all va_ elements to VA_xxx defined in MdePkg/Include/Base.h
 //
 #if !defined(__CC_ARM) // if va_list is not already defined
 #define va_list VA_LIST
 #define va_arg VA_ARG
 #define va_start VA_START
 #define va_end VA_END

from CryptoPkg/Include/OpenSslSupport.h (in the gcc case). Because,
without the VA_* macros (of which OpenSSL itself contains no instances),
there would be no requirement for EFIAPI either. In other words, the
EFIAPI hunks in EDKII_openssl-1.0.2d.patch are a solution to a problem
that CryptoPkg/Include/OpenSslSupport.h creates.

Thanks
Laszlo

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH V3 1/4] MdePkg|EmulatorPkg: Update comment for PcdDefaultTerminalType

[Laszlo Ersek]

On 07/16/15 06:45, Jordan Justen wrote:
 Can you just split this into two patches?
 
 I think we should keep patches confined to updating a single module
 unless there is a technical reason to touch separate packages in a
 single patch.
 
 Or, I suppose if you are making the *exact* same change to more than 3
 packages, I guess it seems a little silly to make separate patches.
 
 On 2015-07-15 19:09:45, Heyi Guo wrote:
 Update comment for PcdDefaultTerminalType, as a new terminal type
 TTYTERM has been added with type value of 4.

 The new type is NOT defined in UEFI SPEC v2.5.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Heyi Guo heyi@linaro.org
 
 In the commit message, you can Cc Andrew and I in the EmulatorPkg
 patch here, and git send-email will automatically add the Cc when
 sending the email.

And please Cc:

M: Michael D Kinney michael.d.kin...@intel.com
M: Liming Gao liming@intel.com

on the MdePkg patch.

Thanks
Laszlo

 
 You can add Reviewed-by: Jordan Justen jordan.l.jus...@intel.com to
 the separate EmulatorPkg patch.
 
 -Jordan
 
 ---
  EmulatorPkg/EmulatorPkg.dsc | 2 +-
  MdePkg/MdePkg.dec   | 3 ++-
  2 files changed, 3 insertions(+), 2 deletions(-)

 diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
 index e0c6161..dfcd476 100644
 --- a/EmulatorPkg/EmulatorPkg.dsc
 +++ b/EmulatorPkg/EmulatorPkg.dsc
 @@ -228,7 +228,7 @@
gEmulatorPkgTokenSpaceGuid.PcdEmuCpuModel|LIntel(R) Processor Model
gEmulatorPkgTokenSpaceGuid.PcdEmuCpuSpeed|L3000
  
 -  #  0-PCANSI, 1-VT100, 2-VT00+, 3-UTF8
 +  #  0-PCANSI, 1-VT100, 2-VT00+, 3-UTF8, 4-TTYTERM
gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1
  
  [PcdsDynamicDefault.common.DEFAULT]
 diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
 index bda6550..598a6d0 100644
 --- a/MdePkg/MdePkg.dec
 +++ b/MdePkg/MdePkg.dec
 @@ -2012,8 +2012,9 @@
#  1 - VT100BR
#  2 - VT100+BR
#  3 - UTF8BR
 +  #  4 - TTYTERM, NOT defined in UEFI SPECBR
# @Prompt Default Terminal Type.
 -  # @ValidRange 0x8001 | 0 - 3
 +  # @ValidRange 0x8001 | 0 - 4
gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|0|UINT8|0x0024
  
## Error level for hardware recorder.
 -- 
 2.1.4



--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH V3 2/4] ArmVirtPkg: Make terminal type consistent

[Laszlo Ersek]

On 07/16/15 04:09, Heyi Guo wrote:
 Change default terminal type to be consistent with default
 ConIn/ConOut device path, which is now determined by TTY_TERMINAL
 flag, TTYTERM or VT100.
 
 I can't say this is a bug, as we can pass the whole console device
 path to ConnectController, and TerminalDxe driver will pick up the
 terminal in the remaining device path. However, in rare circumstances,
 the console devices may be disconnected with the driver, and they will
 be ignored by ConPlatformDxe until we pass the device path explicitly
 just as BDS.
 
 Changing default terminal type to be the same with console device
 path could help serial terminal be reconnected with normal connect
 controller operation.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Heyi Guo heyi@linaro.org
 ---
  ArmVirtPkg/ArmVirtQemu.dsc | 8 
  1 file changed, 8 insertions(+)
 
 diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
 index 0d4f4b0..be2b984 100644
 --- a/ArmVirtPkg/ArmVirtQemu.dsc
 +++ b/ArmVirtPkg/ArmVirtQemu.dsc
 @@ -140,9 +140,17 @@
  !if $(TTY_TERMINAL) == TRUE

 gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)

 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)
 +  ## Terminal Type - TTYTERM, consistent with ConOut/ConIn Device Path.
 +  ## 0-PCANSI, 1-VT100, 2-VT00+, 3-UTF8, 4-TTYTERM
 +  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|4
  !else

 gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()

 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()
 +  ## Terminal Type - VT100, consistent with ConOut/ConIn Device Path.
 +  ## When Intel BDS is enabled, the above ConOut/ConIn device path is 
 useless,
 +  ## but we still use VT100 terminal type when TTY_TERMINAL is not TRUE.
 +  ## 0-PCANSI, 1-VT100, 2-VT00+, 3-UTF8, 4-TTYTERM
 +  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1
  !endif
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3
  
 

Reviewed-by: Laszlo Ersek ler...@redhat.com

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Farewell - last days at ARM Ltd

[Laszlo Ersek]

Hi Olivier,

On 07/16/15 01:41, Olivier Martin wrote:
 For people who does not know me I have been the EDK2 maintainer of
 the ARM Packages for the last 4 years. I took over the excellent work
 Andrew Fish and Eugene Cohen started few years before.
 
 This week was my last week at ARM - my last day would be on Friday
 17th (UK time). I have been learning a lot thanks to the UEFI
 community.
 Being the ARM maintainer has been a great opportunity. I also had the
 chance to go to few conferences to discuss and present my work and
 meet few of you as part of my job.
 
 I have been asked last week what is the new exciting place that makes
 me leave ARM. The answer is my own future start-up... I love
 challenges and I think this one is definitely one of the highest one
 I could find. It is actually quite scary but I am quite excited!
 
 I could potentially have kept my role of EDK2 ARM maintainer with me
 but I would prefer to give the task to Leif Lindholm who has been a
 co-maintainer for almost two months. So I could fully focus on my new
 adventure.
 Leif has been seating not far from me in the ARM office. We have also
 had regular meetings about UEFI. He has been at ARM Ltd longer than
 me and been involved in different Open Source projects. He has also
 been working on UEFI for Linaro for few (three?) years now.
 
 I have been trying to publish as much work as I can on the work I
 have done on UEFI for the last 5 years and half at ARM Ltd in the
 last two weeks. Unfortunately, I am not sure I will have time to
 publish everything. But I will do my best to publish the most
 important bits...
 
 Unfortunately, it is still too early to share more details about my
 future product, so I created a quick website (and found a neutral
 name) last week-end to allow people to follow the adventure:
 http://labapart.com/ (can either be pronounced as Lab apart or Lab
 à Part).
 
 If you would like to contact me, email me here:
 olivier.martin...@gmail.com and/or linkedin me:
 http://www.linkedin.com/in/olivierm.

Thank you for your reviews, your contributions to OvmfPkg, and the
documentation you wrote for the wiki (docs are important!). Best of luck
with your startup!

Cheers
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH V3 3/4] MdeModulePkg/TerminalDxe: Set NullRemaining to FALSE by default

[Laszlo Ersek]

On 07/16/15 04:09, Heyi Guo wrote:
 This is bug fix for TerminalDxe: NullRemaining should be set to FALSE
 by fault and then be set to TRUE conditionally.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Heyi Guo heyi@linaro.org
 ---
  MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c 
 b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
 index 597b15d..75bfdec 100644
 --- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
 +++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c
 @@ -568,7 +568,7 @@ TerminalDriverBindingStart (
DefaultNode= NULL;
ConInSelected   = FALSE;
ConOutSelected  = FALSE;
 -  NullRemaining  = TRUE;
 +  NullRemaining  = FALSE;
SimTxtInInstalled  = FALSE;
SimTxtOutInstalled = FALSE;
FirstEnter = FALSE;
 

This patch is identical to its counterpart in v2, therefore it should
have been posted with Feng's R-b added, from

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/17244/focus=17309

Ditto for [v2 3/3] - [v3 4/4].

Basically, sometime during the preparation of the next version of a
patch series, run a dedicated git rebase -i, set all the actions to
reword, and copy the tags (Reviewed-by, Acked-by, Tested-by, etc) from
the feedback you received to the commit messages. (Unless you changed
the patch significantly.)

Thanks
Laszlo


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH V4 0/5] Some improvements on serial terminal

[Laszlo Ersek]

On 07/16/15 10:51, Ard Biesheuvel wrote:
 On 16 July 2015 at 10:21, Heyi Guo heyi@linaro.org wrote:
 There were some issues when I ran SCT test against Serial IO Protocol
 on qemu aarch64, and below patches were made after I went through the
 code of TerminalDxe driver and the flow of console devices being
 connected.

 V2 is based on TTY terminal patches.
 V3 updates comment for PcdDefaultTerminalType.
 V4 splits the 1st patch.

 
 Thanks Heyi
 
 Committed as SVN r18023 ... r18027

Cool, thanks. I should have processed my INBOX before replying to v3...

Thanks!
Laszlo

 
 Regards,
 Ard.
 
 
 
 Cc: Michael D Kinney michael.d.kin...@intel.com
 Cc: Liming Gao liming@intel.com
 Cc: Jordan Justen jordan.l.jus...@intel.com
 Cc: Andrew Fish af...@apple.com
 Cc: Laszlo Ersek ler...@redhat.com
 Cc: Ard Biesheuvel ard.biesheu...@linaro.org
 Cc: Feng Tian feng.t...@intel.com
 Cc: Ruiyu Ni ruiyu...@intel.com

 Heyi Guo (5):
   MdePkg: Update comment for PcdDefaultTerminalType
   EmulatorPkg: Update comment for PcdDefaultTerminalType
   ArmVirtPkg: Make terminal type consistent
   MdeModulePkg/TerminalDxe: Set NullRemaining to FALSE by default
   MdeModulePkg/TerminalDxe: Some improvements

  ArmVirtPkg/ArmVirtQemu.dsc |  8 ++
  EmulatorPkg/EmulatorPkg.dsc|  2 +-
  .../Universal/Console/TerminalDxe/Terminal.c   | 29 
 --
  MdePkg/MdePkg.dec  |  3 ++-
  4 files changed, 16 insertions(+), 26 deletions(-)

 --
 2.1.4



--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 2/6] OvmfPkg: SmbiosPlatformDxe: restrict current Xen code to IA32/X64

[Laszlo Ersek]

On 07/16/15 17:34, Wei Liu wrote:
 CC Ian, Stefano and Julien who are familiar with ARM side of things.

Right -- I Cc'd Ard too on this patch because he implemented the ARM
hypercalls.

For now, this patch series explicitly doesn't try to implement
SMBIOS-on-ARM-Xen. That could be a future feature.

In this patch I'm just separating out Xen code that will definitely not
work ARM. Refer to
OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf: the
gEfiXenInfoGuid HOB is X86 specific, and here I'm just following what
I learned from reviewing Ard's code there.

Some of the code in this module works on both x86 and ARM, while some
other code (which happens to be Xen code) only works on x86. The patch
just separates the x86-only code out.

Thanks!
Laszlo

 On Thu, Jul 16, 2015 at 12:41:18AM +0200, Laszlo Ersek wrote:
 The Xen code in SmbiosPlatformDxe is centered on the informational HOB
 with GUID gEfiXenInfoGuid. This Xen hand-off mechanism is specific to the
 IA32 and X64 architectures. Therefore, sequester it from the rest of the
 source with appropriate preprocessing directives, arch-specific INF file
 sections, and by renaming Xen.c to X86Xen.c.

 (That file name pattern is inspired by
 OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c.)

 This change enables SmbiosPlatformDxe for ARM architectures; update the
 VALID_ARCHITECTURES comment accordingly.

 Cc: Ard Biesheuvel ard.biesheu...@linaro.org
 Cc: Jordan Justen jordan.l.jus...@intel.com
 Cc: Wei Liu wei.l...@citrix.com
 Cc: Gabriel Somlo so...@cmu.edu
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Laszlo Ersek ler...@redhat.com
 ---
  OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf | 12 
  OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.h   |  2 ++
  OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c   |  5 +
  OvmfPkg/SmbiosPlatformDxe/{Xen.c = X86Xen.c}   |  0
  4 files changed, 15 insertions(+), 4 deletions(-)

 diff --git a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf 
 b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
 index 6596392..ac4666a 100644
 --- a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
 +++ b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
 @@ -25,15 +25,17 @@ [Defines]
  #
  # The following information is for reference only and not required by the 
 build tools.
  #
 -#  VALID_ARCHITECTURES   = IA32 X64 IPF EBC
 +#  VALID_ARCHITECTURES   = IA32 X64 IPF EBC ARM AARCH64
  #
  
  [Sources]
SmbiosPlatformDxe.h
SmbiosPlatformDxe.c
 -  Xen.c
Qemu.c
  
 +[Sources.IA32, Sources.X64]
 +  X86Xen.c
 +
  [Packages]
MdePkg/MdePkg.dec
MdeModulePkg/MdeModulePkg.dec
 @@ -45,14 +47,16 @@ [LibraryClasses]
BaseLib
UefiDriverEntryPoint
DebugLib
 -  HobLib
QemuFwCfgLib
MemoryAllocationLib
  
 +[LibraryClasses.IA32, LibraryClasses.X64]
 +  HobLib
 +
  [Protocols]
gEfiSmbiosProtocolGuid  # PROTOCOL ALWAYS_CONSUMED
  
 -[Guids]
 +[Guids.IA32, Guids.X64]
gEfiXenInfoGuid
  
  [Depex]
 diff --git a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.h 
 b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.h
 index 6210a56..428bdcf 100644
 --- a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.h
 +++ b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.h
 @@ -28,6 +28,7 @@
  #include Library/MemoryAllocationLib.h
  
  
 +#if defined (MDE_CPU_IA32) || defined (MDE_CPU_X64)
  /**
Locates the Xen SMBIOS data if it exists
  
 @@ -38,6 +39,7 @@ SMBIOS_TABLE_ENTRY_POINT *
  GetXenSmbiosTables (
VOID
);
 +#endif
  
  
  /**
 diff --git a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c 
 b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
 index 29948a4..941f8cd 100644
 --- a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
 +++ b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
 @@ -195,7 +195,12 @@ SmbiosTablePublishEntry (
//
// Add Xen or QEMU SMBIOS data if found
//
 +#if defined (MDE_CPU_IA32) || defined (MDE_CPU_X64)
EntryPointStructure = GetXenSmbiosTables ();
 +#else
 +  EntryPointStructure = NULL;
 +#endif
 +
if (EntryPointStructure != NULL) {
  SmbiosTables = (UINT8*)(UINTN)EntryPointStructure-TableAddress;
} else {
 diff --git a/OvmfPkg/SmbiosPlatformDxe/Xen.c 
 b/OvmfPkg/SmbiosPlatformDxe/X86Xen.c
 similarity index 100%
 rename from OvmfPkg/SmbiosPlatformDxe/Xen.c
 rename to OvmfPkg/SmbiosPlatformDxe/X86Xen.c
 -- 
 1.8.3.1



--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] upload two drivers

[Laszlo Ersek]

On 07/14/15 23:49, Andrew Fish wrote:
 
 On Jul 14, 2015, at 2:21 PM, Laszlo Ersek ler...@redhat.com
 mailto:ler...@redhat.com wrote:

 On 07/14/15 20:31, S.Vieira wrote:
 Hi everyone.

 It's possible to do upload of two drives just in ONE .efi

 I am wanting to do upload of the AtaAtapiPassThruDxe and AtaBusDxe
 only in
 ONE file.

 I think it should be possible to install any number of driver binding
 protocol instances in a single driver module, on the image handle.
 However, you'd have to merge the two drivers into one in C source code,
 and then build the resultant driver.

 
 You could also convert one of the drivers to a NULL library (change the
 INF file), and add that new NULL library to the DSC statement for the
 other driver. 

Independently of the thread starter question -- I've never quite gotten
a clear image of NULL libraries. How do they work?

Thanks
Laszlo

 Conceptually the build system could support this behavior, since the
 library constructors and entry point functions are auto-gem’ed code, but
 it currently does not. 
 
 Thanks,
 
 Andrew Fish
 
 Laszlo





 Thx
 S.Vieira


 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 edk2-devel mailing list
 edk2-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/edk2-devel



 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 edk2-devel mailing list
 edk2-devel@lists.sourceforge.net mailto:edk2-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/edk2-devel
 


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] MTRR setup in OVMF [was: PATCH v3 01/10 KVM: MMU: fix decoding cache type from MTRR]

[Laszlo Ersek]

On 07/15/15 00:37, Jordan Justen wrote:
 On 2015-07-14 14:29:11, Laszlo Ersek wrote:
 On 07/14/15 23:15, Paolo Bonzini wrote:
 The long delay that Alex reported (for the case when all guest memory
 was set to UC up-front) is due to the fact that the SEC phase of OVMF
 decompresses an approximately 1712 KB sized, LZMA-compressed blob, to
 approx. 896 KB worth of PEI drivers and 8192 KB worth of DXE and UEFI
 drivers -- and this decompression is extremely memory-intensive.

 (When Jordan implemented that reset vector first, we saw similar
 performance degradation on AMD hosts (albeit not due to MTRR but due to
 page attributes). See
 https://github.com/tianocore/edk2/commit/98f378a7. I'm only mentioning
 it here because it makes me appreciate the current problem report.)

 Anyway, the reset vector's page table building is implemented in
 OvmfPkg/ResetVector/Ia32/PageTables64.asm. The decompression in SEC
 can be found in OvmfPkg/Sec/SecMain.c, function DecompressMemFvs().

 Perhaps the OVMF reset vector should initialize the MTRRs for the BSP?

 That's an idea, yes, if someone feels sufficiently drawn to writing
 assembly.
 
 Maybe we can use MtrrLib in the SEC C code?

If the page table building in the reset vector is not too costly with
UC, then yes, it should suffice if MtrrLib was put to use first just
before the decompression in SEC.

Thanks
Laszlo

 -Jordan
 
 Complications:
 - the reset vector is specific to OvmfPkg only in the OvmfPkgX64.dsc
   build
 - it needs to be determined what memory to cover.

 I think SEC doesn't do any MMIO, so it should be enough to enable MTRRs
 and set the default type to writeback.

 Seems safe to me, off the top of my head (and testing could confirm /
 disprove quickly).

 In any case we're going to have to quirk it, because of the broken
 guests in the wild.

 Thanks.
 Laszlo


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 2/2] MdePkg: remove PcdDefaultTerminalType

[Laszlo Ersek]

On 07/15/15 10:59, Ard Biesheuvel wrote:
 On 15 July 2015 at 08:26, Gao, Liming liming@intel.com wrote:
 Ard:

 From compatible view, I don't prefer to make this change. The
 driver in other EDKII package may use this PCD. After this change,
 they will build break.

 I suggest to keep this PCD, and update its comment to include new
 type. Its comment can highlight this type is not defined in UEFI
 specification.

 
 OK, that is also fine,

I obviously accept the above decision, but it should be noted that this
makes MdePkg practically unmodifiable. Normally a contributor takes care
to modify not just a declaration of something, but to bring in sync
*all* uses of the declaration too.

However, that's only possible for such uses that the contributor can
*see*. If everything in MdePkg must be preserved as-is, forever, for the
sake of forks (proprietary or otherwise -- simply stuff that depends on
the declarations but exists out of tree), then that quite guarantees
that MdePkg will grow layers and layers of cruft over time.

The Linux kernel doesn't guarantee any API stability for out-of-tree
code. But, all in-tree code is carefully adapted when APIs change.

On the other hand, for example, Red Hat guarantees some level of kernel
ABI stability. (Google Red Hat KABI whitelist.) Occasionally it does
come at a hefty price with regard to code clarity in the Red Hat kernels
-- sometimes keeping ABI stability requires elaborate, crufty detours in
code.

While that makes sense for a commercial downstream, in *upstream* edk2 I
don't think it's a very friendly (or clear-cut!) rule / limitation for
contributors. At least Red Hat *clearly* defines separation points in
the release cycle across which the kernel ABI stability is *not*
guaranteed -- and then we can shed the cruft. Clear rules for MdePkg,
MdeModulePkg, etc (as to when compat stuff can be phased out) would be
helpful.

Anyway, I do accept the decision; I just had to say my piece.

Thanks
Laszlo

 
 Thanks,
 Ard.
 
 
 -Original Message-
 From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
 Sent: Tuesday, July 14, 2015 6:36 PM
 To: edk2-devel@lists.sourceforge.net; heyi@linaro.org; 
 ler...@redhat.com; Tian, Feng; Gao, Liming
 Cc: roy.fr...@linaro.org; Ard Biesheuvel
 Subject: [PATCH 2/2] MdePkg: remove PcdDefaultTerminalType

 The PCD gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType is not used anywhere 
 in MdePkg itself, and with the introduction of TTYTERM, it may now assume 
 values that are not defined in MdePkg either.

 So now that we moved it to MdeModulePkg, remove this one that is now unused.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  MdePkg/MdePkg.dec | 9 -
  1 file changed, 9 deletions(-)

 diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index 
 bda6550ed6c6..026a94987bef 100644
 --- a/MdePkg/MdePkg.dec
 +++ b/MdePkg/MdePkg.dec
 @@ -2007,15 +2007,6 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, 
 PcdsDynamic, PcdsDynamicEx]
# @ValidRange 0x8001 | 0 - 3
gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits|1|UINT8|0x0023

 -  ## Indicates the usable type of terminal.BRBR
 -  #  0 - PCANSIBR
 -  #  1 - VT100BR
 -  #  2 - VT100+BR
 -  #  3 - UTF8BR
 -  # @Prompt Default Terminal Type.
 -  # @ValidRange 0x8001 | 0 - 3
 -  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|0|UINT8|0x0024
 -
## Error level for hardware recorder.
#  If value 0, platform does not support feature of hardware error record.
# @Prompt Error Level For Hardware Recorder
 --
 1.9.1



--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH V2 1/3] ArmVirtPkg: Make terminal type consistent

[Laszlo Ersek]

Heyi,

On 07/13/15 13:22, Ard Biesheuvel wrote:
 On 13 July 2015 at 13:15, Laszlo Ersek ler...@redhat.com wrote:
 On 07/13/15 05:24, Heyi Guo wrote:
 Change default terminal type to be consistent with default
 ConIn/ConOut device path, which is now determined by TTY_TERMINAL
 flag, TTYTERM or VT100.

 I can't say this is a bug, as we can pass the whole console device
 path to ConnectController, and TerminalDxe driver will pick up the
 terminal in the remaining device path. However, in rare circumstances,
 the console devices may be disconnected with the driver, and they will
 be ignored by ConPlatformDxe until we pass the device path explicitly
 just as BDS.

 Changing default terminal type to be the same with console device
 path could help serial terminal be reconnected with normal connect
 controller operation.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Heyi Guo heyi@linaro.org
 ---
  ArmVirtPkg/ArmVirtQemu.dsc | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
 index fbc2b12..e62624f 100644
 --- a/ArmVirtPkg/ArmVirtQemu.dsc
 +++ b/ArmVirtPkg/ArmVirtQemu.dsc
 @@ -141,9 +141,15 @@
  !if $(TTY_TERMINAL) == TRUE

 gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)

 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)
 +  ## Terminal Type - TTY, consistent with ConOut/ConIn Device Path.
 +  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|4
  !else

 gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()

 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()
 +  ## Terminal Type - VT100, consistent with ConOut/ConIn Device Path.
 +  ## When Intel BDS is enabled, the above ConOut/ConIn device path is 
 useless,
 +  ## but we still use VT100 terminal type when TTY_TERMINAL is not TRUE.
 +  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1
  !endif
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3



 Reviewed-by: Laszlo Ersek ler...@redhat.com
 
 I am OK with the patch. However, the value '4' is not defined for
 PcdDefaultTerminalType is not defined in MdePkg.
 Is that a concern to anyone? I am aware that we suggested to Roy not
 to touch MdePkg with his TtyTerm changes, but it seems odd to just use
 '4' here
 

can you please prepend another patch to this series that updates the
PcdDefaultTerminalType declaration in MdePkg/MdePkg.dec, with the new
value 4, and a hint that TTYTERM, identified by value 4, is not defined
by the UEFI spec?

Please see here (unless you've seen it already... hm, right, you were Cc'd):

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/17359/focus=17421

Thanks!
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] MTRR setup in OVMF [was: PATCH v3 01/10 KVM: MMU: fix decoding cache type from MTRR]

[Laszlo Ersek]

On 07/15/15 21:30, Xiao Guangrong wrote:
 
 Hi,
 
 I have posted the pachset to make OVMF happy and have CCed you guys,
 could you please check it if it works for you?

Sorry, I can't check it; I don't have an environment that exposes the
issue in the first place. Perhaps Alex can check it, or refer some of
the users that reported the problem to him to this patchset? (Those
users were using bleeding edge v4.2-rc1 anyway, unlike conservative me.)

Thanks!
Laszlo

 On 07/15/2015 05:15 AM, Paolo Bonzini wrote:
 The long delay that Alex reported (for the case when all guest memory
 was set to UC up-front) is due to the fact that the SEC phase of OVMF
 decompresses an approximately 1712 KB sized, LZMA-compressed blob, to
 approx. 896 KB worth of PEI drivers and 8192 KB worth of DXE and UEFI
 drivers -- and this decompression is extremely memory-intensive.

 (When Jordan implemented that reset vector first, we saw similar
 performance degradation on AMD hosts (albeit not due to MTRR but due to
 page attributes). See
 https://github.com/tianocore/edk2/commit/98f378a7. I'm only mentioning
 it here because it makes me appreciate the current problem report.)

 Anyway, the reset vector's page table building is implemented in
 OvmfPkg/ResetVector/Ia32/PageTables64.asm. The decompression in SEC
 can be found in OvmfPkg/Sec/SecMain.c, function DecompressMemFvs().

 Perhaps the OVMF reset vector should initialize the MTRRs for the BSP?
 I think SEC doesn't do any MMIO, so it should be enough to enable MTRRs
 and set the default type to writeback.

 In any case we're going to have to quirk it, because of the broken
 guests in the wild.

 Paolo



--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH 6/6] ArmVirtPkg/ArmVirtQemu: support SMBIOS

[Laszlo Ersek]

The MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf driver is generic, it
provides EFI_SMBIOS_PROTOCOL.

The OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf driver downloads the
SMBIOS payload from QEMU via fw_cfg.

Cc: Ard Biesheuvel ard.biesheu...@linaro.org
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
 ArmVirtPkg/ArmVirtQemu.dsc | 6 ++
 ArmVirtPkg/ArmVirtQemu.fdf | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index f5dd8a3..9570cc2 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -339,6 +339,12 @@ [Components.common]
   MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
 
   #
+  # SMBIOS Support
+  #
+  MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
+  OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
+
+  #
   # ACPI Support
   #
   MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index 5b6bda8..4ef0f8b 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -201,6 +201,12 @@ [FV.FvMain]
   INF MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
 
   #
+  # SMBIOS Support
+  #
+  INF MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
+  INF OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
+
+  #
   # ACPI Support
   #
   INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
-- 
1.8.3.1


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH 5/6] ArmVirtPkg: QemuFwCfgToPcdDxe: set SMBIOS entry point version dynamically

[Laszlo Ersek]

(This patch parallels OvmfPkg commit 37baf06b (SVN r17676).)

PcdSmbiosVersion controls the version number of the SMBIOS entry point
table (and other, related things) that the universal
MdeModulePkg/Universal/SmbiosDxe driver, providing EFI_SMBIOS_PROTOCOL,
installs.

The virt machine type of QEMU generates SMBIOS payload for the firmware
to install. The payload includes the entry point table (anchor table).
OvmfPkg/SmbiosPlatformDxe cannot install the anchor table (because that is
the jurisdiction of the generic MdeModulePkg/Universal/SmbiosDxe
driver); however, we can parse the entry point version from QEMU's anchor
table, and instruct MdeModulePkg/Universal/SmbiosDxe to adhere to that
version.

As default for PcdSmbiosVersion we should keep the current 0x0300 value
(ie. SMBIOS 3.0) from MdeModulePkg/MdeModulePkg.dec; that spec version
was specifically created for ARM / AARCH64 needs.

Cc: Ard Biesheuvel ard.biesheu...@linaro.org
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
 ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf |  4 ++
 ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c   | 40 
 ArmVirtPkg/ArmVirtQemu.dsc  |  5 +++
 3 files changed, 49 insertions(+)

diff --git a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf 
b/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
index a9983be..649cfdc 100644
--- a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
+++ b/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
@@ -29,14 +29,18 @@ [Sources]
 
 [Packages]
   MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
   OvmfPkg/OvmfPkg.dec
 
 [LibraryClasses]
+  BaseMemoryLib
+  DebugLib
   PcdLib
   QemuFwCfgLib
   UefiDriverEntryPoint
 
 [Pcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion
 
 [Depex]
   TRUE
diff --git a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c 
b/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c
index 8f60e21..814bb5c 100644
--- a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c
+++ b/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c
@@ -19,9 +19,48 @@
 #include Uefi/UefiBaseType.h
 #include Uefi/UefiSpec.h
 
+#include IndustryStandard/SmBios.h
+
+#include Library/BaseMemoryLib.h
+#include Library/DebugLib.h
 #include Library/PcdLib.h
 #include Library/QemuFwCfgLib.h
 
+
+/**
+  Set the SMBIOS entry point version for the generic SmbiosDxe driver.
+**/
+STATIC
+VOID
+SmbiosVersionInitialization (
+  VOID
+  )
+{
+  FIRMWARE_CONFIG_ITEM Anchor;
+  UINTNAnchorSize;
+  SMBIOS_TABLE_ENTRY_POINT QemuAnchor;
+  UINT16   SmbiosVersion;
+
+  if (RETURN_ERROR (QemuFwCfgFindFile (etc/smbios/smbios-anchor, Anchor,
+  AnchorSize)) ||
+  AnchorSize != sizeof QemuAnchor) {
+return;
+  }
+
+  QemuFwCfgSelectItem (Anchor);
+  QemuFwCfgReadBytes (AnchorSize, QemuAnchor);
+  if (CompareMem (QemuAnchor.AnchorString, _SM_, 4) != 0 ||
+  CompareMem (QemuAnchor.IntermediateAnchorString, _DMI_, 5) != 0) {
+return;
+  }
+
+  SmbiosVersion = (UINT16)(QemuAnchor.MajorVersion  8 |
+   QemuAnchor.MinorVersion);
+  DEBUG ((EFI_D_INFO, %a: SMBIOS version from QEMU: 0x%04x\n, __FUNCTION__,
+SmbiosVersion));
+  PcdSet16 (PcdSmbiosVersion, SmbiosVersion);
+}
+
 EFI_STATUS
 EFIAPI
 ParseQemuFwCfgToPcd (
@@ -29,5 +68,6 @@ ParseQemuFwCfgToPcd (
   IN EFI_SYSTEM_TABLE *SystemTable
   )
 {
+  SmbiosVersionInitialization ();
   return EFI_SUCCESS;
 }
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 3f5a19e..f5dd8a3 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -225,6 +225,11 @@ [PcdsDynamicDefault.common]
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoHorizontalResolution|640
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoVerticalResolution|480
 
+  #
+  # SMBIOS entry point version
+  #
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion|0x0300
+
 

 #
 # Components Section - list of all EDK II Modules needed by this Platform
-- 
1.8.3.1



--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH 3/6] MdeModulePkg: SmbiosDxe: ARM and AARCH64 are VALID_ARCHITECTURES

[Laszlo Ersek]

This driver is soon going to be built by ArmVirtPkg/ArmVirtQemu.dsc
(without any changes). Although VALID_ARCHITECTURES is not used by the
build system (it is just a comment), it is best kept up-to-date for human
readers' sake.

Cc: Feng Tian feng.t...@intel.com
Cc: Elvin Li elvin...@intel.com
Cc: Star Zeng star.z...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
 MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf 
b/MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
index cabc9d7..4fd6b97 100644
--- a/MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
+++ b/MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
@@ -26,7 +26,7 @@ [Defines]
 #
 # The following information is for reference only and not required by the 
build tools.
 #
-#  VALID_ARCHITECTURES   = IA32 X64 IPF EBC
+#  VALID_ARCHITECTURES   = IA32 X64 IPF EBC ARM AARCH64
 #
 
 [Sources]
-- 
1.8.3.1



--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH 4/6] ArmVirtPkg: add QemuFwCfgToPcdDxe

[Laszlo Ersek]

Many universal DXE drivers in edk2 can be controlled by setting dynamic
PCDs. Such a PCD must be set before the consumer DXE driver is dispatched.

(In general we assume that the DXE driver will consume the PCD in its
entry point, or in the constructor of a library instance it links against.
In special cases this requirement can be relaxed a bit, if we know that
the DXE driver accesses the PCD only in a protocol member function that it
exports.)

On the QEMU platform, the PCD values to be set for the universal drivers
are frequently derived from fw_cfg files that QEMU exports.

In OvmfPkg we tend to handle this in the following way:

- For IA32 and X64, OvmfPkg provides a QemuFwCfgLib instance that is
  usable in PEI.

- In PlatformPei, fw_cfg files can be loaded and transformed to PCD
  values.

- Any DXE driver is bound to be dispatched after the PEI phase is done.

(In specific cases other ordering solutions might be possible, via Depex
or protocol notify, etc.)

In ArmVirtPkg/ArmVirtQemu, things differ a bit:

- We don't have an ArmVirtPkg-specific (Platform) PEIM. This is actually
  a good thing for now, so let's not introduce one just for this purpose.

- Even if we had such a PEIM, it could not easily access fw_cfg: the MMIO
  addresses of the fw_cfg device are available only in the DTB that QEMU
  exports.

  (Accordingly, our QemuFwCfgLib instance is restricted to DXE_DRIVER
  modules: VirtFdtDxe parses the DTB, stores the fw_cfg addresses in PCDs,
  and then QemuFwCfgLib's constructor fetches those PCDs.)

  There are some examples in ArmVirtPkg where early code is forced to
  parse the DTB manually, but those examples are all painful, and our goal
  here (controlling universal DXE drivers) doesn't justify more of that
  pain.

Therefore, introduce a separate, minimal DXE driver that is dispatched
strictly after VirtFdtDxe (so that it can use QemuFwCfgLib), and strictly
before other DXE drivers (so that it can set dynamic PCDs for them).
Because VirtFdtDxe is already ordered with the APRIORI DXE file, it is
simplest to do the same for the new driver.

Actual fw_cfg files and PCDs shall be accessed in future patches.

Cc: Ard Biesheuvel ard.biesheu...@linaro.org
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
 ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf | 42 
 ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c   | 33 +++
 ArmVirtPkg/ArmVirtQemu.dsc  |  1 +
 ArmVirtPkg/ArmVirtQemu.fdf  |  2 +
 4 files changed, 78 insertions(+)

diff --git a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf 
b/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
new file mode 100644
index 000..a9983be
--- /dev/null
+++ b/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
@@ -0,0 +1,42 @@
+## @file
+#  An early DXE driver that parses well-known fw-cfg files into dynamic PCDs
+#  that control other (universal) DXE drivers.
+#
+#  Copyright (C) 2015, Red Hat, Inc.
+#  Copyright (c) 2014, Linaro Ltd. All rights reserved.BR
+#
+#  This program and the accompanying materials are licensed and made available
+#  under the terms and conditions of the BSD License which accompanies this
+#  distribution.  The full text of the license may be found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
+#  IMPLIED.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = QemuFwCfgToPcdDxe
+  FILE_GUID  = 5bb7cc92-1a36-4833-84cf-db7f8258e48d
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  ENTRY_POINT= ParseQemuFwCfgToPcd
+
+[Sources]
+  QemuFwCfgToPcd.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
+
+[LibraryClasses]
+  PcdLib
+  QemuFwCfgLib
+  UefiDriverEntryPoint
+
+[Pcd]
+
+[Depex]
+  TRUE
diff --git a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c 
b/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c
new file mode 100644
index 000..8f60e21
--- /dev/null
+++ b/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c
@@ -0,0 +1,33 @@
+/** @file
+*  An early DXE driver that parses well-known fw-cfg files into dynamic PCDs
+*  that control other (universal) DXE drivers.
+*
+*  Copyright (C) 2015, Red Hat, Inc.
+*  Copyright (c) 2014, Linaro Ltd. All rights reserved.BR
+*
+*  This program and the accompanying materials are licensed and made available
+*  under the terms and conditions of the BSD License which accompanies this
+*  distribution.  The full text of the license may be found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
+*  IMPLIED.
+*
+**/
+
+#include Uefi/UefiBaseType.h

[edk2] [PATCH 2/6] OvmfPkg: SmbiosPlatformDxe: restrict current Xen code to IA32/X64

[Laszlo Ersek]

The Xen code in SmbiosPlatformDxe is centered on the informational HOB
with GUID gEfiXenInfoGuid. This Xen hand-off mechanism is specific to the
IA32 and X64 architectures. Therefore, sequester it from the rest of the
source with appropriate preprocessing directives, arch-specific INF file
sections, and by renaming Xen.c to X86Xen.c.

(That file name pattern is inspired by
OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c.)

This change enables SmbiosPlatformDxe for ARM architectures; update the
VALID_ARCHITECTURES comment accordingly.

Cc: Ard Biesheuvel ard.biesheu...@linaro.org
Cc: Jordan Justen jordan.l.jus...@intel.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Gabriel Somlo so...@cmu.edu
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
 OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf | 12 
 OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.h   |  2 ++
 OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c   |  5 +
 OvmfPkg/SmbiosPlatformDxe/{Xen.c = X86Xen.c}   |  0
 4 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf 
b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
index 6596392..ac4666a 100644
--- a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
+++ b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
@@ -25,15 +25,17 @@ [Defines]
 #
 # The following information is for reference only and not required by the 
build tools.
 #
-#  VALID_ARCHITECTURES   = IA32 X64 IPF EBC
+#  VALID_ARCHITECTURES   = IA32 X64 IPF EBC ARM AARCH64
 #
 
 [Sources]
   SmbiosPlatformDxe.h
   SmbiosPlatformDxe.c
-  Xen.c
   Qemu.c
 
+[Sources.IA32, Sources.X64]
+  X86Xen.c
+
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
@@ -45,14 +47,16 @@ [LibraryClasses]
   BaseLib
   UefiDriverEntryPoint
   DebugLib
-  HobLib
   QemuFwCfgLib
   MemoryAllocationLib
 
+[LibraryClasses.IA32, LibraryClasses.X64]
+  HobLib
+
 [Protocols]
   gEfiSmbiosProtocolGuid  # PROTOCOL ALWAYS_CONSUMED
 
-[Guids]
+[Guids.IA32, Guids.X64]
   gEfiXenInfoGuid
 
 [Depex]
diff --git a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.h 
b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.h
index 6210a56..428bdcf 100644
--- a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.h
+++ b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.h
@@ -28,6 +28,7 @@
 #include Library/MemoryAllocationLib.h
 
 
+#if defined (MDE_CPU_IA32) || defined (MDE_CPU_X64)
 /**
   Locates the Xen SMBIOS data if it exists
 
@@ -38,6 +39,7 @@ SMBIOS_TABLE_ENTRY_POINT *
 GetXenSmbiosTables (
   VOID
   );
+#endif
 
 
 /**
diff --git a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c 
b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
index 29948a4..941f8cd 100644
--- a/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
+++ b/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
@@ -195,7 +195,12 @@ SmbiosTablePublishEntry (
   //
   // Add Xen or QEMU SMBIOS data if found
   //
+#if defined (MDE_CPU_IA32) || defined (MDE_CPU_X64)
   EntryPointStructure = GetXenSmbiosTables ();
+#else
+  EntryPointStructure = NULL;
+#endif
+
   if (EntryPointStructure != NULL) {
 SmbiosTables = (UINT8*)(UINTN)EntryPointStructure-TableAddress;
   } else {
diff --git a/OvmfPkg/SmbiosPlatformDxe/Xen.c 
b/OvmfPkg/SmbiosPlatformDxe/X86Xen.c
similarity index 100%
rename from OvmfPkg/SmbiosPlatformDxe/Xen.c
rename to OvmfPkg/SmbiosPlatformDxe/X86Xen.c
-- 
1.8.3.1



--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] upload two drivers

[Laszlo Ersek]

On 07/15/15 15:40, Andrew Fish wrote:
 
 On Jul 15, 2015, at 2:55 AM, Laszlo Ersek ler...@redhat.com
 mailto:ler...@redhat.com wrote:

 On 07/14/15 23:49, Andrew Fish wrote:

 On Jul 14, 2015, at 2:21 PM, Laszlo Ersek ler...@redhat.com
 mailto:ler...@redhat.com
 mailto:ler...@redhat.com wrote:

 On 07/14/15 20:31, S.Vieira wrote:
 Hi everyone.

 It's possible to do upload of two drives just in ONE .efi

 I am wanting to do upload of the AtaAtapiPassThruDxe and AtaBusDxe
 only in
 ONE file.

 I think it should be possible to install any number of driver binding
 protocol instances in a single driver module, on the image handle.
 However, you'd have to merge the two drivers into one in C source code,
 and then build the resultant driver.


 You could also convert one of the drivers to a NULL library (change the
 INF file), and add that new NULL library to the DSC statement for the
 other driver. 

 Independently of the thread starter question -- I've never quite gotten
 a clear image of NULL libraries. How do they work?

 
 It is not really that complicated. It is just a way to force the build
 system to call the libraries constructor/destructor. 
 
 If you add a NULL library to the LibraryClasses section of a DSC that
 that library gets linked against all drivers. This is not common, but it
 is useful for a library that produces compiler intrinsics. 
 
 If you list a NULL library in the LibraryClasses of a component
 section in the DSC then that library gets added. A good example of this
 is it is a way to add optional shell commands. The library constructor
 will call another library function to register shell commands. 
 
 Normally you just get the libraries the driver/application depends on
 (listed in the INF, mapped in the DSC), and the libraries the libraries
 depend on, etc.

How cool is that. edk2 has a substitute for
__attribute__((constructor)). :)

Thank you for the clear explanation!
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH V2 1/3] ArmVirtPkg: Make terminal type consistent

[Laszlo Ersek]

On 07/14/15 12:27, Ard Biesheuvel wrote:
 On 14 July 2015 at 12:18, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 On 14 July 2015 at 12:15, Laszlo Ersek ler...@redhat.com wrote:
 On 07/13/15 13:34, Laszlo Ersek wrote:
 On 07/13/15 13:22, Ard Biesheuvel wrote:
 On 13 July 2015 at 13:15, Laszlo Ersek ler...@redhat.com wrote:
 On 07/13/15 05:24, Heyi Guo wrote:
 Change default terminal type to be consistent with default
 ConIn/ConOut device path, which is now determined by TTY_TERMINAL
 flag, TTYTERM or VT100.

 I can't say this is a bug, as we can pass the whole console device
 path to ConnectController, and TerminalDxe driver will pick up the
 terminal in the remaining device path. However, in rare circumstances,
 the console devices may be disconnected with the driver, and they will
 be ignored by ConPlatformDxe until we pass the device path explicitly
 just as BDS.

 Changing default terminal type to be the same with console device
 path could help serial terminal be reconnected with normal connect
 controller operation.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Heyi Guo heyi@linaro.org
 ---
  ArmVirtPkg/ArmVirtQemu.dsc | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
 index fbc2b12..e62624f 100644
 --- a/ArmVirtPkg/ArmVirtQemu.dsc
 +++ b/ArmVirtPkg/ArmVirtQemu.dsc
 @@ -141,9 +141,15 @@
  !if $(TTY_TERMINAL) == TRUE

 gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)

 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)
 +  ## Terminal Type - TTY, consistent with ConOut/ConIn Device Path.
 +  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|4
  !else

 gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()

 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()
 +  ## Terminal Type - VT100, consistent with ConOut/ConIn Device Path.
 +  ## When Intel BDS is enabled, the above ConOut/ConIn device path is 
 useless,
 +  ## but we still use VT100 terminal type when TTY_TERMINAL is not 
 TRUE.
 +  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1
  !endif
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3



 Reviewed-by: Laszlo Ersek ler...@redhat.com

 I am OK with the patch. However, the value '4' is not defined for
 PcdDefaultTerminalType is not defined in MdePkg.
 Is that a concern to anyone? I am aware that we suggested to Roy not
 to touch MdePkg with his TtyTerm changes, but it seems odd to just use
 '4' here


 See MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h, commit
 6e3227c8. (The TTYTERMTYPE macro.)

 What should belong to MdePkg (but can't, unless it gets standardized) is
 the textual representation for the new VenMsg(GUID).

 ... Hm, okay, you do have a point, I just checked MdePkg/MdePkg.dec,
 and it does list the values 0-3. However, the PCD is not used inside
 MdePkg, it is only declared there.

 So, I think that this patch is okay. If another terminal type gets
 standardized *before* Roy's TTYTERM, then:
 - that type will get a new (different) GUID,
 - and it will get value 4 in MdePkg/MdePkg.dec. (And, in Terminal.h.)

 The new GUID will obviously not conflict, and the current TTYTERMTYPE=4
 constant will be possible to shift up to TTYTERMTYPE=5, at that point.
 Yes, referring DSCs will have to be updated as well.

 This is not 100% clean, admittedly. I think the root issue is that the
 PCD should not be declared in MdePkg at all; at least (off the top off
 my head) I doubt the numeric value comes from the UEFI spec. So, maybe
 someone can submit a patch that moves the PCD declaration from MdePkg to
 MdeModulePkg. Otherwise, I'd be fine with the above plan. So my R-b
 stands.

 So what do you think, Ard? With Feng's R-b for patches #2 and #3, we
 could commit this series to SVN -- if you agree with #1.


 Yes, I am fine with this series. Please go ahead and commit it, or I
 can do it instead if you're busy.

 In the mean time, I will follow up with a patch that moves
 PcdDefaultTerminalType to MdeModulePkg, and one that adds the missing
 #4 in the comments.

 
 On second thought, perhaps it might be slightly cleaner to introduce
 gEfiMdeModulePkgTokenSpaceGuid.PcdDefaultTerminalType first and move
 existing code in TerminalDxe to it?
 

If Heyi doesn't mind, I think that would be the cleanest, yes.

Let's hope your move PcdDefaultTerminalType to MdeModulePkg patch
series will get reviewed quickly, and then Heyi can post a v3. Heyi, is
that okay with you?

Thanks
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions

Re: [edk2] [PATCH V2 1/3] ArmVirtPkg: Make terminal type consistent

[Laszlo Ersek]

On 07/13/15 13:34, Laszlo Ersek wrote:
 On 07/13/15 13:22, Ard Biesheuvel wrote:
 On 13 July 2015 at 13:15, Laszlo Ersek ler...@redhat.com wrote:
 On 07/13/15 05:24, Heyi Guo wrote:
 Change default terminal type to be consistent with default
 ConIn/ConOut device path, which is now determined by TTY_TERMINAL
 flag, TTYTERM or VT100.

 I can't say this is a bug, as we can pass the whole console device
 path to ConnectController, and TerminalDxe driver will pick up the
 terminal in the remaining device path. However, in rare circumstances,
 the console devices may be disconnected with the driver, and they will
 be ignored by ConPlatformDxe until we pass the device path explicitly
 just as BDS.

 Changing default terminal type to be the same with console device
 path could help serial terminal be reconnected with normal connect
 controller operation.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Heyi Guo heyi@linaro.org
 ---
  ArmVirtPkg/ArmVirtQemu.dsc | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
 index fbc2b12..e62624f 100644
 --- a/ArmVirtPkg/ArmVirtQemu.dsc
 +++ b/ArmVirtPkg/ArmVirtQemu.dsc
 @@ -141,9 +141,15 @@
  !if $(TTY_TERMINAL) == TRUE

 gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)

 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)
 +  ## Terminal Type - TTY, consistent with ConOut/ConIn Device Path.
 +  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|4
  !else

 gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()

 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()
 +  ## Terminal Type - VT100, consistent with ConOut/ConIn Device Path.
 +  ## When Intel BDS is enabled, the above ConOut/ConIn device path is 
 useless,
 +  ## but we still use VT100 terminal type when TTY_TERMINAL is not TRUE.
 +  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1
  !endif
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3



 Reviewed-by: Laszlo Ersek ler...@redhat.com

 I am OK with the patch. However, the value '4' is not defined for
 PcdDefaultTerminalType is not defined in MdePkg.
 Is that a concern to anyone? I am aware that we suggested to Roy not
 to touch MdePkg with his TtyTerm changes, but it seems odd to just use
 '4' here

 
 See MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h, commit
 6e3227c8. (The TTYTERMTYPE macro.)
 
 What should belong to MdePkg (but can't, unless it gets standardized) is
 the textual representation for the new VenMsg(GUID).
 
 ... Hm, okay, you do have a point, I just checked MdePkg/MdePkg.dec,
 and it does list the values 0-3. However, the PCD is not used inside
 MdePkg, it is only declared there.
 
 So, I think that this patch is okay. If another terminal type gets
 standardized *before* Roy's TTYTERM, then:
 - that type will get a new (different) GUID,
 - and it will get value 4 in MdePkg/MdePkg.dec. (And, in Terminal.h.)
 
 The new GUID will obviously not conflict, and the current TTYTERMTYPE=4
 constant will be possible to shift up to TTYTERMTYPE=5, at that point.
 Yes, referring DSCs will have to be updated as well.
 
 This is not 100% clean, admittedly. I think the root issue is that the
 PCD should not be declared in MdePkg at all; at least (off the top off
 my head) I doubt the numeric value comes from the UEFI spec. So, maybe
 someone can submit a patch that moves the PCD declaration from MdePkg to
 MdeModulePkg. Otherwise, I'd be fine with the above plan. So my R-b
 stands.

So what do you think, Ard? With Feng's R-b for patches #2 and #3, we
could commit this series to SVN -- if you agree with #1.

Thanks
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 1/2] MdeModulePkg|EmulatorPkg: add definition for PcdDefaultTerminalType

[Laszlo Ersek]

On 07/14/15 12:36, Ard Biesheuvel wrote:
 Since PcdDefaultTerminalType may now assume values that are not
 defined in MdePkg (i.e., TTYTERM), introduce a new version in
 MdeModulePkg instead. Also add TTYTERM as #4.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  EmulatorPkg/EmulatorPkg.dsc|  4 ++--
  MdeModulePkg/MdeModulePkg.dec  | 10 ++
  MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf |  2 +-
  3 files changed, 13 insertions(+), 3 deletions(-)
 
 diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
 index e0c616144df6..c8e9877b85dc 100644
 --- a/EmulatorPkg/EmulatorPkg.dsc
 +++ b/EmulatorPkg/EmulatorPkg.dsc
 @@ -228,8 +228,8 @@ [PcdsFixedAtBuild]
gEmulatorPkgTokenSpaceGuid.PcdEmuCpuModel|LIntel(R) Processor Model
gEmulatorPkgTokenSpaceGuid.PcdEmuCpuSpeed|L3000
  
 -  #  0-PCANSI, 1-VT100, 2-VT00+, 3-UTF8
 -  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1
 +  #  0-PCANSI, 1-VT100, 2-VT00+, 3-UTF8, 4-TTYTERM
 +  gEfiMdeModulePkgTokenSpaceGuid.PcdDefaultTerminalType|1
  
  [PcdsDynamicDefault.common.DEFAULT]
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64|0
 diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
 index 623b07f9c6a2..76c92d725380 100644
 --- a/MdeModulePkg/MdeModulePkg.dec
 +++ b/MdeModulePkg/MdeModulePkg.dec
 @@ -1333,6 +1333,16 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, 
 PcdsDynamicEx]
# @Prompt Default Creator Revision for ACPI table creation.

 gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorRevision|0x0113|UINT32|0x30001038
  
 +  ## Indicates the usable type of terminal.BRBR
 +  #  0 - PCANSIBR
 +  #  1 - VT100BR
 +  #  2 - VT100+BR
 +  #  3 - UTF8BR
 +  #  4 - TTYTERMBR
 +  # @Prompt Default Terminal Type.
 +  # @ValidRange 0x8001 | 0 - 4
 +  gEfiMdeModulePkgTokenSpaceGuid.PcdDefaultTerminalType|0|UINT8|0x006f
 +
  [PcdsPatchableInModule]
## Specify memory size with page number for PEI code when
#  Loading Module at Fixed Address feature is enabled.
 diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf 
 b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
 index 078029679823..c1ad5779ac29 100644
 --- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
 +++ b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
 @@ -86,7 +86,7 @@ [Protocols]
gEfiSimpleTextOutProtocolGuid ## BY_START
  
  [Pcd]
 -  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType   ## 
 SOMETIMES_CONSUMES
 +  gEfiMdeModulePkgTokenSpaceGuid.PcdDefaultTerminalType ## 
 SOMETIMES_CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdErrorCodeSetVariable## CONSUMES
  
  # [Event]
 

I'm a bit unsure about the 0x006f token value for the new PCD --
MdeModulePkg.dec seems to use some funky numbering scheme, and I'm
missing the idea behind it. In any case, 0x006e is used in the same
section just a little bit higher. So this looks good to me.

Reviewed-by: Laszlo Ersek ler...@redhat.com

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v3 23/23] OvmfPkg: QemuBootOrderLib: recognize extra PCI root buses

[Laszlo Ersek]

On 07/14/15 01:18, Jordan Justen wrote:
 Reviewed-by: Jordan Justen jordan.l.jus...@intel.com

Greatly appreciated!

I committed the series to SVN as r17943 through r17965, inclusive.

Now back to the end-of-dxe series... :)

Thanks!
Laszlo

 
 On 2015-07-07 08:09:25, Laszlo Ersek wrote:
 The OFW device path that QEMU exports in the bootorder fw_cfg file, for
 a device that is plugged into the main PCI root bus, is:

   /pci@i0cf8/...

 Whereas the same device plugged into the N'th extra root bus results in:

   /pci@i0cf8,N/pci-bridge@0/...

 (N is in hex.)

 Extend TranslatePciOfwNodes() so that it not assume a single PCI root;
 instead it parse the extra root bus serial number if present, and resolve
 it in the translation to the UEFI devpath fragment.

 Note that the pci-bridge@0 node is a characteristic of QEMU's PXB
 device. It reflects the actual emulated PCI hierarchy. We don't parse it
 specifically in this patch, because it is automatically handled by the
 bridge sequence translator added recently in SVN rev 17385 (git commit
 feca17fa4b) -- OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of
 PCI bridges.

 The macro EXAMINED_OFW_NODES need not be raised from 6. The longest OFW
 device paths that we wish to recognize under this new scheme comprise 5
 nodes. The initial extra root bus OFW fragment, visible at the top,
 takes up 2 nodes, after which the longest device-specific patterns (IDE
 disk, IDE CD-ROM, ISA floppy, virtio-scsi disk) take 3 more nodes each.

 Cc: Jordan Justen jordan.l.jus...@intel.com
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Laszlo Ersek ler...@redhat.com
 ---

 Notes:
 v3:
 - updated to the most recently agreed upon OFW notation for extra root
   buses
 
 v2:
 - new in v2

  OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c | 152 
 
  1 file changed, 128 insertions(+), 24 deletions(-)

 diff --git a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c 
 b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
 index 276d675..2e96343 100644
 --- a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
 +++ b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
 @@ -27,6 +27,7 @@
  #include Guid/GlobalVariable.h
  #include Guid/VirtioMmioTransport.h
  
 +#include ExtraRootBusMap.h
  
  /**
OpenFirmware to UEFI device path translation output buffer size in 
 CHAR16's.
 @@ -556,6 +557,11 @@ ParseOfwNode (
  
@param[in] NumNodesNumber of elements in OfwNode.
  
 +  @param[in] ExtraPciRoots   An EXTRA_ROOT_BUS_MAP object created with
 + CreateExtraRootBusMap(), to be used for
 + translating positions of extra root buses 
 to
 + bus numbers.
 +
@param[out]Translated  Destination array receiving the UEFI path
   fragment, allocated by the caller. If the
   return value differs from RETURN_SUCCESS, 
 its
 @@ -576,16 +582,23 @@ ParseOfwNode (
@retval RETURN_UNSUPPORTED   The array of OpenFirmware device nodes 
 can't
 be translated in the current 
 implementation.
  
 +  @retval RETURN_PROTOCOL_ERRORThe initial OpenFirmware node refers to 
 an
 +   extra PCI root bus (by serial number) 
 that
 +   is invalid according to ExtraPciRoots.
 +
  **/
  STATIC
  RETURN_STATUS
  TranslatePciOfwNodes (
 -  IN  CONST OFW_NODE *OfwNode,
 -  IN  UINTN  NumNodes,
 -  OUT CHAR16 *Translated,
 -  IN OUT  UINTN  *TranslatedSize
 +  IN  CONST OFW_NODE   *OfwNode,
 +  IN  UINTNNumNodes,
 +  IN  CONST EXTRA_ROOT_BUS_MAP *ExtraPciRoots,
 +  OUT CHAR16   *Translated,
 +  IN OUT  UINTN*TranslatedSize
)
  {
 +  UINT32 PciRoot;
 +  CHAR8  *Comma;
UINTN  FirstNonBridge;
CHAR16 Bridges[BRIDGE_TRANSLATION_OUTPUT_SIZE];
UINTN  BridgesLen;
 @@ -594,7 +607,17 @@ TranslatePciOfwNodes (
UINTN  Written;
  
//
 -  // Get PCI device and optional PCI function. Assume a single PCI root.
 +  // Resolve the PCI root bus number.
 +  //
 +  // The initial OFW node for the main root bus (ie. bus number 0) is:
 +  //
 +  //   /pci@i0cf8
 +  //
 +  // For extra root buses, the initial OFW node is
 +  //
 +  //   /pci@i0cf8,4
 +  //  ^
 +  //  root bus serial number (not PCI bus number)
//
if (NumNodes  REQUIRED_PCI_OFW_NODES ||
!SubstringEq (OfwNode[0].DriverName, pci)
 @@ -602,6 +625,35 @@ TranslatePciOfwNodes (
  return RETURN_UNSUPPORTED;
}
  
 +  PciRoot = 0;
 +  Comma = ScanMem8 (OfwNode[0].UnitAddress.Ptr, OfwNode[0].UnitAddress.Len,
 +',');
 +  if (Comma != NULL) {
 +SUBSTRING PciRootSerialSubString;
 +UINT64PciRootSerial

[edk2] [PATCH v2 4/6] IntelFrameworkModulePkg/GenericBdsLib: remove AcpiS3-S3Save() call

[Laszlo Ersek]

From: Ard Biesheuvel ard.biesheu...@linaro.org

The AcpiS3-S3Save() call needs to occur before the end-of-DXE event
is signalled. The end-of-DXE event needs to be signalled prior to
invoking any UEFI drivers, applications, or connecting consoles.

This means the call to S3Save() that occurs in BdsLibBootViaBootOption()
violates the ordering constraints, and should be removed. Since it is
the responsibility of the platform BDS to signal the end-of-DXE event,
it should also perform the AcpiS3-S3Save() call at an appropriate time.

Commit message update from Laszlo Ersek ler...@redhat.com:

Following Jiewen Yao's idea in

 http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16146

platforms that
(1) use this exact instance of GenericBdsLib, *and*
(2) support S3

should now collect the S3 state
(3) in an End-of-Dxe callback in their AcpiS3SaveDxe drivers, *or*
(4) with an explicit AcpiS3-S3Save() call made to their AcpiS3SaveDxe
drivers from their PlatformBdsLib instances.

OvmfPkg, which uses this GenericBdsLib instance, and has its own
AcpiS3SaveDxe fork, follows (3).

Vlv2TbltDevicePkg, which has a GenericBdsLib fork, and uses
IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe, follows (4).

There are no other platforms in the public edk2 repository that support
S3.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Reviewed-by: Laszlo Ersek ler...@redhat.com
Reviewed-by: Yao, Jiewen jiewen@intel.com
[ler...@redhat.com: updated commit message]
Cc: Ard Biesheuvel ard.biesheu...@linaro.org
Cc: Jeff Fan jeff@intel.com
Cc: Yao, Jiewen jiewen@intel.com
Signed-off-by: Laszlo Ersek ler...@redhat.com
---

Notes:
v2:
- update commit message again

 IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf |  1 -
 IntelFrameworkModulePkg/Library/GenericBdsLib/InternalBdsLib.h  |  1 -
 IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c | 10 --
 3 files changed, 12 deletions(-)

diff --git a/IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf 
b/IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
index 5381e33..5a138a9 100644
--- a/IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
+++ b/IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
@@ -119,7 +119,6 @@ [Protocols]
   gEfiLegacyBiosProtocolGuid## SOMETIMES_CONSUMES
   gEfiCpuArchProtocolGuid   ## CONSUMES
   gEfiDevicePathProtocolGuid## CONSUMES
-  gEfiAcpiS3SaveProtocolGuid## SOMETIMES_CONSUMES
   gEfiGraphicsOutputProtocolGuid## SOMETIMES_CONSUMES
   gEfiUgaDrawProtocolGuid |gEfiMdePkgTokenSpaceGuid.PcdUgaConsumeSupport ## 
SOMETIMES_CONSUMES
   gEfiOEMBadgingProtocolGuid## SOMETIMES_CONSUMES
diff --git a/IntelFrameworkModulePkg/Library/GenericBdsLib/InternalBdsLib.h 
b/IntelFrameworkModulePkg/Library/GenericBdsLib/InternalBdsLib.h
index c32579b..7201d8a 100644
--- a/IntelFrameworkModulePkg/Library/GenericBdsLib/InternalBdsLib.h
+++ b/IntelFrameworkModulePkg/Library/GenericBdsLib/InternalBdsLib.h
@@ -33,7 +33,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include Protocol/SimpleNetwork.h
 #include Protocol/FirmwareVolume2.h
 #include Protocol/PciIo.h
-#include Protocol/AcpiS3Save.h
 #include Protocol/OEMBadging.h
 #include Protocol/GraphicsOutput.h
 #include Protocol/UgaDraw.h
diff --git a/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c 
b/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c
index e02a710..4b7eca7 100644
--- a/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c
+++ b/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c
@@ -2233,7 +2233,6 @@ BdsLibBootViaBootOption (
   EFI_DEVICE_PATH_PROTOCOL  *FilePath;
   EFI_LOADED_IMAGE_PROTOCOL *ImageInfo;
   EFI_DEVICE_PATH_PROTOCOL  *WorkingDevicePath;
-  EFI_ACPI_S3_SAVE_PROTOCOL *AcpiS3Save;
   LIST_ENTRYTempBootLists;
   EFI_BOOT_LOGO_PROTOCOL*BootLogo;
 
@@ -2241,15 +2240,6 @@ BdsLibBootViaBootOption (
   *ExitData = NULL;
 
   //
-  // Notes: this code can be remove after the s3 script table
-  // hook on the event EVT_SIGNAL_READY_TO_BOOT or
-  // EVT_SIGNAL_LEGACY_BOOT
-  //
-  Status = gBS-LocateProtocol (gEfiAcpiS3SaveProtocolGuid, NULL, (VOID **) 
AcpiS3Save);
-  if (!EFI_ERROR (Status)) {
-AcpiS3Save-S3Save (AcpiS3Save, NULL);
-  }
-  //
   // If it's Device Path that starts with a hard drive path, append it with 
the front part to compose a
   // full device path
   //
-- 
1.8.3.1



--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https

[edk2] [PATCH v2 1/6] OvmfPkg: AcpiS3SaveDxe: prepare for End-of-Dxe callback

[Laszlo Ersek]

We are preparing for detaching the S3Ready() functionality from the
EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() protocol member function. Instead, we
will hook the same logic to the End-of-Dxe event group.

The EFI_ACPI_S3_SAVE_PROTOCOL has another member: GetLegacyMemorySize().
According to the documenation,

  This function returns the size of the legacy memory (meaning below 1 MB)
  that is required during an S3 resume. Before the Framework-based
  firmware transfers control to the OS, it has to transition from flat
  mode into real mode in case the OS supplies only a real-mode waking
  vector. This transition requires a certain amount of legacy memory.
  After getting the size of legacy memory below, the caller is responsible
  for allocating the legacy memory below 1 MB according to the size that
  is returned. The specific implementation of allocating the legacy memory
  is out of the scope of this specification.

When EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() is called, the address of the
legacy memory allocated above must be passed to it, in the
LegacyMemoryAddress parameter.

In practice however:

- The S3Ready() function ignores the LegacyMemoryAddress completely.

- No code in the edk2 tree calls
  EFI_ACPI_S3_SAVE_PROTOCOL.GetLegacyMemorySize(), ever.

- All callers of this specific implementation of
  EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() in the edk2 tree pass a NULL
  LegacyMemoryAddress:

  BdsLibBootViaBootOption()
  [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]

For this reason, ASSERT() explicitly that LegacyGetS3MemorySize() is never
called, and that the LegacyMemoryAddress parameter is always NULL.

This fact is important to capture in the code, because in the End-of-Dxe
callback, no LegacyMemoryAddress parameter can be taken. So let's make it
clear that we actually don't even have any use for that parameter.

This patch ports the identical change from IntelFrameworkModulePkg to
OvmfPkg.

Cc: Jordan Justen jordan.l.jus...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
---

Notes:
v2:
- unchanged

 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c 
b/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
index f322981..f05764a 100644
--- a/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
+++ b/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
@@ -2,6 +2,7 @@
   This is an implementation of the ACPI S3 Save protocol.  This is defined in
   S3 boot path specification 0.9.
 
+Copyright (c) 2014-2015, Red Hat, Inc.BR
 Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.BR
 
 This program and the accompanying materials
@@ -402,6 +403,8 @@ LegacyGetS3MemorySize (
   OUT UINTN   *Size
   )
 {
+  ASSERT (FALSE);
+
   if (Size == NULL) {
 return EFI_INVALID_PARAMETER;
   }
@@ -491,6 +494,8 @@ S3Ready (
   }
   AlreadyEntered = TRUE;
 
+  ASSERT (LegacyMemoryAddress == NULL);
+
   AcpiS3Context = AllocateMemoryBelow4G (EfiReservedMemoryType, 
sizeof(*AcpiS3Context));
   ASSERT (AcpiS3Context != NULL);
   AcpiS3ContextBuffer = (EFI_PHYSICAL_ADDRESS)(UINTN)AcpiS3Context;
-- 
1.8.3.1



--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 3/6] OvmfPkg: PlatformBdsLib: signal End-of-Dxe event group

[Laszlo Ersek]

(Paraphrasing git commit 9cd7d3c5 / SVN r17713:)

Currently, OvmfPkg fails to signal the End-of-Dxe event group when
entering the BDS phase, which results in some loss of functionality, eg.
variable reclaim in the variable driver, and the memory region splitting
in the DXE core that belongs to the properties table feature specified in
UEFI-2.5.

As discussed on the edk2-devel mailing list here:

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16109

it is up to the platform BDS to signal End-of-Dxe, since there may be
platform specific ordering constraints with respect to the signalling of
the event that are difficult to honor at the generic level.

(OvmfPkg specifics:)

(1) In OvmfPkg, we can't signal End-of-Dxe before PCI enumeration
completes. According to the previous patch, that would trigger
OvmfPkg/AcpiS3SaveDxe to save S3 state *before* the following chain of
action happened:

- PCI enumeration completes
- ACPI tables are installed by OvmfPkg/AcpiPlatformDxe
- the FACS table becomes available

Since OvmfPkg/AcpiS3SaveDxe can only save S3 state once the FACS table
is available, we must delay the End-of-Dxe signal until after PCI
enumeration completes (ie. root bridges are connected).

(2) Pre-patch, S3Ready() in OvmfPkg/AcpiS3SaveDxe is entered from
BdsLibBootViaBootOption()
[IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c].

After the patch, we enter S3Ready() earlier than that, by signaling
End-of-Dxe in PlatformBdsPolicyBehavior(). The timing / location of
this new call is correct as well, and the original call (that now
becomes the chronologically second call) becomes a no-op: S3Ready() is
protected against 2nd and later entries.

Cc: Jordan Justen jordan.l.jus...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---

Notes:
v2:
- split End-of-Dxe signalling into standalone patch [Jordan]

 OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf |  3 ++
 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h  |  1 +
 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c  | 37 
 3 files changed, 41 insertions(+)

diff --git a/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf 
b/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
index ce29720..c40871b 100644
--- a/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
+++ b/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
@@ -65,3 +65,6 @@ [Pcd.IA32, Pcd.X64]
 [Protocols]
   gEfiDecompressProtocolGuid
   gEfiPciRootBridgeIoProtocolGuid
+
+[Guids]
+  gEfiEndOfDxeEventGroupGuid
diff --git a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h 
b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h
index e3e950e..b510178 100644
--- a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h
+++ b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h
@@ -59,6 +59,7 @@ Abstract:
 #include Guid/Mps.h
 #include Guid/HobList.h
 #include Guid/GlobalVariable.h
+#include Guid/EventGroup.h
 
 #include OvmfPlatforms.h
 
diff --git a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
index de13c6b..ce29987 100644
--- a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
@@ -1163,6 +1163,27 @@ Returns:
 }
 
 
+/**
+  Empty callback function executed when the EndOfDxe event group is signaled.
+
+  We only need this function because we'd like to signal EndOfDxe, and for that
+  we need to create an event, with a callback function.
+
+  @param[in] EventEvent whose notification function is being invoked.
+  @param[in] Context  The pointer to the notification function's context, which
+  is implementation-dependent.
+**/
+STATIC
+VOID
+EFIAPI
+OnEndOfDxe (
+  IN EFI_EVENT Event,
+  IN VOID  *Context
+  )
+{
+}
+
+
 VOID
 EFIAPI
 PlatformBdsPolicyBehavior (
@@ -1197,12 +1218,28 @@ Returns:
 {
   EFI_STATUS Status;
   EFI_BOOT_MODE  BootMode;
+  EFI_EVENT  EndOfDxeEvent;
 
   DEBUG ((EFI_D_INFO, PlatformBdsPolicyBehavior\n));
 
   VisitAllInstancesOfProtocol (gEfiPciRootBridgeIoProtocolGuid,
 ConnectRootBridge, NULL);
 
+  //
+  // We can't signal End-of-Dxe earlier than this. Namely, End-of-Dxe triggers
+  // the preparation of S3 system information. That logic has a hard dependency
+  // on the presence of the FACS ACPI table. Since our ACPI tables are only
+  // installed after PCI enumeration completes, we must not trigger the S3 save
+  // earlier, hence we can't signal End-of-Dxe earlier.
+  //
+  Status = gBS-CreateEventEx (EVT_NOTIFY_SIGNAL, TPL_CALLBACK, OnEndOfDxe,
+  NULL /* NotifyContext */, gEfiEndOfDxeEventGroupGuid,
+  EndOfDxeEvent);
+  if (!EFI_ERROR (Status)) {
+gBS-SignalEvent (EndOfDxeEvent);
+gBS-CloseEvent (EndOfDxeEvent);
+  }
+
   if (PcdGetBool (PcdOvmfFlashVariablesEnable)) {
 DEBUG ((EFI_D_INFO

[edk2] [PATCH v2 6/6] OvmfPkg: AcpiS3SaveDxe: drop EFI_ACPI_S3_SAVE_PROTOCOL

[Laszlo Ersek]

At this point, nothing in the OVMF build calls EFI_ACPI_S3_SAVE_PROTOCOL
member functions; simplify the code by dropping this protocol interface.

Cc: Jordan Justen jordan.l.jus...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---

Notes:
v2:
- replace / update ACPI S3 Save comments with End-of-Dxe callback
  references [Hot Tian]
- remove AcpiS3Save.h, it is now superfluous [Hot Tian]

 OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf |  8 +-
 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.h  | 59 -
 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c  | 88 
 3 files changed, 16 insertions(+), 139 deletions(-)

diff --git a/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf 
b/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
index e657bbe..4cc0713 100644
--- a/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
+++ b/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
@@ -1,7 +1,6 @@
 ## @file
-# Component description file for AcpiS3Save module.
+# AcpiS3Save module installs EndOfDxe callback to prepare S3 boot data.
 #
-# This is an implementation of the ACPI S3 Save protocol.
 # Copyright (c) 2006 - 2011, Intel Corporation. All rights reserved.BR
 #
 # This program and the accompanying materials are
@@ -21,7 +20,7 @@ [Defines]
   MODULE_TYPE= DXE_DRIVER
   VERSION_STRING = 1.0
 
-  ENTRY_POINT= InstallAcpiS3Save
+  ENTRY_POINT= InstallEndOfDxeCallback
 
 #
 # The following information is for reference only and not required by the 
build tools.
@@ -30,7 +29,6 @@ [Defines]
 #
 
 [Sources]
-  AcpiS3Save.h
   AcpiS3Save.c
 
 [Packages]
@@ -61,14 +59,12 @@ [Guids]
   gEfiEndOfDxeEventGroupGuid## CONSUMES  ## Event
 
 [Protocols]
-  gEfiAcpiS3SaveProtocolGuid# PROTOCOL ALWAYS_PRODUCED
   gEfiLockBoxProtocolGuid   # PROTOCOL ALWAYS_PRODUCED
   gEfiLegacyBiosProtocolGuid# PROTOCOL ALWAYS_CONSUMED
   gEfiLegacyRegion2ProtocolGuid # PROTOCOL SOMETIMES_CONSUMED
   gFrameworkEfiMpServiceProtocolGuid# PROTOCOL SOMETIMES_CONSUMED
 
 [FeaturePcd]
-  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformCsmSupport  ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
 
 [Pcd]
diff --git a/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.h 
b/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.h
deleted file mode 100644
index 65974a3..000
--- a/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.h
+++ /dev/null
@@ -1,59 +0,0 @@
-/** @file
-  This is an implementation of the ACPI S3 Save protocol.  This is defined in 
-  S3 boot path specification 0.9.
-
-Copyright (c) 2006 - 2012, Intel Corporation. All rights reserved.BR
-
-This program and the accompanying materials
-are licensed and made available under the terms and conditions
-of the BSD License which accompanies this distribution.  The
-full text of the license may be found at
-http://opensource.org/licenses/bsd-license.php
-
-THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
-WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#ifndef _ACPI_S3_SAVE_H_
-#define _ACPI_S3_SAVE_H_
-
-/**
-  Gets the buffer of legacy memory below 1 MB 
-  This function is to get the buffer in legacy memory below 1MB that is 
required during S3 resume.
-
-  @param This   A pointer to the EFI_ACPI_S3_SAVE_PROTOCOL instance.
-  @param Size   The returned size of legacy memory below 1 MB.
-
-  @retval EFI_SUCCESS   Size is successfully returned.
-  @retval EFI_INVALID_PARAMETER The pointer Size is NULL.
-
-**/
-EFI_STATUS
-EFIAPI
-LegacyGetS3MemorySize (
-  IN  EFI_ACPI_S3_SAVE_PROTOCOL* This,
-  OUT UINTN* Size
-  );
-
-/**
-  Prepares all information that is needed in the S3 resume boot path.
-  
-  Allocate the resources or prepare informations and save in ACPI variable set 
for S3 resume boot path  
-  
-  @param This A pointer to the EFI_ACPI_S3_SAVE_PROTOCOL 
instance.
-  @param LegacyMemoryAddress  The base address of legacy memory.
-
-  @retval EFI_NOT_FOUND Some necessary information cannot be found.
-  @retval EFI_SUCCESS   All information was saved successfully.
-  @retval EFI_OUT_OF_RESOURCES  Resources were insufficient to save all the 
information.
-  @retval EFI_INVALID_PARAMETER The memory range is not located below 1 MB.
-
-**/
-EFI_STATUS
-EFIAPI
-S3Ready (
-  IN EFI_ACPI_S3_SAVE_PROTOCOL *This,
-  IN VOID  *LegacyMemoryAddress   
-  );
-#endif
diff --git a/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c 
b/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
index 8372db8..2e1040b 100644
--- a/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
+++ b/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
@@ -1,6 +1,9 @@
 /** @file
-  This is an implementation of the ACPI S3 Save protocol.  This is defined in
-  S3 boot path specification 0.9.
+  This is a replacement

[edk2] [PATCH v2 2/6] OvmfPkg: AcpiS3SaveDxe: call S3Ready() at End-of-Dxe

[Laszlo Ersek]

Call S3Ready() whenever the first of the following occurs:
- a driver signals End-of-Dxe,
- a driver calls EFI_ACPI_S3_SAVE_PROTOCOL.S3Save().

S3Ready() already contains a static, function scope latch that causes it
to exit early when called for the second time or later.

(At the moment, the only platform in the edk2 tree that includes this
driver is OvmfPkg. That platform does not signal End-of-Dxe (yet).)

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16146
Suggested-by: Yao Jiewen jiewen@intel.com
Cc: Jordan Justen jordan.l.jus...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
---

Notes:
v2:
- unchanged

 OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf |  1 +
 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c  | 46 
 2 files changed, 47 insertions(+)

diff --git a/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf 
b/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
index ae56a20..81da2fb 100644
--- a/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
+++ b/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
@@ -58,6 +58,7 @@ [Guids]
   gEfiAcpiS3ContextGuid # ALWAYS_CONSUMED
   gEfiAcpi20TableGuid   # ALWAYS_CONSUMED  System Table
   gEfiAcpi10TableGuid   # ALWAYS_CONSUMED  System Table
+  gEfiEndOfDxeEventGroupGuid## CONSUMES  ## Event
 
 [Protocols]
   gEfiAcpiS3SaveProtocolGuid# PROTOCOL ALWAYS_PRODUCED
diff --git a/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c 
b/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
index f05764a..5eb33e0 100644
--- a/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
+++ b/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
@@ -29,6 +29,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include Guid/AcpiVariableCompatibility.h
 #include Guid/AcpiS3Context.h
 #include Guid/Acpi.h
+#include Guid/EventGroup.h
 #include Protocol/AcpiS3Save.h
 #include Protocol/S3SaveState.h
 #include Protocol/DxeSmmReadyToLock.h
@@ -571,6 +572,40 @@ S3Ready (
 }
 
 /**
+  Callback function executed when the EndOfDxe event group is signaled.
+
+  @param[in] EventEvent whose notification function is being invoked.
+  @param[in] Context  The pointer to the notification function's context, which
+  is implementation-dependent.
+**/
+VOID
+EFIAPI
+OnEndOfDxe (
+  IN EFI_EVENT Event,
+  IN VOID  *Context
+  )
+{
+  EFI_STATUS Status;
+
+  //
+  // Our S3Ready() function ignores both of its parameters, and always
+  // succeeds.
+  //
+  Status = S3Ready (
+ NULL, // This
+ NULL  // LegacyMemoryAddress
+ );
+  ASSERT_EFI_ERROR (Status);
+
+  //
+  // Close the event, deregistering the callback and freeing resources.
+  //
+  Status = gBS-CloseEvent (Event);
+  ASSERT_EFI_ERROR (Status);
+}
+
+
+/**
   The Driver Entry Point.
   
   The function is the driver Entry point which will produce AcpiS3SaveProtocol.
@@ -591,6 +626,7 @@ InstallAcpiS3Save (
   )
 {
   EFI_STATUSStatus;
+  EFI_EVENT EndOfDxeEvent;
 
   if (!QemuFwCfgS3Enabled()) {
 return EFI_LOAD_ERROR;
@@ -612,5 +648,15 @@ InstallAcpiS3Save (
   NULL
   );
   ASSERT_EFI_ERROR (Status);
+
+  Status = gBS-CreateEventEx (
+  EVT_NOTIFY_SIGNAL,
+  TPL_CALLBACK,
+  OnEndOfDxe,
+  NULL, /* NotifyContext */
+  gEfiEndOfDxeEventGroupGuid,
+  EndOfDxeEvent
+  );
+  ASSERT_EFI_ERROR (Status);
   return Status;
 }
-- 
1.8.3.1



--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 0/6] OvmfPkg: save S3 state at EndOfDxe

[Laszlo Ersek]

Version 2 of
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16304.

Changes relative to v1:

- Since I received no feedback for Vlv2TbltDevicePkg, and no answer to
  my explicit query about interest in Vlv2TbltDevicePkg, I dropped the
  following v1 patches:

  1/9 IntelFrameworkModulePkg: AcpiS3SaveDxe: prepare for End-of-Dxe
  callback
  2/9 IntelFrameworkModulePkg: AcpiS3SaveDxe: call S3Ready() at
  End-of-Dxe
  5/9 Vlv2TbltDevicePkg: replace AcpiS3Save-S3Save() with End-of-Dxe
  signal
  8/9 IntelFrameworkModulePkg: AcpiS3SaveDxe: drop
  EFI_ACPI_S3_SAVE_PROTOCOL

  The explanation is very simple: IntelFrameworkModulePkg/AcpiS3SaveDxe
  and Vlv2TbltDevicePkg must be modified *together*. Since
  Vlv2TbltDevicePkg is not being modified (see above), so can't
  IntelFrameworkModulePkg/AcpiS3SaveDxe.

  The resultant status is valid for the entire tree, and it is also
  explained in v2 4/6.

- Incorporated v1 feedback; please see the notes section of each patch.

Tested with S3 enabled and disabled, with Fedora and Windows Server 2012
R2.

The series compiles and works at each stage (including S3 suspend+resume
when it is enabled).

Public branch: none ATM. The github repo is lagging behind SVN, and
without the most recent SVN commits, the series doesn't apply. It should
be no problem; we discussed repeatedly how to apply edk2 patches from
the mailing list.

Thanks
Laszlo

Ard Biesheuvel (1):
  IntelFrameworkModulePkg/GenericBdsLib: remove AcpiS3-S3Save() call

Laszlo Ersek (5):
  OvmfPkg: AcpiS3SaveDxe: prepare for End-of-Dxe callback
  OvmfPkg: AcpiS3SaveDxe: call S3Ready() at End-of-Dxe
  OvmfPkg: PlatformBdsLib: signal End-of-Dxe event group
  OvmfPkg: install DxeSmmReadyToLock in PlatformBdsLib
  OvmfPkg: AcpiS3SaveDxe: drop EFI_ACPI_S3_SAVE_PROTOCOL

 IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf |   1 -
 OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf |  13 +-
 OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf   |   5 +
 IntelFrameworkModulePkg/Library/GenericBdsLib/InternalBdsLib.h  |   1 -
 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.h  |  59 ---
 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h|   4 +
 IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c |  10 --
 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c  | 168 
+++-
 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c|  86 
++
 9 files changed, 154 insertions(+), 193 deletions(-)
 delete mode 100644 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.h

-- 
1.8.3.1


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 5/6] OvmfPkg: install DxeSmmReadyToLock in PlatformBdsLib

[Laszlo Ersek]

Currently we have the following call chain in OVMF:

  PlatformBdsPolicyBehavior()
[OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
//
// signals End-of-Dxe
//
OnEndOfDxe()  [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
  S3Ready()   [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
//
// 1. saves S3 state
//

SaveS3BootScript()[OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
  //
  // 2. saves INFO opcode in S3 boot script
  // 3. installs DxeSmmReadyToLockProtocol
  //

The bottom of this call chain was introduced in git commit 5a217a06 (SVN
r15305, OvmfPkg: S3 Suspend: save boot script after ACPI context). That
patch was necessary because there was no other way, due to GenericBdsLib
calling S3Save() from BdsLibBootViaBootOption(), to perform the necessary
steps in the right order:
- save S3 system information,
- save a final (well, only) boot script opcode,
- signal DxeSmmReadyToLock, closing the boot script, and locking down
  LockBox and SMM.

The GenericBdsLib bug has been fixed in the previous patch -- the call in
BdsLibBootViaBootOption() has been eliminated.

Therefore, hoist the SaveS3BootScript() code, and call, from
OvmfPkg/AcpiS3SaveDxe, to PlatformBdsLib:

  PlatformBdsPolicyBehavior()
[OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
//
// signals End-of-Dxe
//
OnEndOfDxe()  [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
  S3Ready()   [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
//
// 1. saves S3 state
//

---
SaveS3BootScript()  [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
  //
  // 2. saves INFO opcode in S3 boot script
  // 3. installs DxeSmmReadyToLockProtocol
  //

The installation of DxeSmmReadyToLockProtocol belongs with Platform BDS,
not AcpiS3SaveDxe, and we can now undo the hack in SVN r15305, without
upsetting the relative order of the steps.

Cc: Jordan Justen jordan.l.jus...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---

Notes:
v2:
- move SaveS3BootScript() function definition and call from
  OvmfPkg/AcpiS3SaveDxe to OvmfPkg/Library/PlatformBdsLib in a separate
  patch [Jordan]

 OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf   |  4 +-
 OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf |  2 +
 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h  |  3 ++
 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c| 49 
 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c  | 49 
 5 files changed, 55 insertions(+), 52 deletions(-)

diff --git a/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf 
b/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
index 81da2fb..e657bbe 100644
--- a/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
+++ b/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
@@ -66,8 +66,6 @@ [Protocols]
   gEfiLegacyBiosProtocolGuid# PROTOCOL ALWAYS_CONSUMED
   gEfiLegacyRegion2ProtocolGuid # PROTOCOL SOMETIMES_CONSUMED
   gFrameworkEfiMpServiceProtocolGuid# PROTOCOL SOMETIMES_CONSUMED
-  gEfiS3SaveStateProtocolGuid   # PROTOCOL ALWAYS_CONSUMED
-  gEfiDxeSmmReadyToLockProtocolGuid # PROTOCOL ALWAYS_PRODUCED
 
 [FeaturePcd]
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformCsmSupport  ## 
CONSUMES
@@ -79,4 +77,4 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
 
 [Depex]
-  gEfiVariableArchProtocolGuid AND gEfiVariableWriteArchProtocolGuid AND 
gEfiS3SaveStateProtocolGuid
+  gEfiVariableArchProtocolGuid AND gEfiVariableWriteArchProtocolGuid
diff --git a/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf 
b/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
index c40871b..ab54683 100644
--- a/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
+++ b/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
@@ -65,6 +65,8 @@ [Pcd.IA32, Pcd.X64]
 [Protocols]
   gEfiDecompressProtocolGuid
   gEfiPciRootBridgeIoProtocolGuid
+  gEfiS3SaveStateProtocolGuid   # PROTOCOL SOMETIMES_CONSUMED
+  gEfiDxeSmmReadyToLockProtocolGuid # PROTOCOL SOMETIMES_PRODUCED
 
 [Guids]
   gEfiEndOfDxeEventGroupGuid
diff --git a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h 
b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h
index b510178..6ba0d48 100644
--- a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h
+++ b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h
@@ -47,12 +47,15 @@ Abstract:
 #include Library/DevicePathLib.h
 #include Library/IoLib.h
 #include Library/NvVarsFileLib.h
+#include Library/QemuFwCfgLib.h
 
 #include Protocol/Decompress.h
 #include Protocol/PciIo.h
 #include Protocol/FirmwareVolume2.h
 #include Protocol/SimpleFileSystem.h
 #include Protocol/PciRootBridgeIo.h
+#include Protocol/S3SaveState.h
+#include Protocol/DxeSmmReadyToLock.h
 
 #include Guid/Acpi.h

[edk2] MTRR setup in OVMF [was: PATCH v3 01/10 KVM: MMU: fix decoding cache type from MTRR]

[Laszlo Ersek]

Cross-posting to edk2-devel.

Original sub-thread starts here:
http://thread.gmane.org/gmane.linux.kernel/1952205/focus=1994315

On 07/13/15 17:15, Xiao Guangrong wrote:
 
 
 On 07/13/2015 11:13 PM, Paolo Bonzini wrote:
 On 13/07/2015 16:45, Xiao Guangrong wrote:
 +/* MTRR is completely disabled, use UC for all of physical
 memory. */
 +if (!(mtrr_state-enabled  0x2))
 +return MTRR_TYPE_UNCACHABLE;

 actually disappears in commit fa61213746a7 (KVM: MTRR: simplify
 kvm_mtrr_get_guest_memory_type, 2015-06-15).

 :(

 Based on the SDM, UC is applied to all memory rather than default-type
 if MTRR is disabled.

 There are two issues I think.  One is that I cannot find in the current
 code that UC is applied to all memory rather than default-type if MTRR
 is disabled.  mtrr_default_type unconditionally looks at
 mtrr_state-deftype.
 
 Yes... Will fix.
 

 However, fast boot came back if return 0xFF here. So fast boot expects
 that the memory type is WB.

 Yes.


 static u8 mtrr_default_type(struct kvm_mtrr *mtrr_state)
 {
   if (mtrr_is_enabled(mtrr_state))
   return mtrr_state-deftype 
 IA32_MTRR_DEF_TYPE_TYPE_MASK;
   else
   return MTRR_TYPE_UNCACHABLE;
 }

 ?  Then it's easy to add a quirk that makes the default WRITEBACK until
 MTRRs are enabled.

 It is the wrong configure in OVMF... shall we need to adjust KVM to
 satisfy
 OVMF?

 That's what quirks are for...  The firmware should still be fixed of
 course.
 
 I see, will do it.

The long delay that Alex reported (for the case when all guest memory
was set to UC up-front) is due to the fact that the SEC phase of OVMF
decompresses an approximately 1712 KB sized, LZMA-compressed blob, to
approx. 896 KB worth of PEI drivers and 8192 KB worth of DXE and UEFI
drivers -- and this decompression is extremely memory-intensive.

(Refer to Firmware image structure in the OVMF whitepaper,
http://www.linux-kvm.org/page/OVMF.)

Perhaps also significant, with this initial MTRR change: the x86_64
reset vector builds some page tables too. (Refer to Select features |
X64-specific reset vector for OVMF in the OVMF whitepaper.)

(When Jordan implemented that reset vector first, we saw similar
performance degradation on AMD hosts (albeit not due to MTRR but due to
page attributes). See
https://github.com/tianocore/edk2/commit/98f378a7. I'm only mentioning
it here because it makes me appreciate the current problem report.)

Anyway, the reset vector's page table building is implemented in
OvmfPkg/ResetVector/Ia32/PageTables64.asm. The decompression in SEC
can be found in OvmfPkg/Sec/SecMain.c, function DecompressMemFvs().
(It is recommended to refer heavily to the OVMF whitepaper, or at least
to drink heavily.)

In the PEI phase, we do set up MTRRs sensibly, see
OvmfPkg/PlatformPei/MemDetect.c, function QemuInitializeRam().
However, that's too late with regard this problem report, because PEI
modules run *from* one of the firmware volumes that SEC expands with LZMA.

Anyway, the logic in QemuInitializeRam() relies on the MtrrLib library
class, which OVMF resolves to the
UefiCpuPkg/Library/MtrrLib/MtrrLib.inf instance. The latter has no
client module type restriction (it's BASE), so it could be used in SEC
too, if someone were to write patches.

I'm sorry but I really can't take this on now. So, respectfully:
- please quirk it in KVM for now (SeaBIOS is also affected),
- patches welcome for OVMF, as always.

Thanks
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] MTRR setup in OVMF [was: PATCH v3 01/10 KVM: MMU: fix decoding cache type from MTRR]

[Laszlo Ersek]

On 07/14/15 23:15, Paolo Bonzini wrote:
 The long delay that Alex reported (for the case when all guest memory
 was set to UC up-front) is due to the fact that the SEC phase of OVMF
 decompresses an approximately 1712 KB sized, LZMA-compressed blob, to
 approx. 896 KB worth of PEI drivers and 8192 KB worth of DXE and UEFI
 drivers -- and this decompression is extremely memory-intensive.

 (When Jordan implemented that reset vector first, we saw similar
 performance degradation on AMD hosts (albeit not due to MTRR but due to
 page attributes). See
 https://github.com/tianocore/edk2/commit/98f378a7. I'm only mentioning
 it here because it makes me appreciate the current problem report.)

 Anyway, the reset vector's page table building is implemented in
 OvmfPkg/ResetVector/Ia32/PageTables64.asm. The decompression in SEC
 can be found in OvmfPkg/Sec/SecMain.c, function DecompressMemFvs().
 
 Perhaps the OVMF reset vector should initialize the MTRRs for the BSP?

That's an idea, yes, if someone feels sufficiently drawn to writing
assembly. Complications:
- the reset vector is specific to OvmfPkg only in the OvmfPkgX64.dsc
  build
- it needs to be determined what memory to cover.

 I think SEC doesn't do any MMIO, so it should be enough to enable MTRRs
 and set the default type to writeback.

Seems safe to me, off the top of my head (and testing could confirm /
disprove quickly).

 In any case we're going to have to quirk it, because of the broken
 guests in the wild.

Thanks.
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] upload two drivers

[Laszlo Ersek]

On 07/14/15 20:31, S.Vieira wrote:
 Hi everyone.
 
 It's possible to do upload of two drives just in ONE .efi
 
 I am wanting to do upload of the AtaAtapiPassThruDxe and AtaBusDxe only in
 ONE file.

I think it should be possible to install any number of driver binding
protocol instances in a single driver module, on the image handle.
However, you'd have to merge the two drivers into one in C source code,
and then build the resultant driver.

Laszlo

 
 
 
 
 Thx
 S.Vieira
 
 
 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 edk2-devel mailing list
 edk2-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/edk2-devel
 


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] BUG in properties table feature implementation

[Laszlo Ersek]

On 06/29/15 20:10, Ard Biesheuvel wrote:
 On 29 June 2015 at 17:12, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 On 29 June 2015 at 17:09, Matt Fleming m...@codeblueprint.co.uk wrote:
 On Mon, 29 Jun, at 03:06:32PM, Laszlo Ersek wrote:

 In any case, for OVMF, I think we'll need a small patch that disables
 this feature (if for nothing else, then to quell the noisy warnings
 about the section alignment being != 4 KB). I'm adding that to my
 queue (but anyone please feel free to do it while I'm offline).

 Is there any chance that we could wire up support in OVMF? What work is
 required to support it?


 I think it would be fairly easy, actually, once Laszlo manages to
 untangle the S3Save mess so that OVMF signals EndOfDxe correctly.
 Then, it is mainly a matter of using the new build script that emits 4
 KB aligned segments for .text and .data

 
 This seems to do the job nicely:
 
 --8
 diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
 index e5fc90d2e610..7f06b51f65cf 100644
 --- a/OvmfPkg/OvmfPkgX64.dsc
 +++ b/OvmfPkg/OvmfPkgX64.dsc
 @@ -48,6 +48,9 @@ [BuildOptions]
INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
  !endif
 
 +[BuildOptions.X64.EDKII.DXE_RUNTIME_DRIVER]
 +  GCC:*_*_*_DLINK_FLAGS =
 --script=$(EDK_TOOLS_PATH)/Scripts/gcc-4K-align-ld-script
 +
  
 
  #
  # SKU Identification section - list of all SKU IDs supported by this 
 Platform.
 --8
 
 $ readelf -S 
 Build/OvmfX64/DEBUG_GCC48/X64/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb/DEBUG/EmuVariableFvbRuntimeDxe.dll
 
 Section Headers:
   [Nr] Name  Type Address   Offset
Size  EntSize  Flags  Link  Info  Align
 ...
   [ 1] .text PROGBITS 1000  1000
4780    AX   0 0 4096
 ...
   [ 3] .data PROGBITS 6000  6000
2740    WA   0 0 4096
 ...
 
 
 With Laszlo's 9 piece series applied to ensure that end of DXE gets
 signalled, UEFI seems to do the right thing here. Here's a snippet of
 my boot log (x86_64)
 
 [0.00] efi: mem22: type=6, attr=0x8000400f,
 range=[0x06daa000-0x06db1000) (0MB)
 [0.00] efi: mem23: type=5, attr=0x8002000f,
 range=[0x06db1000-0x06db6000) (0MB)
 [0.00] efi: mem24: type=6, attr=0x8000400f,
 range=[0x06db6000-0x06dc) (0MB)
 [0.00] efi: mem25: type=6, attr=0x8000400f,
 range=[0x06dc-0x06dc1000) (0MB)
 [0.00] efi: mem26: type=5, attr=0x8002000f,
 range=[0x06dc1000-0x06dc5000) (0MB)
 [0.00] efi: mem27: type=6, attr=0x8000400f,
 range=[0x06dc5000-0x06dce000) (0MB)
 [0.00] efi: mem28: type=6, attr=0x8000400f,
 range=[0x06dce000-0x06dcf000) (0MB)
 [0.00] efi: mem29: type=5, attr=0x8002000f,
 range=[0x06dcf000-0x06dd5000) (0MB)
 [0.00] efi: mem30: type=6, attr=0x8000400f,
 range=[0x06dd5000-0x06e02000) (0MB)
 [0.00] efi: mem31: type=6, attr=0x8000400f,
 range=[0x06e02000-0x06e03000) (0MB)
 [0.00] efi: mem32: type=5, attr=0x8002000f,
 range=[0x06e03000-0x06e12000) (0MB)
 [0.00] efi: mem33: type=6, attr=0x8000400f,
 range=[0x06e12000-0x06e1a000) (0MB)
 
 so code and data regions are correctly marked as RO and XP, respectively.
 
 However, further down I get
 
 [0.034428] BUG: unable to handle kernel paging request at fffefe60d64d
 [0.036000] IP: [fffefe60d64d] 0xfffefe60d64d
 [0.036000] PGD 4c11067 PUD 601b063 PMD 6028063 PTE 0
 [0.036000] Oops: 0010 [#1] SMP
 [0.036000] Modules linked in:
 [0.036000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
 3.13.0-55-generic #94-Ubuntu
 [0.036000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
 BIOS 0.0.0 02/06/2015
 [0.036000] task: 81c15480 ti: 81c0 task.ti:
 81c0
 [0.036000] RIP: 0010:[fffefe60d64d]  [fffefe60d64d]
 0xfffefe60d64d
 [0.036000] RSP: :81c01d48  EFLAGS: 0202
 [0.036000] RAX: fffefe60d64d RBX:  RCX: 
 81c396e0
 [0.036000] RDX: 81c01f00 RSI: 81c396e0 RDI: 
 fffefe40a957
 [0.036000] RBP: 81c01e00 R08: 0007 R09: 
 
 [0.036000] R10: ea180e00 R11: 81d51ce0 R12: 
 81c01f00
 [0.036000] R13:  R14: 0007 R15: 
 0009c000
 [0.036000] FS:  () GS:88000660()
 knlGS:
 [0.036000] CS:  0010 DS:  ES:  CR0: 80050033

Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables

[Laszlo Ersek]

On 07/12/15 08:24, B Cran wrote:
 
 On Jul 11, 2015, at 11:42 PM, Jordan Justen jordan.l.jus...@intel.com 
 wrote:

 It could be that the move to git will make it more feasible to have a
 testing branch that could allow all patches to first be tested against
 all toolchains. But, personally I'm not really sure that a separate
 branch would be worth the hassle.
 
 I don’t think you want a separate _branch_, but probably a separate 
 _repository_ that mirrors 
 the official one and that people can create new heads on. Pass the changeset 
 hash to the 
 build farm and it can pull and build the changes. Then, once a day destroy 
 the clone and 
 reset to upstream.

That would be great.

Laszlo


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables

[Laszlo Ersek]

On 07/11/15 09:43, Scott Duplichan wrote:
 Jordan Justen [mailto:jordan.l.jus...@intel.com] wrote:
 
 ]Sent: Friday, July 10, 2015 02:24 AM
 ]To: edk2-devel@lists.sourceforge.net; Scott Duplichan
 ]Subject: Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables
 ]
 ]On 2015-07-08 19:31:09, Scott Duplichan wrote:
 ] Bruce Cran [mailto:br...@cran.org.uk] wrote:
 ] 
 ] ]Sent: Wednesday, July 08, 2015 05:12 PM
 ] ]To: edk2-devel@lists.sourceforge.net
 ] ]Subject: Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables
 ] ]
 ] ]On Wed, Jul 08, 2015 at 10:43:38PM +0200, Laszlo Ersek wrote:
 ] ]
 ] ] I think it would make a difference if -flto *actually* worked, but from
 ] ] a quick google search, I think it either doesn't work with gcc-4.8 at
 ] ] all, *or* the edk2 build system would have to use FLTO-aware binutils
 ] ] and linker wrappers (or parameters). I have no clue how to set that up.
 ] ] So for now we'll have to stick with MDEPKG_NDEBUG I guess.
 ] ]
 ] ]I've been trying to get -flto working this week, but without success 
 (yet!).
 ] ]I'm currently running into a problem of ld (built from source) apparently 
 not
 ] ]knowing about the lto plugin (and passing the liblto.so file via -plugin 
 causes
 ] ]an assert failure), but I'll keep trying.
 ] 
 ] Last year I spent some time to get gcc -flto working properly with EDK2.
 ] At that time, the people here were busy with other things and there didn't
 ] seem to be a lot of interest in gcc link time optimization. So I never
 ] submitted a patch. Maybe it is time to revive this effort. Here is what I
 ] found:
 ] 
 ] http://notabs.org/uefi/gcc-lto.htm
 ] 
 ] So 6 conditions need to be met for ghcc link time optimization to work
 ] properly with EDK2:
 ] 
 ] 1) Add -flto to the compile flags
 ] 2) Use gcc to launch ld instead of invoking ld directly
 ] 3) Include the compile flags on the link command line
 ] 4) Use gcc-ar in place of ar when building static libraries
 ] 5) Library code that resolves helper function calls generated by the 
 compiler must be compiled ]without the -flto flag
 ] 6) These libraries must be prefixed with 
 -Wl,-plugin-opt=-pass-through= on the link command line.
 ] 
 ] A patch from late 2014 is here:
 ] 
 http://sourceforge.net/projects/edk2developertoolsforwindows/files/Patches/Link%20Time%20Optimization/
 ]
 ]BaseTools/Contributions.txt (Contributed-under...)
 ]
 ]If you don't submit it edk2-devel, and continue to follow up on it,
 ]then work can easily slip through the cracks.
 ]
 ]That said, I've spent a little time looking at your work, so it's not
 ]true that there was no interest. But, if you have something that is
 ]*actually working* for DuetPkg, EmulatorPkg and OvmfPkg, can you put
 ]together a patch series?
 
 The patch isn't ready for review. One reason is that it exposes
 a problem that has no simple solution that I can find. A BaseTools
 change may be needed. Link time code generation allows gcc to warn
 about things that it otherwise can't. With -flto, gcc warns about:
 
 extern const VOID* _gPcd_FixedAtBuild_PcdShellSupplier[];
 AutoGen.c:207:15: note: previously declared here
 GLOBAL_REMOVE_IF_UNREFERENCED const UINT16
 _gPcd_FixedAtBuild_PcdShellSupplier[7] = {69, 68, 75, 32, 73, 73, 0 };
 
 Both definitions are generated so they can't easily be changed.
 This slight inconsistency in the array definition stops the build
 because of warnings as errors. For this -flto proof of concept
 experiment, I disable warning as errors. But the problem needs
 to be resolved before a patch can be submitted. It was discussed
 in a thread titled Status of gcc link time optimization for EDK2 use.
 Sergey made a python patch, but as I remember it didn't quite fix
 every occurrence.
 
 ]I don't see how we can manage 5  6 with our current BaseTools. How
 ]did you manage it? Searching for 'pass-through' in your patch doesn't
 ]yield any results.
 
 I punted and omitted -flto for that case. It is only a serious problem
 for ARM:
 
 While making the EDK2 build meet requirement 5 is easy, the same
 is not true for requirement 6 in some cases. For example, the ARM
 build resolves compiler generated helper function calls with
 CompilerIntrinsicsLib.lib and BaseStackCheckLib.lib. The path to
 these libraries varies with the package name and build options.
 Without a significant modification to the EDK2 build tools, there
 is no way to generate the requires prefixed path for use on the
 linker command line. This limitation affects ARM builds the most
 because gcc ARM code uses more compiler generated helper function
 calls than other target architectures. For this reason, link time
 optimization is not enabled for ARM in the gcc LTO EDK2 patch. The
 use of compiler generated helper function calls is kept to a minimum
 in x86 code. For the IA32 builds the compiler generates a floating
 point helper call when building stdlib

Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables

[Laszlo Ersek]

On 07/12/15 04:53, Bruce Cran wrote:
 On Wed, Jul 08, 2015 at 09:02:10PM +0200, Laszlo Ersek wrote:
 
 My lack of faith is based on experience :) We've been complaining
 about this for ages on the list. I think it is safe to assume that the
 primary participant that has legal access to all supported Microsoft
 toolchains is Intel. As described (and provided!) by Scott,
 gcc-for-Windows is almost trivially available (all supported gcc
 versions). It seems to follow that Intel should operate such a build
 farm. Based on how long we've been whining about this, I don't think
 it's going to happen any time soon.
 
 Since I had a few days off from the daily grind, I setup Jenkins and a few VMs
 to build edk2 trunk, polling svn for changes. At the moment it builds debug 
 and
 release, 32-bit and 64-bit OVMF on Linux gcc 4.6, 4.7, 4.8, 4.9 and 5.1, and
 MSVC 2008, 2010, 2012 and 2013. gcc 4.4 and 4.5 need more investigation since
 the compilers don't build.
 The Jenkins URL to see build status etc. is 
 https://edk2.bluestop.org:8000/jenkins .
 
 I've also set up an EDKSMOKE repository at 
 https://edk2.bluestop.org/diffusion/EDKSMOKE
 which currently lets anyone with an account push changesets to. I've not done
 the integration yet, but the idea is that I'll hook it into Jenkins to let
 people smoke test changesets on the various configurations I'll setup.

Thank you very much.

I also spent quite a few hours during the weekend on setting up 6
virtual machines locally (various Fedora releases that have gcc 4.4 to
4.9, inclusive, as their native compiler). I got it working, but it
was quite an awful experience. (For some reason I don't seem to be
attracted to system administration.) In any case, your solution
appears much superior. I'd like to return to it (and hopefully start
using it regularly!) later on.

Thanks!
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH V2 1/3] ArmVirtPkg: Make terminal type consistent

[Laszlo Ersek]

On 07/13/15 05:24, Heyi Guo wrote:
 Change default terminal type to be consistent with default
 ConIn/ConOut device path, which is now determined by TTY_TERMINAL
 flag, TTYTERM or VT100.
 
 I can't say this is a bug, as we can pass the whole console device
 path to ConnectController, and TerminalDxe driver will pick up the
 terminal in the remaining device path. However, in rare circumstances,
 the console devices may be disconnected with the driver, and they will
 be ignored by ConPlatformDxe until we pass the device path explicitly
 just as BDS.
 
 Changing default terminal type to be the same with console device
 path could help serial terminal be reconnected with normal connect
 controller operation.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Heyi Guo heyi@linaro.org
 ---
  ArmVirtPkg/ArmVirtQemu.dsc | 6 ++
  1 file changed, 6 insertions(+)
 
 diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
 index fbc2b12..e62624f 100644
 --- a/ArmVirtPkg/ArmVirtQemu.dsc
 +++ b/ArmVirtPkg/ArmVirtQemu.dsc
 @@ -141,9 +141,15 @@
  !if $(TTY_TERMINAL) == TRUE

 gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)

 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)
 +  ## Terminal Type - TTY, consistent with ConOut/ConIn Device Path.
 +  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|4
  !else

 gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()

 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()
 +  ## Terminal Type - VT100, consistent with ConOut/ConIn Device Path.
 +  ## When Intel BDS is enabled, the above ConOut/ConIn device path is 
 useless,
 +  ## but we still use VT100 terminal type when TTY_TERMINAL is not TRUE.
 +  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1
  !endif
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3
  
 

Reviewed-by: Laszlo Ersek ler...@redhat.com

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH V2 1/3] ArmVirtPkg: Make terminal type consistent

[Laszlo Ersek]

On 07/13/15 13:22, Ard Biesheuvel wrote:
 On 13 July 2015 at 13:15, Laszlo Ersek ler...@redhat.com wrote:
 On 07/13/15 05:24, Heyi Guo wrote:
 Change default terminal type to be consistent with default
 ConIn/ConOut device path, which is now determined by TTY_TERMINAL
 flag, TTYTERM or VT100.

 I can't say this is a bug, as we can pass the whole console device
 path to ConnectController, and TerminalDxe driver will pick up the
 terminal in the remaining device path. However, in rare circumstances,
 the console devices may be disconnected with the driver, and they will
 be ignored by ConPlatformDxe until we pass the device path explicitly
 just as BDS.

 Changing default terminal type to be the same with console device
 path could help serial terminal be reconnected with normal connect
 controller operation.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Heyi Guo heyi@linaro.org
 ---
  ArmVirtPkg/ArmVirtQemu.dsc | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
 index fbc2b12..e62624f 100644
 --- a/ArmVirtPkg/ArmVirtQemu.dsc
 +++ b/ArmVirtPkg/ArmVirtQemu.dsc
 @@ -141,9 +141,15 @@
  !if $(TTY_TERMINAL) == TRUE

 gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)

 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)
 +  ## Terminal Type - TTY, consistent with ConOut/ConIn Device Path.
 +  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|4
  !else

 gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()

 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()
 +  ## Terminal Type - VT100, consistent with ConOut/ConIn Device Path.
 +  ## When Intel BDS is enabled, the above ConOut/ConIn device path is 
 useless,
 +  ## but we still use VT100 terminal type when TTY_TERMINAL is not TRUE.
 +  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1
  !endif
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3



 Reviewed-by: Laszlo Ersek ler...@redhat.com
 
 I am OK with the patch. However, the value '4' is not defined for
 PcdDefaultTerminalType is not defined in MdePkg.
 Is that a concern to anyone? I am aware that we suggested to Roy not
 to touch MdePkg with his TtyTerm changes, but it seems odd to just use
 '4' here
 

See MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h, commit
6e3227c8. (The TTYTERMTYPE macro.)

What should belong to MdePkg (but can't, unless it gets standardized) is
the textual representation for the new VenMsg(GUID).

... Hm, okay, you do have a point, I just checked MdePkg/MdePkg.dec,
and it does list the values 0-3. However, the PCD is not used inside
MdePkg, it is only declared there.

So, I think that this patch is okay. If another terminal type gets
standardized *before* Roy's TTYTERM, then:
- that type will get a new (different) GUID,
- and it will get value 4 in MdePkg/MdePkg.dec. (And, in Terminal.h.)

The new GUID will obviously not conflict, and the current TTYTERMTYPE=4
constant will be possible to shift up to TTYTERMTYPE=5, at that point.
Yes, referring DSCs will have to be updated as well.

This is not 100% clean, admittedly. I think the root issue is that the
PCD should not be declared in MdePkg at all; at least (off the top off
my head) I doubt the numeric value comes from the UEFI spec. So, maybe
someone can submit a patch that moves the PCD declaration from MdePkg to
MdeModulePkg. Otherwise, I'd be fine with the above plan. So my R-b
stands.

Thanks
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 8/8] ArmVirtPkg/ArmVirtQemu.dsc: Remove Linux specific boot path

[Laszlo Ersek]

On 07/13/15 18:36, Olivier Martin wrote:
 PcdDefaultBootType has been removed when the embedded
 Linux Loader has been removed from BdsLib.
 The boot arguments (defined by PcdDefaultBootArgument) are
 now always targetting EFI applications.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Olivier Martin olivier.mar...@arm.com
 Reviewed-by: Ronald Cron ronald.c...@arm.com
 ---
  ArmVirtPkg/ArmVirtQemu.dsc | 1 -
  1 file changed, 1 deletion(-)
 
 diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
 index fbc2b12..0d4f4b0 100644
 --- a/ArmVirtPkg/ArmVirtQemu.dsc
 +++ b/ArmVirtPkg/ArmVirtQemu.dsc
 @@ -133,7 +133,6 @@
gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LLinux (EFI stub) on 
 virtio31:hd0:part0

 gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/HD(1,MBR,0x,0x3F,0x19FC0)/Image
gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|root=/dev/vda2 
 console=ttyAMA0 earlycon uefi_debug
 -  gArmPlatformTokenSpaceGuid.PcdDefaultBootType|0
  
#
# Settings for ARM BDS -- use the serial console (ConIn  ConOut).
 

The declaration of gArmPlatformTokenSpaceGuid.PcdDefaultBootType is
removed from ArmPlatformPkg/ArmPlatformPkg.dec in patch #5. Therefore,
if someone were to build the ArmVirtQemu.dsc platform right at patch #5,
it would break.

I'd like to request the following:
- First, please remove the code (driver, library, etc) that consumes
  PcdDefaultBootType. At this point the PCD becomes unused, code-wise,
  but the tree should build.
- Second, please remove the PCD assignments from the DSC files across
  the tree.
- Third, please drop the PCD declaration as last step.

Thank you
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 0/2] MdePkg|MdeModulePkg: constify mStatusString

[Laszlo Ersek]

On 07/13/15 21:49, Ard Biesheuvel wrote:
 This constifies two instances of mStatusString, preventing it from
 being emitted into the .data section.
 
 Ard Biesheuvel (2):
   MdePkg/BasePrintLib: make mStatusString array CONST
   MdeModulePkg/DxePrintLibPrint2Protocol: make mStatusString array CONST
 
  MdeModulePkg/Library/DxePrintLibPrint2Protocol/PrintLib.c | 2 +-
  MdePkg/Library/BasePrintLib/PrintLibInternal.c| 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)
 

Reviewed-by: Laszlo Ersek ler...@redhat.com

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] Avoid variable set but not used warning from GCC.

[Laszlo Ersek]

On 07/10/15 02:09, Bill Paul wrote:
 The FileReserved variable in QemuFwCfgFindFile() is only used to skip
 over the reserved field in file headers, which causes newer versions of
 GCC to flag it with a variable set but not used warning (which is normally
 not visible since as of right now these warnings are supressed). It's true
 that the value read into FileReserved is never used, but this is
 intentional. This patch adds a do-nothing reference to silence the
 warning.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Bill Paul wp...@windriver.com
 
 ---
  OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c 
 b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
 index 24424f8..573d90f 100644
 --- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
 +++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
 @@ -283,6 +283,7 @@ QemuFwCfgFindFile (
  FileSize = QemuFwCfgRead32 ();
  FileSelect   = QemuFwCfgRead16 ();
  FileReserved = QemuFwCfgRead16 ();
 +(VOID) FileReserved; /* Force a do-nothing reference. */
  InternalQemuFwCfgReadBytes (sizeof (FName), FName);
  
  if (AsciiStrCmp (Name, FName) == 0) {
 

Reviewed-by: Laszlo Ersek ler...@redhat.com

I committed the patch (with a slight update to the subject) to SVN as
r17920. Thank you.

Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] Avoid variable set but not used warning from GCC.

[Laszlo Ersek]

Ooops :)

Apparently I was too quick to commit this, without waiting for your
review. Anyway, some comments:

On 07/10/15 09:05, Jordan Justen wrote:
 Patch subject doesn't contain a package/module prefix. I suggest:
 
 OvmfPkg/QemuFwCfgLib: Avoid variable set but not used warning from GCC

I fixed that up when committing.

 
 https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format
 
 On 2015-07-09 17:09:20, Bill Paul wrote:
 The FileReserved variable in QemuFwCfgFindFile() is only used to skip
 over the reserved field in file headers, which causes newer versions of
 GCC to flag it with a variable set but not used warning (which is normally
 not visible since as of right now these warnings are supressed). It's true
 that the value read into FileReserved is never used, but this is
 intentional. This patch adds a do-nothing reference to silence the
 warning.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Bill Paul wp...@windriver.com
 
 You should add Cc's here (package owners are in Maintainers.txt):
 
 Cc: Jordan Justen jordan.l.jus...@intel.com
 Cc: Laszlo Ersek ler...@redhat.com

Agree, but ultimately both of us noticed the patch :)

 
 ---
  OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c 
 b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
 index 24424f8..573d90f 100644
 --- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
 +++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
 @@ -283,6 +283,7 @@ QemuFwCfgFindFile (
  FileSize = QemuFwCfgRead32 ();
  FileSelect   = QemuFwCfgRead16 ();
  FileReserved = QemuFwCfgRead16 ();
 +(VOID) FileReserved; /* Force a do-nothing reference. */
 
 We use '//' comments in code.
 
 Coding Standards Spec, Section 5. 4.2 Internal Comments:
 
 For internal code comments, use C++ style (//) comment lines.

Yes, I did not miss that, but I thought this was really minor here, and
I was happy that Bill finally decided to submit a patch! :) I didn't
want to discourage further contributions from him by splitting hairs
*here* :)

 Instead of this change, why not just remove the FileReserved variable
 and change the code:
 
 //
 // Read 2 reserved bytes
 //
 QemuFwCfgRead16 ();

I named that option before, in a slightly different form:

  (VOID) QemuFwCfgRead16 ();

Because, without the explicit cast to VOID, some compiler might complain
about the return value being ignored.

In any case, I called Bill's version (the one I ultimately committed
too) more readable, so if you disagree with that, then it's my fault.

If you'd like, you can update the style in the source and commit it at
once as a separate patch, and add my R-b immediately (based on the above).

Thanks
Laszlo

 
 -Jordan
 
  InternalQemuFwCfgReadBytes (sizeof (FName), FName);
  
  if (AsciiStrCmp (Name, FName) == 0) {
 -- 
 1.8.0


 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 edk2-devel mailing list
 edk2-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/edk2-devel


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] CryptoPkg: update OpenSSL dependency to version 1.0.2d

[Laszlo Ersek]

 +  Current supported OpenSSL version for UEFI Crypto Library is 1.0.2d.
 +http://www.openssl.org/source/openssl-1.0.2d.tar.gz
  
  
  
 
HOW to Install Openssl for UEFI Building
  
 
 -1.  Download OpenSSL 1.0.2c from official website:
 -http://www.openssl.org/source/openssl-1.0.2c.tar.gz
 +1.  Download OpenSSL 1.0.2d from official website:
 +http://www.openssl.org/source/openssl-1.0.2d.tar.gz
  
 -NOTE: Some web browsers may rename the downloaded TAR file to 
 openssl-1.0.2c.tar.tar.
 -  When you do the download, rename the openssl-1.0.2c.tar.tar to
 -  openssl-1.0.2c.tar.gz or rename the local downloaded file with 
 .tar.tar
 +NOTE: Some web browsers may rename the downloaded TAR file to 
 openssl-1.0.2d.tar.tar.
 +  When you do the download, rename the openssl-1.0.2d.tar.tar to
 +  openssl-1.0.2d.tar.gz or rename the local downloaded file with 
 .tar.tar
extension to .tar.gz.
  
 -2.  Extract TAR into CryptoPkg/Library/OpenSslLib/openssl-1.0.2c
 +2.  Extract TAR into CryptoPkg/Library/OpenSslLib/openssl-1.0.2d
  
  NOTE: If you use WinZip to unpack the openssl source in Windows, please
uncheck the WinZip smart CR/LF conversion option (WINZIP: Options 
 --
Configuration -- Miscellaneous -- TAR file smart CR/LF 
 conversion).
  
 -3.  Apply this patch: EDKII_openssl-1.0.2c.patch, and make installation
 +3.  Apply this patch: EDKII_openssl-1.0.2d.patch, and make installation
  
  For Windows Environment:
  
  1) Make sure the patch utility has been installed in your machine.
 Install Cygwin or get the patch utility binary from
http://gnuwin32.sourceforge.net/packages/patch.htm
 -2) cd $(WORKSPACE)\CryptoPkg\Library\OpensslLib\openssl-1.0.2c
 -3) patch -p0 -i ..\EDKII_openssl-1.0.2c.patch
 +2) cd $(WORKSPACE)\CryptoPkg\Library\OpensslLib\openssl-1.0.2d
 +3) patch -p0 -i ..\EDKII_openssl-1.0.2d.patch
  4) cd ..
  5) Install.cmd
  
 @@ -54,8 +54,8 @@ cryptography. This patch will enable openssl building under 
 UEFI environment.
  ---
  1) Make sure the patch utility has been installed in your machine.
 Patch utility is available from 
 http://directory.fsf.org/project/patch/
 -2) cd $(WORKSPACE)/CryptoPkg/Library/OpensslLib/openssl-1.0.2c
 -3) patch -p0 -i ../EDKII_openssl-1.0.2c.patch
 +2) cd $(WORKSPACE)/CryptoPkg/Library/OpensslLib/openssl-1.0.2d
 +3) patch -p0 -i ../EDKII_openssl-1.0.2d.patch
  4) cd ..
  5) ./Install.sh
  
 

Reviewed-by: Laszlo Ersek ler...@redhat.com

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v3 3/7] EmulatorPkg: Remove Ip4ConfigDxe module from EmulatorPkg

[Laszlo Ersek]

On 07/10/15 10:40, Wu, Jiaxin wrote:
 Yes, edk2-devel will strip it. You can check version2 for those
 series patches, I had added someone with cc tag to the commit
 message, but it haven't actually cc to those people.

Yes, you did! I *did* get a personal copy of the v2 patches from you!

(And another one from the list server.)

We discussed this earlier. I explained it to you, and I think you missed
the point.

The edk2-devel list's settings *cannot* interfere with the Cc headers of
the patch email that *you* send out. The list settings can only
influence the Cc headers on the emails that the list server *reflects*.

Here's a diagram:

Jiaxin
   /  \
  /\
  [Cc: Laszlo]   [To: edk2-devel]
|  |
|  |
 Laszlo list server
   /   ||  \
  /||   \
  Laszlo Jiaxin |...
  Jordan

Assume the following:

- You write the commit message for your patch, and add Cc: Laszlo to
  the commit message.

- Then you format the patch with git format-patch, and send it with
  git send-email to edk2-devel (To:).

Then the following happens:

(1) The git send-email program will automatically set the Cc: header
of the email from the Cc: tag in the commit message. That is, the
message mailed out *from your side* will have the following headers:

  From: Jiaxin
  To: edk2-devel
  Cc: Laszlo

(2) That message will be *directly* sent to two recipients: Laszlo, and
the edk2-devel list server.

(3) Laszlo will get a copy directly from you, and another copy
*reflected* from the mailing list server. (Laszlo has mail filters in
place that file the direct copy into his INBOX, and the reflected copy
into his edk2-devel folder.)

The copy that Laszlo directly gets from Jiaxin will have the following
headers:

  From: Jiaxin
  To: edk2-devel
  Cc: Laszlo

The copy that Laszlo gets from the mailing list server will have the
following headers:

  From: Jiaxin
  To: edk2-devel

This is because the mailing list server is *stupid*. It sees, in its
internal database, that Laszlo is subscribed, and therefore thinks
(completely incorrectly) that Laszlo should not be Cc:-d on messages
reflected from the list, because he gets them anyway.

(4) Jiaxin, since he is subscribed, will get one copy of the message,
reflected by the mailing list server. The headers on that message will be:

  From: Jiaxin
  To: edk2-devel

No Cc:Laszlo. See above why.

(5) Jordan, because he is subscribed, gets one copy of the message,
reflected by the mailing list server. The headers on Jordan's copy will say:

  From: Jiaxin
  To: edk2-devel

No Cc: Laszlo. See above why.

(6) Now, if Jordan responds at this point, then he will *not*
carbon-copy Laszlo, because the message that he received *lacks* the Cc.

Because, the mailing list server is *stupid*, and intentionally stripped
Cc:Laszlo, *even though* Jiaxin added it initially.

*

Summary:

- The mailing list is stupid. It strips the Cc's of subscribed people,
  but (obviously) it can do this only with messages that it *reflects*.

- The *original* emails sent out by a patch submitter should
  *nonetheless* Cc: the maintainers, because the maintainers will get
  those messages *directly*. That's the point.

The mailing list's broken settings prevent list followups from carrying
forward the Cc, but the initial, direct email does adhere to the Cc's.

Laszlo

 
 For the git script format, I know it support both linux shell and windows 
 CMD(CMD is my choice).
 *Firstly, we must add the git installation path to system variable(PATH with 
 C:\Program Files (x86)\Git\cmd).
 *And then, we can create a .bat file with any git cmd you want to execute 
 for those patch series.
   For example in .bat file:
   git send-email .patch --to=edk2-devel@lists.sourceforge.net 
 --to=someone --to= someone
   git send-email 0001.patch --to=edk2-devel@lists.sourceforge.net --to= 
 someone --to= someone
   git send-email 0002.patch --to=edk2-devel@lists.sourceforge.net --to= 
 someone --to= someone
   git send-email 0003.patch --to=edk2-devel@lists.sourceforge.net --to= 
 someone --to= someone
   git send-email 0004.patch --to=edk2-devel@lists.sourceforge.net --to= 
 someone --to= someone
 *Finally, you just need to run this .bat file.
 
 Thanks.
 Jiaxin
 
 -Original Message-
 From: Justen, Jordan L 
 Sent: Friday, July 10, 2015 4:14 PM
 To: Wu, Jiaxin; edk2-devel@lists.sourceforge.net; af...@apple.com
 Subject: RE: [PATCH v3 3/7] EmulatorPkg: Remove Ip4ConfigDxe module from 
 EmulatorPkg
 
 On 2015-07-10 00:29:18, Wu, Jiaxin wrote:
 I agree your suggested format absolutely. Sorry for my missing any 

Re: [edk2] [PATCH v3 3/7] EmulatorPkg: Remove Ip4ConfigDxe module from EmulatorPkg

[Laszlo Ersek]

On 07/10/15 17:56, Wu, Jiaxin wrote:
 Hi Laszlo,
 Thank you for your wonderful explanation.
 
 You explained before you *did* get a personal copy of the v2. I
 *thought* you got a personal v2 copy *maybe* by setting the specific
 mail filtering rule.
 
 Also as you said it's a terrible practice for edk2-mailing list's
 crazy setting, because followups posted to the *reflected* message
 will have no chance to Cc:  the maintainer! ---Yes! Except the
 followers check the content with Cc: tags carefully, he will do
 miss the Cc people by followups mail.

Correct; if a person is careful enough to look at the Cc: tags in the
message body, and copies the names manually to Cc: headers in his MUA,
then things should work. (And yes, I tend to re-Cc people manually.)

 So, I bothered to send the
 patches to specify the maintainers with “--to==someone” tag to avoid
 this issue. The maintainers and myself(also the others in
 edk2-mailing) *did* get the following headers:

 From: Jiaxin
 To: edk2-devel@lists.sourceforge.net; Someone
 
 That is not only sender and Cc maintainer want, but also the other
 follower's want.

That's a nice workaround I guess (I have not been aware of it, so thanks
for sharing it), but it has several drawbacks:

- You cannot specify different recipients for different patches. If your
patches modify different packages, then that implies different sets of
maintainers too, probably. (Unless, of course, you send each patch email
with a separate invocation of git-send-email, which is quite a mess if
you have longer patch series.)

- If you send v2, v3, v4, you need to remember to include the same set
of people as in the previous version. Whereas, if you stick the Cc into
the commit message, then it stays permanent after a rebase, for the next
version too.

- Including the Cc's in the commit message has additional value:

  - once the patch is committed, the commit message displays that X and
Y and Z were Cc'd. This proves awareness.

  - The commit log can be searched for Cc's. Useful not just for
natural persons, but for pseudo-Cc's as well; for example Jordan
recently suggested to nominate patches as trivial, and as
stable, by Cc'ing them to the edk2-trivial *name*, and the UDK...
*name*, but the usual edk2 email list address. This allows people
to search for patches in the commit log (and the mailing list) that
are candidates for the trivial patch workflow or for the UDK
branch.

 I have another question not verified yet: If we use To: Someone tag
 in commit message instead of Cc: Someone tag, How about
 edk2-mailing list setting? I don't know.

As far as I know, the To: tag inside the commit message is fully
unusual, and I think git-send-email doesn't even recognize it.

So, your initial practice with the Cc: tags was correct.

We shouldn't diverge from otherwise well-working open source practices,
just to work around the brokenness of the list software. The
Cc-stripping problem should be hopefully sorted out once we move to the
new mailing list.

Thank you!
Laszlo

 
 Thanks again.
 Jiaxin
 
 
 -Original Message-
 From: Laszlo Ersek [mailto:ler...@redhat.com] 
 Sent: Friday, July 10, 2015 7:29 PM
 To: Wu, Jiaxin
 Cc: Justen, Jordan L; edk2-devel@lists.sourceforge.net; af...@apple.com
 Subject: Re: [edk2] [PATCH v3 3/7] EmulatorPkg: Remove Ip4ConfigDxe module 
 from EmulatorPkg
 
 On 07/10/15 10:40, Wu, Jiaxin wrote:
 Yes, edk2-devel will strip it. You can check version2 for those series 
 patches, I had added someone with cc tag to the commit message, but it 
 haven't actually cc to those people.
 
 Yes, you did! I *did* get a personal copy of the v2 patches from you!
 
 (And another one from the list server.)
 
 We discussed this earlier. I explained it to you, and I think you missed the 
 point.
 
 The edk2-devel list's settings *cannot* interfere with the Cc headers of the 
 patch email that *you* send out. The list settings can only influence the Cc 
 headers on the emails that the list server *reflects*.
 
 Here's a diagram:
 
 Jiaxin
/  \
   /\
   [Cc: Laszlo]   [To: edk2-devel]
 |  |
 |  |
  Laszlo list server
/   ||  \
   /||   \
   Laszlo Jiaxin |...
   Jordan
 
 Assume the following:
 
 - You write the commit message for your patch, and add Cc: Laszlo to
   the commit message.
 
 - Then you format the patch with git format-patch, and send it with
   git send-email to edk2-devel (To:).
 
 Then the following happens:
 
 (1) The git send-email program will automatically set the Cc: header of the 
 email from the Cc: tag in the commit message

Re: [edk2] [PATCH] OvmfPkg/VirtioLib: Ensure VirtioFlush() is not blocked

[Laszlo Ersek]

On 07/10/15 17:22, Olivier Martin wrote:
 Thanks Lazlo, I had this issue with the ARM FVP Models and its Virtio
 support (see:
 http://infocenter.arm.com/help/topic/com.arm.doc.dui0834a/Chunk446462681.html).
 I do not remember which model version. I am happy to abandon this
 patch until I track down the model version and an action is taken by
 the ARM model team to fix it.

I agree that this would be the best course of action -- in November 2013
or so I reported a virtio bug for the Foundation model (case #566785,
full device reset doesn't reset QueuePFNs), with a reproducer guest
kernel:

http://people.redhat.com/~lersek/arm_case566785_queuepfn_repro/

The model team at ARM fixed the bug for the next release. It was a
positive experience for me.

Thanks!
Laszlo

 
 -Original Message-
 From: Laszlo Ersek [mailto:ler...@redhat.com]
 Sent: 09 July 2015 18:30
 To: Olivier Martin
 Cc: jordan.l.jus...@intel.com; edk2-devel@lists.sourceforge.net
 Subject: Re: [PATCH] OvmfPkg/VirtioLib: Ensure VirtioFlush() is not blocked
 
 On 07/09/15 18:47, Olivier Martin wrote:
 .. in case the platform does not received the used buffer from the
 device, VirtioFlush() returns EFI_TIMEOUT.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Olivier Martin olivier.mar...@arm.com
 ---
  OvmfPkg/Include/Library/VirtioLib.h   |  3 +++
  OvmfPkg/Library/VirtioLib/VirtioLib.c | 16 ++--
  2 files changed, 17 insertions(+), 2 deletions(-)

 diff --git a/OvmfPkg/Include/Library/VirtioLib.h
 b/OvmfPkg/Include/Library/VirtioLib.h
 index 36527a5..62f6811 100644
 --- a/OvmfPkg/Include/Library/VirtioLib.h
 +++ b/OvmfPkg/Include/Library/VirtioLib.h
 @@ -170,6 +170,9 @@ VirtioAppendDesc (

@return  Error code from VirtIo-SetQueueNotify() if it fails.

 +  @retval EFI_TIMEOUT  If it did not received the used buffer from the 
 device
 +   in approximatively less than 10ms
 +
@retval EFI_SUCCESS  Otherwise, the host processed all descriptors.

  **/
 diff --git a/OvmfPkg/Library/VirtioLib/VirtioLib.c
 b/OvmfPkg/Library/VirtioLib/VirtioLib.c
 index 54cf225..566f596 100644
 --- a/OvmfPkg/Library/VirtioLib/VirtioLib.c
 +++ b/OvmfPkg/Library/VirtioLib/VirtioLib.c
 @@ -3,7 +3,7 @@
Utility functions used by virtio device drivers.

Copyright (C) 2012, Red Hat, Inc.
 -  Portion of Copyright (C) 2013, ARM Ltd.
 +  Portion of Copyright (C) 2013-2014, ARM Ltd.

This program and the accompanying materials are licensed and made 
 available
under the terms and conditions of the BSD License which accompanies
 this @@ -252,6 +252,9 @@ VirtioAppendDesc (

@return  Error code from VirtIo-SetQueueNotify() if it fails.

 +  @retval EFI_TIMEOUT  If it did not received the used buffer from the 
 device
 +   in approximatively less than 10ms
 +
@retval EFI_SUCCESS  Otherwise, the host processed all descriptors.

  **/
 @@ -267,6 +270,7 @@ VirtioFlush (
UINT16 NextAvailIdx;
EFI_STATUS Status;
UINTN  PollPeriodUsecs;
 +  UINTN  Timeout;

//
// virtio-0.9.5, 2.4.1.2 Updating the Available Ring @@ -304,16
 +308,24 @@ VirtioFlush (
// Keep slowing down until we reach a poll period of slightly above 1 ms.
//
PollPeriodUsecs = 1;
 +  Timeout = 0;
MemoryFence();
 -  while (*Ring-Used.Idx != NextAvailIdx) {
 +  while ((*Ring-Used.Idx != NextAvailIdx)  (Timeout  10)) {
  gBS-Stall (PollPeriodUsecs); // calls
 AcpiTimerLib::MicroSecondDelay

  if (PollPeriodUsecs  1024) {
PollPeriodUsecs *= 2;
 +} else {
 +  Timeout++;
  }
  MemoryFence();
}

MemoryFence();
 +
 +  if (Timeout == 10) {
 +return EFI_TIMEOUT;
 +  }
 +
return EFI_SUCCESS;
  }

 
 I think if this ever happens, that's a bug in the host / hypervisor.
 Under what conditions are you seeing this as necessary?
 
 VirtioFlush() blocks infinitely on purpose in this loop. The protocol does 
 not define any circumstances for timeout. The communicating peers are not 
 connected by a fragile network link, they are connected by host memory. 
 Whenever you time out, that's an arbitrary decision; it might even misfire 
 dependent on host load.
 
 If you think this is really necessary, then please introduce an integer PCD. 
 The default value of the PCD (probably 0) should preserve existing behavior. 
 The PCD should be then overridden by downstreams (by directly editing the 
 appropriate DSC file). Alternatively, if you have a specific host platform in 
 mind that necessitates this change (and for which the value 10 also seems 
 right), then please introduce a new build flag as well (in the affected 
 DSC(s)). People who build for that platform can then hardcode that flag in 
 their build scripts.
 
 There are two users of VirtioFlush(): the virtio-blk and virtio-scsi drivers. 
 Both check for (and propagate) any errors returned by
 VirtioFlush() correctly. Any timeout error would reach the outermost

Re: [edk2] [PATCH v3 3/7] EmulatorPkg: Remove Ip4ConfigDxe module from EmulatorPkg

[Laszlo Ersek]

On 07/10/15 18:36, Jordan Justen wrote:
 On 2015-07-10 04:29:11, Laszlo Ersek wrote:
 On 07/10/15 10:40, Wu, Jiaxin wrote:
 Yes, edk2-devel will strip it. You can check version2 for those
 series patches, I had added someone with cc tag to the commit
 message, but it haven't actually cc to those people.

 (3) Laszlo will get a copy directly from you, and another copy
 *reflected* from the mailing list server. (Laszlo has mail filters in
 place that file the direct copy into his INBOX, and the reflected copy
 into his edk2-devel folder.)

 The copy that Laszlo directly gets from Jiaxin will have the following
 headers:

   From: Jiaxin
   To: edk2-devel
   Cc: Laszlo

 The copy that Laszlo gets from the mailing list server will have the
 following headers:

   From: Jiaxin
   To: edk2-devel

 This is because the mailing list server is *stupid*. It sees, in its
 internal database, that Laszlo is subscribed, and therefore thinks
 (completely incorrectly) that Laszlo should not be Cc:-d on messages
 reflected from the list, because he gets them anyway.
 
 I found that mailman has a 'nodupes' setting that causes the Cc
 stripping. I've disabled it for the new edk2-devel list. Hopefully
 that is the setting we want...

I do know about a similarly named mailman feature. It is related, but
not the same thing.

The nodupes setting (if it is indeed the one I have in mind, and have
used several times before) controls whether the mailing list software
*reflects* the message to someone at all.

That is, in bullet (3) above, with nodupes=off, Laszlo gets two copies
(one from Jiaxin directly, and another from the list). With nodupes=on,
Laszlo would get *no* copy from the list -- the list software would see
that Laszlo was Cc'd on the original message, and therefore forego
reflecting the message to Laszlo *at all*.

Obviously, this would wreak havoc with Laszlo's email filters; those
really depend on getting *two* copies. But, others like to get one copy
only, under similar circumstances. This is why, in my understanding, the
nodupes setting is actually subscriber-level: the list may have a
top-level default, but each subscriber can change that setting for
himself, after logging in with his password on the list web GUI.

So, I very much agree that the nodupes default should be off for the
new list.

However, the current list has a different problem. It does work
correctly as far as nodupes=off is concerned (ie. it does reflect
messages to originally Cc'd people as well). The problem is that it
mangles those reflected messages: it strips the Cc fields that designate
subscribers.

 Unfortunately, disabling it on the current list would be a hassle.

I guess. :)

... Apologies about the verbiage.

Thanks!
Laszlo


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools: aarch64: add -fno-asynchronous-unwind-tables to gcc cflags

[Laszlo Ersek]

On 07/09/15 15:47, Leif Lindholm wrote:
 Some toolchains, at least Fedora GCC, generate inline unwind tables in
 object files. These confuses GenFw to no end, leading to build failures:
   GenFw: ERROR 3000: Invalid WriteSections64(): ...
  unsupported ELF EM_AARCH64 relocation 0x105.
   GenFw: ERROR 3000: Invalid WriteSections64(): ...
  unsupported ELF EM_AARCH64 relocation 0x0.
 
 I am aware of no current use of these tables, so explicitly disable
 their generation for aarch64.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Leif Lindholm leif.lindh...@linaro.org
 ---
  BaseTools/Conf/tools_def.template | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/BaseTools/Conf/tools_def.template 
 b/BaseTools/Conf/tools_def.template
 index 7edd759..8e5750e 100644
 --- a/BaseTools/Conf/tools_def.template
 +++ b/BaseTools/Conf/tools_def.template
 @@ -3818,7 +3818,7 @@ DEFINE GCC_IA32_CC_FLAGS   = 
 DEF(GCC_ALL_CC_FLAGS) -m32 -malign-double -
  DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone 
 -Wno-address -mno-stack-arg-probe
  DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
 -minline-int-divide-min-latency
  DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
 -mword-relocations -mlittle-endian -mabi=aapcs -mapcs -fno-short-enums 
 -save-temps -fsigned-char -ffunction-sections -fdata-sections 
 -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
 -DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mcmodel=large 
 -mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char  
 -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin 
 -Wno-address
 +DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mcmodel=large 
 -mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char  
 -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin 
 -Wno-address -fno-asynchronous-unwind-tables
  DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
  DEFINE GCC_IA32_X64_DLINK_COMMON   = DEF(GCC_DLINK_FLAGS_COMMON) 
 --gc-sections
  DEFINE GCC_ARM_AARCH64_DLINK_COMMON= --emit-relocs -nostdlib --gc-sections 
 -u $(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map 
 $(DEST_DIR_DEBUG)/$(BASE_NAME).map
 

Am I right to think this is a verbatim repost from

  http://thread.gmane.org/gmane.comp.bios.tianocore.devel/12482

? If so, then I think Olivier should review it and then just go ahead
and commit it, preferably with:

Tested-by: Wei Huang w...@redhat.com

based on Wei's message with Message-Id 54f740b4.3050...@redhat.com.

Unfortunately I can't find that email at the moment in the gmane
archive, but I'm attaching it.

Thanks
Laszlo
---BeginMessage---
I can confirm that this patch fixes my problem. The machine is a native
AArch64 server, with Fedora GCC 4.8.3.

Thanks,
-Wei

On 03/04/2015 03:13 AM, Laszlo Ersek wrote:
 On 02/06/15 14:52, Leif Lindholm wrote:
 Some toolchains, at least Fedora GCC, generate inline unwind tables in
 object files. These confuses GenFw to no end, leading to build failures:
   GenFw: ERROR 3000: Invalid WriteSections64(): ...
  unsupported ELF EM_AARCH64 relocation 0x105.
   GenFw: ERROR 3000: Invalid WriteSections64(): ...
  unsupported ELF EM_AARCH64 relocation 0x0.

 I am aware of no current use of these tables, so explicitly disable
 their generation for aarch64.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Leif Lindholm leif.lindh...@linaro.org
 ---
  BaseTools/Conf/tools_def.template | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/BaseTools/Conf/tools_def.template 
 b/BaseTools/Conf/tools_def.template
 index f008024..04fdeba 100644
 --- a/BaseTools/Conf/tools_def.template
 +++ b/BaseTools/Conf/tools_def.template
 @@ -3817,7 +3817,7 @@ DEFINE GCC_IA32_CC_FLAGS   = 
 DEF(GCC_ALL_CC_FLAGS) -m32 -malign-double -
  DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone 
 -Wno-address -mno-stack-arg-probe
  DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
 -minline-int-divide-min-latency
  DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
 -mword-relocations -mlittle-endian -mabi=aapcs -mapcs -fno-short-enums 
 -save-temps -fsigned-char -ffunction-sections -fdata-sections 
 -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
 -DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mcmodel=large 
 -mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char  
 -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin 
 -Wno-address
 +DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mcmodel=large 
 -mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char  
 -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin 
 -Wno-address -fno-asynchronous-unwind-tables
  DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
  DEFINE

Re: [edk2] [PATCH] OvmfPkg/VirtioLib: Ensure VirtioFlush() is not blocked

[Laszlo Ersek]

On 07/09/15 18:47, Olivier Martin wrote:
 .. in case the platform does not received the used buffer from the
 device, VirtioFlush() returns EFI_TIMEOUT.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Olivier Martin olivier.mar...@arm.com
 ---
  OvmfPkg/Include/Library/VirtioLib.h   |  3 +++
  OvmfPkg/Library/VirtioLib/VirtioLib.c | 16 ++--
  2 files changed, 17 insertions(+), 2 deletions(-)
 
 diff --git a/OvmfPkg/Include/Library/VirtioLib.h 
 b/OvmfPkg/Include/Library/VirtioLib.h
 index 36527a5..62f6811 100644
 --- a/OvmfPkg/Include/Library/VirtioLib.h
 +++ b/OvmfPkg/Include/Library/VirtioLib.h
 @@ -170,6 +170,9 @@ VirtioAppendDesc (
  
@return  Error code from VirtIo-SetQueueNotify() if it fails.
  
 +  @retval EFI_TIMEOUT  If it did not received the used buffer from the device
 +   in approximatively less than 10ms
 +
@retval EFI_SUCCESS  Otherwise, the host processed all descriptors.
  
  **/
 diff --git a/OvmfPkg/Library/VirtioLib/VirtioLib.c 
 b/OvmfPkg/Library/VirtioLib/VirtioLib.c
 index 54cf225..566f596 100644
 --- a/OvmfPkg/Library/VirtioLib/VirtioLib.c
 +++ b/OvmfPkg/Library/VirtioLib/VirtioLib.c
 @@ -3,7 +3,7 @@
Utility functions used by virtio device drivers.
  
Copyright (C) 2012, Red Hat, Inc.
 -  Portion of Copyright (C) 2013, ARM Ltd.
 +  Portion of Copyright (C) 2013-2014, ARM Ltd.
  
This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License which accompanies this
 @@ -252,6 +252,9 @@ VirtioAppendDesc (
  
@return  Error code from VirtIo-SetQueueNotify() if it fails.
  
 +  @retval EFI_TIMEOUT  If it did not received the used buffer from the device
 +   in approximatively less than 10ms
 +
@retval EFI_SUCCESS  Otherwise, the host processed all descriptors.
  
  **/
 @@ -267,6 +270,7 @@ VirtioFlush (
UINT16 NextAvailIdx;
EFI_STATUS Status;
UINTN  PollPeriodUsecs;
 +  UINTN  Timeout;
  
//
// virtio-0.9.5, 2.4.1.2 Updating the Available Ring
 @@ -304,16 +308,24 @@ VirtioFlush (
// Keep slowing down until we reach a poll period of slightly above 1 ms.
//
PollPeriodUsecs = 1;
 +  Timeout = 0;
MemoryFence();
 -  while (*Ring-Used.Idx != NextAvailIdx) {
 +  while ((*Ring-Used.Idx != NextAvailIdx)  (Timeout  10)) {
  gBS-Stall (PollPeriodUsecs); // calls AcpiTimerLib::MicroSecondDelay
  
  if (PollPeriodUsecs  1024) {
PollPeriodUsecs *= 2;
 +} else {
 +  Timeout++;
  }
  MemoryFence();
}
  
MemoryFence();
 +
 +  if (Timeout == 10) {
 +return EFI_TIMEOUT;
 +  }
 +
return EFI_SUCCESS;
  }
 

I think if this ever happens, that's a bug in the host / hypervisor.
Under what conditions are you seeing this as necessary?

VirtioFlush() blocks infinitely on purpose in this loop. The protocol
does not define any circumstances for timeout. The communicating peers
are not connected by a fragile network link, they are connected by host
memory. Whenever you time out, that's an arbitrary decision; it might
even misfire dependent on host load.

If you think this is really necessary, then please introduce an integer
PCD. The default value of the PCD (probably 0) should preserve existing
behavior. The PCD should be then overridden by downstreams (by directly
editing the appropriate DSC file). Alternatively, if you have a specific
host platform in mind that necessitates this change (and for which the
value 10 also seems right), then please introduce a new build flag as
well (in the affected DSC(s)). People who build for that platform can
then hardcode that flag in their build scripts.

There are two users of VirtioFlush(): the virtio-blk and virtio-scsi
drivers. Both check for (and propagate) any errors returned by
VirtioFlush() correctly. Any timeout error would reach the outermost
callers (the respective protocol users) just fine. So those parts of the
tree need not be fixed up, I agree. Still, this patch would work around
a host bug, as far as I understand, and the actual timeout looks
arbitrary, so it should be off by default, and controllable without
modifying the C source.

The commit message (and the PCD's comment) should also identify the host
platform that requires this as precisely as possible.

... Obviously, it is *also* possible that the guest code has some other
bug, elsewhere. (We can never exclude that, unless we prove the code
correct with formal tools.) It seems quite unlikely, but if that's the
case, then I'd prefer to track it down and fix it, instead of papering
it over.

Thanks!
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud 

Re: [edk2] [Patch] OvmfPkg: Fix GCC49 build hang in PeiCore

[Laszlo Ersek]

On 07/09/15 09:13, Ruiyu Ni wrote:
 PeiCore hang when loads a PEIM whose section alignment requirement is
 0x40 but the actual base address is 0x20 aligned.

Thank you very much for tracking this down!

However, can you please describe the analysis (that you must have
certainly done to identify the bug!) in the commit message? (If that's
too much of a chore, then please just explain it to me in detail, and
I'll write up the commit message.)

I guess that means that the exact location in the PeiCore source should
be identified that blows up, plus, can you please say where the section
alignment requirement comes from?

Thanks!
Laszlo

 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ruiyu Ni ruiyu...@intel.com
 Reviewed-by: Liming Gao liming@intel.com
 ---
  OvmfPkg/OvmfPkgIa32.fdf| 4 ++--
  OvmfPkg/OvmfPkgIa32X64.fdf | 4 ++--
  OvmfPkg/OvmfPkgX64.fdf | 4 ++--
  3 files changed, 6 insertions(+), 6 deletions(-)
 
 diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
 index 24ad0bf..d11325e 100644
 --- a/OvmfPkg/OvmfPkgIa32.fdf
 +++ b/OvmfPkg/OvmfPkgIa32.fdf
 @@ -389,7 +389,7 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
  
  [Rule.Common.PEI_CORE]
FILE PEI_CORE = $(NAMED_GUID) {
 -PE32 PE32   Align=32$(INF_OUTPUT)/$(MODULE_NAME).efi
 +PE32 PE32   Align=Auto$(INF_OUTPUT)/$(MODULE_NAME).efi
  UI   STRING =$(MODULE_NAME) Optional
  VERSION  STRING =$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 @@ -397,7 +397,7 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
  [Rule.Common.PEIM]
FILE PEIM = $(NAMED_GUID) {
   PEI_DEPEX PEI_DEPEX Optional$(INF_OUTPUT)/$(MODULE_NAME).depex
 - PE32  PE32   Align=32   $(INF_OUTPUT)/$(MODULE_NAME).efi
 + PE32  PE32   Align=Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
   UI   STRING=$(MODULE_NAME) Optional
   VERSION  STRING=$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
 index 5f98be8..015aca4 100644
 --- a/OvmfPkg/OvmfPkgIa32X64.fdf
 +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
 @@ -389,7 +389,7 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
  
  [Rule.Common.PEI_CORE]
FILE PEI_CORE = $(NAMED_GUID) {
 -PE32 PE32   Align=32$(INF_OUTPUT)/$(MODULE_NAME).efi
 +PE32 PE32   Align=Auto$(INF_OUTPUT)/$(MODULE_NAME).efi
  UI   STRING =$(MODULE_NAME) Optional
  VERSION  STRING =$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 @@ -397,7 +397,7 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
  [Rule.Common.PEIM]
FILE PEIM = $(NAMED_GUID) {
   PEI_DEPEX PEI_DEPEX Optional$(INF_OUTPUT)/$(MODULE_NAME).depex
 - PE32  PE32   Align=32   $(INF_OUTPUT)/$(MODULE_NAME).efi
 + PE32  PE32   Align=Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
   UI   STRING=$(MODULE_NAME) Optional
   VERSION  STRING=$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
 index 11e74e7..f43d3dd 100644
 --- a/OvmfPkg/OvmfPkgX64.fdf
 +++ b/OvmfPkg/OvmfPkgX64.fdf
 @@ -389,7 +389,7 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
  
  [Rule.Common.PEI_CORE]
FILE PEI_CORE = $(NAMED_GUID) {
 -PE32 PE32   Align=32$(INF_OUTPUT)/$(MODULE_NAME).efi
 +PE32 PE32   Align=Auto$(INF_OUTPUT)/$(MODULE_NAME).efi
  UI   STRING =$(MODULE_NAME) Optional
  VERSION  STRING =$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 @@ -397,7 +397,7 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
  [Rule.Common.PEIM]
FILE PEIM = $(NAMED_GUID) {
   PEI_DEPEX PEI_DEPEX Optional$(INF_OUTPUT)/$(MODULE_NAME).depex
 - PE32  PE32   Align=32   $(INF_OUTPUT)/$(MODULE_NAME).efi
 + PE32  PE32   Align=Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
   UI   STRING=$(MODULE_NAME) Optional
   VERSION  STRING=$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH V3 4/5] Add PCD for selecting terminal type at build time

[Laszlo Ersek]

On 07/09/15 08:45, Paolo Bonzini wrote:
 
 
 On 08/07/2015 23:03, Laszlo Ersek wrote:
 On 07/08/15 22:36, Ryan Harkin wrote:

 I have an alias in my ~/.gitconfig file:

 [alias]
 amm=am --ignore-whitespace --ignore-space-change


 Then I use git amm to apply patches and that seems to work most of the
 time.

 But I suspect your method is doing something smarter and more complex
 whereas mine is more brute force.

 Right. Your command is perfect for ad-hoc testing, but it ignores more
 whitespace than what would be acceptable for actually committing a patch
 to SVN. For example, it would enable source files to become mixed LF and
 CRLF, I think. (Because:
 - git-am would strip all \r characters from the patch email,
 - ignore the resultant LF - CRLF mismatch in the hunks' contexts,
 - and add the new lines with LF only.)

 BTW, Paolo had written code for git at some point that fixed this issue
 within git:

 http://thread.gmane.org/gmane.comp.version-control.git/260215
 
 This was included in git 2.3.0. :)

Yay! \o/

Thank you! :)
Laszlo

 
 Paolo
 
 His idea was to armor patch emails against line terminator changes
 incurred by MTAs. (Which is what makes the sed command necessary in my
 method, for the /dev/null hunk headers.)

 Although the quoted-printable and base64 transfer encodings, used for
 such protection, would have resulted in human-*un*readable raw email
 files, Paolo suggested a one liner back-converter for those who like to
 save patch emails to regular files, for comparing them between each
 other. The results would have been very useful: git-am would just
 work, and people comparing raw patches could rely on a one-liner in
 their workflow.

 Alas, I'm unsure about the fate of Paolo's work. I think he didn't have
 time to work on further versions of the patch set, and I had neither the
 time nor the expertise.

 Thanks!
 Laszlo



--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v3 2/7] ArmVirtPkg: Remove Ip4ConfigDxe module from ArmVirtPkg

[Laszlo Ersek]

On 07/09/15 09:24, Jiaxin Wu wrote:
 Version3 continue to update with a proper commit message.
 Ip4ConfigDxe driver is deprecated in UEFI 2.5, so we will not support 
 original Ip4Config Protocol, which is replace by Ip4Config2 Protocol 
 integrated in Ip4Dxe driver(git commit 1f6729ff (SVN r17853)).Therefore we 
 can remove Ip4ConfigDxe driver from this build.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Jiaxin Wu jiaxin...@intel.com
 ---
  ArmVirtPkg/ArmVirt.dsc.inc | 1 -
  ArmVirtPkg/ArmVirtQemu.fdf | 1 -
  2 files changed, 2 deletions(-)
 
 diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
 index 16d7ea6..70e3592 100644
 --- a/ArmVirtPkg/ArmVirt.dsc.inc
 +++ b/ArmVirtPkg/ArmVirt.dsc.inc
 @@ -367,11 +367,10 @@
# Networking stack
#
MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
 -  MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
 diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
 index e822fdf..4448018 100644
 --- a/ArmVirtPkg/ArmVirtQemu.fdf
 +++ b/ArmVirtPkg/ArmVirtQemu.fdf
 @@ -181,11 +181,10 @@ READ_LOCK_STATUS   = TRUE
# Networking stack
#
INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
 -  INF MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
 

Reviewed-by: Laszlo Ersek ler...@redhat.com

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch V2] OvmfPkg: Fix GCC49 build hang in PeiCore

[Laszlo Ersek]

On 07/09/15 10:06, Ruiyu Ni wrote:
 PeiCore hang when loads a PEIM whose section alignment requirement is
 0x40 but the actual base address is 0x20 aligned.

 The issue is caused by the following facts, in order:

 1. GCC49 requires the section alignment of .data to be 0x40. So a new
 link script gcc4.9-ld-script was added for GCC49 to specify the 0x40
 alignment.

 2. GenFw tool was enhanced to sync ELF's section alignment to PE
 header. Before the enhancement, the section alignment of converted PE
 image always equals to 0x20.
 
 If only with #1 change, GCC49 build image won't hang in PeiCore
 because the converted PE image still claims 0x20 section alignment
 which is aligned to the align setting set in FDF file. But later with
 #2 change, the converted PE image starts to claims 0x40 section
 alignment, while build tool still puts the PEIM in 0x20 aligned
 address, resulting the PeCoffLoaderLoadImage() reports
 IMAGE_ERROR_INVALID_SECTION_ALIGNMENT error.

Perfect!

So, ultimately, the alignment at which the build tool places the PEI
modules, controlled by the Align=... directive, must satisfy the
alignment that the PE header itself states. And currently, the alignment
in the PE header comes from the ELF linker script, because the updated
GenFw tool sets the PE header based on the ELF values.

Therefore the Align=... directive in the FDF rules must match the
alignment in the ELF linker script. And, apparently, the simplest way to
ensure this is to convince the build tool to grab the PEIMs alignment
from the PE header, with Align=Auto.

Now the question emerges if *other* module rules in the OVMF FDF files
should see their Align=... directives updated. However, there are no
other Align=... directives; the patch updates them all (apparently only
PEI_CORE and PEIM rules spell out Align=whatever).

Superb work!

Reviewed-by: Laszlo Ersek ler...@redhat.com

I'm going to commit your patch right away (I'll just rewrap the commit
message to 74 characters first).

Thank you!
Laszlo

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ruiyu Ni ruiyu...@intel.com
 Reviewed-by: Liming Gao liming@intel.com
 ---
  OvmfPkg/OvmfPkgIa32.fdf| 4 ++--
  OvmfPkg/OvmfPkgIa32X64.fdf | 4 ++--
  OvmfPkg/OvmfPkgX64.fdf | 4 ++--
  3 files changed, 6 insertions(+), 6 deletions(-)
 
 diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
 index 24ad0bf..d11325e 100644
 --- a/OvmfPkg/OvmfPkgIa32.fdf
 +++ b/OvmfPkg/OvmfPkgIa32.fdf
 @@ -389,7 +389,7 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
  
  [Rule.Common.PEI_CORE]
FILE PEI_CORE = $(NAMED_GUID) {
 -PE32 PE32   Align=32$(INF_OUTPUT)/$(MODULE_NAME).efi
 +PE32 PE32   Align=Auto$(INF_OUTPUT)/$(MODULE_NAME).efi
  UI   STRING =$(MODULE_NAME) Optional
  VERSION  STRING =$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 @@ -397,7 +397,7 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
  [Rule.Common.PEIM]
FILE PEIM = $(NAMED_GUID) {
   PEI_DEPEX PEI_DEPEX Optional$(INF_OUTPUT)/$(MODULE_NAME).depex
 - PE32  PE32   Align=32   $(INF_OUTPUT)/$(MODULE_NAME).efi
 + PE32  PE32   Align=Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
   UI   STRING=$(MODULE_NAME) Optional
   VERSION  STRING=$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
 index 5f98be8..015aca4 100644
 --- a/OvmfPkg/OvmfPkgIa32X64.fdf
 +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
 @@ -389,7 +389,7 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
  
  [Rule.Common.PEI_CORE]
FILE PEI_CORE = $(NAMED_GUID) {
 -PE32 PE32   Align=32$(INF_OUTPUT)/$(MODULE_NAME).efi
 +PE32 PE32   Align=Auto$(INF_OUTPUT)/$(MODULE_NAME).efi
  UI   STRING =$(MODULE_NAME) Optional
  VERSION  STRING =$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 @@ -397,7 +397,7 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
  [Rule.Common.PEIM]
FILE PEIM = $(NAMED_GUID) {
   PEI_DEPEX PEI_DEPEX Optional$(INF_OUTPUT)/$(MODULE_NAME).depex
 - PE32  PE32   Align=32   $(INF_OUTPUT)/$(MODULE_NAME).efi
 + PE32  PE32   Align=Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
   UI   STRING=$(MODULE_NAME) Optional
   VERSION  STRING=$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
 index 11e74e7..f43d3dd 100644
 --- a/OvmfPkg/OvmfPkgX64.fdf
 +++ b/OvmfPkg/OvmfPkgX64.fdf
 @@ -389,7 +389,7 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
  
  [Rule.Common.PEI_CORE]
FILE PEI_CORE = $(NAMED_GUID) {
 -PE32 PE32   Align=32$(INF_OUTPUT)/$(MODULE_NAME).efi
 +PE32 PE32   Align=Auto$(INF_OUTPUT)/$(MODULE_NAME).efi
  UI   STRING =$(MODULE_NAME) Optional
  VERSION  STRING =$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 @@ -397,7

Re: [edk2] [PATCH V4 0/5] Add TtyTerm terminal type

[Laszlo Ersek]

On 07/08/15 21:02, Roy Franz wrote:
 This patchset adds a new terminal type TtyTerm, that better handles the
 typical Linux terminal (xterm/rxvt/gnome terminal/tmux/screen/etc.) These 
 often
 treat backspace/delete differently than the existing EDK2 terminal types
 expect, particularly in emulated environments where the emulated serial port 
 is
 connected to a graphical terminal rather than a serial console.  Some 
 terminals
 use a mix of vt100 and vt200 escape codes for function key handling.  Adding
 vt220 function key support fixes the use of F10 to save changes in BDS
 configuration menus.
 
 This patchset includes changes to make the terminal type build time 
 configurable
 for the QEMU Aarch64 configuration.  Once this patchset goes in I will submit
 patches for the other emulated ARM platforms as appropriate.
 
 Note: While working on the function keys, I could not find any documentation
 that matched the code/comments in TerminalConIn.c regarding VT100 function
 keys.  The VT100 only had 4 function keys (PF1-PF4), which are generally 
 mapped
 to F1-F4.  In the code, F3/F4 don't match the VT100 documentation I found, and
 I have no idea where the values for F5-F10 are from.  I left the existing
 VT100 terminal type escape code handling unchanged.
 
 This patchset is also available as the ttyterm-v4 branch on
 https://git.linaro.org/people/roy.franz/linaro-edk2.git
 
 Changes since v3:
 * Convert !ifdef to !if for TTY_TERMINAL and INTEL_BDS defines (patch 5/5)
 
 Changes since v2:
 * Comment typo fixes, contrib ordering fixes
 * Moved static ttyTerm escape state variables to TerminalDevice structure
 * Add support for changing terminal type on ARM BDS QEMU build (new patch 5/5)
 * Add reviewed-by lines. (not to patch 3 that had changes)
 
 Changes since v1:
 * Added handling of VT220 escape codes for function keys
 * Fixed attribution PCD patch
 * Removed '[' from patch 3 description line
 
 Changes from Linuxterm RFC patchset:
 * Change to ttyTerm name - nothing linux specific in patchset
 * remove changes to Mde module, as changes not part of UEFI specification
 
 Laszlo Ersek (1):
   Add PCD for selecting terminal type at build time
 
 Roy Franz (4):
   Add TtyTerm terminal type to TerminalDxe
   Treat ASCII 0x7F as backspace for TtyTerm terminals
   Accept VT220 DEL and function keys for TTY terminal type
   add TTY_TERMINAL build option for ARM BDS
 
  ArmVirtPkg/ArmVirt.dsc.inc |   6 ++
  ArmVirtPkg/ArmVirtPkg.dec  |   7 ++
  ArmVirtPkg/ArmVirtQemu.dsc |  11 +-
  ArmVirtPkg/ArmVirtQemu.fdf |   4 +-
  ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c  |  12 ++-
  ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf |   4 +
  MdeModulePkg/Include/Guid/TtyTerm.h|  25 +
  MdeModulePkg/MdeModulePkg.dec  |   3 +
  MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c  |  50 
 +++--
  MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h  |   5 +
  MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c | 107 
 +++-
  MdeModulePkg/Universal/Console/TerminalDxe/TerminalConOut.c|   2 +
  MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf |   1 +
  13 files changed, 217 insertions(+), 20 deletions(-)
  create mode 100644 MdeModulePkg/Include/Guid/TtyTerm.h
 

In patch #1, some (trivial) context differences were automatically
resolved by git-am.

Patches #2 and #3 applied cleanly.

Patch #4 did not apply. (I guess I could have fetched your remote branch
and rebased the set with git-rebase, instead of using git am, but your
tree seems to be based on the linaro-edk2 fork anyway, just from the URL
above, so the difference could have been too large even that way. Next
time please consider rebasing to upstream master before posting.)

In any case, I re-ran git-am with the --reject flag for patch #4, then
looked at the rejected hunks and resolved them manually. (Then used
git-add and git-am --resolved.) There was one conflict in
ArmVirtPkg/ArmVirt.dsc.inc, due to fresh upstream commits 093b7c87 and
e109e3fe.

Patch #5 applied cleanly.

The series has been committed to SVN as r17895..r17899.

Thanks
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v3 5/7] OvmfPkg: Remove Ip4ConfigDxe module from OvmfPkg

[Laszlo Ersek]

 FREEFORM = 
 PCD(gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLogoFile) {
INF  MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
INF  MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
INF  MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
INF  MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
INF  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
 -  INF  MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
INF  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
INF  MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
INF  MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
  !if $(NETWORK_IP6_ENABLE) == TRUE
INF  NetworkPkg/Ip6Dxe/Ip6Dxe.inf
 

Reviewed-by: Laszlo Ersek ler...@redhat.com

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v3 7/7] MdeModulePkg: Remove Ip4ConfigDxe and related guid definition

[Laszlo Ersek]

On 07/09/15 09:25, Jiaxin Wu wrote:
 Version3 continue to update with a proper commit message.
 
 Ip4ConfigDxe driver is deprecated in UEFI 2.5, so we will not support 
 original Ip4Config Protocol, which is replace by Ip4Config2 Protocol 
 integrated in Ip4Dxe driver(git commit 1f6729ff (SVN r17853)).
 
 Dependent network drivers, libraries and applications have been migrated to 
 (or extended to) the new protocol version.
 For example:
 git 7c25b7ea (SVN r17869): ping  ifconfig
 git 00a6ad1b (SVN r17870): UefiHandleParsingLib
 git 6c5c70d6 (SVN r17873): DxeNetLib
 git 39561686 (SVN r17874): IpSecDxe
 git c581e503 (SVN r17875): EfiSocketLib
 
 This patch is based on related packages(MdeModulePkg, Nt32Pkg,  
 ArmPlatformPkg, ArmVirtPkg, EmulatorPkg, OvmfPkg, Vlv2TbltDevicePkg) clean-up 
 work finished.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Jiaxin Wu jiaxin...@intel.com
 ---
  MdeModulePkg/Include/Guid/Ip4ConfigHii.h   |  25 -
  MdeModulePkg/Include/Guid/NicIp4ConfigNvData.h |  70 --
  MdeModulePkg/MdeModulePkg.dec  |   6 -
  MdeModulePkg/MdeModulePkg.dsc  |   1 -
  .../Universal/Network/Ip4ConfigDxe/ComponentName.c | 165 
  .../Universal/Network/Ip4ConfigDxe/Ip4Config.c | 745 -
  .../Universal/Network/Ip4ConfigDxe/Ip4Config.h | 533 
  .../Network/Ip4ConfigDxe/Ip4ConfigDriver.c | 505 
  .../Network/Ip4ConfigDxe/Ip4ConfigDxe.inf  |  91 ---
  .../Network/Ip4ConfigDxe/Ip4ConfigDxe.uni  | Bin 2700 - 0 bytes
  .../Network/Ip4ConfigDxe/Ip4ConfigDxe.vfr  |  89 --
  .../Network/Ip4ConfigDxe/Ip4ConfigDxeExtra.uni | Bin 1366 - 0 bytes
  .../Network/Ip4ConfigDxe/Ip4ConfigDxeStrings.uni   | Bin 3000 - 0 bytes
  .../Universal/Network/Ip4ConfigDxe/Ip4ConfigNv.c   | 909 
 -
  .../Universal/Network/Ip4ConfigDxe/Ip4ConfigNv.h   |  54 --
  .../Universal/Network/Ip4ConfigDxe/Ip4NvData.h |  48 --
  .../Network/Ip4ConfigDxe/NicIp4Variable.c  | 319 
  .../Network/Ip4ConfigDxe/NicIp4Variable.h  | 104 ---
  18 files changed, 3664 deletions(-)
  delete mode 100644 MdeModulePkg/Include/Guid/Ip4ConfigHii.h
  delete mode 100644 MdeModulePkg/Include/Guid/NicIp4ConfigNvData.h
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/ComponentName.c
  delete mode 100644 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4Config.c
  delete mode 100644 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4Config.h
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDriver.c
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.uni
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.vfr
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxeExtra.uni
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxeStrings.uni
  delete mode 100644 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigNv.c
  delete mode 100644 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigNv.h
  delete mode 100644 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4NvData.h
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/NicIp4Variable.c
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/NicIp4Variable.h

Reviewed-by: Laszlo Ersek ler...@redhat.com


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch V2] OvmfPkg: Fix GCC49 build hang in PeiCore

[Laszlo Ersek]

Committed as SVN r17902.

Thanks!
Laszlo

On 07/09/15 10:06, Ruiyu Ni wrote:
 PeiCore hang when loads a PEIM whose section alignment requirement is 0x40 
 but the actual base address is 0x20 aligned.
 The issue is caused by the following facts, in order:
 1. GCC49 requires the section alignment of .data to be 0x40. So a new link 
 script gcc4.9-ld-script was added for GCC49 to specify the 0x40 alignment.
 2. GenFw tool was enhanced to sync ELF's section alignment to PE header. 
 Before the enhancement, the section alignment of converted PE image always 
 equals to 0x20.
 
 If only with #1 change, GCC49 build image won't hang in PeiCore because the 
 converted PE image still claims 0x20 section alignment which is aligned to 
 the align setting set in FDF file. But later with #2 change, the converted PE 
 image starts to claims 0x40 section alignment, while build tool still puts 
 the PEIM in 0x20 aligned address, resulting the PeCoffLoaderLoadImage() 
 reports IMAGE_ERROR_INVALID_SECTION_ALIGNMENT error.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ruiyu Ni ruiyu...@intel.com
 Reviewed-by: Liming Gao liming@intel.com
 ---
  OvmfPkg/OvmfPkgIa32.fdf| 4 ++--
  OvmfPkg/OvmfPkgIa32X64.fdf | 4 ++--
  OvmfPkg/OvmfPkgX64.fdf | 4 ++--
  3 files changed, 6 insertions(+), 6 deletions(-)
 
 diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
 index 24ad0bf..d11325e 100644
 --- a/OvmfPkg/OvmfPkgIa32.fdf
 +++ b/OvmfPkg/OvmfPkgIa32.fdf
 @@ -389,7 +389,7 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
  
  [Rule.Common.PEI_CORE]
FILE PEI_CORE = $(NAMED_GUID) {
 -PE32 PE32   Align=32$(INF_OUTPUT)/$(MODULE_NAME).efi
 +PE32 PE32   Align=Auto$(INF_OUTPUT)/$(MODULE_NAME).efi
  UI   STRING =$(MODULE_NAME) Optional
  VERSION  STRING =$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 @@ -397,7 +397,7 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
  [Rule.Common.PEIM]
FILE PEIM = $(NAMED_GUID) {
   PEI_DEPEX PEI_DEPEX Optional$(INF_OUTPUT)/$(MODULE_NAME).depex
 - PE32  PE32   Align=32   $(INF_OUTPUT)/$(MODULE_NAME).efi
 + PE32  PE32   Align=Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
   UI   STRING=$(MODULE_NAME) Optional
   VERSION  STRING=$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
 index 5f98be8..015aca4 100644
 --- a/OvmfPkg/OvmfPkgIa32X64.fdf
 +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
 @@ -389,7 +389,7 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
  
  [Rule.Common.PEI_CORE]
FILE PEI_CORE = $(NAMED_GUID) {
 -PE32 PE32   Align=32$(INF_OUTPUT)/$(MODULE_NAME).efi
 +PE32 PE32   Align=Auto$(INF_OUTPUT)/$(MODULE_NAME).efi
  UI   STRING =$(MODULE_NAME) Optional
  VERSION  STRING =$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 @@ -397,7 +397,7 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
  [Rule.Common.PEIM]
FILE PEIM = $(NAMED_GUID) {
   PEI_DEPEX PEI_DEPEX Optional$(INF_OUTPUT)/$(MODULE_NAME).depex
 - PE32  PE32   Align=32   $(INF_OUTPUT)/$(MODULE_NAME).efi
 + PE32  PE32   Align=Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
   UI   STRING=$(MODULE_NAME) Optional
   VERSION  STRING=$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
 index 11e74e7..f43d3dd 100644
 --- a/OvmfPkg/OvmfPkgX64.fdf
 +++ b/OvmfPkg/OvmfPkgX64.fdf
 @@ -389,7 +389,7 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
  
  [Rule.Common.PEI_CORE]
FILE PEI_CORE = $(NAMED_GUID) {
 -PE32 PE32   Align=32$(INF_OUTPUT)/$(MODULE_NAME).efi
 +PE32 PE32   Align=Auto$(INF_OUTPUT)/$(MODULE_NAME).efi
  UI   STRING =$(MODULE_NAME) Optional
  VERSION  STRING =$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 @@ -397,7 +397,7 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
  [Rule.Common.PEIM]
FILE PEIM = $(NAMED_GUID) {
   PEI_DEPEX PEI_DEPEX Optional$(INF_OUTPUT)/$(MODULE_NAME).depex
 - PE32  PE32   Align=32   $(INF_OUTPUT)/$(MODULE_NAME).efi
 + PE32  PE32   Align=Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
   UI   STRING=$(MODULE_NAME) Optional
   VERSION  STRING=$(INF_VERSION) Optional BUILD_NUM=$(BUILD_NUMBER)
}
 


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: Fix BinWrappers LzmaF86Compress Script

[Laszlo Ersek]

On 07/09/15 14:56, Liming Gao wrote:
 From: Liming liming@intel.com
 
 LzmaF86Compress Script should use $arg to arg value.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Liming Gao liming@intel.com
 ---
  BaseTools/BinWrappers/PosixLike/LzmaF86Compress | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/BaseTools/BinWrappers/PosixLike/LzmaF86Compress 
 b/BaseTools/BinWrappers/PosixLike/LzmaF86Compress
 index c3e49cf..18946a4 100755
 --- a/BaseTools/BinWrappers/PosixLike/LzmaF86Compress
 +++ b/BaseTools/BinWrappers/PosixLike/LzmaF86Compress
 @@ -11,11 +11,11 @@
  # THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
  # WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
 IMPLIED.
  #
  
  for arg in $*; do
 -  if [ arg = -e -o arg = -d ]; then
 +  if [ $arg = -e -o $arg = -d ]; then
  FLAG=--f86
  break;
fi
  done
  
 

Reviewed-by: Laszlo Ersek ler...@redhat.com

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Source code for network devices?

[Laszlo Ersek]

On 07/09/15 19:46, Ralph Campbell wrote:
 I was searching the edk2 code for network device drivers but I could
 only find 3:
 
 EmbeddedPkg/Drivers/Lan9118Dxe/*
 OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772/*
 OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/*
 
 Does anyone know of other examples?

(1) here's a driver for the virtio-net NIC (a virtual network card used
in virtual machines, on the qemu/KVM hypervisor(s)):

OvmfPkg/VirtioNetDxe/

There's a TechNotes.txt in there as well, although the Driver Writer's
Guide is really helpful. (Along the UEFI spec of course.)

(2) The iPXE project provides an EFI SNP interface as well, a generic
wrapper for all the network cards that it can otherwise drive. See
src/interface/efi/efi_snp.c.

(3) Olivier recently posted this port:

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15847

I guess it could be the closest to what you are looking for, since it's
a standalone physical hw driver.

(4) You can find another phys hw driver here:

https://github.com/mlangsdorf/linaro-edk2/tree/acpi-share/ArmPlatformPkg/APMXGenePkg/Drivers/MellanoxDxe

 Perhaps from Ethernet chip manufactures?

Well if Broadcom were to contribute an open source driver, that would be
most awesome ;)

Thanks
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v3 21/23] OvmfPkg: PciHostBridgeDxe: shorten search for extra root buses

[Laszlo Ersek]

On 07/08/15 02:38, Jordan Justen wrote:
 On 2015-07-07 08:09:23, Laszlo Ersek wrote:
 QEMU provides an fw_cfg file called etc/extra-pci-roots, containing a
 
 How long were the extra roots in qemu without the fw_cfg entry?

Not at all. Please see QEMU commit 2118196bb. That patch, adding the
fw_cfg file, is an integral part of Marcel's patch series that
implements the QEMU feature.

OVMF support required twelve more QEMU patches from me. See their list in:

https://bugzilla.redhat.com/show_bug.cgi?id=1193080#c12
https://bugzilla.redhat.com/show_bug.cgi?id=1193080#c11

But both Marcel's feature patches (one of which is 2118196bb), and my
tweaks for OVMF, will be part of QEMU v2.4.0.

 That's a leading question for, what if we only were to only scan for
 the roots if the fw_cfg entry is present?

That's exactly what the patch does. (Apologies if the commit message is
not fully precise on this.) Please see the code that I'm marking below.

 
 Does seabios scan up to 255 if the fw_cfg entry is not found?

It does not, please see seabios commit 5cc7eece. And we're actually
following suit, please see below.

 -Jordan
 
 little-endian UINT64 value that exposes the number of extra root buses. We
 can use this value to terminate the scan as soon as we find the last extra
 root bus.

 Cc: Jordan Justen jordan.l.jus...@intel.com
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Laszlo Ersek ler...@redhat.com
 Regression-tested-by: Gabriel Somlo so...@cmu.edu
 ---

 Notes:
 v2:
 - %Lu is available now in format strings, for printing UINT64 values in
   decimal

  OvmfPkg/PciHostBridgeDxe/PciHostBridgeDxe.inf |  2 ++
  OvmfPkg/PciHostBridgeDxe/PciHostBridge.c  | 22 +++-
  2 files changed, 23 insertions(+), 1 deletion(-)

 diff --git a/OvmfPkg/PciHostBridgeDxe/PciHostBridgeDxe.inf 
 b/OvmfPkg/PciHostBridgeDxe/PciHostBridgeDxe.inf
 index 40f4c3c..ca760b5 100644
 --- a/OvmfPkg/PciHostBridgeDxe/PciHostBridgeDxe.inf
 +++ b/OvmfPkg/PciHostBridgeDxe/PciHostBridgeDxe.inf
 @@ -26,6 +26,7 @@ [Defines]
  
  [Packages]
MdePkg/MdePkg.dec
 +  OvmfPkg/OvmfPkg.dec
  
  [LibraryClasses]
UefiDriverEntryPoint
 @@ -39,6 +40,7 @@ [LibraryClasses]
DevicePathLib
IoLib
PciLib
 +  QemuFwCfgLib
  
  [Sources]
PciHostBridge.c
 diff --git a/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c 
 b/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
 index 3486644..efef2ed 100644
 --- a/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
 +++ b/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
 @@ -15,6 +15,8 @@
  
  **/
  
 +#include Library/QemuFwCfgLib.h
 +
  #include PciHostBridge.h
  
  STATIC
 @@ -207,6 +209,9 @@ InitializePciHostBridge (
)
  {
EFI_STATUS  Status;
 +  FIRMWARE_CONFIG_ITEMFwCfgItem;
 +  UINTN   FwCfgSize;
 +  UINT64  ExtraRootBridgesLeft;
UINTN   LastRootBridgeNumber;
UINTN   RootBridgeNumber;
PCI_HOST_BRIDGE_INSTANCE*HostBridge;
 @@ -237,6 +242,20 @@ InitializePciHostBridge (
}
  
//
 +  // QEMU provides the number of extra root buses, shortening the exhaustive
 +  // search below. If there is no hint, the feature is missing.
 +  //
 +  Status = QemuFwCfgFindFile (etc/extra-pci-roots, FwCfgItem, 
 FwCfgSize);
 +  if (EFI_ERROR (Status) || FwCfgSize != sizeof ExtraRootBridgesLeft) {
 +ExtraRootBridgesLeft = 0;

If QemuFwCfgFindFile() doesn't find the fw_cfg file, then it returns
NOT_FOUND. That will set ExtraRootBridgesLeft to zero, and then:

 +  } else {
 +QemuFwCfgSelectItem (FwCfgItem);
 +QemuFwCfgReadBytes (FwCfgSize, ExtraRootBridgesLeft);
 +DEBUG ((EFI_D_INFO, %a: %Lu extra root buses reported by QEMU\n,
 +  __FUNCTION__, ExtraRootBridgesLeft));
 +  }
 +
 +  //
// The main root bus is always there.
//
LastRootBridgeNumber = 0;
 @@ -247,7 +266,7 @@ InitializePciHostBridge (
// alive.
//
for (RootBridgeNumber = 1;
 -   RootBridgeNumber  256;
 +   RootBridgeNumber  256  ExtraRootBridgesLeft  0;

this condition here will prevent the loop body from executing even once.

See also the comment a bit higher up: If there is no hint, the feature
is missing..

... If you are otherwise okay with this patch, I can append a remark
like this to the commit message, before committing the set:

  If the etc/extra-pci-roots fw_cfg file is absent, then no extra
  root buses are available, and we skip the scan altogether.

Thanks!
Laszlo

 ++RootBridgeNumber) {
  UINTN Device;
  
 @@ -271,6 +290,7 @@ InitializePciHostBridge (
}
InsertTailList (HostBridge-Head, RootBus-Link);
LastRootBridgeNumber = RootBridgeNumber;
 +  --ExtraRootBridgesLeft;
  }
}
  
 -- 
 1.8.3.1




--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need

Re: [edk2] [Patch 3/7] OvmfPkg: Remove Ip4ConfigDxe module from OvmfPkg.

[Laszlo Ersek]

 that used to depend on Ip4Config have been migrated to Ip4Config2.

Thanks
Laszlo

 
 Thanks.
 Jiaxin
 
 -Original Message-
 From: Laszlo Ersek [mailto:ler...@redhat.com] 
 Sent: Tuesday, July 7, 2015 8:56 PM
 To: Wu, Jiaxin
 Cc: edk2-devel@lists.sourceforge.net
 Subject: Re: [edk2] [Patch 3/7] OvmfPkg: Remove Ip4ConfigDxe module from 
 OvmfPkg.
 
 On 07/07/15 03:27, jiaxinwu wrote:
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: jiaxinwu jiaxin...@intel.com
 ---
  OvmfPkg/OvmfPkgIa32.dsc| 1 -
  OvmfPkg/OvmfPkgIa32.fdf| 1 -
  OvmfPkg/OvmfPkgIa32X64.dsc | 1 -
  OvmfPkg/OvmfPkgIa32X64.fdf | 1 -
  OvmfPkg/OvmfPkgX64.dsc | 1 -
  OvmfPkg/OvmfPkgX64.fdf | 1 -
  6 files changed, 6 deletions(-)

 diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index 
 bb008f6..c3508e6 100644
 --- a/OvmfPkg/OvmfPkgIa32.dsc
 +++ b/OvmfPkg/OvmfPkgIa32.dsc
 @@ -524,11 +524,10 @@
MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
 -  MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
  !if $(NETWORK_IP6_ENABLE) == TRUE
NetworkPkg/Ip6Dxe/Ip6Dxe.inf
 diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf index 
 24ad0bf..aadb099 100644
 --- a/OvmfPkg/OvmfPkgIa32.fdf
 +++ b/OvmfPkg/OvmfPkgIa32.fdf
 @@ -302,11 +302,10 @@ FILE FREEFORM = 
 PCD(gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLogoFile) {
INF  MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
INF  MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
INF  MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
INF  MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
INF  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
 -  INF  MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
INF  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
INF  MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
INF  MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
  !if $(NETWORK_IP6_ENABLE) == TRUE
INF  NetworkPkg/Ip6Dxe/Ip6Dxe.inf
 diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc 
 index fed584f..40a1cf1 100644
 --- a/OvmfPkg/OvmfPkgIa32X64.dsc
 +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
 @@ -531,11 +531,10 @@
MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
 -  MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
  !if $(NETWORK_IP6_ENABLE) == TRUE
NetworkPkg/Ip6Dxe/Ip6Dxe.inf
 diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf 
 index 5f98be8..bc42a2b 100644
 --- a/OvmfPkg/OvmfPkgIa32X64.fdf
 +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
 @@ -302,11 +302,10 @@ FILE FREEFORM = 
 PCD(gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLogoFile) {
INF  MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
INF  MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
INF  MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
INF  MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
INF  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
 -  INF  MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
INF  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
INF  MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
INF  MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
  !if $(NETWORK_IP6_ENABLE) == TRUE
INF  NetworkPkg/Ip6Dxe/Ip6Dxe.inf
 diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index 
 92af10f..ac4e731 100644
 --- a/OvmfPkg/OvmfPkgX64.dsc
 +++ b/OvmfPkg/OvmfPkgX64.dsc
 @@ -529,11 +529,10 @@
MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
 -  MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
  !if $(NETWORK_IP6_ENABLE) == TRUE
NetworkPkg/Ip6Dxe/Ip6Dxe.inf
 diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf index 
 11e74e7..b6992bd 100644
 --- a/OvmfPkg/OvmfPkgX64.fdf
 +++ b/OvmfPkg/OvmfPkgX64.fdf

Re: [edk2] [PATCH v2 5/7] ArmVirtPkg: Remove Ip4ConfigDxe module from ArmVirtPkg.

[Laszlo Ersek]

On 07/08/15 10:16, Ard Biesheuvel wrote:
 On 8 July 2015 at 08:24, jiaxinwu jiaxin...@intel.com wrote:
 Version2 update with a proper commit message.

 
 This commit message still does not explain the purpose of this change.

I agree absolutely.

The commit message should be as follows, in *every single* patch that
touches a package in this manner:

PackageName: remove Ip4ConfigDxe module from the build

Ip4ConfigDxe used to provide the Ip4Config protocol, on which many
of the network drivers (used in this package) had traditionally
depended.

Since git commit 1f6729ff (SVN r17853), subject

  MdeModulePkg: Update Ip4Dxe driver to support Ip4Config2 protocol

the Ip4Dxe driver itself provides a new version of the same
protocol: Ip4Config2. Dependent network drivers, libraries and
applications have been migrated to (or extended to) the new
protocol version.

For example:
- git 7c25b7ea (SVN r17869): ping  ifconfig
- git 00a6ad1b (SVN r17870): UefiHandleParsingLib
- git 6c5c70d6 (SVN r17873): DxeNetLib
- git 39561686 (SVN r17874): IpSecDxe
- git c581e503 (SVN r17875): EfiSocketLib

At this point, no driver, library or application in the edk2 tree
remains with a dependency (or an exclusive dependency) on the old
Ip4Config protocol. Therefore we can remove the providing driver,
Ip4ConfigDxe, from this build.

Jiaxin, please submit a v3 of the series, with this commit message in
each relevant patch. (Please don't forget to customize PackageName in
the subject line as appropriate.)

Thanks
Laszlo


 
 Cc: Laszlo Ersek ler...@redhat.com
 Cc: Ard Biesheuvel ard.biesheu...@linaro.org
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: jiaxinwu jiaxin...@intel.com
 ---
  ArmVirtPkg/ArmVirt.dsc.inc | 1 -
  ArmVirtPkg/ArmVirtQemu.fdf | 1 -
  2 files changed, 2 deletions(-)

 diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
 index 7ec0de4..6f47d8e 100644
 --- a/ArmVirtPkg/ArmVirt.dsc.inc
 +++ b/ArmVirtPkg/ArmVirt.dsc.inc
 @@ -364,11 +364,10 @@
# Networking stack
#
MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
 -  MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
 diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
 index e822fdf..4448018 100644
 --- a/ArmVirtPkg/ArmVirtQemu.fdf
 +++ b/ArmVirtPkg/ArmVirtQemu.fdf
 @@ -181,11 +181,10 @@ READ_LOCK_STATUS   = TRUE
# Networking stack
#
INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
 -  INF MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
 --
 1.9.5.msysgit.1



--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] OVMF for Xeon

[Laszlo Ersek]

On 07/08/15 12:27, tiger...@zhaoxin.com wrote:
 Hi, Laszlo:
 I have a question about OVMF package.
 1. Qemu could emulate Xeon CPU, so OVMF firmware could run with Xeon in
 Qemu?

Yes, why not.

We have a few AsmCpuid() calls in OvmfPkg (and probably many more in
modules that OvmfPkg pulls in), but I'd expect everything to work on
Xeon emulation too.

Thanks
Laszlo

 Thanks a lot!
 
 Best wishes,
 本邮件仅针对指定的收件人发送并可能含有保密或专有内容。任何非指定收件人所为之查阅、转发或使用本信息是不被允许的。
 如果您误收到本邮件，请立即告知发件人并删除本邮件及所有附件。谢谢！
 The information transmitted in this e-mail is intended only for the addressee 
 and may contain confidential and/or privileged material. Any review, 
 retransmission, dissemination or other use of this information by persons or 
 entities other than the intended recipient is prohibited. If you received 
 this e-mail in error, please notify the sender immediately, and delete this 
 e-mail and any attachments. Thank you.
 
 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 edk2-devel mailing list
 edk2-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/edk2-devel
 


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [patch] MdemodulePkg: fix the problem that data type conversion may loss data

[Laszlo Ersek]

On 07/08/15 11:29, Zhang Lubo wrote:
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Zhang Lubo lubo.zh...@intel.com
 ---
  MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Support.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Support.c 
 b/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Support.c
 index 9ac6363..fce80d2 100644
 --- a/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Support.c
 +++ b/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Support.c
 @@ -326,15 +326,15 @@ Mtftp4SendRequest (
Len -= ((UINT32) AsciiStrLen ((CHAR8 *) Token-Filename) + (UINT32) 
 AsciiStrLen ((CHAR8 *) Mode) + 4);
  
for (Index = 0; Index  Token-OptionCount; ++Index) {
  Cur  = (UINT8 *) AsciiStrCpyS ((CHAR8 *) Cur, Len, (CHAR8 *) 
 Options[Index].OptionStr);
  Cur += AsciiStrLen ((CHAR8 *) Options[Index].OptionStr) + 1;
 -Len -= (AsciiStrLen ((CHAR8 *) Options[Index].OptionStr) + 1);
 +Len -= (UINT32) AsciiStrLen ((CHAR8 *) Options[Index].OptionStr) + 1;
  
  Cur  = (UINT8 *) AsciiStrCpyS ((CHAR8 *) Cur, Len, (CHAR8 *) 
 Options[Index].ValueStr);
  Cur += AsciiStrLen ((CHAR8 *) (CHAR8 *) Options[Index].ValueStr) + 1;
 -Len -= (AsciiStrLen ((CHAR8 *) (CHAR8 *) Options[Index].ValueStr) + 1);
 +Len -= (UINT32) AsciiStrLen ((CHAR8 *) (CHAR8 *) 
 Options[Index].ValueStr) + 1;
}
  
return Mtftp4SendPacket (Instance, Nbuf);
  }
  
 

I don't understand how this can avoid data loss.

I can imagine is that MSVC whines about possible data loss, because
AsciiStrLen() returns UINTN, and Len is UINT32. However, this patch does
not prevent any truncation, it just shuts up MSVC.

Now that may be the right thing to do (I can't tell without evaluating
the function fully, which I won't volunteer for now, although I do find
it probable that the string length will be significantly smaller than
4G), but in any case, the commit message should be clear about the fact
that all the patch does is suppress the MSVC warning.

Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg: Refine INF file for SmmMemLib.

[Laszlo Ersek]

On 07/08/15 09:53, Qiu Shumin wrote:
 Add [Depex] section and update protocol usage.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Qiu Shumin shumin@intel.com
 CC: Liming Gao liming@intel.com
 CC: Yao, Jiewen jiewen@intel.com
 ---
  MdePkg/Library/SmmMemLib/SmmMemLib.inf | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/MdePkg/Library/SmmMemLib/SmmMemLib.inf 
 b/MdePkg/Library/SmmMemLib/SmmMemLib.inf
 index 5531423..a9d47cc 100644
 --- a/MdePkg/Library/SmmMemLib/SmmMemLib.inf
 +++ b/MdePkg/Library/SmmMemLib/SmmMemLib.inf
 @@ -49,4 +49,7 @@
MemoryAllocationLib
  
  [Protocols]
 -  gEfiSmmAccess2ProtocolGuid## SOMETIMES_CONSUMES
 +  gEfiSmmAccess2ProtocolGuid## CONSUMES
 +  
 +[Depex]
 +  gEfiSmmAccess2ProtocolGuid
 

The subject line is useless. If someone runs

  git log --oneline

which prints only the commit hashes and the subject lines, he will see

  MdePkg: Refine INF file for SmmMemLib.

which carries zero meaning. The subject line should be:

  MdePkg: SmmMemLib.inf: add Depex section and update protocol usage

Thanks
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/7] Remove Ip4ConfigDxe module and related guid definitions from related packages.

[Laszlo Ersek]

On 07/08/15 09:21, Wu, Jiaxin wrote:
 For question1: I have really add the commit message in v2
 patches(highlight below). Did I misunderstand?

You added a description to the cover letter (email 0/7), but whatever
you write there will never reach the repo commit log, because the 0/7
email (the cover letter) is not a *patch*, therefore it cannot be committed.

As I said for v3, if you perform the same update for N separate
top-level packages, then the reasoning needs to be spelled out N times,
separately. Someone might run

  git log -- OvmfPkg/

and the output will contain only patches (commit messages) that overlap
with OvmfPkg/. For that reason the full explanation should be available
in the OvmfPkg-specific (and all the other pkg-specific) patches too.

 For question2: Maybe the cc part maintainers in commit message will be
 ignored by edk2-devel if the maintainers already in edk2-devel mailing
 list.

That's correct, yes -- unfortunately, the edk2-mailing list has crazy
settings. If you send an email To: the list, and Cc: a maintainer, but
the maintainer is also subscribed, then emails *reflected* from the list
server will drop the Cc: header.

That is a terrible practice, because followups posted to the *reflected*
message will have no chance to Cc:  the maintainer!

 If so, we need to specify the maintainers with “--to xxx” in git bash.

Don't bother, I think your posting was fine (I received personal copies
in my INBOX); it's just that edk2-devel is beyond repair. (I hope the
new list will get this right.)

Thanks
Laszlo

 
  
 
  
 
 *From:*Ryan Harkin [mailto:ryan.har...@linaro.org]
 *Sent:* Wednesday, July 8, 2015 2:44 PM
 *To:* edk2-devel@lists.sourceforge.net
 *Subject:* Re: [edk2] [PATCH v2 0/7] Remove Ip4ConfigDxe module and
 related guid definitions from related packages.
 
  
 
 Thanks for updating, but perhaps I am reading the wrong thing.  I don't
 see a commit message in any of the v2 patches describing what you are
 doing, like in your previous message on this thread.
 
 Also, you've added CC: someone to the commit message, but you
 haven't actually CC'd the maintainers in question.  So they might miss
 your change.
 
  
 
 On 8 July 2015 at 07:24, jiaxinwu jiaxin...@intel.com
 mailto:jiaxin...@intel.com wrote:
 
 Version2 update with a proper commit message.
 Those patches are used to remove Ip4ConfigDxe module and related
 guid definitions from related packages.
 Ip4ConfigDxe driver is deprecated in UEFI 2.5, so we will not
 support original Ip4Config Protocol, which is replace by Ip4Config2
 Protocol integrated in Ip4Dxe driver.
 Related packages(MdeModulePkg, Nt32Pkg,  ArmPlatformPkg, ArmVirtPkg,
 EmulatorPkg, OvmfPkg, Vlv2TbltDevicePkg) need to remove Ip4ConfigDxe
 module and related guid definitions.
 
 
 jiaxinwu (7):
   MdeModulePkg: Remove Ip4ConfigDxe module and related guid definition
 from MdeModulePkg.
   Nt32Pkg: Remove Ip4ConfigDxe module from Nt32Pkg.
   OvmfPkg: Remove Ip4ConfigDxe module from OvmfPkg.
   ArmPlatformPkg: Remove Ip4ConfigDxe module from ArmPlatformPkg.
   ArmVirtPkg: Remove Ip4ConfigDxe module from ArmVirtPkg.
   EmulatorPkg: Remove Ip4ConfigDxe module from EmulatorPkg.
   Vlv2TbltDevicePkg: Remove Ip4ConfigDxe module from Vlv2TbltDevicePkg.
 
  ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf  |   1 -
  .../ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf|   1 -
  .../ArmVExpressPkg/ArmVExpress-CTA9x4.fdf  |   1 -
  .../ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf|   1 -
  .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf |   1 -
  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc  |   1 -
  ArmVirtPkg/ArmVirt.dsc.inc |   1 -
  ArmVirtPkg/ArmVirtQemu.fdf |   1 -
  EmulatorPkg/EmulatorPkg.dsc|   1 -
  EmulatorPkg/EmulatorPkg.fdf|   3 +-
  MdeModulePkg/Include/Guid/Ip4ConfigHii.h   |  25 -
  MdeModulePkg/Include/Guid/NicIp4ConfigNvData.h |  70 --
  MdeModulePkg/MdeModulePkg.dec  |   6 -
  MdeModulePkg/MdeModulePkg.dsc  |   1 -
  .../Universal/Network/Ip4ConfigDxe/ComponentName.c | 165 
  .../Universal/Network/Ip4ConfigDxe/Ip4Config.c | 745
 -
  .../Universal/Network/Ip4ConfigDxe/Ip4Config.h | 533 
  .../Network/Ip4ConfigDxe/Ip4ConfigDriver.c | 505 
  .../Network/Ip4ConfigDxe/Ip4ConfigDxe.inf  |  91 ---
  .../Network/Ip4ConfigDxe/Ip4ConfigDxe.uni  | Bin 2700 - 0
 bytes
  .../Network/Ip4ConfigDxe/Ip4ConfigDxe.vfr  |  89 --
  .../Network/Ip4ConfigDxe/Ip4ConfigDxeExtra.uni | Bin 1366 - 0
 bytes
  .../Network/Ip4ConfigDxe/Ip4ConfigDxeStrings.uni   | Bin 3000 - 0
 bytes
  .../Universal/Network/Ip4ConfigDxe/Ip4ConfigNv.c   | 909

Re: [edk2] I don't understand EmulatorPkg

[Laszlo Ersek]

On 07/08/15 01:17, Shubha Ramani wrote:
 [...]

Here's a polite request:

- please stop posting HTML mail

- if you are forced at gunpoint to post HTML mail, please, for the sake
  of all subscribers, stop posting with 24px sized and/or x-large
  fonts. It looks extremely unprofessional and is a nuisance. Again, if
  you *must* post HTML, try not to specify any font size, or go with
  something in the 12-16 px range.

Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v2 1/7] MdeModulePkg: Remove Ip4ConfigDxe module and related guid definition from MdeModulePkg.

[Laszlo Ersek]

comments below

On 07/08/15 08:24, jiaxinwu wrote:
 Version2 update with a proper commit message.
 
 Cc: Feng Tian feng.t...@intel.com
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: jiaxinwu jiaxin...@intel.com
 ---
  MdeModulePkg/Include/Guid/Ip4ConfigHii.h   |  25 -
  MdeModulePkg/Include/Guid/NicIp4ConfigNvData.h |  70 --
  MdeModulePkg/MdeModulePkg.dec  |   6 -
  MdeModulePkg/MdeModulePkg.dsc  |   1 -
  .../Universal/Network/Ip4ConfigDxe/ComponentName.c | 165 
  .../Universal/Network/Ip4ConfigDxe/Ip4Config.c | 745 -
  .../Universal/Network/Ip4ConfigDxe/Ip4Config.h | 533 
  .../Network/Ip4ConfigDxe/Ip4ConfigDriver.c | 505 
  .../Network/Ip4ConfigDxe/Ip4ConfigDxe.inf  |  91 ---
  .../Network/Ip4ConfigDxe/Ip4ConfigDxe.uni  | Bin 2700 - 0 bytes
  .../Network/Ip4ConfigDxe/Ip4ConfigDxe.vfr  |  89 --
  .../Network/Ip4ConfigDxe/Ip4ConfigDxeExtra.uni | Bin 1366 - 0 bytes
  .../Network/Ip4ConfigDxe/Ip4ConfigDxeStrings.uni   | Bin 3000 - 0 bytes
  .../Universal/Network/Ip4ConfigDxe/Ip4ConfigNv.c   | 909 
 -
  .../Universal/Network/Ip4ConfigDxe/Ip4ConfigNv.h   |  54 --
  .../Universal/Network/Ip4ConfigDxe/Ip4NvData.h |  48 --
  .../Network/Ip4ConfigDxe/NicIp4Variable.c  | 319 
  .../Network/Ip4ConfigDxe/NicIp4Variable.h  | 104 ---
  18 files changed, 3664 deletions(-)
  delete mode 100644 MdeModulePkg/Include/Guid/Ip4ConfigHii.h
  delete mode 100644 MdeModulePkg/Include/Guid/NicIp4ConfigNvData.h
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/ComponentName.c
  delete mode 100644 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4Config.c
  delete mode 100644 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4Config.h
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDriver.c
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.uni
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.vfr
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxeExtra.uni
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxeStrings.uni
  delete mode 100644 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigNv.c
  delete mode 100644 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigNv.h
  delete mode 100644 MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4NvData.h
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/NicIp4Variable.c
  delete mode 100644 
 MdeModulePkg/Universal/Network/Ip4ConfigDxe/NicIp4Variable.h

Okay, so this patch has again the exact same two problems:
- bad commit message
- ordering error

First, the commit message should justify why removing the driver *at
this exact point* is safe. The reason should be given as:

no platform DSC in the edk2 tree references Ip4ConfigDxe.inf
any longer

Which immediately brings us to the second point, the ordering error.
Assume that the tree is checked out right at this patch. (Which is a
*perfectly* valid assumption.) If someone tried to build OvmfPkg,
ArmVirtPkg, or other packages at that point, the build would fail.
Because, at this point in the series, you remove the driver, but leave
the references in place.

Therefore this patch must be the *last* one in the series, ie. after you
removed the references in all the DSC and FDF files.

Thanks
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v3 20/23] OvmfPkg: PciHostBridgeDxe: look for all root buses

[Laszlo Ersek]

On 07/08/15 02:32, Jordan Justen wrote:
 On 2015-07-07 08:09:22, Laszlo Ersek wrote:
 In this patch we assume that root bus number 0 is always there (same as
 before), and scan the rest of the extra root buses, up to and including
 255. When an extra root bus is found, we install the PCI root bridge IO
 protocol for the previous root bus (which might be bus 0 or just the
 previous extra root bus).

 The root bridge protocol created thus will report the available bus number
 range

   [own bus number, next extra root bus number - 1]

 The LHS of this interval will be used for the root bus's own number, and
 the rest of the interval (which might encompass 0 additional elements too)
 can be used by the PCI bus driver to assign subordinate bus numbers from.

 (Subordinate buses are provided by PCI bridges that hang off the root bus
 in question.)

 For MMIO and IO space allocation, all the root buses share the original
 [0x8000_, 0x_] and [0x0, 0x] ranges, respectively.

 Cc: Jordan Justen jordan.l.jus...@intel.com
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Laszlo Ersek ler...@redhat.com
 Regression-tested-by: Gabriel Somlo so...@cmu.edu
 ---
  OvmfPkg/PciHostBridgeDxe/PciHostBridge.c | 95 +++-
  1 file changed, 71 insertions(+), 24 deletions(-)

 diff --git a/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c 
 b/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
 index 7dda75f..3486644 100644
 --- a/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
 +++ b/OvmfPkg/PciHostBridgeDxe/PciHostBridge.c
 @@ -43,14 +43,6 @@ EFI_PCI_ROOT_BRIDGE_DEVICE_PATH 
 mRootBridgeDevicePathTemplate = {
}
  };
  
 -//
 -// Hard code: Root Bridge's resource aperture
 -//
 -
 -PCI_ROOT_BRIDGE_RESOURCE_APERTURE  mResAperture[1] = {
 -  {0, 0xff, 0x8000, 0x, 0, 0x}
 -};
 -
  EFI_HANDLE mDriverImageHandle;
  
  PCI_HOST_BRIDGE_INSTANCE mPciHostBridgeInstanceTemplate = {
 @@ -80,8 +72,15 @@ PCI_HOST_BRIDGE_INSTANCE mPciHostBridgeInstanceTemplate = 
 {
  
param[in]  RootBusNumber The bus number of the root bus (root bridge) 
 to
 create.
 -   RootBusNumber is expected to fall into the 
 valid
 -   offset range of mResAperture.
 +
 +  param[in]  MaxSubBusNumber   The inclusive maximum bus number that can be
 +   assigned to any subordinate bus found behind 
 any
 +   PCI bridge hanging off this root bus.
 +
 +   The caller is repsonsible for ensuring that
 +   RootBusNumber = MaxSubBusNumber. If
 +   RootBusNumber equals MaxSubBusNumber, then 
 the
 +   root bus has no room for subordinate buses.
  
param[in]  HostBridgeHandle  The EFI_HANDLE corresponding to the host 
 bridge
 that is the parent of the root bridge to 
 create.
 @@ -108,12 +107,16 @@ STATIC
  EFI_STATUS
  InitRootBridge (
IN  UINT8RootBusNumber,
 +  IN  UINT8MaxSubBusNumber,
IN  EFI_HANDLE   HostBridgeHandle,
OUT PCI_ROOT_BRIDGE_INSTANCE **RootBus
)
  {
 -  PCI_ROOT_BRIDGE_INSTANCE *PrivateData;
 -  EFI_STATUS   Status;
 +  PCI_ROOT_BRIDGE_INSTANCE  *PrivateData;
 +  PCI_ROOT_BRIDGE_RESOURCE_APERTURE ResAperture;
 +  EFI_STATUSStatus;
 +
 +  ASSERT (RootBusNumber = MaxSubBusNumber);
  
PrivateData = AllocateZeroPool (sizeof *PrivateData);
if (PrivateData == NULL) {
 @@ -126,13 +129,18 @@ InitRootBridge (
  sizeof mRootBridgeDevicePathTemplate);
PrivateData-DevicePath.AcpiDevicePath.UID = RootBusNumber;
  
 +  ResAperture.BusBase  = RootBusNumber;
 +  ResAperture.BusLimit = MaxSubBusNumber;
 +  ResAperture.MemBase  = BASE_2GB;
 +  ResAperture.MemLimit = BASE_4GB - 1;
 +  ResAperture.IoBase   = 0;
 +  ResAperture.IoLimit  = MAX_UINT16;
//
// The function call below allocates no resources and performs no actions
// that have to be rolled back on later failure. It always succeeds.
//
Status = RootBridgeConstructor (PrivateData-Io, HostBridgeHandle,
 - EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM,
 - mResAperture[RootBusNumber]);
 + EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM, ResAperture);
ASSERT_EFI_ERROR (Status);
  
Status = gBS-InstallMultipleProtocolInterfaces (PrivateData-Handle,
 @@ -143,6 +151,9 @@ InitRootBridge (
  goto FreePrivateData;
}
  
 +  DEBUG ((EFI_D_INFO,
 +%a: installed root bus %d, with room for %d subordinate bus(es)\n,
 +__FUNCTION__, RootBusNumber, MaxSubBusNumber - RootBusNumber));
*RootBus = PrivateData;
return EFI_SUCCESS;
  
 @@ -196,6 +207,7 @@ InitializePciHostBridge (
)
  {
EFI_STATUS  Status;
 +  UINTN   LastRootBridgeNumber;
UINTN

Re: [edk2] [PATCH V3 4/5] Add PCD for selecting terminal type at build time

[Laszlo Ersek]

On 07/08/15 04:46, Heyi Guo wrote:
 Hi Roy,
 
 I have one question; please see my comments below.

Indeed:

 
 On 07/08/2015 08:44 AM, Roy Franz wrote:
 From: Laszlo Ersek ler...@redhat.com

 Add a fixed pointer PCD to allow build-time selection of VT100 or TTY
 terminal
 type.  The default remains VT100 emulation.
 Add support for building the ARM QEMU platforms with the TTY terminal
 with the -D TTY_TERMINAL build option.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Laszlo Ersek ler...@redhat.com
 [Roy Franz: minor edits: add TtyTerminal GUID, rename LINUX_TERMINAL
 to TTY_TERMINAL]
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Roy Franz roy.fr...@linaro.org
 Reviewed-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
   ArmVirtPkg/ArmVirt.dsc.inc |  6
 ++
   ArmVirtPkg/ArmVirtPkg.dec  |  7
 +++
   ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c  | 12
 
   ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf |  4
 
   4 files changed, 25 insertions(+), 4 deletions(-)

 diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
 index 7ec0de4..2feebd3 100644
 --- a/ArmVirtPkg/ArmVirt.dsc.inc
 +++ b/ArmVirtPkg/ArmVirt.dsc.inc
 @@ -15,6 +15,7 @@
 [Defines]
 DEFINE DEBUG_PRINT_ERROR_LEVEL = 0x804F
 +  DEFINE TTY_TERMINAL= FALSE

 I see in ArmVirtQemu.dsc file (patch 5#), we are using #ifdef
 TTY_TERMINAL. In my opinion the above statement will cause #ifdef
 TTY_TERMINAL to be always true.

I agree. That's my only comment for patch #5 too. Patch #5 should be
consistent with this one here, and use

!if $(TTY_TERMINAL) == TRUE

 [LibraryClasses.common]
   !if $(TARGET) == RELEASE
 @@ -359,6 +360,11 @@

 gEfiSecurityPkgTokenSpaceGuid.PcdRemovableMediaImageVerificationPolicy|0x04

   !endif
   +!if $(TTY_TERMINAL) == TRUE
 And I don't understand why we use !if here and !ifdef in dsc file.

BTW, we have a good reason for this kind of conditional. We use

  $(WHATEVER_ENABLE) == TRUE

because that allows

  -D WHATEVER_ENABLE=FALSE

on a command line to *override* an earlier

  -D WHATEVER_ENABLE[=TRUE]

on the same command line. The build utility has no -U option (for
undefining a macro).

Assume you have a build script that hardcodes

  -D WHATEVER_ENABLE

because that's how you build the tree most of the time. However,
occasionally you'd like to build without that feature, and you'd like to
override the macro. If the script just appends $@ to the build command
line, *and* the DSC files use the above kind of conditional, then you
can simply pass -D WHATEVER_ENABLE=FALSE to override the macro (but
still use the rest of your build script).

... Yes, we should have done the same with INTEL_BDS too, and we didn't.

I guess I didn't catch that because I *never* build without INTEL_BDS.

... Well, that, and because the patch that added INTEL_BDS (SVN r16208)
was never reviewed on the list.

Anyway, I digress.

 I should have tested the patch directly, but I couldn't apply the mail
 patches with git am right now (git 2.1.4 on Debian; really appreciate
 if someone could tell me the reason :-) ).

Sure. The edk2 project uses CRLF line endings. For that to work in the
first place (without git yelling at you all the time), you need to add
the following git config settings:

[core]
whitespace = cr-at-eol

Then, to make git-am compatible, you further need:

[am]
keepcr = true

This will *almost* make things work, but it will still break down when
you have a patch that adds or removes files *and* has crossed MTA
boundaries. In this case, you'll have

+++ /dev/null\r

or

--- /dev/null\r

hunk headers in the patch. The am.keepcr setting (which is otherwise
necessary for the *source code* CRLFs) will prevent git-am from
stripping the \r even from the /dev/null hunk headers, and that will
trip up git-am. So you need to pre-process the /dev/null hunk headers
manually, stripping *only those* \r characters, *if* you have a patch
that adds or removes files *and* has crossed MTA boundaries. (If the
patch doesn't cross an MTA, ie. it is straight out of git format-patch,
then /dev/null will have no \r.)

Summary (I'm sure you'll appreciate a summary): if you'd like to apply
edk2 patches from the mailing list, with git-am, do the following:
(1) set core.whitespace to cr-at-eol,
(2) set am.keepcr to true,
(3) save the patch emails *intact* into local files (eg. *.eml)
(4) preprocess those local files with:

sed -r -i 's,^((---|\+\+\+) /dev/null)\r$,\1,'   *.eml

(5) apply them with git-am.

HTH
Laszlo

 
 Heyi Guo
 
 +  # Set terminal type to TtyTerm, the value encoded is EFI_TTY_TERM_GUID
 +  gArmVirtTokenSpaceGuid.PcdTerminalTypeGuidBuffer|{0x80, 0x6d, 0x91,
 0x7d, 0xb1, 0x5b, 0x8c, 0x45, 0xa4, 0x8f, 0xe2, 0x5f, 0xdd, 0x51,
 0xef, 0x94}
 +!endif
 +
   [Components.common]
 #
 # Networking stack

Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables

[Laszlo Ersek]

On 07/08/15 15:24, Ard Biesheuvel wrote:
 This fixes a recurring problem where patches that have only been
 tested on MS toolchains break the build on GCC because they use
 variables that are only written but never read.
 
 However, there is a valid pattern where this may happen as well.
 For instance,
 
   Status = SomeFunc (OutVar);
   ASSERT_EFI_ERROR (Status);
   if (Outvar == ... ) { ... }
   // Status never referenced again
 
 may never access Status again at all in RELEASE builds, since the
 ASSERT_EFI_ERROR () macro evaluates to nothing in that case.
 
 So let's allow this pattern, by passing the appropriate GCC command
 line option.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  BaseTools/Conf/tools_def.template | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/BaseTools/Conf/tools_def.template 
 b/BaseTools/Conf/tools_def.template
 index 7edd7590956b..15d8db04232f 100644
 --- a/BaseTools/Conf/tools_def.template
 +++ b/BaseTools/Conf/tools_def.template
 @@ -3813,7 +3813,7 @@ NOOPT_DDK3790xASL_IPF_DLINK_FLAGS= /NOLOGO 
 /NODEFAULTLIB /LTCG /DLL /OPT:REF
  DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG = 
 --add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug
  RELEASE_*_*_OBJCOPY_ADDDEBUGFLAG   =
  
 -DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar 
 -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -c -include AutoGen.h
 +DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar 
 -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -c -include AutoGen.h 
 -Wno-error=unused-but-set-variable
  DEFINE GCC_IA32_CC_FLAGS   = DEF(GCC_ALL_CC_FLAGS) -m32 
 -malign-double -freorder-blocks -freorder-blocks-and-partition -O2 
 -mno-stack-arg-probe
  DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone 
 -Wno-address -mno-stack-arg-probe
  DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
 -minline-int-divide-min-latency
 

The least recent gcc version supported by the build tools is gcc-4.4.
That version supports the -Wno-error option, according to the documentation.

However, the unused-but-set-variable option argument is only supported
starting with gcc-4.6; again according to the documentation:

https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Warning-Options.html
https://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc/Warning-Options.html
https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Warning-Options.html
https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/Warning-Options.html
https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/Warning-Options.html
https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/Warning-Options.html

Also, from https://gcc.gnu.org/gcc-4.6/changes.html:

  * New -Wunused-but-set-variable and -Wunused-but-set-parameter
warnings were added for C, C++, Objective-C and Objective-C++.
These warnings diagnose variables respective parameters which are
only set in the code and never otherwise used. Usually such
variables are useless and often even the value assigned to them is
computed needlessly, sometimes expensively. The
-Wunused-but-set-variable warning is enabled by default by -Wall
flag and -Wunused-but-set-parameter by -Wall -Wextra flags

Regarding ASSERT_EFI_ERROR() being compiled out for RELEASE: that
implies we should add this option only for RELEASE builds. The GCC flags
can be filtered / specified for build type.

Combining these two restrictions, I think we should append this new gcc
option to

  RELEASE_GCC46_*_CC_FLAGS
  RELEASE_GCC47_*_CC_FLAGS
  RELEASE_GCC48_*_CC_FLAGS
  RELEASE_GCC49_*_CC_FLAGS

at most.

... Actually, we already have -Wno-unused-but-set-variable in a bunch
of places in BaseTools/Conf/tools_def.template, so I'd rather propose
the attached patch.

Thanks
Laszlo
From 418cc4a23d3c7c6cd6bb130bbbd670a99e6d544e Mon Sep 17 00:00:00 2001
From: Laszlo Ersek ler...@redhat.com
Date: Wed, 8 Jul 2015 17:43:01 +0200
Subject: [PATCH] BaseTools: unused-but-set-variable be no error with
 gcc-4.6+  RELEASE

This commit splits the DEBUG, NOOPT and RELEASE targets for IA32 and X64,
and adds -Wno-error=unused-but-set-variable to the RELEASE compiler flags.

The gcc option in question (recognized by gcc-4.6+) prevents the build
from breaking when the following pattern is built for RELEASE:

  Status = SomeFunc (OutVar);
  ASSERT_EFI_ERROR (Status);
  if (Outvar == ... ) { ... }
  // Status never referenced again

The ASSERT_EFI_ERROR() macro expands to nothing in this case, and Status
may only be assigned, but never read.

In addition, the existent -Wno-unused-but-set-variable options (in place
for RELEASE_(GCC4[6789]|ARMGCC|ARMLINUXGCC)_(ARM|AARCH64)) are also
consolidated as -Wno-error=unused-but-set-variable -- the warning is now
emitted, but it doesn't break the build.

Suggested-by: Ard Biesheuvel ard.biesheu...@linaro.org
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---

Notes

Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables

[Laszlo Ersek]

On 07/08/15 17:02, Ard Biesheuvel wrote:
 On 8 July 2015 at 16:59, Olivier Martin olivier.mar...@arm.com wrote:
 For ARM architectures, I only disable this flag for RELEASE build:

 
 OK, I hadn't noticed that. This means my patch would be only for the
 convenience of the Intel engineers (and my peace of mind as operator
 of a Jenkins job that gets broken all the time :-)) since the other
 use case I described is already covered by these.
 
 So please disregard my patch then.

I think your idea is good. For RELEASE builds, the valid pattern you
described should be kept working, but for DEBUG and NOOPT builds, the
warning should be emitted and it should also break the build. It's
regrettable that it's always us having to report / clean up after the
Intel developers working with MSVC, but ultimately it leads to a tidier
code base.

(Perhaps NOOPT should be handled similarly to RELEASE, and not DEBUG. In
that case I should update the patch I attached to my other email. We
don't really use NOOPT with gcc at all, so I included it in my patch
only for completeness.)

Thanks
Laszlo

 
 
 $ grep -r unused-but-set-variable Conf/tools_def.txt
 DEFINE GCC46_IA32_CC_FLAGS   = DEF(GCC45_IA32_CC_FLAGS) -Wno-address 
 -Wno-unused-but-set-variable
 DEFINE GCC46_X64_CC_FLAGS= DEF(GCC45_X64_CC_FLAGS) -Wno-address 
 -Wno-unused-but-set-variable
 RELEASE_GCC46_ARM_CC_FLAGS   = DEF(GCC46_ARM_CC_FLAGS) 
 -Wno-unused-but-set-variable
 RELEASE_GCC47_ARM_CC_FLAGS   = DEF(GCC47_ARM_CC_FLAGS) 
 -Wno-unused-but-set-variable
 RELEASE_GCC47_AARCH64_CC_FLAGS   = DEF(GCC47_AARCH64_CC_FLAGS) 
 -Wno-unused-but-set-variable
 RELEASE_GCC48_ARM_CC_FLAGS   = DEF(GCC48_ARM_CC_FLAGS) 
 -Wno-unused-but-set-variable
 RELEASE_GCC48_AARCH64_CC_FLAGS   = DEF(GCC48_AARCH64_CC_FLAGS) 
 -Wno-unused-but-set-variable
 RELEASE_GCC49_ARM_CC_FLAGS   = DEF(GCC49_ARM_CC_FLAGS) 
 -Wno-unused-but-set-variable
 RELEASE_GCC49_AARCH64_CC_FLAGS   = DEF(GCC49_AARCH64_CC_FLAGS) 
 -Wno-unused-but-set-variable


 -Original Message-
 From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
 Sent: 08 July 2015 14:24
 To: edk2-devel@lists.sourceforge.net; ler...@redhat.com; Olivier Martin; 
 leif.lindh...@linaro.org; jordan.l.jus...@intel.com
 Cc: roy.fr...@linaro.org; Ard Biesheuvel
 Subject: [PATCH] BaseTools/GCC: allow unused but set variables

 This fixes a recurring problem where patches that have only been tested on 
 MS toolchains break the build on GCC because they use variables that are 
 only written but never read.

 However, there is a valid pattern where this may happen as well.
 For instance,

   Status = SomeFunc (OutVar);
   ASSERT_EFI_ERROR (Status);
   if (Outvar == ... ) { ... }
   // Status never referenced again

 may never access Status again at all in RELEASE builds, since the 
 ASSERT_EFI_ERROR () macro evaluates to nothing in that case.

 So let's allow this pattern, by passing the appropriate GCC command line 
 option.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  BaseTools/Conf/tools_def.template | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/BaseTools/Conf/tools_def.template 
 b/BaseTools/Conf/tools_def.template
 index 7edd7590956b..15d8db04232f 100644
 --- a/BaseTools/Conf/tools_def.template
 +++ b/BaseTools/Conf/tools_def.template
 @@ -3813,7 +3813,7 @@ NOOPT_DDK3790xASL_IPF_DLINK_FLAGS= /NOLOGO 
 /NODEFAULTLIB /LTCG /DLL /OPT:REF
  DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG = 
 --add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug
  RELEASE_*_*_OBJCOPY_ADDDEBUGFLAG   =

 -DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar 
 -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -c -include AutoGen.h
 +DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar 
 -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -c -include AutoGen.h 
 -Wno-error=unused-but-set-variable
  DEFINE GCC_IA32_CC_FLAGS   = DEF(GCC_ALL_CC_FLAGS) -m32 
 -malign-double -freorder-blocks -freorder-blocks-and-partition -O2 
 -mno-stack-arg-probe
  DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone 
 -Wno-address -mno-stack-arg-probe
  DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
 -minline-int-divide-min-latency
 --
 1.9.1


 -- IMPORTANT NOTICE: The contents of this email and any attachments are 
 confidential and may also be privileged. If you are not the intended 
 recipient, please notify the sender immediately and do not disclose the 
 contents to any other person, use it for any purpose, or store or copy the 
 information in any medium.  Thank you.

 ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
 Registered in England  Wales, Company No:  2557590
 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
 Registered in England  Wales, Company No:  2548782



--

Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables

[Laszlo Ersek]

On 07/08/15 17:28, Scott Duplichan wrote:
 Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] wrote:
 
 ]Sent: Wednesday, July 08, 2015 08:24 AM
 ]To: edk2-devel@lists.sourceforge.net; ler...@redhat.com; 
 olivier.mar...@arm.com; leif.lindh...@linaro.org; ]jordan.l.jus...@intel.com
 ]Subject: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables
 ]
 ]This fixes a recurring problem where patches that have only been
 ]tested on MS toolchains break the build on GCC because they use
 ]variables that are only written but never read.
 
 An alternative point of view is that anyone who tests with MS tool chains
 should also test with gcc tool chains. Windows hosted gcc tool chains of
 all supported versions are free, small and easy to download and use:
 http://sourceforge.net/projects/edk2developertoolsforwindows/

I agree 100%, but experience shows that MSVC users cannot be bothered.

 
 
 ]However, there is a valid pattern where this may happen as well.
 ]For instance,
 ]
 ]  Status = SomeFunc (OutVar);
 ]  ASSERT_EFI_ERROR (Status);
 ]  if (Outvar == ... ) { ... }
 ]  // Status never referenced again
 ]
 ]may never access Status again at all in RELEASE builds, since the
 ]ASSERT_EFI_ERROR () macro evaluates to nothing in that case.
 
 To me this gcc warning is a good thing because it is pointing out
 a coding problem. The coding problem is that error handling is 
 completely missing from the release build. Once the coding problem
 is fixed, the warning goes away. After years of debate on the role
 of ASSERT in EDK2 code, there is now a sort of official opinion in
 the EDK2 Coding document:
 
 ASSERT macros are development and debugging aids and
 shall never be used for error handling. Assertions are
 used to catch conditions caused by programming errors
 that are resolved prior to product release.
 
 The EDK II PCD, PcdDebugPropertyMask, can be used to
 enable or disable the generation of code associated with
 ASSERT usage. Thus, all code must be able to operate, and
 recover in a reasonable maner [sic] with ASSERTs disabled.

In the above pattern, ASSERT_EFI_ERROR() is not necessarily used for
error handling. It is perfectly possible that the programmer knows that,
at that point, SomeFunc() *must* succeed, given the circumstances. One
way to express that is to write a comment before the function call, and
then ignore the return value completely. Another way is to add
ASSERT_EFI_ERROR().

If an invariant turns out to be false (fully unexpectedly), there's no
way to recover; the system state has been corrupted, and further
behavior is undefined.

So yes, ASSERT_EFI_ERROR() can be mis-used for error handling, but it is
not necessarily the only use case. For a given SomeFunc() -- and
situation --, the only reasonable error handling could be:

  //
  // This shall succeed here.
  //
  Status = SomeFunc (OutVar);
  ASSERT_EFI_ERROR (Status);

  if (EFI_ERROR (Status)) {
//
// this should have never happened; system state is corrupt and we
// must not continue
//
CpuDeadLoop();
  }

But I guess this just files under debate on the role of ASSERT in EDK2
code :)

 If you never plan on using a release build, which I think might
 be the case with OVMF, the RELEASE option could be removed from
 the DSC file and -Wno-error=unused-but-set-variable could be
 added through the DSC file for that project only. 

Well, *I* don't plan to use anything but DEBUG builds of OVMF (because
ASSERT()s should never be compiled out, due to the above argument), but
others might want to.

Anyway, if, according to the refreshed coding style, ASSERT() must not
be used any longer for stating (and enforcing) invariants, then I guess
I'll just stop using ASSERT() altogether, and begin using _ASSERT()
instead, with an explicit check around it.

Namely, _ASSERT() is never compiled out. It is also never disabled by
PcdDebugPropertyMask. Yet, it does adhere to PcdDebugPropertyMask with
the *action* taken. So, henceforth I should be writing

  //
  // This shall succeed here.
  //
  Status = SomeFunc (OutVar);

  if (EFI_ERROR (Status)) {
//
// this should have never happened; system state is corrupt and we
// must not continue
//
_ASSERT (FALSE);
  }

Thanks for helping me make up my mind :)

 
 Just my opinion anyway. We all know from the old Microsoft tool chains
 how annoying unwanted warnings are.

Right. I do agree with you that the optimal solution would be a build
farm where all developers could test-build against all supported
compilers. I doubt it's ever going to happen.

Thanks
Laszlo

 
 Thanks,
 Scott
 
 
 ]So let's allow this pattern, by passing the appropriate GCC command
 ]line option.
 ]
 ]Contributed-under: TianoCore Contribution Agreement 1.0
 ]Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ]---
 ] BaseTools/Conf/tools_def.template | 2 +-
 ] 1 file changed, 1 insertion(+), 1 deletion(-)
 ]
 ]diff --git a/BaseTools/Conf/tools_def.template 
 

Re: [edk2] [Patch 3/7] OvmfPkg: Remove Ip4ConfigDxe module from OvmfPkg.

[Laszlo Ersek]

 your good suggestions.

Looking at the SVN commit log, and your explanation, I do understand now
(and agree) that the ordering has not been ignored. It's just that the
position of 1/7 is not correct in this series (a minor issue,
admittedly). I'm sorry I *assumed* that you didn't care about the ordering.

Apparently you did care (and 1/7 is just a minor hiccup here), it just
wasn't clear from the (very laconic) description.

Thanks!
Laszlo

 -
 
 Thanks for everyone's great comments. 
 
 Best Regards!
 Jiaxin
 
 -Original Message-
 From: Laszlo Ersek [mailto:ler...@redhat.com] 
 Sent: Wednesday, July 8, 2015 6:33 PM
 To: Wu, Jiaxin
 Cc: edk2-devel@lists.sourceforge.net
 Subject: Re: [edk2] [Patch 3/7] OvmfPkg: Remove Ip4ConfigDxe module from 
 OvmfPkg.
 
 On 07/08/15 07:18, Wu, Jiaxin wrote:
 Hi Laszlo,
 
 Thanks for your comments first.
 
 Ip4Dxe driver update patch has been sent out and reviewed, we have 
 submitted to edk2 already.  So, that means the packages I listed will 
 consume Ip4Config2 protocol integrated in Ip4Dxe driver directly.
 
 What patch are you *specifically* referring to?
 
 Are you referring to the email
 
   [edk2] [Patch] MdeModulePkg: Update Ip4Dxe driver to support
  Ip4Config2 protocol, and also add UI support in Ip4Dxe
  driver.
   http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15823
 
 If that is the patch that you have in mind, I have a couple of notes:
 
 - Yes, that patch seems to install gEfiIp4Config2ProtocolGuid, in the
   Ip4DriverBindingStart() function.
 
 - However, the INF file change (for
   MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf) is not correct.
   It uses the TO_START comment for the protocol GUID, while it should
   by BY_START.
 
 - You are saying that the patch has been reviewed. I cannot see any
   discussion in that thread (or any other thread with the same subject).
   Your initial posting also doesn't carry any Reviewed-by tags (from
   internal reviewers at Intel).
 
 For patch series, those patches used to update related pkgs and remove 
 Ip4ConfigDxe driver. I will submit related pkgs  to edk2 first, and 
 then remove Ip4ConfigDxe driver.  I don't think the patch series has 
 any issue.
 
 The issue here is that your current patchset (that removes version 1 of the 
 protocol from a number of packages) *depends* on your patch that adds version 
 2 of the protocol. The ordering between the patches must be:
 
   - add version 2 of the protocol
   - migrate drivers to version 2 of the protocol
   - remove version 1 of the protocol
 
 *Unless* you spell out this dependency in your patch submission explicitly, 
 there is no guarantee that the independently submitted patches will not be 
 committed in reverse order. If you commit them in reverse order, then there 
 will exist a state in the edk2 tree where those platforms are broken, because 
 they have *no* version of the ip4 config protocol.
 
 And yes, that is bad. When someone looks for an independent bug with 
 git-bisect, they might end up at that exact broken state in the tree.
 
 So, this patch set is not broken *per se*. The breakage is that you did not 
 spell out either the justification for this set, or the strict dependency 
 this patch has on other patches of yours.
 
 When I reviewed this series of yours, I realized the dependency myself.
 Not knowing about your other patches, I went to the edk2 tree and verified 
 the dependency manually. The dependency was not satisfied at that point, 
 inside the tree, which is why I rejected your patch. (If you patch had been 
 committed at that exact moment, it would have broken OVMF.)
 
 *Now* we have a different situation of course. I can see that your patch that 
 I referenced above, providing gEfiIp4Config2ProtocolGuid, has been committed 
 to the tree:
 
 commit 1f6729ffe98095107ce82e67a4a0209674601a90
 Author: jiaxinwu jiaxin...@intel.com
 Date:   Tue Jul 7 08:19:55 2015 +
 
 MdeModulePkg: Update Ip4Dxe driver to support Ip4Config2 protocol,
 
 and also add new UI configuration support in Ip4Dxe driver.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: jiaxinwu jiaxin...@intel.com
 Reviewed-by: Ye Ting ting...@intel.com
 
 git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17853
 6f19259b-4bc3-4df7-8a09-765794883524
 
 I have a couple notes for this as well:
 
 - This patch was never submitted to the list for review. Minimally, the
   subject line has been changed relative to the patch I linked above.
 
 - The patch carries the Reviewed-by tag of Ye Ting. Where was that
   Reviewed-by tag posted to the public mailing list? If you got it in
   private, that's useless.
 
 - The patch

Re: [edk2] [PATCH V3 4/5] Add PCD for selecting terminal type at build time

[Laszlo Ersek]

On 07/08/15 22:36, Ryan Harkin wrote:

 I have an alias in my ~/.gitconfig file:
 
 [alias]
 amm=am --ignore-whitespace --ignore-space-change
 
 
 Then I use git amm to apply patches and that seems to work most of the
 time.
 
 But I suspect your method is doing something smarter and more complex
 whereas mine is more brute force.

Right. Your command is perfect for ad-hoc testing, but it ignores more
whitespace than what would be acceptable for actually committing a patch
to SVN. For example, it would enable source files to become mixed LF and
CRLF, I think. (Because:
- git-am would strip all \r characters from the patch email,
- ignore the resultant LF - CRLF mismatch in the hunks' contexts,
- and add the new lines with LF only.)

BTW, Paolo had written code for git at some point that fixed this issue
within git:

http://thread.gmane.org/gmane.comp.version-control.git/260215

His idea was to armor patch emails against line terminator changes
incurred by MTAs. (Which is what makes the sed command necessary in my
method, for the /dev/null hunk headers.)

Although the quoted-printable and base64 transfer encodings, used for
such protection, would have resulted in human-*un*readable raw email
files, Paolo suggested a one liner back-converter for those who like to
save patch emails to regular files, for comparing them between each
other. The results would have been very useful: git-am would just
work, and people comparing raw patches could rely on a one-liner in
their workflow.

Alas, I'm unsure about the fate of Paolo's work. I think he didn't have
time to work on further versions of the patch set, and I had neither the
time nor the expertise.

Thanks!
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables

[Laszlo Ersek]

On 07/08/15 21:26, Andrew Fish wrote:
 
 On Jul 8, 2015, at 12:02 PM, Laszlo Ersek ler...@redhat.com
 mailto:ler...@redhat.com wrote:


 It should be noted that once in a while I run into this sort of thing in 
 VxWorks as well, only it's often the other way around. We typically have 
 DEBUG()-style messages turned off by default, and sometimes there are
 debug 
 messages that refer to variables which no longer exist in the code. (The 
 variables were removed but the debug messages were never updated to
 match.)

 SeaBIOS employs the following trick to avoid this: all CONFIG_ flags
 are checked in regular if() statements, not in #if macros. That is, any
 elmination happens during compilation / optimization / linking, not in
 preprocessing. This allows the compiler to catch such errors even when a
 CONFIG_ option is predominantly false (or predominantly true).
 
 This is how the edk2 works. Your platform has to “opt-in” to the #if.
 The default is to use PCDs, and that is what happens on VC++.
 The MDEPKG_NDEBUG
 #define was added for compilers, like gcc, that could not dead strip the
 code. 
 
 https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Library/DebugLib.h
 
 #if !defined(MDEPKG_NDEBUG)   
   #define ASSERT(Expression)\
 do {\
   if (DebugAssertEnabled ()) {  \
 if (!(Expression)) {\
   _ASSERT (Expression); \
 }   \
   } \
 } while (FALSE)
 #else
   #define ASSERT(Expression)
 #endif
 
 If you are not using the optional MDEPKG_NDEBUG flag then DEBUG and
 ASSERT macros just become policy for a release build based on PCD. 

Ah! That's very useful background info.

Perhaps it's time for dropping MDEPKG_NDEBUG? We have:

[BuildOptions]
  GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
  GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
  INTEL:RELEASE_*_*_CC_FLAGS   = /D MDEPKG_NDEBUG
  MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG

I wonder why MDEPKG_NDEBUG was then added for MSFT in the first place
(assuming MSVC had always been able to remove dead code), but in any
case, perhaps we should restrict MDEPKG_NDEBUG to RELEASE builds with
older (4.4, 4.5, ... ?) gcc.

... I experimented a bit now. I removed MDEPKG_NDEBUG, and watched how
the size of DXEFV changed when I flipped the DEBUG_VERBOSE bit on and
off. Summary: no matter what I tried in place of MDEPKG_NDEBUG (-O0,
-O1, -O1 -flto), given one specific CC_FLAGS (and DLINK_FLAGS) setting,
inverting the DEBUG_VERBOSE bit in the PCD mask had no effect.

I think it would make a difference if -flto *actually* worked, but from
a quick google search, I think it either doesn't work with gcc-4.8 at
all, *or* the edk2 build system would have to use FLTO-aware binutils
and linker wrappers (or parameters). I have no clue how to set that up.
So for now we'll have to stick with MDEPKG_NDEBUG I guess.

Thanks!
Laszlo

 
 Also in most of the DebugLib instances what do on the ASSERT is a policy
 choice (breakpoint, dead loop, no-op). 
 https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Library/BaseDebugLibSerialPort/DebugLib.c
 
 VOID
 EFIAPI
 DebugAssert (
   IN CONST CHAR8  *FileName,
   IN UINTNLineNumber,
   IN CONST CHAR8  *Description
   )
 {
   CHAR8  Buffer[MAX_DEBUG_MESSAGE_LENGTH];
 
   //
   // Generate the ASSERT() message in Ascii format
   //
   AsciiSPrint (Buffer, sizeof (Buffer), ASSERT %a(%d): %a\n, FileName, 
 LineNumber, Description);
 
   //
   // Send the print string to the Console Output device
   //
   SerialPortWrite ((UINT8 *)Buffer, AsciiStrLen (Buffer));
 
   //
   // Generate a Breakpoint, DeadLoop, or NOP based on PCD settings
   //
   if ((PcdGet8(PcdDebugPropertyMask)  
 DEBUG_PROPERTY_ASSERT_BREAKPOINT_ENABLED) != 0) {
 CpuBreakpoint ();
   } else if ((PcdGet8(PcdDebugPropertyMask)  
 DEBUG_PROPERTY_ASSERT_DEADLOOP_ENABLED) != 0) {
 CpuDeadLoop ();
   }
 }
 
 Thanks,
 
 Andrew Fish
 
 
 
 
 
 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 
 
 
 ___
 edk2-devel mailing list
 edk2-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/edk2-devel
 


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel

Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables

[Laszlo Ersek]

On 07/09/15 01:42, Jordan Justen wrote:
 On 2015-07-08 08:58:04, Laszlo Ersek wrote:
 On 07/08/15 17:02, Ard Biesheuvel wrote:
 On 8 July 2015 at 16:59, Olivier Martin olivier.mar...@arm.com wrote:
 For ARM architectures, I only disable this flag for RELEASE build:

 OK, I hadn't noticed that. This means my patch would be only for the
 convenience of the Intel engineers (and my peace of mind as operator
 of a Jenkins job that gets broken all the time :-)) since the other
 use case I described is already covered by these.

 So please disregard my patch then.

 I think your idea is good. For RELEASE builds, the valid pattern you
 described should be kept working, but for DEBUG and NOOPT builds, the
 warning should be emitted and it should also break the build. It's
 regrettable that it's always us having to report / clean up after the
 Intel developers working with MSVC, but ultimately it leads to a tidier
 code base.
 
 What is the use case? Someone has a regular build pool that *only*
 does RELEASE builds?
 
 I think nearly all automated build systems will also do DEBUG builds,
 and thus will still see the build error.
 
 What about a lower bar for committing build break fixes? What if we
 said that compiler warning fixes could be committed by any package
 maintainer for any package as long as it is an obvious trivial fix and
 it has at least one r-b?

That sounds pretty good to me!

 I think qemu has a 'trivial' patch process. I can't remember the
 details, but it may involve just Cc'ing the list with a different
 name. Like:
 
 Cc: edk2-trivial edk2-devel@lists.sourceforge.net

http://wiki.qemu.org/Contribute/TrivialPatches

 Anyway, I don't really support this build flag change, but I suppose
 it could be acceptable for RELEASE builds.

I think Ard abandoned the idea on seeing Olivier's followup, and I did
the same when I saw Bill's answer.

Your idea about streamlining the current fixup process is a good one;
let's adopt it. Does it need to be codified somewhere (Maintainers.txt,
Contributions.txt, ...)?

Cheers!
Laszlo

 
 -Jordan
 
 (Perhaps NOOPT should be handled similarly to RELEASE, and not DEBUG. In
 that case I should update the patch I attached to my other email. We
 don't really use NOOPT with gcc at all, so I included it in my patch
 only for completeness.)

 Thanks
 Laszlo



 $ grep -r unused-but-set-variable Conf/tools_def.txt
 DEFINE GCC46_IA32_CC_FLAGS   = DEF(GCC45_IA32_CC_FLAGS) 
 -Wno-address -Wno-unused-but-set-variable
 DEFINE GCC46_X64_CC_FLAGS= DEF(GCC45_X64_CC_FLAGS) 
 -Wno-address -Wno-unused-but-set-variable
 RELEASE_GCC46_ARM_CC_FLAGS   = DEF(GCC46_ARM_CC_FLAGS) 
 -Wno-unused-but-set-variable
 RELEASE_GCC47_ARM_CC_FLAGS   = DEF(GCC47_ARM_CC_FLAGS) 
 -Wno-unused-but-set-variable
 RELEASE_GCC47_AARCH64_CC_FLAGS   = DEF(GCC47_AARCH64_CC_FLAGS) 
 -Wno-unused-but-set-variable
 RELEASE_GCC48_ARM_CC_FLAGS   = DEF(GCC48_ARM_CC_FLAGS) 
 -Wno-unused-but-set-variable
 RELEASE_GCC48_AARCH64_CC_FLAGS   = DEF(GCC48_AARCH64_CC_FLAGS) 
 -Wno-unused-but-set-variable
 RELEASE_GCC49_ARM_CC_FLAGS   = DEF(GCC49_ARM_CC_FLAGS) 
 -Wno-unused-but-set-variable
 RELEASE_GCC49_AARCH64_CC_FLAGS   = DEF(GCC49_AARCH64_CC_FLAGS) 
 -Wno-unused-but-set-variable


 -Original Message-
 From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
 Sent: 08 July 2015 14:24
 To: edk2-devel@lists.sourceforge.net; ler...@redhat.com; Olivier Martin; 
 leif.lindh...@linaro.org; jordan.l.jus...@intel.com
 Cc: roy.fr...@linaro.org; Ard Biesheuvel
 Subject: [PATCH] BaseTools/GCC: allow unused but set variables

 This fixes a recurring problem where patches that have only been tested on 
 MS toolchains break the build on GCC because they use variables that are 
 only written but never read.

 However, there is a valid pattern where this may happen as well.
 For instance,

   Status = SomeFunc (OutVar);
   ASSERT_EFI_ERROR (Status);
   if (Outvar == ... ) { ... }
   // Status never referenced again

 may never access Status again at all in RELEASE builds, since the 
 ASSERT_EFI_ERROR () macro evaluates to nothing in that case.

 So let's allow this pattern, by passing the appropriate GCC command line 
 option.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  BaseTools/Conf/tools_def.template | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/BaseTools/Conf/tools_def.template 
 b/BaseTools/Conf/tools_def.template
 index 7edd7590956b..15d8db04232f 100644
 --- a/BaseTools/Conf/tools_def.template
 +++ b/BaseTools/Conf/tools_def.template
 @@ -3813,7 +3813,7 @@ NOOPT_DDK3790xASL_IPF_DLINK_FLAGS= /NOLOGO 
 /NODEFAULTLIB /LTCG /DLL /OPT:REF
  DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG = 
 --add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug
  RELEASE_*_*_OBJCOPY_ADDDEBUGFLAG   =

 -DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar 
 -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -c -include

Re: [edk2] [PATCH V4 0/5] Add TtyTerm terminal type

[Laszlo Ersek]

Feng,

On 07/09/15 02:39, Tian, Feng wrote:
 Ok, I will do it.

I just checked the SVN repo and I can't see the patches yet. So please
allow me to commit these patches instead -- I'm not sure if you are a
regular git user otherwise, but in any case, given the extra processing
needed for patches snarfed from the list, I'd like to help with this.

So I'm going to go ahead now and commit them. Hope that's okay.

Thanks!
Laszlo

 
 -Original Message-
 From: Roy Franz [mailto:roy.fr...@linaro.org] 
 Sent: Thursday, July 9, 2015 8:38 AM
 To: Tian, Feng
 Cc: edk2-devel@lists.sourceforge.net; ler...@redhat.com; 
 ard.biesheu...@linaro.org; heyi@linaro.org
 Subject: Re: [PATCH V4 0/5] Add TtyTerm terminal type
 
 On Wed, Jul 8, 2015 at 5:25 PM, Tian, Feng feng.t...@intel.com wrote:
 Roy,

 For patch 1, 2, 3, I would sign Reviewed-by: Feng Tian feng.t...@intel.com

 Thanks for your contribution. Please go ahead to check them in.

 I'm not a committer, so I'll need someone to commit this for me.
 
 Thanks,
 Roy
 
 -Original Message-
 From: Roy Franz [mailto:roy.fr...@linaro.org]
 Sent: Thursday, July 9, 2015 3:03 AM
 To: edk2-devel@lists.sourceforge.net; Tian, Feng; ler...@redhat.com; 
 ard.biesheu...@linaro.org
 Cc: heyi@linaro.org; Roy Franz
 Subject: [PATCH V4 0/5] Add TtyTerm terminal type

 This patchset adds a new terminal type TtyTerm, that better handles the 
 typical Linux terminal (xterm/rxvt/gnome terminal/tmux/screen/etc.) These 
 often treat backspace/delete differently than the existing EDK2 terminal 
 types expect, particularly in emulated environments where the emulated 
 serial port is connected to a graphical terminal rather than a serial 
 console.  Some terminals use a mix of vt100 and vt200 escape codes for 
 function key handling.  Adding
 vt220 function key support fixes the use of F10 to save changes in BDS 
 configuration menus.

 This patchset includes changes to make the terminal type build time 
 configurable for the QEMU Aarch64 configuration.  Once this patchset goes in 
 I will submit patches for the other emulated ARM platforms as appropriate.

 Note: While working on the function keys, I could not find any documentation 
 that matched the code/comments in TerminalConIn.c regarding VT100 function 
 keys.  The VT100 only had 4 function keys (PF1-PF4), which are generally 
 mapped to F1-F4.  In the code, F3/F4 don't match the VT100 documentation I 
 found, and I have no idea where the values for F5-F10 are from.  I left the 
 existing
 VT100 terminal type escape code handling unchanged.

 This patchset is also available as the ttyterm-v4 branch on 
 https://git.linaro.org/people/roy.franz/linaro-edk2.git

 Changes since v3:
 * Convert !ifdef to !if for TTY_TERMINAL and INTEL_BDS defines (patch 5/5)

 Changes since v2:
 * Comment typo fixes, contrib ordering fixes
 * Moved static ttyTerm escape state variables to TerminalDevice structure
 * Add support for changing terminal type on ARM BDS QEMU build (new patch 
 5/5)
 * Add reviewed-by lines. (not to patch 3 that had changes)

 Changes since v1:
 * Added handling of VT220 escape codes for function keys
 * Fixed attribution PCD patch
 * Removed '[' from patch 3 description line

 Changes from Linuxterm RFC patchset:
 * Change to ttyTerm name - nothing linux specific in patchset
 * remove changes to Mde module, as changes not part of UEFI specification

 Laszlo Ersek (1):
   Add PCD for selecting terminal type at build time

 Roy Franz (4):
   Add TtyTerm terminal type to TerminalDxe
   Treat ASCII 0x7F as backspace for TtyTerm terminals
   Accept VT220 DEL and function keys for TTY terminal type
   add TTY_TERMINAL build option for ARM BDS

  ArmVirtPkg/ArmVirt.dsc.inc |   6 ++
  ArmVirtPkg/ArmVirtPkg.dec  |   7 ++
  ArmVirtPkg/ArmVirtQemu.dsc |  11 +-
  ArmVirtPkg/ArmVirtQemu.fdf |   4 +-
  ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c  |  12 ++-
  ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf |   4 +
  MdeModulePkg/Include/Guid/TtyTerm.h|  25 +
  MdeModulePkg/MdeModulePkg.dec  |   3 +
  MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c  |  50 
 +++--
  MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h  |   5 +
  MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c | 107 
 +++-
  MdeModulePkg/Universal/Console/TerminalDxe/TerminalConOut.c|   2 +
  MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf |   1 +
  13 files changed, 217 insertions(+), 20 deletions(-)  create mode 100644 
 MdeModulePkg/Include/Guid/TtyTerm.h

 --
 2.1.4



--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools

Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables

[Laszlo Ersek]

On 07/08/15 22:53, Andrew Fish wrote:
 
 On Jul 8, 2015, at 1:43 PM, Laszlo Ersek ler...@redhat.com
 mailto:ler...@redhat.com wrote:

 https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Library/DebugLib.h

 #if !defined(MDEPKG_NDEBUG)   
  #define ASSERT(Expression)\
do {\
  if (DebugAssertEnabled ()) {  \
if (!(Expression)) {\
  _ASSERT (Expression); \
}   \
  } \
} while (FALSE)
 #else
  #define ASSERT(Expression)
 #endif

 If you are not using the optional MDEPKG_NDEBUG flag then DEBUG and
 ASSERT macros just become policy for a release build based on PCD. 

 Ah! That's very useful background info.

 Perhaps it's time for dropping MDEPKG_NDEBUG? We have:

 [BuildOptions]
  GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
  GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
  INTEL:RELEASE_*_*_CC_FLAGS   = /D MDEPKG_NDEBUG
  MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG

 I wonder why MDEPKG_NDEBUG was then added for MSFT in the first place
 (assuming MSVC had always been able to remove dead code),
 
 It might make MSVC catch the same errors as GCC? Not sure about that? 
 
 I wonder is some hackery could make MDEPKG_NDEBUG path behave the same way?
 
 #else
   #define ASSERT(Expression)  do {} while (FALSE  (Expression))
 #endif

I guess this could work, yes.

 
 Maybe we could find something that all the compilers dead strip, but
 behaves more like the non #if path?

One idea (not sure if it makes any sense): the DebugAssertEnabled()
function call could be replaced with an open coded *fixed* PCD check.
(Yes, this would actually remove the DebugAssertEnabled() function from
the DebugLib interface, because the implementation would become
centralized. It would also require all platforms to provide the PCD as a
fixed one.)

Then no cross object file analysis would be necessary, just basic
constant folding and local dead code elimination.

Something like:

#define ASSERT(Expression)\
  do {\
if ((FixedPcdGet8 (PcdDebugPropertyMask) \
 DEBUG_PROPERTY_DEBUG_ASSERT_ENABLED) != 0  \
!(Expression)) {  \
  _ASSERT (Expression);   \
} \
  } while (FALSE)


Similarly for DebugPrintEnabled().

Thanks
Laszlo

 
 Thanks,
 
 Andrew Fish
 
 but in any
 case, perhaps we should restrict MDEPKG_NDEBUG to RELEASE builds with
 older (4.4, 4.5, ... ?) gcc.

 ... I experimented a bit now. I removed MDEPKG_NDEBUG, and watched how
 the size of DXEFV changed when I flipped the DEBUG_VERBOSE bit on and
 off. Summary: no matter what I tried in place of MDEPKG_NDEBUG (-O0,
 -O1, -O1 -flto), given one specific CC_FLAGS (and DLINK_FLAGS) setting,
 inverting the DEBUG_VERBOSE bit in the PCD mask had no effect.

 I think it would make a difference if -flto *actually* worked, but from
 a quick google search, I think it either doesn't work with gcc-4.8 at
 all, *or* the edk2 build system would have to use FLTO-aware binutils
 and linker wrappers (or parameters). I have no clue how to set that up.
 So for now we'll have to stick with MDEPKG_NDEBUG I guess.

 Thanks!
 Laszlo
 
 
 
 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 
 
 
 ___
 edk2-devel mailing list
 edk2-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/edk2-devel
 


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables

[Laszlo Ersek]

On 07/09/15 04:31, Scott Duplichan wrote:
 Bruce Cran [mailto:br...@cran.org.uk] wrote:
 
 ]Sent: Wednesday, July 08, 2015 05:12 PM
 ]To: edk2-devel@lists.sourceforge.net
 ]Subject: Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables
 ]
 ]On Wed, Jul 08, 2015 at 10:43:38PM +0200, Laszlo Ersek wrote:
 ]
 ] I think it would make a difference if -flto *actually* worked, but from
 ] a quick google search, I think it either doesn't work with gcc-4.8 at
 ] all, *or* the edk2 build system would have to use FLTO-aware binutils
 ] and linker wrappers (or parameters). I have no clue how to set that up.
 ] So for now we'll have to stick with MDEPKG_NDEBUG I guess.
 ]
 ]I've been trying to get -flto working this week, but without success (yet!).
 ]I'm currently running into a problem of ld (built from source) apparently not
 ]knowing about the lto plugin (and passing the liblto.so file via -plugin 
 causes
 ]an assert failure), but I'll keep trying.
 
 Last year I spent some time to get gcc -flto working properly with EDK2.
 At that time, the people here were busy with other things and there didn't
 seem to be a lot of interest in gcc link time optimization. So I never
 submitted a patch. Maybe it is time to revive this effort. Here is what I
 found:
 
 http://notabs.org/uefi/gcc-lto.htm

I apologize if I should remember this from last year, but I don't. Sorry
about that. Do you think you could revive it? The space savings would be
nice, but more importantly (to me), that would allow us to opt out of
MDEPKG_NDEBUG in at least OvmfPkg. (Based on Andrew's description, I now
believe that opting out of MDEPKG_NDEBUG is a good thing -- it would
allow the compiler to check more things, rather than hiding those
things with the preprocessor.)

In the article you wrote,
 gcc link time optimization exposes a few warnings that do not occur
 with the standard builds

and I guess Bill hinted that he saw similar warnings, and at least one
of those indicated a real problem?... So maybe we should find and fix
these for good.

 So 6 conditions need to be met for ghcc link time optimization to work
 properly with EDK2:
 
 1) Add -flto to the compile flags

Right.

 2) Use gcc to launch ld instead of invoking ld directly

This was consistent with my google results, and where I gave up.

 3) Include the compile flags on the link command line

I did that too (DLINK_FLAGS?)

 4) Use gcc-ar in place of ar when building static libraries

Also why I gave up... But now I checked (based on your article), and my
RHEL-7 laptop actually satisfies these requirements. It has gcc-ar, has
plugin support, etc. I ran your (very helpful!) build test from your
article, and it seemed to work:

main.exe: file format elf64-x86-64
Disassembly of section .text:
00400150 main:
  400150:   31 c0   xoreax,eax
  400152:   c3  ret
  400153:   90  nop

Thanks!
Laszlo

 5) Library code that resolves helper function calls generated by the 
 compiler must be compiled without the -flto flag
 6) These libraries must be prefixed with -Wl,-plugin-opt=-pass-through= 
 on the link command line.
 
 A patch from late 2014 is here:
 http://sourceforge.net/projects/edk2developertoolsforwindows/files/Patches/Link%20Time%20Optimization/
 
 Thanks,
 Scott
 
 
 ]Also, in terms of edk2-related resources, if anyone's interested I've been
 ]running doxygen on the sources and putting the results in
 ]http://bluestop.org/edk2/docs - the log files contain the tons of warnings 
 the
 ]tool generates, while the directories (http://bluestop.org/edk2/docs/trunk, 
 ]http://bluestop.org/edk2/docs/UDK2014.SP1 etc.)
 ]contain the API docs themselves.  I started generating them since I noticed
 ]feishare.com hadn't been updated for a couple of years and wasn't aware of 
 any
 ]other sites hosting a copy.
 ]
 ]-- 
 ]Bruce
 
 
 
 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 edk2-devel mailing list
 edk2-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/edk2-devel
 


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables

[Laszlo Ersek]

On 07/08/15 20:15, Bill Paul wrote:
 Of all the gin joints in all the towns in all the world, Laszlo Ersek had to 
 walk into mine at 09:17:08 on Wednesday 08 July 2015 and say:

 In the above pattern, ASSERT_EFI_ERROR() is not necessarily used for
 error handling.
 
 You are absolutely right: it's not. It's being used as a panic().

Good point! I guess I've always used ASSERT() in the sense of
PANIC_UNLESS().

 [...] There is also DEBUG(). You will find several 
 instances of the following construction:
 
 int SomeInterestingValue;
 
 /* Populate SomeInterestingValue */
 
 SomeInterestingValue = GetSomeInterestingStatus (handle);
 
 /* SomeInterestingValue is never referenced again */
 
 DEBUG(EFI_D_INFO, INTERESTING VALUE IS: %d\n, SomeInterestingValue);
 
 DEBUG() is also disabled when MDEPKG_NDEBUG is enabled, which creates the 
 same 
 problem. What would be the correct way to handle this case?

Honestly, I don't know. I only concern myself with the case when even
DEBUG_VERBOSE is enabled (PcdDebugPrintErrorLevel == 0x8040004F). The
case when I have to look at debug messages and analyze behavior is the
*norm*, not the exception (even if OVMF is not at fault -- the user may
have passed wrong QEMU options, for example).

It's an incredible chore when a user reports behavior he doesn't
understand or expect, and I first have to ask him to reproduce on a
DEBUG_VERBOSE build, and that he send me *that* log. Usually he has no
access to such a build, cannot build one himself, so I get to build it
for him. Blech. (I think Gerd's packages do enable DEBUG_VERBOSE, but
I'm not sure.)

 It should be noted that once in a while I run into this sort of thing in 
 VxWorks as well, only it's often the other way around. We typically have 
 DEBUG()-style messages turned off by default, and sometimes there are debug 
 messages that refer to variables which no longer exist in the code. (The 
 variables were removed but the debug messages were never updated to match.)

SeaBIOS employs the following trick to avoid this: all CONFIG_ flags
are checked in regular if() statements, not in #if macros. That is, any
elmination happens during compilation / optimization / linking, not in
preprocessing. This allows the compiler to catch such errors even when a
CONFIG_ option is predominantly false (or predominantly true).

 Right. I do agree with you that the optimal solution would be a build
 farm where all developers could test-build against all supported
 compilers. I doubt it's ever going to happen.
 
 Given that UEFI firmware is supposed to be the standard for a large number of 
 commercially available computer platforms, I find your lack of faith... 
 disturbing.

My lack of faith is based on experience :) We've been complaining
about this for ages on the list. I think it is safe to assume that the
primary participant that has legal access to all supported Microsoft
toolchains is Intel. As described (and provided!) by Scott,
gcc-for-Windows is almost trivially available (all supported gcc
versions). It seems to follow that Intel should operate such a build
farm. Based on how long we've been whining about this, I don't think
it's going to happen any time soon.

 Lastly, yesterday I actually spent some time updating the mingw-gcc-build.py 
 to support binutils 2.25 and GCC 4.9.3, and I ran into this exact issue. I 
 had 
 to add -Wno-unused-but-set-variable to the UNIXGCC instances of CC_FLAGS in 
 tools_def.template in order to get the OVMF build to work. But along the way, 
 I noticed about a dozen instances of this anti-pattern. There are at least as 
 many cases that stem from DEBUG() rather than ASSERT() or ASSERT_EFI_ERROR().
 
 However I also found at least one legitimate error case of a useless set but 
 never used variable too (i.e. a case that didn't involve conditional 
 compilation effects). This means that now that GCC has been muzzled to 
 disguise intentional abuses of this pattern, some unintentional abuses are 
 now 
 being hidden too.

Optimally, we shouldn't conflate the different (deeper) reasons this
warning gets emitted for. Unfortunately, it's not practical even for me
to build OVMF in all possible configurations:
- DEBUG and RELEASE (2)
- gcc 4.4 to 4.9 (6)
- Ia32, X64, Ia32X64 for OVMF (3)

That's 36 configs (and yes, the data flow analysis is specific to both
target architecture and gcc version, so some warnings would only be
found in configs that I can't test).

Add ARM and AARCH64 for ArmVirtPkg (QEMU and Xen separately)... Secure
Boot enabled vs. disabled... ARM BDS vs. Intel BDS... For OVMF, CSM
enabled vs. disabled; IPv6 enabled vs. disabled... It's really
unmanageable without a build farm.

Yes, someone could say hey Laszlo why don't you create a number of
virtual machines, with different gcc versions installed, and implement
at least the 'free software' build farm? -- Because I don't have time
for it. (And that's the reason I can't really blame Intel people either

Re: [edk2] [PATCH V4 5/5] add TTY_TERMINAL build option for ARM BDS

[Laszlo Ersek]

On 07/08/15 21:02, Roy Franz wrote:
 Enable selecting the TtyTerminal type for the ARM BDS build of QEMU using
 the TTY_TERMINAL define.
 Convert INTEL_BDS define to check for value (!if) rather than just definition
 (!ifdef) to allow setting of either value on command line.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Roy Franz roy.fr...@linaro.org
 ---
  ArmVirtPkg/ArmVirtQemu.dsc | 11 ---
  ArmVirtPkg/ArmVirtQemu.fdf |  4 ++--
  2 files changed, 10 insertions(+), 5 deletions(-)
 
 diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
 index 0671469..fbc2b12 100644
 --- a/ArmVirtPkg/ArmVirtQemu.dsc
 +++ b/ArmVirtPkg/ArmVirtQemu.dsc
 @@ -57,7 +57,7 @@
TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
  
 -!ifdef INTEL_BDS
 +!if $(INTEL_BDS) == TRUE
CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf

 GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf

 PlatformBdsLib|ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
 @@ -138,8 +138,13 @@
#
# Settings for ARM BDS -- use the serial console (ConIn  ConOut).
#
 +!if $(TTY_TERMINAL) == TRUE
 +  
 gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)
 +  
 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)
 +!else

 gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()

 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()
 +!endif
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3
  
#
 @@ -163,7 +168,7 @@
# initial location of the device tree blob passed by QEMU -- base of DRAM
gArmVirtTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress|0x4000
  
 -!ifdef INTEL_BDS
 +!if $(INTEL_BDS) == TRUE
gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 
 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
  !endif
 @@ -313,7 +318,7 @@
# Bds
#
MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
 -!ifdef INTEL_BDS
 +!if $(INTEL_BDS) == TRUE
MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
 diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
 index e822fdf..30556f5 100644
 --- a/ArmVirtPkg/ArmVirtQemu.fdf
 +++ b/ArmVirtPkg/ArmVirtQemu.fdf
 @@ -169,7 +169,7 @@ READ_LOCK_STATUS   = TRUE
# Bds
#
INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
 -!ifdef INTEL_BDS
 +!if $(INTEL_BDS) == TRUE
INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
 @@ -227,7 +227,7 @@ READ_LOCK_STATUS   = TRUE
INF MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
INF MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
  
 -!ifdef INTEL_BDS
 +!if $(INTEL_BDS) == TRUE
#
# TianoCore logo (splash screen)
#
 

The INTEL_BDS conditional conversion should have been a separate patch,
but I won't risk you throwing a keyboard at me, should we ever meet in
person, so I won't insist ;)

Reviewed-by: Laszlo Ersek ler...@redhat.com

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v2 02/24] PcAtChipsetPkg: remove PciHostBridgeDxe

[Laszlo Ersek]

On 07/07/15 02:52, Jordan Justen wrote:
 On 2015-07-06 15:10:45, Laszlo Ersek wrote:
 On 06/28/15 01:36, Jordan Justen wrote:
 On 2015-06-25 21:26:20, Ni, Ruiyu wrote:
 Jordan,
 Simply using PCD to split the code is very straightforward. Another
 approach is to introduce a new library class with carefully defined
 library APIs so that different platforms can use one common driver
 plus different instances of libraries.
 After all, abstracting is never a easy work.
 So let's firstly make OVMF work by duplicating a PciHostBridgeDxe.

 Is this the preferred method of making progress then? Duplicate code
 first, then figure out how to make it more general? I don't see
 drivers duplicated all that often, so it seems a little strange.

 I haven't heard you say the PCD idea can't work, so can you spend a
 little more time considering it to see if it seems reasonable to you?
 If you are still concerned about the PCDs, then fine we'll just
 duplicate the code.

 And, Laszlo, is this really that urgent that you'd rather duplicate a
 driver under the platform rather than allowing for some discussion on
 a possible common solution?

 I'm back from my PTO. After processing my email backlog, I can't find
 any news related to this patchset, so please consider it dropped, for
 the reasons described elsewhere in this thread.
 
 This continues to be very frustrating to me. I strongly disagree with
 forking this driver. I have instead argued that we should make other
 EDK II platforms use the same driver.
 
 But, it appears that Ray will not budge. (Or *something* is preventing
 us from coming up with a solution in PcAtChipsetPkg.) This is doubly
 frustrating since he is saying that we should keep the PcAtChipsetPkg
 version that no one else is using because 'maybe some closed source
 platform is using it'.
 
 I don't expect that the PcAtChipsetPkg version will ever be updated to
 allow OVMF to go back to using it at the common location. Instead, it
 will just be orphaned under PcAtChipsetPkg.
 
 I think Ray is just taking the easy/safe route with his decision. :(
 
 But, as much as this all annoys me, I find the prospect of you having
 to carry downstream patches for this even worse.

Me too, to be honest. :(

 
 I'm just having trouble giving a Reviewed-by or Acked-by for patches
 that are doing the opposite of what I want to happen.
 
 How about?
 Acked-under-duress-by: Jordan Justen jordan.l.jus...@intel.com
 
 Better yet, how about I say that I'm specifically not NAK'ing the
 patches, but I'd rather not have my name on them.

I understand completely. Let me post a version 3 shortly, that leaves
PcAtChipSetPkg alone (dropping patch #2), and updates the final
bootorderlib patch slightly (as I promised earlier).

Then you could skim the series, and respond with your

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

formally.

Or, if you don't want your name on it even in that double negative form,
you could state the same on the mailing list only informally.

(I'd prefer an explicit Not-nacked-by from you, under the circumstances,
because that makes it clear in the commit history that you looked at the
patches, and it points out your disagreement with some of the aspects.
Otherwise the commit messages would (incorrectly) imply that I just went
ahead and committed the patches without any feedback.)

Would this work? Not-nacked-by is not the most traditional tag,
admittedly, but the circumstances aren't either.

Thanks!
Laszlo

 -Jordan
 
 We'll carry the patches (with slight updates) in our downstream OVMF
 package, for https://bugzilla.redhat.com/show_bug.cgi?id=1193080.

 I'll ask Gerd too to add them to his https://www.kraxel.org/repos/
 builds, for the benefit of the wider public.


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 1/3] ArmVirtPkg: Make terminal type consistent

[Laszlo Ersek]

comments below

On 07/07/15 18:56, Heyi Guo wrote:
 Change default terminal type to be VT100, to make it consistent with
 default ConIn/ConOut device path.
 
 I can't say this is a bug, as we can pass the whole console device
 path to ConnectController, and TerminalDxe driver will pick up the
 terminal in the remaining device path. However, in rare circumstances,
 the console devices may be disconnected with the driver, and they will
 be ignored by ConPlatformDxe until we pass the device path explicitly
 just as BDS.
 
 Changing default terminal type to be the same with console device
 path could help serial terminal be reconnected with normal connect
 controller operation.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Heyi Guo heyi@linaro.org
 ---
  ArmVirtPkg/ArmVirtQemu.dsc | 2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
 index 0671469..0f104f3 100644
 --- a/ArmVirtPkg/ArmVirtQemu.dsc
 +++ b/ArmVirtPkg/ArmVirtQemu.dsc
 @@ -140,6 +140,8 @@
#

 gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()

 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()
 +  ## Terminal Type - VT100, consistent with ConOut/ConIn Device Path.
 +  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3
  
#
 

(1) When you mention that this brings the default terminal type in
accordance with the PCDs visible just above it: those PCDs are only used
by the ARM BDS. When ArmVirtQemu.dsc is built with -D INTEL_BDS, those
PCDs are not used.

The device path used for all of the consoles in case of -D INTEL_BDS is
hardcoded in the source. That device path happens to spceify VT100 too,
but the commit message doesn't reflect -D INTEL_BDS.

(2) This patch should be rebased on Roy's recent patch set

  [PATCH V2 0/4] Add TtyTerm terminal type
  http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16769

In particular, *if* we're doing this, then PcdDefaultTerminalType should
be kept in sync with the devpath that is in effect with

  -D TTY_TERMINAL -D INTEL_BDS

(please refer to patch #4 in Roy's series). Meaning, the
PcdDefaultTerminalType setting will have to depend on TTY_TERMINAL too.

So, ultimately, I think you need three separate cases:

(a) !INTEL_BDS   -- VT100TYPE   (value 1)
(b)  INTEL_BDS  !TTY_TERMINAL  -- VT100TYPE   (value 1)
(c)  INTEL_BDS   TTY_TERMINAL  -- TTYTERMTYPE (value 4)

Again, this should be implemented on top of Roy's patch series.

Thanks
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 1/3] ArmVirtPkg: Make terminal type consistent

[Laszlo Ersek]

On 07/07/15 22:16, Roy Franz wrote:
 On Tue, Jul 7, 2015 at 11:47 AM, Laszlo Ersek ler...@redhat.com wrote:
 comments below

 On 07/07/15 18:56, Heyi Guo wrote:
 Change default terminal type to be VT100, to make it consistent with
 default ConIn/ConOut device path.

 I can't say this is a bug, as we can pass the whole console device
 path to ConnectController, and TerminalDxe driver will pick up the
 terminal in the remaining device path. However, in rare circumstances,
 the console devices may be disconnected with the driver, and they will
 be ignored by ConPlatformDxe until we pass the device path explicitly
 just as BDS.

 Changing default terminal type to be the same with console device
 path could help serial terminal be reconnected with normal connect
 controller operation.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Heyi Guo heyi@linaro.org
 ---
  ArmVirtPkg/ArmVirtQemu.dsc | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
 index 0671469..0f104f3 100644
 --- a/ArmVirtPkg/ArmVirtQemu.dsc
 +++ b/ArmVirtPkg/ArmVirtQemu.dsc
 @@ -140,6 +140,8 @@
#

 gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()

 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()
 +  ## Terminal Type - VT100, consistent with ConOut/ConIn Device Path.
 +  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3

#


 (1) When you mention that this brings the default terminal type in
 accordance with the PCDs visible just above it: those PCDs are only used
 by the ARM BDS. When ArmVirtQemu.dsc is built with -D INTEL_BDS, those
 PCDs are not used.

 The device path used for all of the consoles in case of -D INTEL_BDS is
 hardcoded in the source. That device path happens to spceify VT100 too,
 but the commit message doesn't reflect -D INTEL_BDS.

 (2) This patch should be rebased on Roy's recent patch set

   [PATCH V2 0/4] Add TtyTerm terminal type
   http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16769

 In particular, *if* we're doing this, then PcdDefaultTerminalType should
 be kept in sync with the devpath that is in effect with

   -D TTY_TERMINAL -D INTEL_BDS

 (please refer to patch #4 in Roy's series). Meaning, the
 PcdDefaultTerminalType setting will have to depend on TTY_TERMINAL too.

 So, ultimately, I think you need three separate cases:

 (a) !INTEL_BDS   -- VT100TYPE   (value 1)
 (b)  INTEL_BDS  !TTY_TERMINAL  -- VT100TYPE   (value 1)
 (c)  INTEL_BDS   TTY_TERMINAL  -- TTYTERMTYPE (value 4)

 Again, this should be implemented on top of Roy's patch series.

 Thanks
 Laszlo
 
 Hi Heyi,
 
   Also, there is currently no support for text-guid conversion for
 the tty terminal type, so you will need to use the
 VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)
 path element in place of VenVt100()

Sorry, I don't understand; in which case is a VenMsg() textual
representation necessary?

All I had in mind was that

  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1

vs.

  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|4

should be added several times, in accordance with the above conditions.
As far as I understand, the textual representation of any device path is
irrelevant here.

Thanks
Laszlo

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH V2 3/4] Accept VT220 DEL and function keys for TTY terminal type

[Laszlo Ersek]

On 07/07/15 22:25, Ard Biesheuvel wrote:
 On 7 July 2015 at 22:07, Roy Franz roy.fr...@linaro.org wrote:
 On Tue, Jul 7, 2015 at 6:18 AM, Ard Biesheuvel
 ard.biesheu...@linaro.org wrote:
 On 7 July 2015 at 01:04, Roy Franz roy.fr...@linaro.org wrote:
 Accept the VT220 escape code [3~ as backspace for TtyTerm terminals.  This 
 is
 sent by many Linux terminals by default.  Also accept VT220 function keys
 F1-F12, and VT100 F1-F4 keys as these are commonly sent by Linux terminals.
 The VT220 escape codes are longer, and variable length so a new state is 
 added
 to the state machine along with a variable to construct the multibyte 
 escape
 sequence.
 There are currently no ambiguous escape sequence prefixes accepted, so the 
 TTY
 terminal accepts escape sequences for a variety of terminals.  The goal is 
 to
 'just work' with as many terminals as possible, rather than properly 
 emulating
 any specific terminal.  Backspace, Del, and F10 have been tested on xterm,
 rxvt, tmux, and screen.
 Note: The existing vt100 function key handling does not match the vt100
 documentation that I found, so I added the TTY terminal handling
 of VT100 F1-F4 (really PF1-PF4 on vt100) separately.  The vt100
 has no F5-F10 keys, so I don't know what the current vt100 code
 is based on.

 Signed-off-by: Roy Franz roy.fr...@linaro.org
 Contributed-under: TianoCore Contribution Agreement 1.0

 Same here ^^^
 (and in patch 1/4)

 I'll fix this here and in the other patches.  Maybe I should re-read
 my contributions.txt patch so I get this right :)
 
 :-)
 

 ---
  MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h  |  1 +
  MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c | 95 
 +++-
  2 files changed, 95 insertions(+), 1 deletion(-)

 diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h 
 b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
 index 03542a4..4616ab3 100644
 --- a/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
 +++ b/MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
 @@ -118,6 +118,7 @@ typedef struct {
  #define INPUT_STATE_LEFTOPENBRACKET   0x04
  #define INPUT_STATE_O 0x08
  #define INPUT_STATE_2 0x10
 +#define INPUT_STATE_LEFTOPENBRACKET_2 0x20

  #define RESET_STATE_DEFAULT   0x00
  #define RESET_STATE_ESC_R 0x01
 diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c 
 b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
 index 227df85..12e7f9f 100644
 --- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
 +++ b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
 @@ -1182,6 +1182,8 @@ UnicodeToEfiKey (
UINT16  UnicodeChar;
EFI_INPUT_KEY   Key;
BOOLEAN SetDefaultResetState;
 +  static UINT16   TtyEscapeStr[3];
 +  static INTN TtyEscapeIndex;


 Is this guaranteed to be safe?
 I'm assuming you mean the length of 3? (for 2 characters + NUL termination)
 I think it is.

 
 No, I mean the static. I know UEFI is single threaded, but it has an
 event model that could potentially result in functions being called in
 a reentrant fashion. I think this can only happen in functions that
 signal events themselves, but I am not intimate enough with this stuff
 to claim that this is 100%  safe.

Sorry, I have not been following the discussion of these three other
patches. But, we can see that the call chain for this function is:

TerminalConInTimerHandler()
  TranslateRawDataToEfiKey()
UnicodeToEfiKey()

and TerminalConInTimerHandler() is set up as a periodic callback in
TerminalDriverBindingStart(). (That is, the Start() method of the UEFI
driver binding protocol.)

Furthermore, the context for TerminalConInTimerHandler() is
TerminalDevice (of type TERMINAL_DEV), which is the wrapper structure
(container) for the bunch of protocol interfaces that the driver
implements for a given terminal *instance*.

This means that all long-lived state, handled in UnicodeToEfiKey(), must
be terminal instance specific, and live inside the TERMINAL_DEV structure.

Thanks
Laszlo

 
 I do the following when the INPUT_STATE_LEFTOPENBRACKET_2 is entered:
 +TtyEscapeStr[0] = UnicodeChar;
 +TtyEscapeIndex = 1;

 When any additional escape sequence characters are processed any values
 of TtyEscapeIndex other than 1 or 2 are errors.  If we got an escape sequence
 that was too long, we will go back to the RESET_STATE_DEFAULT state,
 and TtyEscape* will be re-initialized when the INPUT_STATE_LEFTOPENBRACKET_2
 state is entered.

 There is only 1 place where  INPUT_STATE_LEFTOPENBRACKET_2 is entered,
 and both TtyEscape* variables are initialized there, and only valid
 (ie Index of 1 or 2)
 index values are processed once in INPUT_STATE_LEFTOPENBRACKET_2.

 I can add some comments to this effect if you think it is worthwhile.



TimerStatus = gBS-CheckEvent (TerminalDevice-TwoSecondTimeOut);

 @@ 

[edk2] [PATCH v3 03/23] PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.h: rewrap comments to 79 columns

[Laszlo Ersek]

Cc: Ruiyu Ni ruiyu...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
Regression-tested-by: Gabriel Somlo so...@cmu.edu
Reviewed-by: Ruiyu Ni ruiyu...@intel.com
---

Notes:
v3:
- rewrap the driver under PcAtChipsetPkg

 PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.h | 590 
 1 file changed, 372 insertions(+), 218 deletions(-)

diff --git a/PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.h 
b/PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.h
index f9ef7d8..59f47e7 100644
--- a/PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.h
+++ b/PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.h
@@ -1,16 +1,16 @@
 /** @file
-  The Header file of the Pci Host Bridge Driver 
+  The Header file of the Pci Host Bridge Driver
 
   Copyright (c) 2008 - 2010, Intel Corporation. All rights reserved.BR
-  This program and the accompanying materials are
-  licensed and made available under the terms and conditions of the BSD License
-  which accompanies this distribution.  The full text of the license may be 
found at
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution.  The full text of the license may be found at
   http://opensource.org/licenses/bsd-license.php
-  
+
   THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
   WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/ 
+**/
 
 #ifndef _PCI_HOST_BRIDGE_H_
 #define _PCI_HOST_BRIDGE_H_
@@ -72,68 +72,114 @@ typedef struct {
 //
 
 /**
-   These are the notifications from the PCI bus driver that it is about to 
enter a certain
-   phase of the PCI enumeration process.
-
-   This member function can be used to notify the host bridge driver to 
perform specific actions,
-   including any chipset-specific initialization, so that the chipset is ready 
to enter the next phase.
-   Eight notification points are defined at this time. See belows:
-   EfiPciHostBridgeBeginEnumeration   Resets the host bridge PCI apertures 
and internal data
-  structures. The PCI enumerator 
should issue this notification
-  before starting a fresh enumeration 
process. Enumeration cannot
-  be restarted after sending any other 
notification such as
-  EfiPciHostBridgeBeginBusAllocation.
-   EfiPciHostBridgeBeginBusAllocation The bus allocation phase is about to 
begin. No specific action is
-  required here. This notification can 
be used to perform any
-  chipset-specific programming.
-   EfiPciHostBridgeEndBusAllocation   The bus allocation and bus 
programming phase is complete. No
-  specific action is required here. 
This notification can be used to
-  perform any chipset-specific 
programming.
-   EfiPciHostBridgeBeginResourceAllocation
-  The resource allocation phase is 
about to begin. No specific
-  action is required here. This 
notification can be used to perform
-  any chipset-specific programming.
-   EfiPciHostBridgeAllocateResources  Allocates resources per previously 
submitted requests for all the PCI
-  root bridges. These resource 
settings are returned on the next call to
-  GetProposedResources(). Before 
calling NotifyPhase() with a Phase of
-  EfiPciHostBridgeAllocateResource, 
the PCI bus enumerator is responsible
-  for gathering I/O and memory 
requests for
-  all the PCI root bridges and 
submitting these requests using
-  SubmitResources(). This function 
pads the resource amount
-  to suit the root bridge hardware, 
takes care of dependencies between
-  the PCI root bridges, and calls the 
Global Coherency Domain (GCD)
-  with the allocation request. In the 
case of padding, the allocated range
-  could be bigger than what was 
requested.
-   EfiPciHostBridgeSetResources   Programs the host bridge hardware to 
decode previously allocated
-  resources (proposed resources) for 
all the PCI root bridges. After the
-  hardware is programmed, reassigning 
resources will not be supported

[edk2] [PATCH v3 01/23] PcAtChipsetPkg: PciHostBridgeDxe: rewrap IoFifo source files to 79 columns

[Laszlo Ersek]

Cc: Ruiyu Ni ruiyu...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
Regression-tested-by: Gabriel Somlo so...@cmu.edu
Reviewed-by: Ruiyu Ni ruiyu...@intel.com
---

Notes:
v3:
- rewrap the driver under PcAtChipsetPkg

 PcAtChipsetPkg/PciHostBridgeDxe/IoFifo.h| 11 ++-
 PcAtChipsetPkg/PciHostBridgeDxe/Ia32/IoFifo.S   |  7 ---
 PcAtChipsetPkg/PciHostBridgeDxe/Ia32/IoFifo.asm |  7 ---
 PcAtChipsetPkg/PciHostBridgeDxe/X64/IoFifo.S|  7 ---
 PcAtChipsetPkg/PciHostBridgeDxe/X64/IoFifo.asm  |  7 ---
 5 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/PcAtChipsetPkg/PciHostBridgeDxe/IoFifo.h 
b/PcAtChipsetPkg/PciHostBridgeDxe/IoFifo.h
index 5d48bf5..9978f8b 100644
--- a/PcAtChipsetPkg/PciHostBridgeDxe/IoFifo.h
+++ b/PcAtChipsetPkg/PciHostBridgeDxe/IoFifo.h
@@ -2,15 +2,16 @@
   I/O FIFO routines
 
   Copyright (c) 2008 - 2012, Intel Corporation. All rights reserved.BR
-  This program and the accompanying materials are
-  licensed and made available under the terms and conditions of the BSD License
-  which accompanies this distribution.  The full text of the license may be 
found at
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution.  The full text of the license may be found at
   http://opensource.org/licenses/bsd-license.php
-  
+
   THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
   WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
-**/ 
+**/
 
 #ifndef _IO_FIFO_H_INCLUDED_
 #define _IO_FIFO_H_INCLUDED_
diff --git a/PcAtChipsetPkg/PciHostBridgeDxe/Ia32/IoFifo.S 
b/PcAtChipsetPkg/PciHostBridgeDxe/Ia32/IoFifo.S
index 6b9c096..03a014d 100644
--- a/PcAtChipsetPkg/PciHostBridgeDxe/Ia32/IoFifo.S
+++ b/PcAtChipsetPkg/PciHostBridgeDxe/Ia32/IoFifo.S
@@ -1,9 +1,10 @@
 #--
 #
 # Copyright (c) 2006 - 2012, Intel Corporation. All rights reserved.BR
-# This program and the accompanying materials
-# are licensed and made available under the terms and conditions of the BSD 
License
-# which accompanies this distribution.  The full text of the license may be 
found at
+#
+# This program and the accompanying materials are licensed and made available
+# under the terms and conditions of the BSD License which accompanies this
+# distribution.  The full text of the license may be found at
 # http://opensource.org/licenses/bsd-license.php.
 #
 # THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
diff --git a/PcAtChipsetPkg/PciHostBridgeDxe/Ia32/IoFifo.asm 
b/PcAtChipsetPkg/PciHostBridgeDxe/Ia32/IoFifo.asm
index 4b147cb..b1cc25e 100644
--- a/PcAtChipsetPkg/PciHostBridgeDxe/Ia32/IoFifo.asm
+++ b/PcAtChipsetPkg/PciHostBridgeDxe/Ia32/IoFifo.asm
@@ -1,9 +1,10 @@
 ;--
 ;
 ; Copyright (c) 2006 - 2012, Intel Corporation. All rights reserved.BR
-; This program and the accompanying materials
-; are licensed and made available under the terms and conditions of the BSD 
License
-; which accompanies this distribution.  The full text of the license may be 
found at
+;
+; This program and the accompanying materials are licensed and made available
+; under the terms and conditions of the BSD License which accompanies this
+; distribution.  The full text of the license may be found at
 ; http://opensource.org/licenses/bsd-license.php.
 ;
 ; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
diff --git a/PcAtChipsetPkg/PciHostBridgeDxe/X64/IoFifo.S 
b/PcAtChipsetPkg/PciHostBridgeDxe/X64/IoFifo.S
index ca484f5..decb382 100644
--- a/PcAtChipsetPkg/PciHostBridgeDxe/X64/IoFifo.S
+++ b/PcAtChipsetPkg/PciHostBridgeDxe/X64/IoFifo.S
@@ -1,9 +1,10 @@
 #--
 #
 # Copyright (c) 2006 - 2012, Intel Corporation. All rights reserved.BR
-# This program and the accompanying materials
-# are licensed and made available under the terms and conditions of the BSD 
License
-# which accompanies this distribution.  The full text of the license may be 
found at
+#
+# This program and the accompanying materials are licensed and made available
+# under the terms and conditions of the BSD License which accompanies this
+# distribution.  The full text of the license may be found at
 # http://opensource.org/licenses/bsd-license.php.
 #
 # THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
diff --git a/PcAtChipsetPkg/PciHostBridgeDxe/X64/IoFifo.asm 
b/PcAtChipsetPkg/PciHostBridgeDxe/X64/IoFifo.asm
index d16f024..1a3f0ef 100644
--- a/PcAtChipsetPkg/PciHostBridgeDxe/X64/IoFifo.asm
+++ b/PcAtChipsetPkg/PciHostBridgeDxe/X64/IoFifo.asm
@@ -1,9 +1,10

[edk2] [PATCH v3 04/23] PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.h: strip trailing ws from code

[Laszlo Ersek]

Cc: Ruiyu Ni ruiyu...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
Regression-tested-by: Gabriel Somlo so...@cmu.edu
Reviewed-by: Ruiyu Ni ruiyu...@intel.com
---

Notes:
v3:
- rewrap the driver under PcAtChipsetPkg

 PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.h | 34 ++--
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.h 
b/PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.h
index 59f47e7..f475eb7 100644
--- a/PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.h
+++ b/PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.h
@@ -59,14 +59,14 @@ typedef struct {
   EFI_HANDLEHostBridgeHandle;
   UINTN RootBridgeNumber;
   LIST_ENTRYHead;
-  BOOLEAN   ResourceSubmited;  
-  BOOLEAN   CanRestarted;  
+  BOOLEAN   ResourceSubmited;
+  BOOLEAN   CanRestarted;
   EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL  ResAlloc;
 } PCI_HOST_BRIDGE_INSTANCE;
 
 #define INSTANCE_FROM_RESOURCE_ALLOCATION_THIS(a) \
   CR(a, PCI_HOST_BRIDGE_INSTANCE, ResAlloc, PCI_HOST_BRIDGE_SIGNATURE)
-  
+
 //
 //  HostBridge Resource Allocation interface
 //
@@ -551,13 +551,13 @@ typedef struct {
 
 typedef struct {
   UINT64  BusBase;
-  UINT64  BusLimit; 
-  
-  UINT64  MemBase; 
-  UINT64  MemLimit;
-  
-  UINT64  IoBase; 
-  UINT64  IoLimit; 
+  UINT64  BusLimit;
+
+  UINT64  MemBase;
+  UINT64  MemLimit;
+
+  UINT64  IoBase;
+  UINT64  IoLimit;
 } PCI_ROOT_BRIDGE_RESOURCE_APERTURE;
 
 typedef enum {
@@ -595,21 +595,21 @@ typedef struct {
   UINT64 RootBridgeAttrib;
   UINT64 Attributes;
   UINT64 Supports;
-  
+
   //
   // Specific for this memory controller: Bus, I/O, Mem
   //
   PCI_RES_NODE   ResAllocNode[6];
-  
+
   //
   // Addressing for Memory and I/O and Bus arrange
   //
   UINT64 BusBase;
-  UINT64 MemBase; 
-  UINT64 IoBase; 
-  UINT64 BusLimit; 
-  UINT64 MemLimit;
-  UINT64 IoLimit; 
+  UINT64 MemBase;
+  UINT64 IoBase;
+  UINT64 BusLimit;
+  UINT64 MemLimit;
+  UINT64 IoLimit;
 
   EFI_DEVICE_PATH_PROTOCOL*DevicePath;
   EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL Io;
-- 
1.8.3.1



--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v3 07/23] PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c: rewrap leading comments

[Laszlo Ersek]

Cc: Ruiyu Ni ruiyu...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
Regression-tested-by: Gabriel Somlo so...@cmu.edu
Reviewed-by: Ruiyu Ni ruiyu...@intel.com
---

Notes:
v3:
- rewrap the driver under PcAtChipsetPkg

 PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c | 1841 
 1 file changed, 1133 insertions(+), 708 deletions(-)

diff --git a/PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c 
b/PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c
index 7986550..a386130 100644
--- a/PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c
+++ b/PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c
@@ -1,16 +1,16 @@
 /** @file
   PCI Root Bridge Io Protocol implementation
 
-Copyright (c) 2008 - 2012, Intel Corporation. All rights reserved.BR
-This program and the accompanying materials are
-licensed and made available under the terms and conditions of the BSD License
-which accompanies this distribution.  The full text of the license may be 
found at
-http://opensource.org/licenses/bsd-license.php
+  Copyright (c) 2008 - 2012, Intel Corporation. All rights reserved.BR
 
-THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
-WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution.  The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
 
-**/ 
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS, WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
 
 #include PciHostBridge.h
 #include IoFifo.h
@@ -35,33 +35,48 @@ RESOURCE_CONFIGURATION Configuration = {
 //
 
 /**
-   Polls an address in memory mapped I/O space until an exit condition is met, 
or 
-   a timeout occurs. 
-
-   This function provides a standard way to poll a PCI memory location. A PCI 
memory read
-   operation is performed at the PCI memory address specified by Address for 
the width specified
-   by Width. The result of this PCI memory read operation is stored in Result. 
This PCI memory
-   read operation is repeated until either a timeout of Delay 100 ns units has 
expired, or (Result 
-   Mask) is equal to Value.
-
-   @param[in]   This  A pointer to the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.
-   @param[in]   Width Signifies the width of the memory operations.
-   @param[in]   Address   The base address of the memory operations. The 
caller is
-  responsible for aligning Address if required.
-   @param[in]   Mask  Mask used for the polling criteria. Bytes above 
Width in Mask
-  are ignored. The bits in the bytes below Width which 
are zero in
-  Mask are ignored when polling the memory address.
-   @param[in]   Value The comparison value used for the polling exit 
criteria.
-   @param[in]   Delay The number of 100 ns units to poll. Note that timer 
available may
-  be of poorer granularity.
-   @param[out]  ResultPointer to the last value read from the memory 
location.
-   
-   @retval EFI_SUCCESSThe last data returned from the access 
matched the poll exit criteria.
-   @retval EFI_INVALID_PARAMETER  Width is invalid.
-   @retval EFI_INVALID_PARAMETER  Result is NULL.
-   @retval EFI_TIMEOUTDelay expired before a match occurred.
-   @retval EFI_OUT_OF_RESOURCES   The request could not be completed due to a 
lack of resources.
+  Polls an address in memory mapped I/O space until an exit condition is met,
+  or a timeout occurs.
 
+  This function provides a standard way to poll a PCI memory location. A PCI
+  memory read operation is performed at the PCI memory address specified by
+  Address for the width specified by Width. The result of this PCI memory read
+  operation is stored in Result. This PCI memory read operation is repeated
+  until either a timeout of Delay 100 ns units has expired, or (Result  Mask)
+  is equal to Value.
+
+  @param[in]   This  A pointer to the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.
+
+  @param[in]   Width Signifies the width of the memory operations.
+
+  @param[in]   Address   The base address of the memory operations. The caller
+ is responsible for aligning Address if required.
+
+  @param[in]   Mask  Mask used for the polling criteria. Bytes above Width
+ in Mask are ignored. The bits in the bytes below Width
+ which are zero in Mask are ignored when polling the
+ memory address.
+
+  @param[in]   Value The comparison value used for the polling exit
+ criteria.
+
+  @param[in]   Delay The number of 100 ns units to poll. Note that timer

[edk2] [PATCH v3 00/23] OvmfPkg: support extra PCI root buses

[Laszlo Ersek]

Changes in v3 (also noted per patch):

- The PciHostBridgeDxe driver is now rewrapped to 79 columns in its
  original place, under PcAtChipsetPkg. No other (ie. no functional)
  changes are made to PcAtChipsetPkg/PciHostBridgeDxe. The clone under
  OvmfPkg is created from the rewrapped source code.

- The very last patch has been updated to the most recently agreed upon
  OFW notation for extra root buses.

Public branch:
https://github.com/lersek/edk2/commits/multiple_root_bridges_bz1193080_v3

Cc: Jordan Justen jordan.l.jus...@intel.com
Cc: Ruiyu Ni ruiyu...@intel.com
Cc: Gabriel Somlo so...@cmu.edu

Laszlo Ersek (23):
  PcAtChipsetPkg: PciHostBridgeDxe: rewrap IoFifo source files to 79
columns
  PcAtChipsetPkg: PciHostBridgeDxe: rewrap INF file to 79 columns
  PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.h: rewrap comments to 79
columns
  PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.h: strip trailing ws
from code
  PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.c: rewrap leading
comments
  PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.c: rewrap code, strip
trailing ws
  PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c: rewrap leading
comments
  PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c: rewrap code, strip
trailing ws
  OvmfPkg: clone PciHostBridgeDxe from PcAtChipsetPkg
  OvmfPkg: PlatformBdsLib: debug log interrupt line assignments
  OvmfPkg: PlatformBdsLib: refine PCI host bridge assertion
  OvmfPkg: PlatformBdsLib: connect all PCI root buses
  OvmfPkg: PciHostBridgeDxe: eliminate nominal support for multiple host
bridges
  OvmfPkg: PciHostBridgeDxe: kill RootBridgeNumber and
RootBridgeAttribute
  OvmfPkg: PciHostBridgeDxe: embed device path in private root bridge
struct
  OvmfPkg: PciHostBridgeDxe: factor out InitRootBridge() function
  OvmfPkg: PciHostBridgeDxe: release resources on driver entry failure
  OvmfPkg: PciHostBridgeDxe: use private buffer in
RootBridgeIoConfiguration()
  OvmfPkg: PciHostBridgeDxe: eliminate
PCI_HOST_BRIDGE_INSTANCE.RootBridgeNumber
  OvmfPkg: PciHostBridgeDxe: look for all root buses
  OvmfPkg: PciHostBridgeDxe: shorten search for extra root buses
  OvmfPkg: QemuBootOrderLib: introduce ExtraRootBusMap
  OvmfPkg: QemuBootOrderLib: recognize extra PCI root buses

 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c  |   88 +-
 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h  |   25 +-
 OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf |2 +-
 OvmfPkg/Library/PlatformBdsLib/PlatformData.c |   13 -
 OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.c|  313 +++
 OvmfPkg/Library/QemuBootOrderLib/ExtraRootBusMap.h|   40 +
 OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c   |  152 +-
 OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf |6 +
 OvmfPkg/OvmfPkgIa32.dsc   |2 +-
 OvmfPkg/OvmfPkgIa32.fdf   |2 +-
 OvmfPkg/OvmfPkgIa32X64.dsc|2 +-
 OvmfPkg/OvmfPkgIa32X64.fdf|2 +-
 OvmfPkg/OvmfPkgX64.dsc|2 +-
 OvmfPkg/OvmfPkgX64.fdf|2 +-
 OvmfPkg/PciHostBridgeDxe/PciHostBridge.c  | 1551 

 OvmfPkg/PciHostBridgeDxe/PciHostBridge.h  |  651 +
 OvmfPkg/PciHostBridgeDxe/PciRootBridgeIo.c| 2628 

 PcAtChipsetPkg/PciHostBridgeDxe/Ia32/IoFifo.S |7 +-
 PcAtChipsetPkg/PciHostBridgeDxe/Ia32/IoFifo.asm   |7 +-
 PcAtChipsetPkg/PciHostBridgeDxe/IoFifo.h  |   11 +-
 PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.c   |  976 
+---
 PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.h   |  624 +++--
 PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridgeDxe.inf  |   13 +-
 PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c | 2054 
+--
 PcAtChipsetPkg/PciHostBridgeDxe/X64/IoFifo.S  |7 +-
 PcAtChipsetPkg/PciHostBridgeDxe/X64/IoFifo.asm|7 +-
 {PcAtChipsetPkg = OvmfPkg}/PciHostBridgeDxe/Ia32/IoFifo.S|7 +-
 {PcAtChipsetPkg = OvmfPkg}/PciHostBridgeDxe/Ia32/IoFifo.asm  |7 +-
 {PcAtChipsetPkg = OvmfPkg}/PciHostBridgeDxe/IoFifo.h |   11 +-
 {PcAtChipsetPkg = OvmfPkg}/PciHostBridgeDxe/PciHostBridgeDxe.inf |   21 +-
 {PcAtChipsetPkg = OvmfPkg}/PciHostBridgeDxe/X64/IoFifo.S |7 +-
 {PcAtChipsetPkg = OvmfPkg}/PciHostBridgeDxe/X64/IoFifo.asm   |7 +-
 32 files changed, 7669 insertions(+), 1578 deletions(-)
 copy {PcAtChipsetPkg = OvmfPkg}/PciHostBridgeDxe/Ia32/IoFifo.S (90%)
 copy {PcAtChipsetPkg = OvmfPkg}/PciHostBridgeDxe/Ia32