Re: [edk2-devel] [PATCH] Maintainers.txt: Add new reviewer for UefiPayloadPkg

[Sean Rhodes]

Reviewed -by: Sean Rhodes 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86957): https://edk2.groups.io/g/devel/message/86957
Mute This Topic: https://groups.io/mt/89353894/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] MdeModulePkg/Usb/Keyboard.c: Don't request protocol before setting

[Sean Rhodes]

No need to check the interface protocol then conditionally setting,
just set it to BOOT_PROTOCOL and check for error.

This is what Linux does for HID devices as some don't follow the USB spec.
One example is the Aspeed BMC HID keyboard device, which adds a massive
boot delay without this patch as it doesn't respond to 'GetProtocolRequest'.

Cc: Hao A Wu 
Cc: Ray Ni 
Signed-off-by: Matt DeVillier 
Signed-off-by: Patrick Rudolph 
Signed-off-by: Sean Rhodes 
---
 MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c 
b/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
index 5a94a4dda7..73b5df2b64 100644
--- a/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
+++ b/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
@@ -854,22 +854,15 @@ InitUSBKeyboard (
 }
   }
 
-  UsbGetProtocolRequest (
-UsbKeyboardDevice->UsbIo,
-UsbKeyboardDevice->InterfaceDescriptor.InterfaceNumber,
-&Protocol
-);
   //
   // Set boot protocol for the USB Keyboard.
   // This driver only supports boot protocol.
   //
-  if (Protocol != BOOT_PROTOCOL) {
-UsbSetProtocolRequest (
-  UsbKeyboardDevice->UsbIo,
-  UsbKeyboardDevice->InterfaceDescriptor.InterfaceNumber,
-  BOOT_PROTOCOL
-  );
-  }
+  UsbSetProtocolRequest (
+UsbKeyboardDevice->UsbIo,
+UsbKeyboardDevice->InterfaceDescriptor.InterfaceNumber,
+BOOT_PROTOCOL
+);
 
   UsbKeyboardDevice->CtrlOn= FALSE;
   UsbKeyboardDevice->AltOn = FALSE;
-- 
2.32.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86958): https://edk2.groups.io/g/devel/message/86958
Mute This Topic: https://groups.io/mt/89228276/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/5] OvmfPkg: Make the Xen ELF header generator more flexible

[Gerd Hoffmann]

On Wed, Feb 23, 2022 at 05:51:26PM +0100, sebastien.bo...@intel.com wrote:
> From: Sebastien Boeuf 
> 
> Adding some flexibility to the program so that other targets can use it
> if needed.
> 
> An optional size parameter is added so that we can provide the expected
> blob size of the generated binary.
> 
> A global define is added so that we can choose at build time if we want
> to use 32-bit or 64-bit bases structures.
> 
> The default behavior isn't modified.

Acked-by: Gerd Hoffmann 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86959): https://edk2.groups.io/g/devel/message/86959
Mute This Topic: https://groups.io/mt/89345229/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 2/5] OvmfPkg: Generate CloudHv as a PVH ELF binary

[Gerd Hoffmann]

  Hi,

> -!include OvmfPkg/VarStore.fdf.inc
> +!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
> +0x|0xe000
> +!endif
> +!if $(FD_SIZE_IN_KB) == 4096
> +0x|0x0004
> +!endif

Hmm, VarStore.fdf.inc reduces duplication, and now you revert this.
Maybe add this to VarStore.fdf.inc instead, and add a PVH_HEADER_ENABLE
option to turn it on and off?

Also: With this in place the start of the vars firmware volume moves
because it's prefixed by the elf header.  Does that work without code
changes?

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86960): https://edk2.groups.io/g/devel/message/86960
Mute This Topic: https://groups.io/mt/89345268/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] Reconfigure OpensslLib to add elliptic curve chipher algorithms

[yi1 li]

Hi Vineel,

Code is good to me, just some BKM for edk2 upstream:


  1.  It's a little strange that there are submodule changes in the patch 0004, 
maybe you forget to run git submodule update:

diff --git a/BaseTools/Source/C/BrotliCompress/brotli 
b/BaseTools/Source/C/BrotliCompress/brotli

index f4153a09f8..666c3280cc 16

--- a/BaseTools/Source/C/BrotliCompress/brotli

+++ b/BaseTools/Source/C/BrotliCompress/brotli



  1.  Good commit titles and comments can get feedback from the community more 
quickly and more accurately, refer: 
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format,

And CC Maintainers about changed pkg in commit will remind relevant people to 
review the code as soon as possible, you can find them at: 
https://github.com/tianocore/edk2/blob/master/Maintainers.txt,

A demo:



CryptoPkg: Enable ECC ciphers



REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3679



Reconfigure OpenSSLLib to add elliptic curve ciphers  # detail info



Cc: Vineel Kovvuri 

Cc: # Maintainers or other people you want to Cc

Signed-off-by: Vineel Kovvuri 



  1.  According to 2, it is best to split the changes of different PKGs, such 
in patch 0003.


  1.  Extra spaces or tabs can cause formatting errors in CI, make sure there 
are no unnecessary changes in the patch. Such:

#ifndef OSSL_CRYPTO_DSO_CONF_H
-#define OSSL_CRYPTO_DSO_CONF_H
-#define DSO_NONE
-#define DSO_EXTENSION  ".so"
+# define OSSL_CRYPTO_DSO_CONF_H
+# define DSO_NONE
+# define DSO_EXTENSION ".so"
#endif

You can submit PR to edk2 mater branch directly to check for CI bugs(will not 
be reviewed or merged).


Thanks!
Yi Li
From: vineelko via groups.io 
Sent: Thursday, February 24, 2022 2:51 PM
To: Li, Yi1 ; devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH 1/2] Reconfigure OpensslLib to add elliptic 
curve chipher algorithms

Hi Yi Li,

I have posted the recent patch set to enable ECC ciphers in OpenSSLLib to the 
bug https://bugzilla.tianocore.org/show_bug.cgi?id=3679

I have ran the entire OVMF Azure pipeline locally and confirm that the code 
gets build without any issue. Thanks for the inputs after enlarging DXEFV the 
build succeeded.

I am new to EDK build and to the overall process so please review the patch set 
and provide your comments. I am happy to address them. Once reviewed I can add 
it to the proposed feature to the release planning wiki
0001-Crypto-Enable-ECC-ciphers.patch
0002-Port-VsIntrinsicLib-from-Project-Mu.patch
0003-Reference-VsIntrinsicLib.patch
0004-Increase-FV-size.patch

Thanks,
Vineel


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86961): https://edk2.groups.io/g/devel/message/86961
Mute This Topic: https://groups.io/mt/86257810/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-non-osi][PATCH 1/1] Drivers/Realtek: Including Realtek driver to enable network support

[Ard Biesheuvel]

On Wed, 16 Feb 2022 at 16:37, Himanshu Sharma  wrote:
>
> This patch adds the generic Realtek PCIe UNDI Driver version 2.057
> driver binary to edk2-non-osi that can be made available to use for
> the platforms that use Realtek's network controller
>
> This is a Aarch64 binary, available at:
> https://www.realtek.com/en/directly-download?downloadid=b0c3e46b2831dcab4edfecce06f15a4f
>
> Signed-off-by: Himanshu Sharma 

Where did you obtain the License text? Can we get anyone from Realtek
to publicly endorse this contribution?


> ---
>  Drivers/Realtek/Bus/Pcie/PcieNetworking/RtkUndiDxe.inf |  24 
> 
>  Drivers/Realtek/Bus/Pcie/PcieNetworking/AArch64/RtkUndiDxe.efi | Bin 0 -> 
> 132456 bytes
>  Drivers/Realtek/Bus/Pcie/PcieNetworking/License.txt|  23 
> +++
>  3 files changed, 47 insertions(+)
>
> diff --git a/Drivers/Realtek/Bus/Pcie/PcieNetworking/RtkUndiDxe.inf 
> b/Drivers/Realtek/Bus/Pcie/PcieNetworking/RtkUndiDxe.inf
> new file mode 100644
> index ..63ca0e0803ea
> --- /dev/null
> +++ b/Drivers/Realtek/Bus/Pcie/PcieNetworking/RtkUndiDxe.inf
> @@ -0,0 +1,24 @@
> +#/** @file
> +#
> +#Copyright (c) 2022 Realtek Semiconductor Corp. All rights reserved.
> +#
> +#This program and the accompanying materials
> +#are licensed and made available under the terms and conditions of the 
> BSD License
> +#which accompanies this distribution. The full text of the license may 
> be found at
> +#http://opensource.org/licenses/bsd-license.php
> +#
> +#THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +#WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +#
> +#**/
> +
> +
> +[Defines]
> +  INF_VERSION= 1.27
> +  BASE_NAME  = RtkUndiDxe
> +  FILE_GUID  = 22DE1691-D65D-456A-993E-A253DD1F308C
> +  MODULE_TYPE= UEFI_DRIVER
> +  VERSION_STRING = 1.0
> +
> +[Binaries.AARCH64]
> +  PE32|AArch64/RtkUndiDxe.efi|*
> diff --git a/Drivers/Realtek/Bus/Pcie/PcieNetworking/AArch64/RtkUndiDxe.efi 
> b/Drivers/Realtek/Bus/Pcie/PcieNetworking/AArch64/RtkUndiDxe.efi
> new file mode 100644
> index 
> ..34d750e1b0abf9e7e6d6e7b4dbe4342d77b94bb3
> GIT binary patch
> literal 132456
> zcmeEv3wTu3wf{ad0nSW# zI{~eXVzIT#!`dd(_SV*C`j7 zehuGYX6?Q9+H0@9*4k^o&YX9N_}G8FAG_oyU+{vnh4@^2bQ zT3KchJ}1iWEl9P#yCj_c-^obK5TgF;E|Hm@b417@d!%fa2#iAB3x)_6 zgdwIKsmRAjud2KD@^d5gOHGy~Lu?z`q5l;L5k7In9?}
> zSGS@L*`F!Ef4hN0W*^6=_7@PM_rxz+h_a2Wl(e2Z46o|Ml@?wGvnB$M{E@Eq7Z9TA
> z#A`0U@(as_lo4em@dggZ(~AB3>&K8l-3~=4G=3^B7cai@C5*R&7 zZxEgG(=FmfLTnrq;sG;pR$@qq4aJ6t4Y) z-}f72xec!Vq8Q5+1&d=n6I%NI3+XI3LuB=Q}|pR-zu%8QXtDfOW@|F7B`W
> zdFO#kjm|?kB0)aHdl`xSZX^B%zIO}pFw z#bd1e$B-YM6-XRFxsJCp61@s%>rt_O8|R0_IWfTYKHxJ(v0kelw1H_wJ;ky9Q7wJ<
> z1Fz$4DVGOIihZ%YXip&MiW#D%&)gbFP&WI44_-ICNf|&+N zmhCt?7Sri%wdon@^qe$8HjN&eMvG3P&Zg07r19jW5wvNvj z-fH9Y7%|oELphM~rNPeqwNG@gFZb6z-g)2#qZ6{+kQ>a1S@J(C(c*G-O1 z{ei@QJ2&34O~j=9pid8`=@)bk`jrbFNz2x+2a1eiW36UOUjXSjLgd=KZ8)~SQ1;8&
> zK_T_<=pJv3b+E7IwOVN<#hDT(Xt-lzz=K{lb@jjvY{w3}9hN@6b%P6fYCQcGm>Gl)
> z8~~qhKriphlX?R?fh=wfB-V zTSfsFw(`OZ5p$z`pc8`ZL%ZE(+?;Cb80x;(4ZKeWD)wgve_ZGhP5myhXfP+x+&;Z6
> zRA_h_>j+N{G-#c%_Z)A1FU9v7`+KJli-z#sG&~DPvl?&?+Ckp;
> zpe@_LH~A;8X3XM+@`7AqZ{1J@yVd*ur_zq!TJGvhG`c(Axgn!-*zHQnuYZD&GNdjP
> zwYsGq4eSw8=km~A%B@?VjfL zpig4?lP$R?fLrW#;69O#yB}q0PqgsaC&n8$_qBizvsjb)@dqE>jlN;t3lZoezI(rS
> zbKg*AAi@4-Ke-L>dfyrBPmkn*bWimkeDomnW(1w9Es0TLatmnbw
> zP!H^hc~7FASMhy#T;TNp`s3AN5t~pjDp5UNY%f2
> z!4?B;njA=Yc5mpTy#;~iGCb>uH!xYG;gZ)~Gk_1e)IGahA(qMb(J?U}^iOZswIvpA
> zF7n#Ff#we2`3=**H%Bx_0T&kg8>wroi~2kR^|t}17?0#}y2T^)HtH44N5r%Bo_M`S
> zO)QI+1u6<#MN>U!n;9*kXql*B*_+C&I<^^_&DeFAkUhsB@AN>0zbmVmZ4~`8Vt*WG
> z$#E2T`vG)lIb=>A4LrZaIK?u9&@o@BNbKeJfD8V2iGBEd2mKs&
> zm&PJp3!5{WOAihKKXM)V1$my%OA;A9r5OKGa@ zGh$zMiH%Y>bD=ZHlfKg!9do%_`oz<&*fi(|b#gKELCOz$ek8xq;zC`p1+OtGw(t2s
> z^FRI)Xg=2?Vy_Hu4)wnB zti0)>_Ko4;$>hhoANmhnhP?V*)P0PDa$Gbrq(7etIc^b%7l7;8cXMB1q_o@ve=TM9
> z+e;H3*tUuE2<&@l#8-}pKX(B>iC;QNEZGa%98X(!xaD}Ud%1{t3`_puT(QJ=nI+rI
> zx)~LeT^RNGE}u~$>w}N=M6B z>tZXtl zC0r;kT4%(3D7O~vn}NPdmWO|5%+vDvS&1z|JVbwC9;4AmUs9*r+K!9Se|VtR#PR>*
> z%e&~ag76ch#kwhrfal;NX?1qOZ=%mwXAk&N^|D{6zctX`0C+5<4ugizuG@n;eW(lm
> zc((bTJIgm+RQR(36`A1SW%#@&ksh5CD4#z{EHsVG%uMLYy5ZqDzDek3BXfaolBl3>
> zgD$1Di9FIj(dW=VxPEX+LieL=8}(etfUxrE9G5sA?Xmqn^VHbj%#-7l+ZB7~hO;m(
> z&Fg$?xf-{ADaZSarn3^G;6HpAM>w8vTv4 zO{VwPjxhc`A)ZdSUGYSwNW24H4 z1ahFg8;DKnF$VbTF*}TO`VpqFTyc zY;li>ZMivc@ND2M2b~vCegHn6<1gyoaA1Ovw$NP+pECxwKSM0Z?Js#c>Ix(fpX}>~
> zFR8COIu>j~oV4xe*zc|o8{Yul9Rsk3r`Gm`8^Yy`118~_jHhFim>te<>?(X#G%Xk<
> z78U+oG@X}$&-X;rZ}7PTIL65wS90PvED{@y(bo5|wbpm|m08SNfxOnEt-Mjl+wBr%
> zy%$^c750dxt>7zMwm2aMZt7!yW9cS$nSXJ@031FC=}3DRK5)BVG(GX&@S-uux5l%a
> zc;rIV1wL5Mk5Lc#HJ=p=3&)8jA9#d*ha{iVEu6285*tg%x6SK+fS*5smkOkX8?GzY
> z`3V^C_ZmMzz=|JL=S3m0@fq+|C?;Jq*S#r!*d>~N=bgXmKJb} z9sDeTt@9H)?!#wmwlyyKMp=G_u|tbLK;QL1iy z2OlMVG=52F$9K5JL*XaE2k3@RT%4$ThIJ#xEw%8N2

Re: [edk2-devel] [PATCH 1/2] UefiPayloadPkg: Add i801 SMBus controller DXE

[Patrick Rudolph]

Hi Maurice,
I agree that edk2-platforms is the right place.
How should it be used to build UefiPlayloadPkg? Should it be hooked up
as git submodule?

Just wondering why you added vendor (or platform) specific code in
UefiPayloadPkg/Library/SpiFlashLib/SpiFlashLib.inf ?
Please clarify.

Regards,
Patrick Rudolph

On Thu, Feb 17, 2022 at 7:24 PM Ma, Maurice  wrote:
>
> This vendor specific device driver implementation does not seem to fit into 
> UEFI payload package scope well.
>
> Do you think https://github.com/tianocore/edk2-platforms/tree/master/Silicon 
> could be a better location ?
>
> Thanks
> Maurice
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Sean
> > Rhodes
> > Sent: Thursday, February 17, 2022 9:51
> > To: devel@edk2.groups.io
> > Cc: Dong, Guo ; Patrick Rudolph
> > ; Ni, Ray ; Ma,
> > Maurice ; You, Benjamin
> > 
> > Subject: [edk2-devel] [PATCH 1/2] UefiPayloadPkg: Add i801 SMBus
> > controller DXE
> >
> > From: Patrick Rudolph 
> >
> > Implement a subset of the gEfiSmbusHcProtocolGuid using a generic PCI i801
> > SMBus controller.
> >
> > Cc: Guo Dong 
> > Cc: Ray Ni 
> > Cc: Maurice Ma 
> > Cc: Benjamin You 
> > Signed-off-by: Patrick Rudolph 
> > ---
> >  .../Library/BrotliCustomDecompressLib/brotli  |   2 +-
> >  UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.c| 556
> > ++
> >  UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.h|  17 +
> >  UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.inf  |  45 ++
> >  UefiPayloadPkg/UefiPayloadPkg.dsc |   7 +
> >  UefiPayloadPkg/UefiPayloadPkg.fdf |   5 +
> >  6 files changed, 631 insertions(+), 1 deletion(-)  create mode 100644
> > UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.c
> >  create mode 100644 UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.h
> >  create mode 100644 UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.inf
> >
> > diff --git a/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> > b/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> > index f4153a09f8..666c3280cc 16
> > --- a/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> > +++ b/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> > @@ -1 +1 @@
> > -Subproject commit f4153a09f87cbb9c826d8fc12c74642bb2d879ea
> > +Subproject commit 666c3280cc11dc433c303d79a83d4ffbdd12cc8d
> > diff --git a/UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.c
> > b/UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.c
> > new file mode 100644
> > index 00..7bf7b893ad
> > --- /dev/null
> > +++ b/UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.c
> > @@ -0,0 +1,556 @@
> > +/** @file+  Implementation for a generic i801 SMBus driver.++Copyright (c)
> > 2016, Intel Corporation. All rights reserved.+SPDX-License-Identifier:
> > BSD-2-Clause-Patent+++**/++#include "SMBusi801Dxe.h"+#include
> > +#include +#include
> > +#include +#include
> > +#include
> > ++EFI_HANDLE  mDriverHandle =
> > NULL;+UINT32  PciDevice = 0;++/* SMBus register offsets. */+#define
> > SMBHSTSTAT  0x0+#define SMBHSTCTL   0x2+#define SMBHSTCMD
> > 0x3+#define SMBXMITADD  0x4+#define SMBHSTDAT0  0x5+#define
> > SMBHSTDAT1  0x6+#define SMBBLKDAT   0x7+#define SMBTRNSADD
> > 0x9+#define SMBSLVDATA  0xa+#define SMLINK_PIN_CTL  0xe+#define
> > SMBUS_PIN_CTL   0xf+#define SMBSLVCMD   0x11++/* I801 command
> > constants */+#define I801_QUICK   (0 << 2)+#define I801_BYTE
> > (1
> > << 2)+#define I801_BYTE_DATA   (2 << 2)+#define I801_WORD_DATA   (3
> > << 2)+#define I801_PROCESS_CALL(4 << 2)+#define I801_BLOCK_DATA
> > (5 << 2)+#define I801_I2C_BLOCK_DATA  (6 << 2) /* ICH5 and later */++/*
> > I801 Host Control register bits */+#define SMBHSTCNT_INTREN (1 <<
> > 0)+#define SMBHSTCNT_KILL   (1 << 1)+#define SMBHSTCNT_LAST_BYTE
> > (1 << 5)+#define SMBHSTCNT_START  (1 << 6)+#define
> > SMBHSTCNT_PEC_EN (1 << 7)/* ICH3 and later */++/* I801 Hosts Status
> > register bits */+#define SMBHSTSTS_BYTE_DONE (1 << 7)+#define
> > SMBHSTSTS_INUSE_STS (1 << 6)+#define SMBHSTSTS_SMBALERT_STS  (1
> > << 5)+#define SMBHSTSTS_FAILED(1 << 4)+#define
> > SMBHSTSTS_BUS_ERR   (1 << 3)+#define SMBHSTSTS_DEV_ERR   (1 <<
> > 2)+#define SMBHSTSTS_INTR  (1 << 1)+#define SMBHSTSTS_HOST_BUSY
> > (1 << 0)++/* For SMBXMITADD register. */+#define XMIT_WRITE(dev)
> > (((dev) << 1) | 0)+#define XMIT_READ(dev)   (((dev) << 1) |
> > 1)++STATIC+UINT16+EFIAPI+SmbusGetSMBaseAddress (+  IN VOID+  )+{+
> > UINT16  Cmd;+  UINT32  Reg32;+  UINT16  IoBase;++  IoBase = 0;+  //+  // 
> > Test
> > if I/O decoding is enabled+  //+  Cmd = PciRead16 (PciDevice + 0x4);+  if
> > (!(Cmd & 1)) {+goto CloseAndReturn;+  }++  //+  // Test if BAR0 is I/O 
> > bar
> > and enabled+  //+  Reg32 = PciRead16 (PciDevice + 0x20);+  if (!(Reg32 & 1)
> > || !(Reg32 & 0xfffc) || ((Reg32 & 0xfffc) == 0xfffc)) {+goto
> > CloseAndReturn;+  }++  IoBase = Reg32 & 0xfffc;++CloseAndReturn:+  return
> > IoBase;+}++STATIC+EFI_STATUS+SmbusSetupCommand (+  IN UINT16
> >

[edk2-devel] [PATCH] MdeModulePkg/Usb/Keyboard.c: Don't request protocol before setting

[Sean Rhodes]

No need to check the interface protocol then conditionally setting,
just set it to BOOT_PROTOCOL and check for error.

This is what Linux does for HID devices as some don't follow the USB spec.
One example is the Aspeed BMC HID keyboard device, which adds a massive
boot delay without this patch as it doesn't respond to 'GetProtocolRequest'.

Cc: Hao A Wu 
Cc: Ray Ni 
Signed-off-by: Matt DeVillier 
Signed-off-by: Patrick Rudolph 
Signed-off-by: Sean Rhodes 
---
 MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c | 18 +-
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c 
b/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
index 5a94a4dda7..b5a6459a35 100644
--- a/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
+++ b/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
@@ -805,7 +805,6 @@ InitUSBKeyboard (
   )
 {
   UINT16  ConfigValue;
-  UINT8   Protocol;
   EFI_STATUS  Status;
   UINT32  TransferResult;
 
@@ -854,22 +853,15 @@ InitUSBKeyboard (
 }
   }
 
-  UsbGetProtocolRequest (
-UsbKeyboardDevice->UsbIo,
-UsbKeyboardDevice->InterfaceDescriptor.InterfaceNumber,
-&Protocol
-);
   //
   // Set boot protocol for the USB Keyboard.
   // This driver only supports boot protocol.
   //
-  if (Protocol != BOOT_PROTOCOL) {
-UsbSetProtocolRequest (
-  UsbKeyboardDevice->UsbIo,
-  UsbKeyboardDevice->InterfaceDescriptor.InterfaceNumber,
-  BOOT_PROTOCOL
-  );
-  }
+  UsbSetProtocolRequest (
+UsbKeyboardDevice->UsbIo,
+UsbKeyboardDevice->InterfaceDescriptor.InterfaceNumber,
+BOOT_PROTOCOL
+);
 
   UsbKeyboardDevice->CtrlOn= FALSE;
   UsbKeyboardDevice->AltOn = FALSE;
-- 
2.32.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86964): https://edk2.groups.io/g/devel/message/86964
Mute This Topic: https://groups.io/mt/89228276/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] MdeModulePkg: Correct high-memory use in NvmExpressDxe

[Ard Biesheuvel]

On Thu, 24 Feb 2022 at 12:48, Tomas Pilar  wrote:
>
> Delay and move the allocation and mapping of memory that backs the DMA
> engine in NvmExpress devices to NvmeInit() to ensure that
> the allocation only happens after the
> EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute is set
> on the PciIo controller.
>
> This ensures that the DMA-backing memory is not forcibly allocated
> below 4G in system address map. Otherwise the allocation fails on
> platforms that do not have any memory below the 4G mark and the drive
> initialisation fails.
>
> Cc: Ray Ni 
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Signed-off-by: Tomas Pilar 

NvmeControllerInit () can be called multiple times, no? So you should
probably make sure that the buffer is not allocated and mapped again
if one already exists.



> ---
>  .../Bus/Pci/NvmExpressDxe/NvmExpress.c| 41 -
>  .../Bus/Pci/NvmExpressDxe/NvmExpressHci.c | 57 ---
>  2 files changed, 49 insertions(+), 49 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c 
> b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
> index 9d40f67e8e..cc921756f5 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
> @@ -912,8 +912,6 @@ NvmExpressDriverBindingStart (
>NVME_CONTROLLER_PRIVATE_DATA*Private;
>EFI_DEVICE_PATH_PROTOCOL*ParentDevicePath;
>UINT32  NamespaceId;
> -  EFI_PHYSICAL_ADDRESSMappedAddr;
> -  UINTN   Bytes;
>EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL  *Passthru;
>
>DEBUG ((DEBUG_INFO, "NvmExpressDriverBindingStart: start\n"));
> @@ -959,45 +957,6 @@ NvmExpressDriverBindingStart (
>goto Exit;
>  }
>
> -//
> -// 6 x 4kB aligned buffers will be carved out of this buffer.
> -// 1st 4kB boundary is the start of the admin submission queue.
> -// 2nd 4kB boundary is the start of the admin completion queue.
> -// 3rd 4kB boundary is the start of I/O submission queue #1.
> -// 4th 4kB boundary is the start of I/O completion queue #1.
> -// 5th 4kB boundary is the start of I/O submission queue #2.
> -// 6th 4kB boundary is the start of I/O completion queue #2.
> -//
> -// Allocate 6 pages of memory, then map it for bus master read and write.
> -//
> -Status = PciIo->AllocateBuffer (
> -  PciIo,
> -  AllocateAnyPages,
> -  EfiBootServicesData,
> -  6,
> -  (VOID **)&Private->Buffer,
> -  0
> -  );
> -if (EFI_ERROR (Status)) {
> -  goto Exit;
> -}
> -
> -Bytes  = EFI_PAGES_TO_SIZE (6);
> -Status = PciIo->Map (
> -  PciIo,
> -  EfiPciIoOperationBusMasterCommonBuffer,
> -  Private->Buffer,
> -  &Bytes,
> -  &MappedAddr,
> -  &Private->Mapping
> -  );
> -
> -if (EFI_ERROR (Status) || (Bytes != EFI_PAGES_TO_SIZE (6))) {
> -  goto Exit;
> -}
> -
> -Private->BufferPciAddr = (UINT8 *)(UINTN)MappedAddr;
> -
>  Private->Signature = 
> NVME_CONTROLLER_PRIVATE_DATA_SIGNATURE;
>  Private->ControllerHandle  = Controller;
>  Private->ImageHandle   = This->DriverBindingHandle;
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c 
> b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
> index ac77afe113..359373300e 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
> @@ -718,14 +718,16 @@ NvmeControllerInit (
>IN NVME_CONTROLLER_PRIVATE_DATA  *Private
>)
>  {
> -  EFI_STATUS   Status;
> -  EFI_PCI_IO_PROTOCOL  *PciIo;
> -  UINT64   Supports;
> -  NVME_AQA Aqa;
> -  NVME_ASQ Asq;
> -  NVME_ACQ Acq;
> -  UINT8Sn[21];
> -  UINT8Mn[41];
> +  EFI_STATUSStatus;
> +  EFI_PCI_IO_PROTOCOL   *PciIo;
> +  UINT64Supports;
> +  NVME_AQA  Aqa;
> +  NVME_ASQ  Asq;
> +  NVME_ACQ  Acq;
> +  UINT8 Sn[21];
> +  UINT8 Mn[41];
> +  UINTN Bytes;
> +  EFI_PHYSICAL_ADDRESS  MappedAddr;
>
>//
>// Save original PCI attributes and enable this controller.
> @@ -777,6 +779,45 @@ NvmeControllerInit (
>  DEBUG ((DEBUG_WARN, "NvmeControllerInit: failed to enable 64-bit DMA 
> (%r)\n", Status));
>}
>
> +  //
> +  // 6 x 4kB aligned buffers will be carved out of this buffer.
> +  // 1st 4kB boundary is the start of the admin submission queue.
> +  // 2nd 4kB boundary is the start of the admin completion queue.
> +  // 3rd 4kB boundary is the start of I/O submission queue #1.
> +  // 4th 4kB

[edk2-devel] [PATCH] MdeModulePkg: Correct high-memory use in NvmExpressDxe

[Tomas Pilar]

Delay and move the allocation and mapping of memory that backs the DMA
engine in NvmExpress devices to NvmeInit() to ensure that
the allocation only happens after the
EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute is set
on the PciIo controller.

This ensures that the DMA-backing memory is not forcibly allocated
below 4G in system address map. Otherwise the allocation fails on
platforms that do not have any memory below the 4G mark and the drive
initialisation fails.

Cc: Ray Ni 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Signed-off-by: Tomas Pilar 
---
 .../Bus/Pci/NvmExpressDxe/NvmExpress.c| 41 -
 .../Bus/Pci/NvmExpressDxe/NvmExpressHci.c | 57 ---
 2 files changed, 49 insertions(+), 49 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
index 9d40f67e8e..cc921756f5 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
@@ -912,8 +912,6 @@ NvmExpressDriverBindingStart (
   NVME_CONTROLLER_PRIVATE_DATA*Private;

   EFI_DEVICE_PATH_PROTOCOL*ParentDevicePath;

   UINT32  NamespaceId;

-  EFI_PHYSICAL_ADDRESSMappedAddr;

-  UINTN   Bytes;

   EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL  *Passthru;

 

   DEBUG ((DEBUG_INFO, "NvmExpressDriverBindingStart: start\n"));

@@ -959,45 +957,6 @@ NvmExpressDriverBindingStart (
   goto Exit;

 }

 

-//

-// 6 x 4kB aligned buffers will be carved out of this buffer.

-// 1st 4kB boundary is the start of the admin submission queue.

-// 2nd 4kB boundary is the start of the admin completion queue.

-// 3rd 4kB boundary is the start of I/O submission queue #1.

-// 4th 4kB boundary is the start of I/O completion queue #1.

-// 5th 4kB boundary is the start of I/O submission queue #2.

-// 6th 4kB boundary is the start of I/O completion queue #2.

-//

-// Allocate 6 pages of memory, then map it for bus master read and write.

-//

-Status = PciIo->AllocateBuffer (

-  PciIo,

-  AllocateAnyPages,

-  EfiBootServicesData,

-  6,

-  (VOID **)&Private->Buffer,

-  0

-  );

-if (EFI_ERROR (Status)) {

-  goto Exit;

-}

-

-Bytes  = EFI_PAGES_TO_SIZE (6);

-Status = PciIo->Map (

-  PciIo,

-  EfiPciIoOperationBusMasterCommonBuffer,

-  Private->Buffer,

-  &Bytes,

-  &MappedAddr,

-  &Private->Mapping

-  );

-

-if (EFI_ERROR (Status) || (Bytes != EFI_PAGES_TO_SIZE (6))) {

-  goto Exit;

-}

-

-Private->BufferPciAddr = (UINT8 *)(UINTN)MappedAddr;

-

 Private->Signature = 
NVME_CONTROLLER_PRIVATE_DATA_SIGNATURE;

 Private->ControllerHandle  = Controller;

 Private->ImageHandle   = This->DriverBindingHandle;

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
index ac77afe113..359373300e 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
@@ -718,14 +718,16 @@ NvmeControllerInit (
   IN NVME_CONTROLLER_PRIVATE_DATA  *Private

   )

 {

-  EFI_STATUS   Status;

-  EFI_PCI_IO_PROTOCOL  *PciIo;

-  UINT64   Supports;

-  NVME_AQA Aqa;

-  NVME_ASQ Asq;

-  NVME_ACQ Acq;

-  UINT8Sn[21];

-  UINT8Mn[41];

+  EFI_STATUSStatus;

+  EFI_PCI_IO_PROTOCOL   *PciIo;

+  UINT64Supports;

+  NVME_AQA  Aqa;

+  NVME_ASQ  Asq;

+  NVME_ACQ  Acq;

+  UINT8 Sn[21];

+  UINT8 Mn[41];

+  UINTN Bytes;

+  EFI_PHYSICAL_ADDRESS  MappedAddr;

 

   //

   // Save original PCI attributes and enable this controller.

@@ -777,6 +779,45 @@ NvmeControllerInit (
 DEBUG ((DEBUG_WARN, "NvmeControllerInit: failed to enable 64-bit DMA 
(%r)\n", Status));

   }

 

+  //

+  // 6 x 4kB aligned buffers will be carved out of this buffer.

+  // 1st 4kB boundary is the start of the admin submission queue.

+  // 2nd 4kB boundary is the start of the admin completion queue.

+  // 3rd 4kB boundary is the start of I/O submission queue #1.

+  // 4th 4kB boundary is the start of I/O completion queue #1.

+  // 5th 4kB boundary is the start of I/O submission queue #2.

+  // 6th 4kB boundary is the start of I/O completion queue #2.

+  //

+  // Allocate 6 pages of memory, then map it for bus master read and write.

+  //

+  Status = PciIo->AllocateBuffer (

+PciIo,

+Alloc

Re: [edk2-devel] [PATCH] MdeModulePkg: Correct high-memory use in NvmExpressDxe

[Ard Biesheuvel]

On Thu, 24 Feb 2022 at 12:58, Ard Biesheuvel  wrote:
>
> On Thu, 24 Feb 2022 at 12:48, Tomas Pilar  wrote:
> >
> > Delay and move the allocation and mapping of memory that backs the DMA
> > engine in NvmExpress devices to NvmeInit() to ensure that
> > the allocation only happens after the
> > EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute is set
> > on the PciIo controller.
> >
> > This ensures that the DMA-backing memory is not forcibly allocated
> > below 4G in system address map. Otherwise the allocation fails on
> > platforms that do not have any memory below the 4G mark and the drive
> > initialisation fails.
> >
> > Cc: Ray Ni 
> > Cc: Ard Biesheuvel 
> > Cc: Leif Lindholm 
> > Signed-off-by: Tomas Pilar 
>
> NvmeControllerInit () can be called multiple times, no? So you should
> probably make sure that the buffer is not allocated and mapped again
> if one already exists.
>

Alternatively, you could move all PCI attribute handling into the
start() hook. Other drivers keep it there as well, and it seems like a
more natural place for it (given the fact that NvmeControllerInit() is
also called on a host controller reset)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86967): https://edk2.groups.io/g/devel/message/86967
Mute This Topic: https://groups.io/mt/89363151/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] MdeModulePkg: Correct high-memory use in NvmExpressDxe

[Tomas Pilar (tpilar)]

On 24/02/2022 12:09, Ard Biesheuvel wrote:


On Thu, 24 Feb 2022 at 12:58, Ard Biesheuvel  wrote:

On Thu, 24 Feb 2022 at 12:48, Tomas Pilar  wrote:

Delay and move the allocation and mapping of memory that backs the DMA
engine in NvmExpress devices to NvmeInit() to ensure that
the allocation only happens after the
EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute is set
on the PciIo controller.

This ensures that the DMA-backing memory is not forcibly allocated
below 4G in system address map. Otherwise the allocation fails on
platforms that do not have any memory below the 4G mark and the drive
initialisation fails.

Cc: Ray Ni 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Signed-off-by: Tomas Pilar 

NvmeControllerInit () can be called multiple times, no? So you should
probably make sure that the buffer is not allocated and mapped again
if one already exists.


Alternatively, you could move all PCI attribute handling into the
start() hook. Other drivers keep it there as well, and it seems like a
more natural place for it (given the fact that NvmeControllerInit() is
also called on a host controller reset)


Brilliant idea, I'll do this!



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86968): https://edk2.groups.io/g/devel/message/86968
Mute This Topic: https://groups.io/mt/89363151/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2] MdeModulePkg: Correct high-memory use in NvmExpressDxe

[Tomas Pilar (tpilar)]

Move the logic that sets EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE Pci

attribute to DriverBindingStart() before the memory that backs the

DMA engine is allocated.



This ensures that the DMA-backing memory is not forcibly allocated

below 4G in system address map. Otherwise the allocation fails on

platforms that do not have any memory below the 4G mark and the drive

initialisation fails.



Cc: Ray Ni 

Cc: Ard Biesheuvel 

Cc: Leif Lindholm 

Signed-off-by: Tomas Pilar 

---

 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c| 13 +

 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c | 13 -

 2 files changed, 13 insertions(+), 13 deletions(-)



diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c

index 9d40f67e8e..1f0fc5bb68 100644

--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c

+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c

@@ -959,6 +959,19 @@ NvmExpressDriverBindingStart (

   goto Exit;

 }

 

+//

+// Enable 64-bit DMA support in the PCI layer.

+//

+Status = PciIo->Attributes (

+  PciIo,

+  EfiPciIoAttributeOperationEnable,

+  EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE,

+  NULL

+  );

+if (EFI_ERROR (Status)) {

+  DEBUG ((DEBUG_WARN, "NvmeControllerInit: failed to enable 64-bit DMA 
(%r)\n", Status));

+}

+

 //

 // 6 x 4kB aligned buffers will be carved out of this buffer.

 // 1st 4kB boundary is the start of the admin submission queue.

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c

index ac77afe113..748cb0ba24 100644

--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c

+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c

@@ -764,19 +764,6 @@ NvmeControllerInit (

 return Status;

   }

 

-  //

-  // Enable 64-bit DMA support in the PCI layer.

-  //

-  Status = PciIo->Attributes (

-PciIo,

-EfiPciIoAttributeOperationEnable,

-EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE,

-NULL

-);

-  if (EFI_ERROR (Status)) {

-DEBUG ((DEBUG_WARN, "NvmeControllerInit: failed to enable 64-bit DMA 
(%r)\n", Status));

-  }

-

   //

   // Read the Controller Capabilities register and verify that the NVM command 
set is supported

   //

-- 

2.30.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86969): https://edk2.groups.io/g/devel/message/86969
Mute This Topic: https://groups.io/mt/89364026/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2] MdeModulePkg: Correct high-memory use in NvmExpressDxe

[Ard Biesheuvel]

On Thu, 24 Feb 2022 at 13:58, Tomas Pilar (tpilar)
 wrote:
>
> Move the logic that sets EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE Pci
>
> attribute to DriverBindingStart() before the memory that backs the
>
> DMA engine is allocated.
>
>
>
> This ensures that the DMA-backing memory is not forcibly allocated
>
> below 4G in system address map. Otherwise the allocation fails on
>
> platforms that do not have any memory below the 4G mark and the drive
>
> initialisation fails.
>
>
>
> Cc: Ray Ni 
>
> Cc: Ard Biesheuvel 
>
> Cc: Leif Lindholm 
>
> Signed-off-by: Tomas Pilar 

Ehm, nope, that is not exactly what I meant.

The existing code stores the original PCI attributes in the controller
private data, enables MMIO/IO decoding and bus mastering, and only
then sets the dual address cycle attribute.

All of that needs to move, so that the captured attributes are accurate.


>
> ---
>
>  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c| 13 +
>
>  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c | 13 -
>
>  2 files changed, 13 insertions(+), 13 deletions(-)
>
>
>
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c 
> b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
>
> index 9d40f67e8e..1f0fc5bb68 100644
>
> --- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
>
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
>
> @@ -959,6 +959,19 @@ NvmExpressDriverBindingStart (
>
>goto Exit;
>
>  }
>
>
>
> +//
>
> +// Enable 64-bit DMA support in the PCI layer.
>
> +//
>
> +Status = PciIo->Attributes (
>
> +  PciIo,
>
> +  EfiPciIoAttributeOperationEnable,
>
> +  EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE,
>
> +  NULL
>
> +  );
>
> +if (EFI_ERROR (Status)) {
>
> +  DEBUG ((DEBUG_WARN, "NvmeControllerInit: failed to enable 64-bit DMA 
> (%r)\n", Status));
>
> +}
>
> +
>
>  //
>
>  // 6 x 4kB aligned buffers will be carved out of this buffer.
>
>  // 1st 4kB boundary is the start of the admin submission queue.
>
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c 
> b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
>
> index ac77afe113..748cb0ba24 100644
>
> --- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
>
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
>
> @@ -764,19 +764,6 @@ NvmeControllerInit (
>
>  return Status;
>
>}
>
>
>
> -  //
>
> -  // Enable 64-bit DMA support in the PCI layer.
>
> -  //
>
> -  Status = PciIo->Attributes (
>
> -PciIo,
>
> -EfiPciIoAttributeOperationEnable,
>
> -EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE,
>
> -NULL
>
> -);
>
> -  if (EFI_ERROR (Status)) {
>
> -DEBUG ((DEBUG_WARN, "NvmeControllerInit: failed to enable 64-bit DMA 
> (%r)\n", Status));
>
> -  }
>
> -
>
>//
>
>// Read the Controller Capabilities register and verify that the NVM 
> command set is supported
>
>//
>
> --
>
> 2.30.2
>
>
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86970): https://edk2.groups.io/g/devel/message/86970
Mute This Topic: https://groups.io/mt/89364026/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2] MdeModulePkg: Correct high-memory use in NvmExpressDxe

[Tomas Pilar (tpilar)]

On 24/02/2022 13:13, Ard Biesheuvel wrote:

On Thu, 24 Feb 2022 at 13:58, Tomas Pilar (tpilar)
 wrote:

Move the logic that sets EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE Pci

attribute to DriverBindingStart() before the memory that backs the

DMA engine is allocated.



This ensures that the DMA-backing memory is not forcibly allocated

below 4G in system address map. Otherwise the allocation fails on

platforms that do not have any memory below the 4G mark and the drive

initialisation fails.



Cc: Ray Ni 

Cc: Ard Biesheuvel 

Cc: Leif Lindholm 

Signed-off-by: Tomas Pilar 

Ehm, nope, that is not exactly what I meant.

The existing code stores the original PCI attributes in the controller
private data, enables MMIO/IO decoding and bus mastering, and only
then sets the dual address cycle attribute.

All of that needs to move, so that the captured attributes are accurate.


Okay, I was wondering. My thought was that we probably want to re-enable 
bus mastering

on reset so I kept that bit of code in the original location.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86971): https://edk2.groups.io/g/devel/message/86971
Mute This Topic: https://groups.io/mt/89364026/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2] MdeModulePkg: Correct high-memory use in NvmExpressDxe

[Tomas Pilar (tpilar)]

On 24/02/2022 13:14, Tomas Pilar (tpilar) wrote:



On 24/02/2022 13:13, Ard Biesheuvel wrote:

On Thu, 24 Feb 2022 at 13:58, Tomas Pilar (tpilar)
 wrote:

Move the logic that sets EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE Pci

attribute to DriverBindingStart() before the memory that backs the

DMA engine is allocated.



This ensures that the DMA-backing memory is not forcibly allocated

below 4G in system address map. Otherwise the allocation fails on

platforms that do not have any memory below the 4G mark and the drive

initialisation fails.



Cc: Ray Ni 

Cc: Ard Biesheuvel 

Cc: Leif Lindholm 

Signed-off-by: Tomas Pilar 

Ehm, nope, that is not exactly what I meant.

The existing code stores the original PCI attributes in the controller
private data, enables MMIO/IO decoding and bus mastering, and only
then sets the dual address cycle attribute.

All of that needs to move, so that the captured attributes are accurate.


Okay, I was wondering. My thought was that we probably want to 
re-enable bus mastering

on reset so I kept that bit of code in the original location.



Also, doesn't this code:

  if (!EFI_ERROR (Status)) {
    Supports &= (UINT64)EFI_PCI_DEVICE_ENABLE;
    Status    = PciIo->Attributes (
 PciIo,
 EfiPciIoAttributeOperationEnable,
 Supports,
 NULL
 );
  }

*strip* the PCI_DEVICE_ENABLE set of attributes rather than add them? I 
am somewhat confused about this.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86972): https://edk2.groups.io/g/devel/message/86972
Mute This Topic: https://groups.io/mt/89364026/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2] MdeModulePkg: Correct high-memory use in NvmExpressDxe

[Tomas Pilar (tpilar)]

On 24/02/2022 13:19, Tomas Pilar (tpilar) wrote:



On 24/02/2022 13:14, Tomas Pilar (tpilar) wrote:



On 24/02/2022 13:13, Ard Biesheuvel wrote:

On Thu, 24 Feb 2022 at 13:58, Tomas Pilar (tpilar)
 wrote:

Move the logic that sets EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE Pci

attribute to DriverBindingStart() before the memory that backs the

DMA engine is allocated.



This ensures that the DMA-backing memory is not forcibly allocated

below 4G in system address map. Otherwise the allocation fails on

platforms that do not have any memory below the 4G mark and the drive

initialisation fails.



Cc: Ray Ni 

Cc: Ard Biesheuvel 

Cc: Leif Lindholm 

Signed-off-by: Tomas Pilar 

Ehm, nope, that is not exactly what I meant.

The existing code stores the original PCI attributes in the controller
private data, enables MMIO/IO decoding and bus mastering, and only
then sets the dual address cycle attribute.

All of that needs to move, so that the captured attributes are 
accurate.



Okay, I was wondering. My thought was that we probably want to 
re-enable bus mastering

on reset so I kept that bit of code in the original location.



Also, doesn't this code:

  if (!EFI_ERROR (Status)) {
    Supports &= (UINT64)EFI_PCI_DEVICE_ENABLE;
    Status    = PciIo->Attributes (
 PciIo,
 EfiPciIoAttributeOperationEnable,
 Supports,
 NULL
 );
  }

*strip* the PCI_DEVICE_ENABLE set of attributes rather than add them? 
I am somewhat confused about this.


Wait no. I just cannot read code, ignore that last bit. I'll prepare a 
patch.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86973): https://edk2.groups.io/g/devel/message/86973
Mute This Topic: https://groups.io/mt/89364026/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3] MdeModulePkg: Correct high-memory use in NvmExpressDxe

[Tomas Pilar (tpilar)]

Move the logic that stores starting PCI attributes and sets the
EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute to
DriverBindingStart() before the memory that backs the
DMA engine is allocated.

This ensures that the DMA-backing memory is not forcibly allocated
below 4G in system address map. Otherwise the allocation fails on
platforms that do not have any memory below the 4G mark and the drive
initialisation fails.

Leave the PCI device enabling attribute logic in NvmeControllerInit()
to ensure that the device is re-enabled on reset in case it was
disabled via PCI attributes.

Cc: Ray Ni 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Signed-off-by: Tomas Pilar 
---
 .../Bus/Pci/NvmExpressDxe/NvmExpress.c| 27 +++
 .../Bus/Pci/NvmExpressDxe/NvmExpressHci.c | 26 +-
 2 files changed, 28 insertions(+), 25 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
index 9d40f67e8e..b70499e3be 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
@@ -959,6 +959,33 @@ NvmExpressDriverBindingStart (
   goto Exit;
 }
 
+//
+// Save original PCI attributes
+//
+Status = PciIo->Attributes (
+  PciIo,
+  EfiPciIoAttributeOperationGet,
+  0,
+  &Private->PciAttributes
+  );
+
+if (EFI_ERROR (Status)) {
+  return Status;
+}
+
+//
+// Enable 64-bit DMA support in the PCI layer.
+//
+Status = PciIo->Attributes (
+  PciIo,
+  EfiPciIoAttributeOperationEnable,
+  EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE,
+  NULL
+  );
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_WARN, "NvmeControllerInit: failed to enable 64-bit DMA 
(%r)\n", Status));
+}
+
 //
 // 6 x 4kB aligned buffers will be carved out of this buffer.
 // 1st 4kB boundary is the start of the admin submission queue.
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
index ac77afe113..d87212ffb2 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
@@ -728,20 +728,9 @@ NvmeControllerInit (
   UINT8Mn[41];
 
   //
-  // Save original PCI attributes and enable this controller.
+  // Enable this controller.
   //
   PciIo  = Private->PciIo;
-  Status = PciIo->Attributes (
-PciIo,
-EfiPciIoAttributeOperationGet,
-0,
-&Private->PciAttributes
-);
-
-  if (EFI_ERROR (Status)) {
-return Status;
-  }
-
   Status = PciIo->Attributes (
 PciIo,
 EfiPciIoAttributeOperationSupported,
@@ -764,19 +753,6 @@ NvmeControllerInit (
 return Status;
   }
 
-  //
-  // Enable 64-bit DMA support in the PCI layer.
-  //
-  Status = PciIo->Attributes (
-PciIo,
-EfiPciIoAttributeOperationEnable,
-EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE,
-NULL
-);
-  if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_WARN, "NvmeControllerInit: failed to enable 64-bit DMA 
(%r)\n", Status));
-  }
-
   //
   // Read the Controller Capabilities register and verify that the NVM command 
set is supported
   //
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86974): https://edk2.groups.io/g/devel/message/86974
Mute This Topic: https://groups.io/mt/89364574/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] edk2/MdeModulePkg/Debuglib: Add Standalone MM support

[Wang, Jian J]

Please update the copyright year to 2022 (line 5). With it addressed,

Reviewed-by: Jian J Wang 

Regards,
Jian

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Xiaolu.Jiang
> Sent: Tuesday, February 22, 2022 10:21 PM
> To: devel@edk2.groups.io
> Cc: Jiang, Xiaolu ; Wang, Jian J
> ; Gao, Liming 
> Subject: [edk2-devel] [PATCH] edk2/MdeModulePkg/Debuglib: Add Standalone
> MM support
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=3844
> 
> This change added Standalone MM instance of DebugLib.
> 
> Cc: Jian J Wang 
> Cc: Liming Gao 
> 
> Signed-off-by: Xiaolu.Jiang 
> ---
>  .../PeiDxeDebugLibReportStatusCode.inf  | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibR
> eportStatusCode.inf
> b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibR
> eportStatusCode.inf
> index b52fc5686a..72456084ff 100644
> ---
> a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibR
> eportStatusCode.inf
> +++
> b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibR
> eportStatusCode.inf
> @@ -16,7 +16,7 @@
>FILE_GUID  = bda39d3a-451b-4350-8266-81ab10fa0523
> 
>MODULE_TYPE= PEIM
> 
>VERSION_STRING = 1.0
> 
> -  LIBRARY_CLASS  = DebugLib|DXE_CORE DXE_DRIVER
> DXE_RUNTIME_DRIVER DXE_SMM_DRIVER SMM_CORE PEIM SEC PEI_CORE
> UEFI_APPLICATION UEFI_DRIVER
> 
> +  LIBRARY_CLASS  = DebugLib|DXE_CORE DXE_DRIVER
> DXE_RUNTIME_DRIVER DXE_SMM_DRIVER SMM_CORE PEIM SEC PEI_CORE
> UEFI_APPLICATION UEFI_DRIVER MM_STANDALONE
> 
> 
> 
>  #
> 
>  # The following information is for reference only and not required by the 
> build
> tools.
> 
> --
> 2.30.2.windows.1
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#86858): https://edk2.groups.io/g/devel/message/86858
> Mute This Topic: https://groups.io/mt/89317370/1768734
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [jian.j.w...@intel.com]
> -=-=-=-=-=-=
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86975): https://edk2.groups.io/g/devel/message/86975
Mute This Topic: https://groups.io/mt/89317370/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3] MdeModulePkg: Correct high-memory use in NvmExpressDxe

[Ard Biesheuvel]

(+ Hao Wu)

On Thu, 24 Feb 2022 at 14:29, Tomas Pilar (tpilar)
 wrote:
>
> Move the logic that stores starting PCI attributes and sets the
> EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute to
> DriverBindingStart() before the memory that backs the
> DMA engine is allocated.
>
> This ensures that the DMA-backing memory is not forcibly allocated
> below 4G in system address map. Otherwise the allocation fails on
> platforms that do not have any memory below the 4G mark and the drive
> initialisation fails.
>
> Leave the PCI device enabling attribute logic in NvmeControllerInit()
> to ensure that the device is re-enabled on reset in case it was
> disabled via PCI attributes.
>
> Cc: Ray Ni 
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Signed-off-by: Tomas Pilar 

This is still not exactly what I had in mind, but I think it's
actually better: the manipulation of the MMIO/IO decode and bus master
attributes occurs in the same place as before (and therefore
potentially multiple times), whereas recording the original value of
the attributes now occurs only once. In that sense, this patch fixes
more than one bug.

Reviewed-by: Ard Biesheuvel 


> ---
>  .../Bus/Pci/NvmExpressDxe/NvmExpress.c| 27 +++
>  .../Bus/Pci/NvmExpressDxe/NvmExpressHci.c | 26 +-
>  2 files changed, 28 insertions(+), 25 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c 
> b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
> index 9d40f67e8e..b70499e3be 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
> @@ -959,6 +959,33 @@ NvmExpressDriverBindingStart (
>goto Exit;
>  }
>
> +//
> +// Save original PCI attributes
> +//
> +Status = PciIo->Attributes (
> +  PciIo,
> +  EfiPciIoAttributeOperationGet,
> +  0,
> +  &Private->PciAttributes
> +  );
> +
> +if (EFI_ERROR (Status)) {
> +  return Status;
> +}
> +
> +//
> +// Enable 64-bit DMA support in the PCI layer.
> +//
> +Status = PciIo->Attributes (
> +  PciIo,
> +  EfiPciIoAttributeOperationEnable,
> +  EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE,
> +  NULL
> +  );
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_WARN, "NvmeControllerInit: failed to enable 64-bit DMA 
> (%r)\n", Status));
> +}
> +
>  //
>  // 6 x 4kB aligned buffers will be carved out of this buffer.
>  // 1st 4kB boundary is the start of the admin submission queue.
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c 
> b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
> index ac77afe113..d87212ffb2 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
> @@ -728,20 +728,9 @@ NvmeControllerInit (
>UINT8Mn[41];
>
>//
> -  // Save original PCI attributes and enable this controller.
> +  // Enable this controller.
>//
>PciIo  = Private->PciIo;
> -  Status = PciIo->Attributes (
> -PciIo,
> -EfiPciIoAttributeOperationGet,
> -0,
> -&Private->PciAttributes
> -);
> -
> -  if (EFI_ERROR (Status)) {
> -return Status;
> -  }
> -
>Status = PciIo->Attributes (
>  PciIo,
>  EfiPciIoAttributeOperationSupported,
> @@ -764,19 +753,6 @@ NvmeControllerInit (
>  return Status;
>}
>
> -  //
> -  // Enable 64-bit DMA support in the PCI layer.
> -  //
> -  Status = PciIo->Attributes (
> -PciIo,
> -EfiPciIoAttributeOperationEnable,
> -EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE,
> -NULL
> -);
> -  if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_WARN, "NvmeControllerInit: failed to enable 64-bit DMA 
> (%r)\n", Status));
> -  }
> -
>//
>// Read the Controller Capabilities register and verify that the NVM 
> command set is supported
>//
> --
> 2.30.2
>
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86976): https://edk2.groups.io/g/devel/message/86976
Mute This Topic: https://groups.io/mt/89364574/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 0/7] CloudHv: Rely on PVH boot specification

[Boeuf, Sebastien]

From: Sebastien Boeuf 

Cloud Hypervisor aims at emulating the minimal amount of legacy devices
and this is why the PVH boot specification is supported. The point is to
be able to share some information with the guest without the need for
emulating devices that would be present on real hardware.

Since Cloud Hypervisor supports loading a PVH ELF binary, the CloudHv
target is updated to be generated as such. Relying on the PVH boot
specification, we don't need to hardcode the location of the ACPI tables
anymore since we can retrieve the RSDP address from the hvm_start_info
structure. Same thing for the RAM below 4G, we can find this information
through the PVH memmap entries rather than relying on the emulated CMOS.

Signed-off-by: Sebastien Boeuf 

Sebastien Boeuf (7):
  OvmfPkg: Make the Xen ELF header generator more flexible
  OvmfPkg: Xen: Use a new fdf include for the PVH ELF header
  OvmfPkg: Xen: Generate fdf include file from ELF header generator
  OvmfPkg: Generate CloudHv as a PVH ELF binary
  OvmfPkg: CloudHv: Retrieve RSDP address from PVH
  OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS
  OvmfPkg: CloudHv: Add README

 OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |   2 +
 OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c   |  39 --
 OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc|  54 
 OvmfPkg/CloudHv/CloudHvX64.dsc  |   2 +-
 OvmfPkg/CloudHv/CloudHvX64.fdf  |  48 ++-
 OvmfPkg/CloudHv/README  |  66 +
 OvmfPkg/Include/IndustryStandard/CloudHv.h  |   5 -
 OvmfPkg/OvmfXen.fdf |  57 +---
 OvmfPkg/OvmfXenElfHeaderGenerator.c | 141 +++-
 OvmfPkg/PlatformPei/MemDetect.c |  73 ++
 OvmfPkg/PlatformPei/PlatformPei.inf |   2 +
 OvmfPkg/XenElfHeader.fdf.inc|  42 ++
 12 files changed, 424 insertions(+), 107 deletions(-)
 create mode 100644 OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc
 create mode 100644 OvmfPkg/CloudHv/README
 create mode 100644 OvmfPkg/XenElfHeader.fdf.inc

-- 
2.32.0

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86977): https://edk2.groups.io/g/devel/message/86977
Mute This Topic: https://groups.io/mt/89365701/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 1/7] OvmfPkg: Make the Xen ELF header generator more flexible

[Boeuf, Sebastien]

From: Sebastien Boeuf 

Adding some flexibility to the program through optional parameters and
global define, so that other targets can use the generator.

* A global define is added so that we can choose at build time if we
  want to use 32-bit or 64-bit base structures.
* A first optional parameter is added so the user can provide the
  expected blob size of the generated binary.
* A second optional parameter is added so the user can specify an output
  file to which the generated output will be printed.

The default behavior isn't modified.

Signed-off-by: Sebastien Boeuf 
---
 OvmfPkg/OvmfXenElfHeaderGenerator.c | 141 +---
 1 file changed, 109 insertions(+), 32 deletions(-)

diff --git a/OvmfPkg/OvmfXenElfHeaderGenerator.c 
b/OvmfPkg/OvmfXenElfHeaderGenerator.c
index 489060cdad..672129b85d 100644
--- a/OvmfPkg/OvmfXenElfHeaderGenerator.c
+++ b/OvmfPkg/OvmfXenElfHeaderGenerator.c
@@ -10,19 +10,31 @@
 **/
 
 #include "elf.h"
-#include "stdio.h"
+#include "fcntl.h"
+#include "stdbool.h"
 #include "stddef.h"
+#include "stdio.h"
+#include "stdlib.h"
 
 void
 print_hdr (
+  FILE*file,
   void*s,
-  size_t  size
+  size_t  size,
+  boolend_delimiter
   )
 {
   char  *c = s;
 
-  while (size--) {
-printf ("0x%02hhx, ", *(c++));
+  fprintf (file, "  ");
+  while (size-- > 1) {
+fprintf (file, "0x%02hhx, ", *(c++));
+  }
+
+  if (end_delimiter) {
+fprintf (file, "0x%02hhx,", *c);
+  } else {
+fprintf (file, "0x%02hhx", *c);
   }
 }
 
@@ -36,34 +48,79 @@ typedef struct {
   uint32_tdesc;
 } xen_elfnote_phys32_entry;
 
+#define LICENSE_HDR  "\
+## @file\r\n\
+#  FDF include file that defines a PVH ELF header.\r\n\
+#\r\n\
+#  Copyright (c) 2022, Intel Corporation. All rights reserved.\r\n\
+#\r\n\
+#  SPDX-License-Identifier: BSD-2-Clause-Patent\r\n\
+#\r\n\
+##\r\n\
+\r\n\
+"
+
 int
 main (
-  void
+  int   argc,
+  char  *argv[]
   )
 {
   /* FW_SIZE */
   size_t  ovmf_blob_size = 0x0020;
   /* Load OVMF at 1MB when running as PVH guest */
   uint32_t  ovmf_base_address = 0x0010;
+  uint32_t  ovmfxen_pvh_entry_point;
+  size_toffset_into_file = 0;
+  char  *endptr, *str;
+  long  param;
+  FILE  *file = stdout;
+
+  /* Parse the size parameter */
+  if (argc > 1) {
+str   = argv[1];
+param = strtol (str, &endptr, 10);
+if (endptr != str) {
+  ovmf_blob_size = (size_t)param;
+}
+  }
+
+  /* Parse the filepath parameter */
+  if (argc > 2) {
+file = fopen (argv[2], "w");
+fprintf (file, LICENSE_HDR);
+  }
+
   /* Xen PVH entry point */
-  uint32_t  ovmfxen_pvh_entry_point = ovmf_base_address + ovmf_blob_size - 
0x30;
-  size_toffset_into_file= 0;
+  ovmfxen_pvh_entry_point = ovmf_base_address + ovmf_blob_size - 0x30;
 
   /* ELF file header */
+ #ifdef PVH64
+  Elf64_Ehdr  hdr = {
+ #else
   Elf32_Ehdr  hdr = {
-.e_ident = ELFMAG,
-.e_type  = ET_EXEC,
-.e_machine   = EM_386,
-.e_version   = EV_CURRENT,
-.e_entry = ovmfxen_pvh_entry_point,
-.e_flags = R_386_NONE,
-.e_ehsize= sizeof (hdr),
+ #endif
+.e_ident   = ELFMAG,
+.e_type= ET_EXEC,
+.e_machine = EM_386,
+.e_version = EV_CURRENT,
+.e_entry   = ovmfxen_pvh_entry_point,
+.e_flags   = R_386_NONE,
+.e_ehsize  = sizeof (hdr),
+ #ifdef PVH64
+.e_phentsize = sizeof (Elf64_Phdr),
+ #else
 .e_phentsize = sizeof (Elf32_Phdr),
+ #endif
   };
 
   offset_into_file += sizeof (hdr);
 
-  hdr.e_ident[EI_CLASS]   = ELFCLASS32;
+ #ifdef PVH64
+  hdr.e_ident[EI_CLASS] = ELFCLASS64;
+ #else
+  hdr.e_ident[EI_CLASS] = ELFCLASS32;
+ #endif
   hdr.e_ident[EI_DATA]= ELFDATA2LSB;
   hdr.e_ident[EI_VERSION] = EV_CURRENT;
   hdr.e_ident[EI_OSABI]   = ELFOSABI_LINUX;
@@ -71,14 +128,22 @@ main (
   hdr.e_phoff = sizeof (hdr);
 
   /* program header */
+ #ifdef PVH64
+  Elf64_Phdr  phdr_load = {
+ #else
   Elf32_Phdr  phdr_load = {
+ #endif
 .p_type   = PT_LOAD,
 .p_offset = 0, /* load everything */
 .p_paddr  = ovmf_base_address,
 .p_filesz = ovmf_blob_size,
 .p_memsz  = ovmf_blob_size,
 .p_flags  = PF_X | PF_W | PF_R,
+ #ifdef PVH64
+.p_align  = 4,
+ #else
 .p_align  = 0,
+ #endif
   };
 
   phdr_load.p_vaddr = phdr_load.p_paddr;
@@ -98,12 +163,20 @@ main (
   sizeof (xen_elfnote_phys32_entry) -
   offsetof (xen_elfnote_phys32_entry, desc),
   };
-  Elf32_Phdrphdr_note = {
+ #ifdef PVH64
+  Elf64_Phdr  phdr_note = {
+ #else
+  Elf32_Phdr  phdr_note = {
+ #endif
 .p_type   = PT_NOTE,
 .p_filesz = sizeof (xen_elf_note),
 .p_memsz  = sizeof (xen_elf_note),
 .p_flags  = PF_R,
+ #ifdef PVH64
+.p_align  = 4,
+ #else
 .p_align  = 0,
+ #endif
   };
 
   hdr.e_phnum   += 1;
@@ -120,31 +193,35 @@ main (
   size_t  hdr_size  = sizeof (hdr);
   size_t  entry_off = offsetof (typeof(hdr), e_entry);
 
-  printf ("# ELF file header\n");
-  print_hdr (&hdr, entry_off);
-  printf ("\n");
-  print_hdr (&hdr.e_entry

[edk2-devel] [PATCH v3 2/7] OvmfPkg: Xen: Use a new fdf include for the PVH ELF header

[Boeuf, Sebastien]

From: Sebastien Boeuf 

Instead of having the PVH ELF header part of the fdf file directly, we
move it to a dedicated include file. This is the first step in
automating the generation of the header.

Signed-off-by: Sebastien Boeuf 
---
 OvmfPkg/OvmfXen.fdf  | 57 ++--
 OvmfPkg/XenElfHeader.fdf.inc | 64 
 2 files changed, 66 insertions(+), 55 deletions(-)
 create mode 100644 OvmfPkg/XenElfHeader.fdf.inc

diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index a6acf3b835..2e67db5d32 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -31,61 +31,8 @@ NumBlocks = $(FW_BLOCKS)
 !if $(FD_SIZE_IN_KB) == 4096
 0x|0x0004
 !endif
-DATA = {
-  #
-  # This hex array have been generated by OvmfPkg/OvmfXenElfHeaderGenerator.c
-  # and copied manually.
-  #
-  # ELF file header
-  0x7f, 0x45, 0x4c, 0x46, # e_ident[0..3]: Magic number
-  0x01, # File class: 32-bit objects
-  0x01, # Data encoding: 2's complement, little endian
-  0x01, # File version
-  0x03, # OS ABI identification: Object uses GNU ELF extensions
-  0x00, # ABI version
-  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  # e_ident[EI_PAD...]
-  0x02, 0x00, # e_type = Executable file
-  0x03, 0x00, # e_machine = Intel 80386
-  0x01, 0x00, 0x00, 0x00, # e_version
-  0xd0, 0xff, 0x2f, 0x00, # e_entry: Entry point virtual address
-  0x34, 0x00, 0x00, 0x00, # e_phoff: Program header table file offset
-  0x00, 0x00, 0x00, 0x00, # e_shoff: Section header table file offset
-  0x00, 0x00, 0x00, 0x00, # e_flags: Processor-specific flags
-  0x34, 0x00, #e_ehsize: ELF header size
-  0x20, 0x00, # e_phentsize: Program header table entry size
-  0x02, 0x00, # e_phnum: Program header table entry count
-  0x00, 0x00, # e_shentsize: Section header table entry size
-  0x00, 0x00, # e_shnum: Section header table entry count
-  0x00, 0x00, # e_shstrndx
-
-  # ELF Program segment headers
-  # - Load segment
-  0x01, 0x00, 0x00, 0x00, # p_type = Loadable program segment
-  0x00, 0x00, 0x00, 0x00, # p_offset
-  0x00, 0x00, 0x10, 0x00, # p_vaddr: Segment virtual address
-  0x00, 0x00, 0x10, 0x00, # p_paddr: Segment physical address
-  0x00, 0x00, 0x20, 0x00, # p_filesz: Segment size in file
-  0x00, 0x00, 0x20, 0x00, # p_memsz: Segment size in memory
-  0x07, 0x00, 0x00, 0x00, # p_flags = Segment is executable | writable | 
readable
-  0x00, 0x00, 0x00, 0x00, # p_align
-  # - ELFNOTE segment
-  0x04, 0x00, 0x00, 0x00, # p_type = PT_NOTE
-  0x74, 0x00, 0x00, 0x00, # p_offset = point to XEN_ELFNOTE_PHYS32_ENTRY below
-  0x74, 0x00, 0x10, 0x00,
-  0x74, 0x00, 0x10, 0x00,
-  0x14, 0x00, 0x00, 0x00,
-  0x14, 0x00, 0x00, 0x00,
-  0x04, 0x00, 0x00, 0x00, # p_flags = Segment is readable
-  0x00, 0x00, 0x00, 0x00,
-
-  # XEN_ELFNOTE_PHYS32_ENTRY
-  0x04, 0x00, 0x00, 0x00, # name size
-  0x04, 0x00, 0x00, 0x00, # desc size
-  0x12, 0x00, 0x00, 0x00, # type = XEN_ELFNOTE_PHYS32_ENTRY
-  0x58, 0x65, 0x6e, 0x00, # name = "Xen"
-  0xd0, 0xff, 0x2f, 0x00, # desc: PVH entry point
-  0x00
-}
+
+!include XenElfHeader.fdf.inc
 
 !if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
 0xe000|0x1000
diff --git a/OvmfPkg/XenElfHeader.fdf.inc b/OvmfPkg/XenElfHeader.fdf.inc
new file mode 100644
index 00..dbc1305d25
--- /dev/null
+++ b/OvmfPkg/XenElfHeader.fdf.inc
@@ -0,0 +1,64 @@
+## @file
+#  FDF include file that defines a PVH ELF header.
+#
+#  Copyright (c) 2022, Intel Corporation. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+DATA = {
+  #
+  # This hex array have been generated by OvmfPkg/OvmfXenElfHeaderGenerator.c
+  # and copied manually.
+  #
+  # ELF file header
+  0x7f, 0x45, 0x4c, 0x46, # e_ident[0..3]: Magic number
+  0x01, # File class: 32-bit objects
+  0x01, # Data encoding: 2's complement, little endian
+  0x01, # File version
+  0x03, # OS ABI identification: Object uses GNU ELF extensions
+  0x00, # ABI version
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  # e_ident[EI_PAD...]
+  0x02, 0x00, # e_type = Executable file
+  0x03, 0x00, # e_machine = Intel 80386
+  0x01, 0x00, 0x00, 0x00, # e_version
+  0xd0, 0xff, 0x2f, 0x00, # e_entry: Entry point virtual address
+  0x34, 0x00, 0x00, 0x00, # e_phoff: Program header table file offset
+  0x00, 0x00, 0x00, 0x00, # e_shoff: Section header table file offset
+  0x00, 0x00, 0x00, 0x00, # e_flags: Processor-specific flags
+  0x34, 0x00, #e_ehsize: ELF header size
+  0x20, 0x00, # e_phentsize: Program header table entry size
+  0x02, 0x00, # e_phnum: Program header table entry count
+  0x00, 0x00, # e_shentsize: Section header table entry size
+  0x00, 0x00, # e_shnum: Section header table entry count
+  0x00, 0x00, # e_shstrndx
+
+  # ELF Program segment headers
+  # - Load segment
+  0x01, 0x00, 0x00, 0x00, # p_type = Loadable program segment
+  0x00, 0x00, 0x00, 0x00, # p_offset
+  0x00, 0x00, 0x10, 0x00, # p_vaddr: Segment virtual address
+  0x00, 0x00, 0x10, 0x00

[edk2-devel] [PATCH v3 3/7] OvmfPkg: Xen: Generate fdf include file from ELF header generator

[Boeuf, Sebastien]

From: Sebastien Boeuf 

Updating the fdf include file based on the run of the ELF header
generator. The diff from this patch is the result of:

$ gcc -o elf_gen OvmfPkg/OvmfXenElfHeaderGenerator.c
$ ./elf_gen 2097152 OvmfPkg/XenElfHeader.fdf.inc

Signed-off-by: Sebastien Boeuf 
---
 OvmfPkg/XenElfHeader.fdf.inc | 60 
 1 file changed, 19 insertions(+), 41 deletions(-)

diff --git a/OvmfPkg/XenElfHeader.fdf.inc b/OvmfPkg/XenElfHeader.fdf.inc
index dbc1305d25..c4f04ad28b 100644
--- a/OvmfPkg/XenElfHeader.fdf.inc
+++ b/OvmfPkg/XenElfHeader.fdf.inc
@@ -8,57 +8,35 @@
 ##
 
 DATA = {
-  #
-  # This hex array have been generated by OvmfPkg/OvmfXenElfHeaderGenerator.c
-  # and copied manually.
-  #
   # ELF file header
-  0x7f, 0x45, 0x4c, 0x46, # e_ident[0..3]: Magic number
-  0x01, # File class: 32-bit objects
-  0x01, # Data encoding: 2's complement, little endian
-  0x01, # File version
-  0x03, # OS ABI identification: Object uses GNU ELF extensions
-  0x00, # ABI version
-  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  # e_ident[EI_PAD...]
-  0x02, 0x00, # e_type = Executable file
-  0x03, 0x00, # e_machine = Intel 80386
-  0x01, 0x00, 0x00, 0x00, # e_version
-  0xd0, 0xff, 0x2f, 0x00, # e_entry: Entry point virtual address
-  0x34, 0x00, 0x00, 0x00, # e_phoff: Program header table file offset
-  0x00, 0x00, 0x00, 0x00, # e_shoff: Section header table file offset
-  0x00, 0x00, 0x00, 0x00, # e_flags: Processor-specific flags
-  0x34, 0x00, #e_ehsize: ELF header size
-  0x20, 0x00, # e_phentsize: Program header table entry size
-  0x02, 0x00, # e_phnum: Program header table entry count
-  0x00, 0x00, # e_shentsize: Section header table entry size
-  0x00, 0x00, # e_shnum: Section header table entry count
-  0x00, 0x00, # e_shstrndx
+  0x7f, 0x45, 0x4c, 0x46, 0x01, 0x01, 0x01, 0x03, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x03, 0x00, 0x01, 0x00, 0x00, 0x00,
+  0xd0, 0xff, 0x2f, 0x00, # hdr.e_entry
+  0x34, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x34, 0x00, 0x20, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
 
   # ELF Program segment headers
   # - Load segment
-  0x01, 0x00, 0x00, 0x00, # p_type = Loadable program segment
-  0x00, 0x00, 0x00, 0x00, # p_offset
-  0x00, 0x00, 0x10, 0x00, # p_vaddr: Segment virtual address
-  0x00, 0x00, 0x10, 0x00, # p_paddr: Segment physical address
-  0x00, 0x00, 0x20, 0x00, # p_filesz: Segment size in file
-  0x00, 0x00, 0x20, 0x00, # p_memsz: Segment size in memory
-  0x07, 0x00, 0x00, 0x00, # p_flags = Segment is executable | writable | 
readable
-  0x00, 0x00, 0x00, 0x00, # p_align
+  0x01, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x10, 0x00,
+  0x00, 0x00, 0x10, 0x00,
+  0x00, 0x00, 0x20, 0x00,
+  0x00, 0x00, 0x20, 0x00,
+  0x07, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
   # - ELFNOTE segment
-  0x04, 0x00, 0x00, 0x00, # p_type = PT_NOTE
-  0x74, 0x00, 0x00, 0x00, # p_offset = point to XEN_ELFNOTE_PHYS32_ENTRY below
+  0x04, 0x00, 0x00, 0x00,
+  0x74, 0x00, 0x00, 0x00,
   0x74, 0x00, 0x10, 0x00,
   0x74, 0x00, 0x10, 0x00,
   0x14, 0x00, 0x00, 0x00,
   0x14, 0x00, 0x00, 0x00,
-  0x04, 0x00, 0x00, 0x00, # p_flags = Segment is readable
+  0x04, 0x00, 0x00, 0x00,
   0x00, 0x00, 0x00, 0x00,
 
   # XEN_ELFNOTE_PHYS32_ENTRY
-  0x04, 0x00, 0x00, 0x00, # name size
-  0x04, 0x00, 0x00, 0x00, # desc size
-  0x12, 0x00, 0x00, 0x00, # type = XEN_ELFNOTE_PHYS32_ENTRY
-  0x58, 0x65, 0x6e, 0x00, # name = "Xen"
-  0xd0, 0xff, 0x2f, 0x00, # desc: PVH entry point
-  0x00
+  0x04, 0x00, 0x00, 0x00,
+  0x04, 0x00, 0x00, 0x00,
+  0x12, 0x00, 0x00, 0x00,
+  0x58, 0x65, 0x6e, 0x00,
+  0xd0, 0xff, 0x2f, 0x00
 }
-- 
2.32.0

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86980): https://edk2.groups.io/g/devel/message/86980
Mute This Topic: https://groups.io/mt/89365709/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 4/7] OvmfPkg: Generate CloudHv as a PVH ELF binary

[Boeuf, Sebastien]

From: Sebastien Boeuf 

Following the model from the Xen target, CloudHv is generated as a PVH
ELF binary to take advantage of the PVH specification, which requires
less emulation from the VMM.

The fdf include file CloudHvElfHeader.fdf.inc has been generated from
the following commands:

$ gcc -D PVH64 -o elf_gen OvmfPkg/OvmfXenElfHeaderGenerator.c
$ ./elf_gen 4194304 OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc

Signed-off-by: Sebastien Boeuf 
---
 OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc | 54 
 OvmfPkg/CloudHv/CloudHvX64.dsc   |  2 +-
 OvmfPkg/CloudHv/CloudHvX64.fdf   | 45 +++-
 3 files changed, 98 insertions(+), 3 deletions(-)
 create mode 100644 OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc

diff --git a/OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc 
b/OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc
new file mode 100644
index 00..8377e30bdc
--- /dev/null
+++ b/OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc
@@ -0,0 +1,54 @@
+## @file
+#  FDF include file that defines a PVH ELF header.
+#
+#  Copyright (c) 2022, Intel Corporation. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+DATA = {
+  # ELF file header
+  0x7f, 0x45, 0x4c, 0x46, 0x02, 0x01, 0x01, 0x03, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x03, 0x00, 0x01, 0x00, 0x00, 0x00,
+  0xd0, 0xff, 0x4f, 0x00, 0x00, 0x00, 0x00, 0x00, # hdr.e_entry
+  0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x38, 0x00, 0x02, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+
+  # ELF Program segment headers
+  # - Load segment
+  0x01, 0x00, 0x00, 0x00,
+  0x07, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x10, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x10, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x40, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x40, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x04, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  # - ELFNOTE segment
+  0x04, 0x00, 0x00, 0x00,
+  0x04, 0x00, 0x00, 0x00,
+  0xb0, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0xb0, 0x00, 0x10, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0xb0, 0x00, 0x10, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x14, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x14, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x04, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+
+  # XEN_ELFNOTE_PHYS32_ENTRY
+  0x04, 0x00, 0x00, 0x00,
+  0x04, 0x00, 0x00, 0x00,
+  0x12, 0x00, 0x00, 0x00,
+  0x58, 0x65, 0x6e, 0x00,
+  0xd0, 0xff, 0x4f, 0x00
+}
diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
index 3172100310..b4d855d80f 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.dsc
+++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
@@ -631,7 +631,7 @@
 #
 

 [Components]
-  OvmfPkg/ResetVector/ResetVector.inf
+  OvmfPkg/XenResetVector/XenResetVector.inf
 
   #
   # SEC Phase modules
diff --git a/OvmfPkg/CloudHv/CloudHvX64.fdf b/OvmfPkg/CloudHv/CloudHvX64.fdf
index ce3302c6d6..1056c0bd46 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.fdf
+++ b/OvmfPkg/CloudHv/CloudHvX64.fdf
@@ -24,7 +24,48 @@ ErasePolarity = 1
 BlockSize = $(BLOCK_SIZE)
 NumBlocks = $(FW_BLOCKS)
 
-!include OvmfPkg/VarStore.fdf.inc
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x|0xe000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x|0x0004
+!endif
+
+!include CloudHvElfHeader.fdf.inc
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0xe000|0x1000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x0004|0x1000
+!endif
+#NV_EVENT_LOG
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0xf000|0x1000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00041000|0x1000
+!endif
+#NV_FTW_WORKING
+DATA = {
+  # EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature = 
gEdkiiWorkingBlockSignatureGuid =
+  #  { 0x9e58292b, 0x7c68, 0x497d, { 0xa0, 0xce, 0x65,  0x0, 0xfd, 0x9f, 0x1b, 
0x95 }}
+  0x2b, 0x29, 0x58, 0x9e, 0x68, 0x7c, 0x7d, 0x49,
+  0xa0, 0xce, 0x65,  0x0, 0xfd, 0x9f, 0x1b, 0x95,
+  # Crc:UINT32#WorkingBlockValid:1, WorkingBlockInvalid:1, Reserved
+  0x2c, 0xaf, 0x2c, 0x64, 0xFE, 0xFF, 0xFF, 0xFF,
+  # WriteQueueSize: UINT64
+  0xE0, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+}
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x0001|0x0001
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00042000|0x00042000
+!endif
+#NV_FTW_SPARE
 
 $(VARS_SIZE)|$(FVMAIN_SIZE)
 FV = FVMAIN_COMPACT
@@ -142,7 +183,7 @@ READ_LOCK_STATUS   = TRUE
 #
 INF  OvmfPkg/Sec/SecMain.inf
 
-INF  RuleOverride=RESET_VECTOR OvmfPkg/ResetVector/ResetVector.inf
+INF  RuleOverride=RESET_VECTOR OvmfPkg/XenResetVector/XenResetVector.inf
 
 

 [FV.PEIFV]
-- 
2.32.0

--

[edk2-devel] [PATCH v3 5/7] OvmfPkg: CloudHv: Retrieve RSDP address from PVH

[Boeuf, Sebastien]

From: Sebastien Boeuf 

Instead of hardcoding the address of the RSDP in the firmware, let's
rely on the PVH structure hvm_start_info to retrieve this information.

Signed-off-by: Sebastien Boeuf 
---
 OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |  2 ++
 OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c   | 39 ++---
 OvmfPkg/CloudHv/CloudHvX64.fdf  |  3 ++
 OvmfPkg/Include/IndustryStandard/CloudHv.h  |  5 ---
 4 files changed, 32 insertions(+), 17 deletions(-)

diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf 
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
index b36b8413e0..f22bd7cb6d 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -56,6 +56,8 @@
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize
 
 [Depex]
   gEfiAcpiTableProtocolGuid
diff --git a/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c 
b/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
index 44a6bb70fe..ff59600d3e 100644
--- a/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
+++ b/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
@@ -7,9 +7,11 @@
 
 **/
 
-#include  // CLOUDHV_RSDP_ADDRESS
-#include   // CpuDeadLoop()
-#include  // DEBUG()
+#include  // 
CLOUDHV_RSDP_ADDRESS
+#include  // hvm_start_info
+#include   // CpuDeadLoop()
+#include  // DEBUG()
+#include// PcdGet32()
 
 #include "AcpiPlatform.h"
 
@@ -23,20 +25,33 @@ InstallCloudHvTables (
   EFI_STATUS  Status;
   UINTN   TableHandle;
 
-  EFI_ACPI_DESCRIPTION_HEADER*Xsdt;
-  VOID   *CurrentTableEntry;
-  UINTN  CurrentTablePointer;
-  EFI_ACPI_DESCRIPTION_HEADER*CurrentTable;
-  UINTN  Index;
-  UINTN  NumberOfTableEntries;
-  EFI_ACPI_2_0_FIXED_ACPI_DESCRIPTION_TABLE  *Fadt2Table;
-  EFI_ACPI_DESCRIPTION_HEADER*DsdtTable;
+  EFI_ACPI_DESCRIPTION_HEADER   *Xsdt;
+  VOID  *CurrentTableEntry;
+  UINTN CurrentTablePointer;
+  EFI_ACPI_DESCRIPTION_HEADER   *CurrentTable;
+  UINTN Index;
+  UINTN NumberOfTableEntries;
+  EFI_ACPI_2_0_FIXED_ACPI_DESCRIPTION_TABLE *Fadt2Table;
+  EFI_ACPI_DESCRIPTION_HEADER   *DsdtTable;
+  EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER  *AcpiRsdpStructurePtr;
+  UINT32*PVHResetVectorData;
+  struct hvm_start_info *pvh_start_info;
 
   Fadt2Table   = NULL;
   DsdtTable= NULL;
   TableHandle  = 0;
   NumberOfTableEntries = 0;
-  EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER  *AcpiRsdpStructurePtr = (VOID 
*)CLOUDHV_RSDP_ADDRESS;
+  AcpiRsdpStructurePtr = NULL;
+  PVHResetVectorData   = NULL;
+  pvh_start_info   = NULL;
+
+  PVHResetVectorData = (VOID *)(UINTN)PcdGet32 (PcdXenPvhStartOfDayStructPtr);
+  if (PVHResetVectorData == 0) {
+return EFI_NOT_FOUND;
+  }
+
+  pvh_start_info   = (struct hvm_start_info *)(UINTN)PVHResetVectorData[0];
+  AcpiRsdpStructurePtr = (EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER 
*)(UINTN)pvh_start_info->rsdp_paddr;
 
   // If XSDT table is found, just install its tables.
   // Otherwise, try to find and install the RSDT tables.
diff --git a/OvmfPkg/CloudHv/CloudHvX64.fdf b/OvmfPkg/CloudHv/CloudHvX64.fdf
index 1056c0bd46..8d135f4bcb 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.fdf
+++ b/OvmfPkg/CloudHv/CloudHvX64.fdf
@@ -135,6 +135,9 @@ 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase|gUefiOvmfPkgTokenSpaceGuid.PcdO
 0x00E000|0x001000
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidSize
 
+0x00F000|0x001000
+gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr|gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize
+
 0x01|0x01
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
 
diff --git a/OvmfPkg/Include/IndustryStandard/CloudHv.h 
b/OvmfPkg/Include/IndustryStandard/CloudHv.h
index 86404cc97e..d31ecc9eec 100644
--- a/OvmfPkg/Include/IndustryStandard/CloudHv.h
+++ b/OvmfPkg/Include/IndustryStandard/CloudHv.h
@@ -38,9 +38,4 @@
 //
 #define CLOUDHV_SMBIOS_ADDRESS  0xf
 
-//
-// RSDP address
-//
-#define CLOUDHV_RSDP_ADDRESS  0xa
-
 #endif // __CLOUDHV_H__
-- 
2.32.0

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 M

[edk2-devel] [PATCH v3 6/7] OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS

[Boeuf, Sebastien]

From: Sebastien Boeuf 

Instead of using the CMOS, the CloudHv platform relies on the list of
memmap entries provided through the PVH boot protocol to determine the
last RAM address below 4G.

Signed-off-by: Sebastien Boeuf 
---
 OvmfPkg/PlatformPei/MemDetect.c | 73 +
 OvmfPkg/PlatformPei/PlatformPei.inf |  2 +
 2 files changed, 75 insertions(+)

diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 1bcb5a08bc..8ecc8257f9 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -17,6 +17,7 @@ Module Name:
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -315,6 +316,73 @@ ScanOrAdd64BitE820Ram (
   return EFI_SUCCESS;
 }
 
+/**
+  Returns PVH memmap
+
+  @param Entries  Pointer to PVH memmap
+  @param CountNumber of entries
+
+  @return EFI_STATUS
+**/
+EFI_STATUS
+GetPvhMemmapEntries (
+  struct hvm_memmap_table_entry  **Entries,
+  UINT32 *Count
+  )
+{
+  UINT32 *PVHResetVectorData;
+  struct hvm_start_info  *pvh_start_info;
+
+  PVHResetVectorData = (VOID *)(UINTN)PcdGet32 (PcdXenPvhStartOfDayStructPtr);
+  if (PVHResetVectorData == 0) {
+return EFI_NOT_FOUND;
+  }
+
+  pvh_start_info = (struct hvm_start_info *)(UINTN)PVHResetVectorData[0];
+
+  *Entries = (struct hvm_memmap_table_entry 
*)(UINTN)pvh_start_info->memmap_paddr;
+  *Count   = pvh_start_info->memmap_entries;
+
+  return EFI_SUCCESS;
+}
+
+STATIC
+UINT64
+GetHighestSystemMemoryAddressFromPvhMemmap (
+  BOOLEAN  Below4gb
+  )
+{
+  struct hvm_memmap_table_entry  *Memmap;
+  UINT32 MemmapEntriesCount;
+  struct hvm_memmap_table_entry  *Entry;
+  EFI_STATUS Status;
+  UINT32 Loop;
+  UINT64 HighestAddress;
+  UINT64 EntryEnd;
+
+  HighestAddress = 0;
+
+  Status = GetPvhMemmapEntries (&Memmap, &MemmapEntriesCount);
+  ASSERT_EFI_ERROR (Status);
+
+  for (Loop = 0; Loop < MemmapEntriesCount; Loop++) {
+Entry= Memmap + Loop;
+EntryEnd = Entry->addr + Entry->size;
+
+if ((Entry->type == XEN_HVM_MEMMAP_TYPE_RAM) &&
+(EntryEnd > HighestAddress))
+{
+  if (Below4gb && (EntryEnd <= BASE_4GB)) {
+HighestAddress = EntryEnd;
+  } else if (!Below4gb && (EntryEnd >= BASE_4GB)) {
+HighestAddress = EntryEnd;
+  }
+}
+  }
+
+  return HighestAddress;
+}
+
 UINT32
 GetSystemMemorySizeBelow4gb (
   VOID
@@ -325,6 +393,11 @@ GetSystemMemorySizeBelow4gb (
   UINT8   Cmos0x34;
   UINT8   Cmos0x35;
 
+  if (mHostBridgeDevId == CLOUDHV_DEVICE_ID) {
+// Get the information from PVH memmap
+return (UINT32)GetHighestSystemMemoryAddressFromPvhMemmap (TRUE);
+  }
+
   Status = ScanOrAdd64BitE820Ram (FALSE, &LowerMemorySize, NULL);
   if ((Status == EFI_SUCCESS) && (LowerMemorySize > 0)) {
 return (UINT32)LowerMemorySize;
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 8ef404168c..212aa7b047 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -91,6 +91,8 @@
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize
   gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
-- 
2.32.0

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86983): https://edk2.groups.io/g/devel/message/86983
Mute This Topic: https://groups.io/mt/89365716/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 7/7] OvmfPkg: CloudHv: Add README

[Boeuf, Sebastien]

From: Sebastien Boeuf 

Add some documentation to the CloudHv target in order to clarify how to
use it and what to expect from it.

Signed-off-by: Sebastien Boeuf 
---
 OvmfPkg/CloudHv/README | 66 ++
 1 file changed, 66 insertions(+)
 create mode 100644 OvmfPkg/CloudHv/README

diff --git a/OvmfPkg/CloudHv/README b/OvmfPkg/CloudHv/README
new file mode 100644
index 00..b5ef2a8be6
--- /dev/null
+++ b/OvmfPkg/CloudHv/README
@@ -0,0 +1,66 @@
+
+CloudHv is a port of OVMF for the Cloud Hypervisor project.
+
+The Cloud Hypervisor project
+
+
+Cloud Hypervisor is a Virtual Machine Monitor that runs on top of KVM. The
+project focuses on exclusively running modern, cloud workloads, on top of a
+limited set of hardware architectures and platforms. Cloud workloads refers to
+those that are usually run by customers inside a cloud provider. This means
+modern operating systems with most I/O handled by paravirtualised devices
+(i.e. virtio), no requirement for legacy devices, and 64-bit CPUs.
+
+https://github.com/cloud-hypervisor/cloud-hypervisor
+
+Design
+--
+
+Based on Cloud Hypervisor's motto to reduce the emulation as much as possible,
+the project logically decided to support the PVH boot specification as the only
+way of booting virtual machines. That includes both direct kernel boot and OVMF
+firmware which must be generated as PVH ELF binaries.
+PVH allows information like location of ACPI tables and location of guest RAM
+ranges to be shared without the need of an extra emulated device like a CMOS.
+
+Features
+
+
+* Serial console
+* EFI shell
+* virtio-pci
+
+Build
+-
+
+The way to build the CloudHv target is as follows:
+
+OvmfPkg/build.sh -p OvmfPkg/CloudHv/CloudHvX64.dsc -a X64 -b DEBUG
+
+Usage
+-
+
+Assuming Cloud Hypervisor is already built, one can start a virtual machine as
+follows:
+
+./cloud-hypervisor \
+--cpus boot=1 \
+--memory size=1G \
+--kernel Build/CloudHvX64/DEBUG_GCC5/FV/CLOUDHV.fd \
+--disk path=/path/to/disk.raw
+
+Releases
+
+
+In edk2-stable202202, CloudHv is generated as data-only binary.
+Starting with edk2-stable202205, CloudHv is generated as a PVH ELF binary to
+reduce the amount of emulation needed from Cloud Hypervisor.
+For TDX, things are handled differently and PVH is not used, which is why the
+firmware is always generated as a data-only binary.
+
++---++-+
+|  CloudHv  |non-TDX | TDX |
++---++-+
+| edk2-stable202202 | Data binary| Data binary |
+| edk2-stable202205 | PVH ELF binary | Data binary |
++---++-+
-- 
2.32.0

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86984): https://edk2.groups.io/g/devel/message/86984
Mute This Topic: https://groups.io/mt/89365717/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary

[Boeuf, Sebastien]

On Thu, 2022-02-24 at 07:27 +0100, Gerd Hoffmann wrote:
> > > > +DATA = {
> > > > +  #
> > > > +  # This hex array have been generated by
> > > > OvmfPkg/OvmfXenElfHeaderGenerator.c
> > > > +  # and copied manually.
> > > 
> > > How about having the generator write a .fdf.inc file which you
> > > can
> > > just
> > > include directly without manual copying?
> > 
> > I understand the idea, but do you have any pointer to some existing
> > code in the repo already doing such thing?
> 
> I'd suggest to just commit the generated include file to git instead
> of
> hooking the generator call into the build system, i.e. updating it
> would
> still be a manual process, but easier and less error-prone because
> the
> manual copying goes away.

I took care of that in the v3.
> 
> take care,
>   Gerd
> 
> 
> 
> 
> 
> 

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86985): https://edk2.groups.io/g/devel/message/86985
Mute This Topic: https://groups.io/mt/89319391/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 2/3] OvmfPkg: CloudHv: Retrieve RSDP address from PVH

[Boeuf, Sebastien]

On Wed, 2022-02-23 at 12:31 +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > +  PVHResetVectorData = (VOID *)(UINTN)PcdGet32
> > (PcdXenPvhStartOfDayStructPtr);
> > +  pvh_start_info   = (struct hvm_start_info
> > *)(UINTN)PVHResetVectorData[0];
> 
> Ah, I see, here is the xen reset vector dependency.
> 
> I'm wondering whenever there are plans for cloudhv to also support
> sev
> and/or tdx some day.  If so, then it probably isn't a good idea to
> switch to the xen reset vector.  

Well Cloud Hypervisor aims at supporting TDX, but based on a separate
firmware. We're not trying to support both TDX and non-TDX use cases
with the same binary, which simplifies the problem here.

> There is the work area used for by
> confidential computing code, I think it would be an option to store a
> pointer to the pvh_start_info there.

Sorry I'm not aware of the confidential computing code. Can you point
me to it?

> 
> take care,
>   Gerd
> 
> 
> 
> 
> 
> 

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86986): https://edk2.groups.io/g/devel/message/86986
Mute This Topic: https://groups.io/mt/89319394/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 2/5] OvmfPkg: Generate CloudHv as a PVH ELF binary

[Boeuf, Sebastien]

On Thu, 2022-02-24 at 09:16 +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > -!include OvmfPkg/VarStore.fdf.inc
> > +!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
> > +0x|0xe000
> > +!endif
> > +!if $(FD_SIZE_IN_KB) == 4096
> > +0x|0x0004
> > +!endif
> 
> Hmm, VarStore.fdf.inc reduces duplication, and now you revert this.
> Maybe add this to VarStore.fdf.inc instead, and add a
> PVH_HEADER_ENABLE
> option to turn it on and off?

It's quite hard to use VarStore.fdf.inc since I would need to replace
only the first DATA section. And I can't include something specific
like OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc inside VarStore.fdf.inc.
Should I create something like OvmfPkg/CloudHv/CloudHvVarStore.fdf.inc
so that it makes sense to include
OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc based on a PVH_HEADER_ENABLE
variable?

> 
> Also: With this in place the start of the vars firmware volume moves
> because it's prefixed by the elf header.  Does that work without code
> changes?

TBH, I'm not sure. I've been testing CLOUDHV.fd and it works fine.

> 
> take care,
>   Gerd
> 
> 
> 
> 
> 
> 

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86987): https://edk2.groups.io/g/devel/message/86987
Mute This Topic: https://groups.io/mt/89345268/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 0/1] MdePkg/Include SMBIOS 3.5.0 changes

[Abdul Lateef Attar via groups.io]

Hi Liming,
   I didnt reliaze that patch v2 was empty.
Sending patch v3 after rebase.
Thanks
AbduL
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 

Abdul Lateef Attar (1):
  MdePkg/Include: Smbios Specification 3.5.0 changes

 MdePkg/Include/IndustryStandard/SmBios.h | 144 +++-
 1 file changed, 140 insertions(+), 4 deletions(-)

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86988): https://edk2.groups.io/g/devel/message/86988
Mute This Topic: https://groups.io/mt/89367736/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 1/1] MdePkg/Include: Smbios Specification 3.5.0 changes

[Abdul Lateef Attar via groups.io]

Adds following changes
1) Added support for manufacturing mode in
   BIOS Characteristics Extension Byte 2.
2) Added support for slot height in
   System Slot Table (type 9).
3) Updated Built-in pointing device interface with
   USB, I2C and SPI.
4) Updates Onboard Devices Extended Information with
   wireless LAN, bluetooth, WWAN, eMMC, NVMe and UFC.
5) Added new table Firmware Inventory Information (Type 45)
   and its corresponding enum values.
6) Added new table String Property Table (Type 46)
   and its corresponding enum values.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Signed-off-by: Abdul Lateef Attar 
---
 MdePkg/Include/IndustryStandard/SmBios.h | 144 +++-
 1 file changed, 140 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/SmBios.h 
b/MdePkg/Include/IndustryStandard/SmBios.h
index 828ea6d753c2..2b1567b0528b 100644
--- a/MdePkg/Include/IndustryStandard/SmBios.h
+++ b/MdePkg/Include/IndustryStandard/SmBios.h
@@ -1,9 +1,10 @@
 /** @file

-  Industry Standard Definitions of SMBIOS Table Specification v3.3.0.

+  Industry Standard Definitions of SMBIOS Table Specification v3.5.0.

 

 Copyright (c) 2006 - 2021, Intel Corporation. All rights reserved.

 (C) Copyright 2015-2017 Hewlett Packard Enterprise Development LP

 (C) Copyright 2015 - 2019 Hewlett Packard Enterprise Development LP

+Copyright (c) 2022, AMD Incorporated. All rights reserved.

 SPDX-License-Identifier: BSD-2-Clause-Patent

 

 **/

@@ -94,6 +95,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #define SMBIOS_TYPE_MANAGEMENT_CONTROLLER_HOST_INTERFACE  42

 #define SMBIOS_TYPE_TPM_DEVICE43

 #define SMBIOS_TYPE_PROCESSOR_ADDITIONAL_INFORMATION  44

+#define SMBIOS_TYPE_FIRMWARE_INVENTORY_INFORMATION45

+#define SMBIOS_TYPE_STRING_PROPERTY_INFORMATION   46

 

 ///

 /// Inactive type is added from SMBIOS 2.2. Reference SMBIOS 2.6, chapter 
3.3.43.

@@ -252,7 +255,9 @@ typedef struct {
   UINT8TargetContentDistributionEnabled  : 1;

   UINT8UefiSpecificationSupported: 1;

   UINT8VirtualMachineSupported   : 1;

-  UINT8ExtensionByte2Reserved: 3;

+  UINT8ManufacturingModeSupported: 1;

+  UINT8ManufacturingModeEnabled  : 1;

+  UINT8ExtensionByte2Reserved: 1;

 } MBCE_SYSTEM_RESERVED;

 

 ///

@@ -1401,6 +1406,17 @@ typedef struct {
   UINT8Reserved: 1; ///< Set to 0.

 } MISC_SLOT_CHARACTERISTICS2;

 

+///

+/// System Slots - Slot Height

+///

+typedef enum {

+  SlotHeightNone   = 0x00,

+  SlotHeightOther  = 0x01,

+  SlotHeightUnknown= 0x02,

+  SlotHeightFullHeight = 0x03,

+  SlotHeightLowProfile = 0x04

+} MISC_SLOT_HEIGHT;

+

 ///

 /// System Slots - Peer Segment/Bus/Device/Function/Width Groups

 ///

@@ -1446,6 +1462,10 @@ typedef struct {
   UINT8 SlotInformation;

   UINT8 SlotPhysicalWidth;

   UINT16SlotPitch;

+  //

+  // Add for smbios 3.5

+  //

+  UINT8 SlotHeight; ///< The enumeration 
value from MISC_SLOT_HEIGHT.

 } SMBIOS_TABLE_TYPE9;

 

 ///

@@ -2004,7 +2024,9 @@ typedef enum {
   PointingDeviceInterfaceADB  = 0x08,

   PointingDeviceInterfaceBusMouseDB9  = 0xA0,

   PointingDeviceInterfaceBusMouseMicroDin = 0xA1,

-  PointingDeviceInterfaceUsb  = 0xA2

+  PointingDeviceInterfaceUsb  = 0xA2,

+  PointingDeviceInterfaceI2c  = 0xA3,

+  PointingDeviceInterfaceSpi  = 0xA4

 } BUILTIN_POINTING_DEVICE_INTERFACE;

 

 ///

@@ -2508,7 +2530,13 @@ typedef enum {
   OnBoardDeviceExtendedTypeSound  = 0x07,

   OnBoardDeviceExtendedTypePATAController = 0x08,

   OnBoardDeviceExtendedTypeSATAController = 0x09,

-  OnBoardDeviceExtendedTypeSASController  = 0x0A

+  OnBoardDeviceExtendedTypeSASController  = 0x0A,

+  OnBoardDeviceExtendedTypeWirelessLAN= 0x0B,

+  OnBoardDeviceExtendedTypeBluetooth  = 0x0C,

+  OnBoardDeviceExtendedTypeWWAN   = 0x0D,

+  OnBoardDeviceExtendedTypeeMMC   = 0x0E,

+  OnBoardDeviceExtendedTypeNvme   = 0x0F,

+  OnBoardDeviceExtendedTypeUfc= 0x10

 } ONBOARD_DEVICE_EXTENDED_INFO_TYPE;

 

 ///

@@ -2646,6 +2674,112 @@ typedef struct {
   UINT32 OemDefined;

 } SMBIOS_TABLE_TYPE43;

 

+///

+/// Firmware Inventory Version Format Type (Type 45).

+///

+typedef enum {

+  VersionFormatTypeFreeForm   = 0x00,

+  VersionFormatTypeMajorMinor = 0x01,

+  VersionFormatType32BitHex   = 0x02,

+  VersionFormatType64BitHex   = 0x03,

+  VersionFormatTypeReserved   = 0x04,  /// 0x04 - 0x7F are reserved

+  VersionFormatTypeOem= 0x80   /// 0x80 - 0xFF are BIOS 
Vendor/OEM-specific

+} FIRMWARE_INVENTORY_VERSION_FORMAT_TYPE;

+

+///

+/// Firmware Inventory Firmware Id Format Type (Type 45).

+///

+typedef enum {

+  FirmwareIdFormat

Re: [edk2-devel] [PATCH 1/2] UefiPayloadPkg: Add i801 SMBus controller DXE

[Guo Dong]

Hi Patrick,

UefiPayloadPkg/Library/SpiFlashLib/SpiFlashLib.inf is a common module as the 
commit message mentioned as below:

* UefiPayloadPkg: Add SpiFlashLib

This is a common SPI Flash library used for the Intel platform that
supports SPI hardware sequence. This library provides actual SPI flash
operation via Intel PCH SPI controller.

Thanks,
Guo

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Patrick Rudolph
Sent: Thursday, February 24, 2022 3:46 AM
To: devel@edk2.groups.io; Ma, Maurice 
Cc: Rhodes, Sean ; Dong, Guo ; Ni, 
Ray ; You, Benjamin 
Subject: Re: [edk2-devel] [PATCH 1/2] UefiPayloadPkg: Add i801 SMBus controller 
DXE

Hi Maurice,
I agree that edk2-platforms is the right place.
How should it be used to build UefiPlayloadPkg? Should it be hooked up as git 
submodule?

Just wondering why you added vendor (or platform) specific code in 
UefiPayloadPkg/Library/SpiFlashLib/SpiFlashLib.inf ?
Please clarify.

Regards,
Patrick Rudolph

On Thu, Feb 17, 2022 at 7:24 PM Ma, Maurice  wrote:
>
> This vendor specific device driver implementation does not seem to fit into 
> UEFI payload package scope well.
>
> Do you think https://github.com/tianocore/edk2-platforms/tree/master/Silicon 
> could be a better location ?
>
> Thanks
> Maurice
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Sean 
> > Rhodes
> > Sent: Thursday, February 17, 2022 9:51
> > To: devel@edk2.groups.io
> > Cc: Dong, Guo ; Patrick Rudolph 
> > ; Ni, Ray ; Ma, 
> > Maurice ; You, Benjamin 
> > 
> > Subject: [edk2-devel] [PATCH 1/2] UefiPayloadPkg: Add i801 SMBus 
> > controller DXE
> >
> > From: Patrick Rudolph 
> >
> > Implement a subset of the gEfiSmbusHcProtocolGuid using a generic 
> > PCI i801 SMBus controller.
> >
> > Cc: Guo Dong 
> > Cc: Ray Ni 
> > Cc: Maurice Ma 
> > Cc: Benjamin You 
> > Signed-off-by: Patrick Rudolph 
> > ---
> >  .../Library/BrotliCustomDecompressLib/brotli  |   2 +-
> >  UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.c| 556
> > ++
> >  UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.h|  17 +
> >  UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.inf  |  45 ++
> >  UefiPayloadPkg/UefiPayloadPkg.dsc |   7 +
> >  UefiPayloadPkg/UefiPayloadPkg.fdf |   5 +
> >  6 files changed, 631 insertions(+), 1 deletion(-)  create mode 
> > 100644 UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.c
> >  create mode 100644 UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.h
> >  create mode 100644 UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.inf
> >
> > diff --git a/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> > b/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> > index f4153a09f8..666c3280cc 16
> > --- a/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> > +++ b/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> > @@ -1 +1 @@
> > -Subproject commit f4153a09f87cbb9c826d8fc12c74642bb2d879ea
> > +Subproject commit 666c3280cc11dc433c303d79a83d4ffbdd12cc8d
> > diff --git a/UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.c
> > b/UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.c
> > new file mode 100644
> > index 00..7bf7b893ad
> > --- /dev/null
> > +++ b/UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.c
> > @@ -0,0 +1,556 @@
> > +/** @file+  Implementation for a generic i801 SMBus 
> > +driver.++Copyright (c)
> > 2016, Intel Corporation. All rights reserved.+SPDX-License-Identifier:
> > BSD-2-Clause-Patent+++**/++#include "SMBusi801Dxe.h"+#include
> > +#include +#include 
> > +#include +#include 
> > +#include
> > ++EFI_HANDLE  mDriverHandle =
> > NULL;+UINT32  PciDevice = 0;++/* SMBus register offsets. */+#define
> > SMBHSTSTAT  0x0+#define SMBHSTCTL   0x2+#define SMBHSTCMD
> > 0x3+#define SMBXMITADD  0x4+#define SMBHSTDAT0  0x5+#define
> > SMBHSTDAT1  0x6+#define SMBBLKDAT   0x7+#define SMBTRNSADD
> > 0x9+#define SMBSLVDATA  0xa+#define SMLINK_PIN_CTL  0xe+#define
> > SMBUS_PIN_CTL   0xf+#define SMBSLVCMD   0x11++/* I801 command
> > constants */+#define I801_QUICK   (0 << 2)+#define I801_BYTE
> > (1
> > << 2)+#define I801_BYTE_DATA   (2 << 2)+#define I801_WORD_DATA   (3
> > << 2)+#define I801_PROCESS_CALL(4 << 2)+#define I801_BLOCK_DATA
> > (5 << 2)+#define I801_I2C_BLOCK_DATA  (6 << 2) /* ICH5 and later */++/*
> > I801 Host Control register bits */+#define SMBHSTCNT_INTREN (1 <<
> > 0)+#define SMBHSTCNT_KILL   (1 << 1)+#define SMBHSTCNT_LAST_BYTE
> > (1 << 5)+#define SMBHSTCNT_START  (1 << 6)+#define
> > SMBHSTCNT_PEC_EN (1 << 7)/* ICH3 and later */++/* I801 Hosts Status
> > register bits */+#define SMBHSTSTS_BYTE_DONE (1 << 7)+#define
> > SMBHSTSTS_INUSE_STS (1 << 6)+#define SMBHSTSTS_SMBALERT_STS  (1
> > << 5)+#define SMBHSTSTS_FAILED(1 << 4)+#define
> > SMBHSTSTS_BUS_ERR   (1 << 3)+#define SMBHSTSTS_DEV_ERR   (1 <<
> > 2)+#define SMBHSTSTS_INTR  (1 << 1)+#define SMBHSTSTS_HOST_BUSY
> > (1 << 0)++/* For SMBXMITADD register. */+#define XMIT_WRITE(dev)
>

Re: [edk2-devel] [PATCH v3] MdeModulePkg: Correct high-memory use in NvmExpressDxe

[Rebecca Cran]

On 2/24/22 06:29, Tomas Pilar (tpilar) wrote:

+//
+// Enable 64-bit DMA support in the PCI layer.
+//
+Status = PciIo->Attributes (
+  PciIo,
+  EfiPciIoAttributeOperationEnable,
+  EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE,
+  NULL
+  );
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_WARN, "NvmeControllerInit: failed to enable 64-bit DMA 
(%r)\n", Status));
+}
+


The message should probably mention NvmExpressDriverBindingStart instead 
of NvmeControllerInit.



--
Rebecca Cran



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86991): https://edk2.groups.io/g/devel/message/86991
Mute This Topic: https://groups.io/mt/89364574/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4] MdeModulePkg: Correct high-memory use in NvmExpressDxe

[Tomas Pilar (tpilar)]

Move the logic that stores starting PCI attributes and sets the
EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute to
DriverBindingStart() before the memory that backs the
DMA engine is allocated.

This ensures that the DMA-backing memory is not forcibly allocated
below 4G in system address map. Otherwise the allocation fails on
platforms that do not have any memory below the 4G mark and the drive
initialisation fails.

Leave the PCI device enabling attribute logic in NvmeControllerInit()
to ensure that the device is re-enabled on reset in case it was
disabled via PCI attributes.

Cc: Ray Ni 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Hao A Wu 
Reviewed-by: Ard Biesheuvel 
Signed-off-by: Tomas Pilar 
---
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c| 27 
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c | 26 +--
 2 files changed, 28 insertions(+), 25 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
index 9d40f67e8e..5a1eda8e8d 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
@@ -959,6 +959,33 @@ NvmExpressDriverBindingStart (
   goto Exit;

 }

 

+//

+// Save original PCI attributes

+//

+Status = PciIo->Attributes (

+  PciIo,

+  EfiPciIoAttributeOperationGet,

+  0,

+  &Private->PciAttributes

+  );

+

+if (EFI_ERROR (Status)) {

+  return Status;

+}

+

+//

+// Enable 64-bit DMA support in the PCI layer.

+//

+Status = PciIo->Attributes (

+  PciIo,

+  EfiPciIoAttributeOperationEnable,

+  EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE,

+  NULL

+  );

+if (EFI_ERROR (Status)) {

+  DEBUG ((DEBUG_WARN, "NvmExpressDriverBindingStart: failed to enable 
64-bit DMA (%r)\n", Status));

+}

+

 //

 // 6 x 4kB aligned buffers will be carved out of this buffer.

 // 1st 4kB boundary is the start of the admin submission queue.

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
index ac77afe113..d87212ffb2 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
@@ -728,20 +728,9 @@ NvmeControllerInit (
   UINT8Mn[41];

 

   //

-  // Save original PCI attributes and enable this controller.

+  // Enable this controller.

   //

   PciIo  = Private->PciIo;

-  Status = PciIo->Attributes (

-PciIo,

-EfiPciIoAttributeOperationGet,

-0,

-&Private->PciAttributes

-);

-

-  if (EFI_ERROR (Status)) {

-return Status;

-  }

-

   Status = PciIo->Attributes (

 PciIo,

 EfiPciIoAttributeOperationSupported,

@@ -764,19 +753,6 @@ NvmeControllerInit (
 return Status;

   }

 

-  //

-  // Enable 64-bit DMA support in the PCI layer.

-  //

-  Status = PciIo->Attributes (

-PciIo,

-EfiPciIoAttributeOperationEnable,

-EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE,

-NULL

-);

-  if (EFI_ERROR (Status)) {

-DEBUG ((DEBUG_WARN, "NvmeControllerInit: failed to enable 64-bit DMA 
(%r)\n", Status));

-  }

-

   //

   // Read the Controller Capabilities register and verify that the NVM command 
set is supported

   //

-- 
2.30.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86992): https://edk2.groups.io/g/devel/message/86992
Mute This Topic: https://groups.io/mt/89368533/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v5] MdeModulePkg: Correct high-memory use in NvmExpressDxe

[Tomas Pilar (tpilar)]

Move the logic that stores starting PCI attributes and sets the
EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute to
DriverBindingStart() before the memory that backs the
DMA engine is allocated.

This ensures that the DMA-backing memory is not forcibly allocated
below 4G in system address map. Otherwise the allocation fails on
platforms that do not have any memory below the 4G mark and the drive
initialisation fails.

Leave the PCI device enabling attribute logic in NvmeControllerInit()
to ensure that the device is re-enabled on reset in case it was
disabled via PCI attributes.

Cc: Ray Ni 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Hao A Wu 
Reviewed-by: Ard Biesheuvel 
Signed-off-by: Tomas Pilar 
---
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c| 27 
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c | 26 +--
 2 files changed, 28 insertions(+), 25 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
index 9d40f67e8e..5a1eda8e8d 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
@@ -959,6 +959,33 @@ NvmExpressDriverBindingStart (
   goto Exit;
 }
 
+//
+// Save original PCI attributes
+//
+Status = PciIo->Attributes (
+  PciIo,
+  EfiPciIoAttributeOperationGet,
+  0,
+  &Private->PciAttributes
+  );
+
+if (EFI_ERROR (Status)) {
+  return Status;
+}
+
+//
+// Enable 64-bit DMA support in the PCI layer.
+//
+Status = PciIo->Attributes (
+  PciIo,
+  EfiPciIoAttributeOperationEnable,
+  EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE,
+  NULL
+  );
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_WARN, "NvmExpressDriverBindingStart: failed to enable 
64-bit DMA (%r)\n", Status));
+}
+
 //
 // 6 x 4kB aligned buffers will be carved out of this buffer.
 // 1st 4kB boundary is the start of the admin submission queue.
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
index ac77afe113..d87212ffb2 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
@@ -728,20 +728,9 @@ NvmeControllerInit (
   UINT8Mn[41];
 
   //
-  // Save original PCI attributes and enable this controller.
+  // Enable this controller.
   //
   PciIo  = Private->PciIo;
-  Status = PciIo->Attributes (
-PciIo,
-EfiPciIoAttributeOperationGet,
-0,
-&Private->PciAttributes
-);
-
-  if (EFI_ERROR (Status)) {
-return Status;
-  }
-
   Status = PciIo->Attributes (
 PciIo,
 EfiPciIoAttributeOperationSupported,
@@ -764,19 +753,6 @@ NvmeControllerInit (
 return Status;
   }
 
-  //
-  // Enable 64-bit DMA support in the PCI layer.
-  //
-  Status = PciIo->Attributes (
-PciIo,
-EfiPciIoAttributeOperationEnable,
-EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE,
-NULL
-);
-  if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_WARN, "NvmeControllerInit: failed to enable 64-bit DMA 
(%r)\n", Status));
-  }
-
   //
   // Read the Controller Capabilities register and verify that the NVM command 
set is supported
   //
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86993): https://edk2.groups.io/g/devel/message/86993
Mute This Topic: https://groups.io/mt/89368607/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] CI: install qemu failing with timeout connecting to azure.archive.ubuntu.com

[Rebecca Cran]

I noticed the latest CI job for master failed installing qemu. Is this 
the same problem we had a couple of weeks ago?


Err:1 http://azure.archive.ubuntu.com/ubuntu 
 bionic/main amd64 libiscsi7 
amd64 1.17.0-1.1
Could not connect to azure.archive.ubuntu.com:80 (52.250.76.244), 
connection timed out


--
Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86994): https://edk2.groups.io/g/devel/message/86994
Mute This Topic: https://groups.io/mt/89377682/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] UefiPayloadPkg: Add i801 SMBus controller DXE

[Guo Dong]

Hi Patrick,

You could refer this page https://github.com/tianocore/edk2-platforms on how to 
build platform with EDK2 and edk2-platform repo.

I had thought you added a SMbus driver that could only work on a particular 
device.  I agree with Maurice to put this kind of modules to Edk2-platform repo.
For SpiFlashLib it is library specific for Intel PCH SPI, we ever discussed to 
put to edk2-platform before.  But we temporarily put to EDK2 with other SMM 
modules for convenience since there is only few this kind of modules.
Let me explore a solution to move PCH specific modules to edk2-platform. Maybe 
create PayloadPlatformPkg under edk2-platforms\Platform\Intel to build 
universal UEFI payload from Edk2 repo, and build a separate FV to include PCH 
specific modules from edk2-platform repo. The build script could add the FV 
into the universal payload as a section of universal payload defined by the 
universal payload specification. This way the UEFI payload in EDK2 could be 
generic enough without platform specific modules.

Thanks,
Guo

-Original Message-
From: Dong, Guo 
Sent: Thursday, February 24, 2022 8:54 AM
To: devel@edk2.groups.io; patrick.rudo...@9elements.com; Ma, Maurice 

Cc: Rhodes, Sean ; Ni, Ray ; You, 
Benjamin 
Subject: RE: [edk2-devel] [PATCH 1/2] UefiPayloadPkg: Add i801 SMBus controller 
DXE


Hi Patrick,

UefiPayloadPkg/Library/SpiFlashLib/SpiFlashLib.inf is a common module as the 
commit message mentioned as below:

* UefiPayloadPkg: Add SpiFlashLib

This is a common SPI Flash library used for the Intel platform that supports 
SPI hardware sequence. This library provides actual SPI flash operation via 
Intel PCH SPI controller.

Thanks,
Guo

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Patrick Rudolph
Sent: Thursday, February 24, 2022 3:46 AM
To: devel@edk2.groups.io; Ma, Maurice 
Cc: Rhodes, Sean ; Dong, Guo ; Ni, 
Ray ; You, Benjamin 
Subject: Re: [edk2-devel] [PATCH 1/2] UefiPayloadPkg: Add i801 SMBus controller 
DXE

Hi Maurice,
I agree that edk2-platforms is the right place.
How should it be used to build UefiPlayloadPkg? Should it be hooked up as git 
submodule?

Just wondering why you added vendor (or platform) specific code in 
UefiPayloadPkg/Library/SpiFlashLib/SpiFlashLib.inf ?
Please clarify.

Regards,
Patrick Rudolph

On Thu, Feb 17, 2022 at 7:24 PM Ma, Maurice  wrote:
>
> This vendor specific device driver implementation does not seem to fit into 
> UEFI payload package scope well.
>
> Do you think https://github.com/tianocore/edk2-platforms/tree/master/Silicon 
> could be a better location ?
>
> Thanks
> Maurice
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Sean 
> > Rhodes
> > Sent: Thursday, February 17, 2022 9:51
> > To: devel@edk2.groups.io
> > Cc: Dong, Guo ; Patrick Rudolph 
> > ; Ni, Ray ; Ma, 
> > Maurice ; You, Benjamin 
> > 
> > Subject: [edk2-devel] [PATCH 1/2] UefiPayloadPkg: Add i801 SMBus 
> > controller DXE
> >
> > From: Patrick Rudolph 
> >
> > Implement a subset of the gEfiSmbusHcProtocolGuid using a generic 
> > PCI i801 SMBus controller.
> >
> > Cc: Guo Dong 
> > Cc: Ray Ni 
> > Cc: Maurice Ma 
> > Cc: Benjamin You 
> > Signed-off-by: Patrick Rudolph 
> > ---
> >  .../Library/BrotliCustomDecompressLib/brotli  |   2 +-
> >  UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.c| 556
> > ++
> >  UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.h|  17 +
> >  UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.inf  |  45 ++
> >  UefiPayloadPkg/UefiPayloadPkg.dsc |   7 +
> >  UefiPayloadPkg/UefiPayloadPkg.fdf |   5 +
> >  6 files changed, 631 insertions(+), 1 deletion(-)  create mode
> > 100644 UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.c
> >  create mode 100644 UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.h
> >  create mode 100644 UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.inf
> >
> > diff --git a/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> > b/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> > index f4153a09f8..666c3280cc 16
> > --- a/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> > +++ b/MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
> > @@ -1 +1 @@
> > -Subproject commit f4153a09f87cbb9c826d8fc12c74642bb2d879ea
> > +Subproject commit 666c3280cc11dc433c303d79a83d4ffbdd12cc8d
> > diff --git a/UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.c
> > b/UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.c
> > new file mode 100644
> > index 00..7bf7b893ad
> > --- /dev/null
> > +++ b/UefiPayloadPkg/SmbusDxe/SMBusi801Dxe.c
> > @@ -0,0 +1,556 @@
> > +/** @file+  Implementation for a generic i801 SMBus 
> > +driver.++Copyright (c)
> > 2016, Intel Corporation. All rights reserved.+SPDX-License-Identifier:
> > BSD-2-Clause-Patent+++**/++#include "SMBusi801Dxe.h"+#include
> > +#include +#include 
> > +#include +#include 
> > +#include
> > ++EFI_HANDLE  mDriverHandle =
> > NULL;+UINT32  PciDevice = 0;++/* SMBus register offsets. */+#define
> > SMBHSTSTAT  0x0+#define SMBHSTCTL 

[edk2-devel][PATCH] edk2/MdeModulePkg/Debuglib: Add Standalone MM support

[Xiaolu.Jiang]

https://bugzilla.tianocore.org/show_bug.cgi?id=3844

This change added Standalone MM instance of DebugLib.

Cc: Jian J Wang 
Cc: Liming Gao 

Signed-off-by: Xiaolu.Jiang 
---
 .../PeiDxeDebugLibReportStatusCode.inf| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
 
b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
index b52fc5686a..c7b75de38a 100644
--- 
a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
+++ 
b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
@@ -2,7 +2,7 @@
 #  Debug Library based on report status code library
 #
 #  Debug Library for PEIMs and DXE drivers that sends debug messages to 
ReportStatusCode
-#  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2022, Intel Corporation. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -16,7 +16,7 @@
   FILE_GUID  = bda39d3a-451b-4350-8266-81ab10fa0523
   MODULE_TYPE= PEIM
   VERSION_STRING = 1.0
-  LIBRARY_CLASS  = DebugLib|DXE_CORE DXE_DRIVER 
DXE_RUNTIME_DRIVER DXE_SMM_DRIVER SMM_CORE PEIM SEC PEI_CORE UEFI_APPLICATION 
UEFI_DRIVER
+  LIBRARY_CLASS  = DebugLib|DXE_CORE DXE_DRIVER 
DXE_RUNTIME_DRIVER DXE_SMM_DRIVER SMM_CORE PEIM SEC PEI_CORE UEFI_APPLICATION 
UEFI_DRIVER MM_STANDALONE
 
 #
 # The following information is for reference only and not required by the 
build tools.
-- 
2.30.2.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86996): https://edk2.groups.io/g/devel/message/86996
Mute This Topic: https://groups.io/mt/89317370/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-