Re: [edk2-devel] [PATCH 1/1] MdeModulePkg: Add BootDiscoveryPolicyUiLib.

Internally reviewed this patch before sending the edk2 mailing list and Greg already addressed all my comments, so It looks good to me. Reviewed-by: Sunny Wang Add Ray and Zhichao. They're BDS modules reviewers. Hi Ray and Zhichao, Could you help review this patch? -Original Message-

Re: [edk2-devel] [edk2-platforms][PATCH v4 05/41] IntelSiliconPkg: Add microcode FV PCDs

Ok. I understand your patch just merges the existing PCDs from individual XXSIliconPkgs to IntelSiliconPkg. Are there any modules that use these PCDs in XXSiliconPkgs? -Original Message- From: Michael Kubacki Sent: Wednesday, June 30, 2021 10:27 AM To: Ni, Ray Cc: devel@edk2.groups.io

Re: [edk2-devel] [PATCH] MdeModulePkg PiSmmCore: Change MemoryAttributes message to DEBUG_VERBOSE level

Can you explain why VERBOSE is chosen instead of INFO? Thanks, Ray -Original Message- From: Yang Gang Sent: Wednesday, June 30, 2021 1:54 PM To: devel@edk2.groups.io Cc: Dong, Eric ; Ni, Ray ; Liming Gao Subject: [PATCH] MdeModulePkg PiSmmCore: Change MemoryAttributes message to DEBU

Re: [edk2-devel] [PATCH V2] Maintainers.txt: Update Maintainers and reviewers for UefiPayloadPkg

Reviewed-by: Maurice Ma -Maurice > -Original Message- > From: Dong, Guo > Sent: Tuesday, June 29, 2021 21:54 > To: devel@edk2.groups.io > Cc: Ma, Maurice ; You, Benjamin > ; Ni, Ray ; Kinney, Michael D > > Subject: [edk2-devel] [PATCH V2] Maintainers.txt: Update Maintainers and > revie

[edk2-devel] [PATCH V2] Maintainers.txt: Update Maintainers and reviewers for UefiPayloadPkg

Add Ray Ni as UefiPayloadPkg Maintainer. Update Maurice Ma and Benjamin You as reviewers to continue support UefiPayloadPkg patch review. Cc: Ray Ni Cc: Benjamin You Cc: Maurice Ma Cc: Michael D Kinney Reviewed-by: Maurice Ma Reviewed-by: Benjamin You Signed-off-by: Guo Dong --- Maintainer

Re: [edk2-devel] [PATCH 2/2] UefiPayloadPkg/PayloadLoader: Remove assertion

Reviewed-by: Guo Dong > -Original Message- > From: Ni, Ray > Sent: Monday, June 28, 2021 11:27 PM > To: devel@edk2.groups.io > Cc: Ma, Maurice ; Dong, Guo > ; You, Benjamin > Subject: [PATCH 2/2] UefiPayloadPkg/PayloadLoader: Remove assertion > > For R_386_RELATIVE and R_X86_64_RELAT

Re: [edk2-devel] [PATCH 1/2] UefiPayloadPkg/PayloadLoader: Fix bug in locating relocation section

Reviewed-by: Guo Dong > -Original Message- > From: Ni, Ray > Sent: Monday, June 28, 2021 11:27 PM > To: devel@edk2.groups.io > Cc: Ma, Maurice ; Dong, Guo > ; You, Benjamin > Subject: [PATCH 1/2] UefiPayloadPkg/PayloadLoader: Fix bug in locating > relocation section > > Per ELF spec,

Re: [edk2-devel] [edk2-platforms][PATCH v4 05/41] IntelSiliconPkg: Add microcode FV PCDs

Unfortunately, those cannot be used in the silicon packages. This is not new to this series, see existing code: https://github.com/tianocore/edk2-platforms/blob/086a3a3ce6c42c859ee5943eb2c4b6edcefdc241/Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec#L460 https://github.com/tianocore/edk2-platforms/b

Re: [edk2-devel] [PATCH] MdeModulePkg/RegularExpressionDxe: Fix memory assert in FreePool()

I see. Thanks for your quick response. I will work on it. Nickle -Original Message- From: gaoliming Sent: Wednesday, June 30, 2021 9:43 AM To: Wang, Nickle (HPS SW) ; devel@edk2.groups.io; ler...@redhat.com Cc: jian.j.w...@intel.com; hao.a...@intel.com Subject: 回复: [edk2-devel] [PATCH]

回复: [edk2-devel] [PATCH] MdeModulePkg/RegularExpressionDxe: Fix memory assert in FreePool()

This is a separate commit. You can send it together with previous patch. Thanks Liming > -邮件原件- > 发件人: Wang, Nickle (HPS SW) > 发送时间: 2021年6月30日 9:29 > 收件人: gaoliming ; devel@edk2.groups.io; > ler...@redhat.com > 抄送: jian.j.w...@intel.com; hao.a...@intel.com; Wang, Nickle (HPS SW) > > 主题

Re: [edk2-devel] [PATCH] MdeModulePkg/RegularExpressionDxe: Fix memory assert in FreePool()

Hi Liming, No problem. It looks like I have to add OnigurumaUefiPort.c into "IgnoreFiles" object in MdeModulePkg.ci.yaml. And should I send this patch alone? Or I have to send it as a part of patch in early fix? Thanks, Nickle -Original Message- From: gaoliming Sent: Wednesday, June

回复: [edk2-devel] 回复: [edk2][PATCH V3] MdePkg : Add IPMI Macro and Structure Defintions to resolve build errors

If no other comment, I will create PR to merge this patch. Thanks Liming 发件人: devel@edk2.groups.io 代表 gaoliming 发送时间: 2021年6月24日 8:54 收件人: devel@edk2.groups.io; latee...@gmail.com 抄送: 'manickavasakam karpagavinayagam' ; isaac.w.o...@intel.com; nathaniel.l.desim...@intel.com; fel...@ami.com

Re: [EXTERNAL] Re: [edk2-devel] [PATCH v1 0/5] EDK2 Code First: PI Specification: Update EFI_MM_COMMUNICATE_HEADER

If it breaks in the future, then that would be due to a new compiler that or changes to the configuration of an existing compiler that break compatibility with UEFI ABI. The compiler issue must be resolved before the new compiler or change to existing compiler are accepted. Mike > -Original

回复: [edk2-devel] [PATCH] MdeModulePkg/RegularExpressionDxe: Fix memory assert in FreePool()

Laszlo: Yes. I agree to add OnigurumaUefiPort.c into ECC exception in MdeModulePkg.ci.yaml. Nickle: Can you provide the patch to update MdeModulePkg.ci.yaml? Thanks Liming > -邮件原件- > 发件人: devel@edk2.groups.io 代表 Laszlo Ersek > 发送时间: 2021年6月29日 22:52 > 收件人: devel@edk2.groups.io; nickle

Re: [EXTERNAL] Re: [edk2-devel] [PATCH v1 0/5] EDK2 Code First: PI Specification: Update EFI_MM_COMMUNICATE_HEADER

Hi Mike, Thanks for the note. I will add this check for sanity check in v-next, assuming this will not fail for currently supported compilers. Just curious, what do we normally do if this type of check start to break in the future? Thanks, Kun On 06/29/2021 10:28, Kinney, Michael D wrote:

Re: [edk2-devel] [PATCH v2 0/6] NetworkPkg/IScsiDxe: support SHA256 in CHAP

Thanks, Laszlo. I really like moving the condition out of 'if' clause in IScsiCHAPAuthTarget :) For the patchset: Reviewed-by: Maciej Rabeda On 29-Jun-21 18:33, Laszlo Ersek wrote: Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=3355 Repo: https://pagure.io/lersek/edk2.git Branch

Re: [edk2-devel] [RFC PATCH v4 02/27] OvmfPkg/ResetVector: add the macro to invoke MSR protocol based VMGEXIT

While looking carefully, I found an error in this and next patch, I will send a follow up patch to address it. SEV status and GHCB MSR value are very close and I missed it and used SEV_STATUS_MSR for both case. It should look like this and used accordingly. %define SEV_STATUS_MSR 0xc0010130 %defi

Re: [EXTERNAL] Re: [edk2-devel] [PATCH v1 0/5] EDK2 Code First: PI Specification: Update EFI_MM_COMMUNICATE_HEADER

Good idea on use of STATIC_ASSERT(). For structures that use flexible array members, we can add a STATIC_ASSERT() for the sizeof() and OFFSET_OF() returning the same result. For example: STATIC_ASSERT (sizeof (EFI_MM_COMMUNICATE_HEADER) == OFFSET_OF (EFI_MM_COMMUNICATE_HEADER, Data)); Mik

Re: [EXTERNAL] Re: [edk2-devel] NetworkPkg: Unexpected DHCP RELEASE after PXE server reply on IPv6

FYI For IPv6, the TFTP-based network boot process (i.e., pxe) is called Netboot6 & detailed in "24.3.1 Netboot6"/" 24.3.1.2 IPv6-based PXE boot", and for IPV4 PXE we also curate changes/clarifications in "E.4.20 PXE 2.1 specification wire protocol clarifications", all of which are found in http

Re: [edk2-devel] [PATCH v1 0/5] EDK2 Code First: PI Specification: Update EFI_MM_COMMUNICATE_HEADER

Hi Marvin, Thank you for checking this specific structure. I think this should be part of the evaluation when proposing the use of a flexible array member to the UEFI/PI specs as part of the EDK II Code First Process. We should verify that the sizeof() and offsetof() return the same value when u

Re: [EXTERNAL] Re: [edk2-devel] Do the edk2 CI unit tests work in Linux?

Hmmm. If that works well, we might be able to investigate carrying both and picking based on the host OS. - Bret From: devel@edk2.groups.io on behalf of Rebecca Cran via groups.io Sent: Tuesday, June 29, 2021 9:42:41 AM To: devel@edk2.groups.io ; steven@int

Re: [EXTERNAL] Re: [edk2-devel] NetworkPkg: Unexpected DHCP RELEASE after PXE server reply on IPv6

Thanks, Maciej! We’ll investigate! - Bret From: Rabeda, Maciej Sent: Tuesday, June 29, 2021 9:39:59 AM To: devel@edk2.groups.io ; LathaKannan Arumugam ; Bret Barkelew Subject: Re: [EXTERNAL] Re: [edk2-devel] NetworkPkg: Unexpected DHCP RELEASE after PXE server

Re: [edk2-devel] Do the edk2 CI unit tests work in Linux?

Your Linux distribution should have a nuget package available (e.g. https://packages.ubuntu.com/hirsute/nuget) but the EDK2 CI is designed to use the copy of nuget installed with the edk2toolext package. -- Rebecca Cran On 6/29/21 9:44 AM, Steven Shi wrote: Cran, Thanks. I’m curious whethe

Re: [edk2-devel] [EXTERNAL] RE: [edk2-platforms] [PATCH V1] PurleyOpenBoardPkg : Support for LINUX Boot

I think Features/LinuxBoot would be consistent with other OpenBoardPkg organization. Regards, Isaac -Original Message- From: devel@edk2.groups.io On Behalf Of manickavasakam karpagavinayagam Sent: Tuesday, June 29, 2021 7:32 AM To: Oram, Isaac W ; Desimone, Nathaniel L ; devel@edk2.gr

Re: [EXTERNAL] Re: [edk2-devel] NetworkPkg: Unexpected DHCP RELEASE after PXE server reply on IPv6

Additionally, for claim that IPv4 does not do that, please provide Wireshark trace, if available. On 29-Jun-21 18:36, Maciej Rabeda wrote: Hi guys, Finally got some time to look into it. Long story short, this smells like infrastructure problem. SARR passes over 546/547 port pair. That is bet

Re: [EXTERNAL] Re: [edk2-devel] NetworkPkg: Unexpected DHCP RELEASE after PXE server reply on IPv6

Hi guys, Finally got some time to look into it. Long story short, this smells like infrastructure problem. SARR passes over 546/547 port pair. That is between UEFI PXE client and DHCP server (even if it is the same machine). The next packet is essentially a Boot Server choice step. UEFI PXE cl

Re: [edk2-devel] Do the edk2 CI unit tests work in Linux?

I think he's referring to NuGet.exe, which unless you're familiar with .NET appears to be a Windows executable. -- Rebecca Cran On 6/29/21 9:59 AM, Bret Barkelew wrote: Which executable are you referring to? Also, yes, it is entirely possible that Linux has more dependencies since the de

[edk2-devel] [PATCH v2 6/6] NetworkPkg: introduce the NETWORK_ISCSI_MD5_ENABLE feature test macro

Introduce the NETWORK_ISCSI_MD5_ENABLE feature test macro for NetworkPkg. When explicitly set to FALSE, remove MD5 from IScsiDxe's CHAP algorithm list. Set NETWORK_ISCSI_MD5_ENABLE to TRUE by default, for compatibility reasons. Not just to minimize the disruption for platforms that currently inclu

[edk2-devel] [PATCH v2 5/6] NetworkPkg/IScsiDxe: support SHA256 in CHAP

Insert a SHA256 CHAP_HASH structure at the start of "mChapHash". Update ISCSI_CHAP_MAX_DIGEST_SIZE to SHA256_DIGEST_SIZE (32). This enables the initiator and the target to negotiate SHA256 for CHAP, in preference to MD5. Cc: Jiaxin Wu Cc: Maciej Rabeda Cc: Philippe Mathieu-Daudé Cc: Siyuan Fu

[edk2-devel] [PATCH v2 4/6] NetworkPkg/IScsiDxe: support multiple hash algorithms for CHAP

Introduce the "mChapHash" table, containing the hash algorithms supported for CHAP. Hash algos listed at the beginning of the table are preferred by the initiator. In ISCSI_CHAP_STEP_ONE, send such a CHAP_A value that is the comma-separated, ordered list of algorithm identifiers from "mChapHash".

[edk2-devel] [PATCH v2 3/6] NetworkPkg/IScsiDxe: distinguish "maximum" and "selected" CHAP digest sizes

IScsiDxe uses the ISCSI_CHAP_RSP_LEN macro for expressing the size of the digest (16) that it solely supports at this point (MD5). ISCSI_CHAP_RSP_LEN is used for both (a) *allocating* digest-related buffers (binary buffers and hex encodings alike), and (b) *processing* binary digest buffers (compar

[edk2-devel] [PATCH v2 1/6] NetworkPkg/IScsiDxe: re-set session-level authentication state before login

RFC 7143 explains that a single iSCSI session may use multiple TCP connections. The first connection established is called the leading connection. The login performed on the leading connection is called the leading login. Before the session is considered full-featured, the leading login must succee

[edk2-devel] [PATCH v2 2/6] NetworkPkg/IScsiDxe: add horizontal whitespace to IScsiCHAP files

In the next patches, we'll need more room for various macro and parameter names. For maintaining the current visual alignments, insert some horizontal whitespace in preparation. "git show -b" produces no output for this patch; the patch introduces no functional changes. Cc: Jiaxin Wu Cc: Maciej R

[edk2-devel] [PATCH v2 0/6] NetworkPkg/IScsiDxe: support SHA256 in CHAP

Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=3355 Repo: https://pagure.io/lersek/edk2.git Branch: iscsi_sha256_bz3355_v2 (at commit 73b92e85b4de) CI: https://github.com/tianocore/edk2/pull/1772 v1 was posted at: * [edk2-devel] [PATCH 0/6] NetworkPkg/IScsiDxe: support SHA25

Re: [EXTERNAL] Re: [edk2-devel] [PATCH v1 0/5] EDK2 Code First: PI Specification: Update EFI_MM_COMMUNICATE_HEADER

Good note. Thanks! - Bret From: Marvin Häuser Sent: Tuesday, June 29, 2021 1:58 AM To: Bret Barkelew; Laszlo Ersek; Kun Qin; Kinney, Michael D;

Re: [edk2-devel] Do the edk2 CI unit tests work in Linux?

Which executable are you referring to? Also, yes, it is entirely possible that Linux has more dependencies since the dependency list has conditionals based on your OS. - Bret From: Steven Shi via groups.io Sent: Tuesday, June 29, 2021 8:44 AM To: devel@edk

Re: [EXTERNAL] Re: [edk2-devel] Do the edk2 CI unit tests work in Linux?

Here’s some of the documentation, but I believe the standard apt mono-devel package is now up-to-date enough that the extra apt source is not necessary. edk2-pytool-extensions/using_extdep.md at master · tianocore/edk2-pytool-extensions (github.com)

Re: [edk2-devel] Do the edk2 CI unit tests work in Linux?

Cran, Thanks. I'm curious whether the .pytool has native Linux executable binary to run? It looks the edk2 CI framework has more dependency in Linux than Windows. Thanks Steven Shi Intel\IAGS\SFP\FIA (Firmware Infrastructure Automation) From: devel@edk2.groups.io On Behalf Of Rebecca Cran S

Re: [edk2-devel] [PATCH] MdeModulePkg/RegularExpressionDxe: Fix memory assert in FreePool()

On 06/10/21 06:56, Nickle Wang wrote: > Memory buffer that is allocated by malloc() and realloc() will be > shifted by 8 bytes because Oniguruma keeps its memory signature. This 8 > bytes shift is not handled while calling free() to release memory. Add > free() function to check Oniguruma signature

Re: [edk2-devel] [PATCH] OvmfPkg/XenPlatformPei: Relocate shared_info page mapping

On 06/29/21 13:41, Jan Beulich via groups.io wrote: > On 29.06.2021 13:29, Laszlo Ersek wrote: >> On 06/29/21 12:35, Andrew Cooper wrote: >>> On 29/06/2021 11:07, Jan Beulich wrote: On 29.06.2021 11:20, Laszlo Ersek wrote: > On 06/28/21 15:23, Anthony PERARD via groups.io wrote: >> Fro

Re: [edk2-devel] [EXTERNAL] RE: [edk2-platforms] [PATCH V1] PurleyOpenBoardPkg : Support for LINUX Boot

Isaac : >From our understanding, features under edk2-platform/Intel/OpenBoardPkg >are named without pkg >https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/PurleyOpenBoardPkg > (ex: Pci/PciPlatform, Acpi/BoardAcpiDxe) Can we name it as "LinuxBoot" or ServerLinuxBoot"?

Re: [edk2-devel] [edk2-platforms PATCH 0/4] ACPI MDIO support for Marvell SoCs

Hi Leif, pon., 14 cze 2021 o 23:55 Leif Lindholm napisał(a): > > Hi Marcin, > > On Sun, Jun 13, 2021 at 20:16:27 +0200, Marcin Wojtas wrote: > > Hi, > > > > The MDIO ACPI binding has been established and merged to the > > Linux tree, > > Congratulations! :) > > Is FreeBSD expected to follow suit?

Re: [edk2-devel] [PATCH v3 0/5] OvmfPkg: Use QemuKernelLoaderFs to read cmdline/initrd

On 06/29/21 15:03, Dov Murik wrote: > Out of curiousity, I wonder regarding the leak fixes -- is there a way > to see that the fix works? Is there some accounting of used pages that > we can check that decreases after the fix? You could try a UEFI memmap comparison, but the cmdline is a pool allo

Re: [edk2-devel] [PATCH v3 0/5] OvmfPkg: Use QemuKernelLoaderFs to read cmdline/initrd

On 29/06/2021 15:54, Laszlo Ersek wrote: > On 06/28/21 12:51, Dov Murik wrote: >> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3457 >> >> In order to support measured SEV boot with kernel/initrd/cmdline, we'd >> like to have one place that reads those blobs; in the future we'll add >> the

Re: [edk2-devel] [PATCH v3 0/5] OvmfPkg: Use QemuKernelLoaderFs to read cmdline/initrd

On 06/28/21 12:51, Dov Murik wrote: > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3457 > > In order to support measured SEV boot with kernel/initrd/cmdline, we'd > like to have one place that reads those blobs; in the future we'll add > the measurement and verification in that place. > > W

Re: [edk2-devel] Do the edk2 CI unit tests work in Linux?

NuGet.exe is a .NET assembly/executable, so on Linux you'll need to install Mono (https://www.mono-project.com/). -- Rebecca Cran On 6/28/21 7:45 PM, Steven Shi wrote: Hello, I’m interested in the edk2 CI unit tests(https://github.com/tianocore/edk2/tree/master/.pytool

Re: [edk2-devel] [PATCH] OvmfPkg/XenPlatformPei: Relocate shared_info page mapping

On 29.06.2021 13:29, Laszlo Ersek wrote: > On 06/29/21 12:35, Andrew Cooper wrote: >> On 29/06/2021 11:07, Jan Beulich wrote: >>> On 29.06.2021 11:20, Laszlo Ersek wrote: On 06/28/21 15:23, Anthony PERARD via groups.io wrote: > From: Anthony PERARD > > Unfortunately, Xen isn't rea

Re: [edk2-devel] [PATCH] OvmfPkg/XenPlatformPei: Relocate shared_info page mapping

On 29.06.2021 11:20, Laszlo Ersek wrote: > On 06/28/21 15:23, Anthony PERARD via groups.io wrote: >> From: Anthony PERARD >> >> Unfortunately, Xen isn't ready to deal with mapping at the top of the >> physical address space, so we relocate the mapping after the LAPIC >> location. >> >> See this th

Re: [edk2-devel] [PATCH] OvmfPkg/XenPlatformPei: Relocate shared_info page mapping

On 29/06/2021 11:07, Jan Beulich wrote: > On 29.06.2021 11:20, Laszlo Ersek wrote: >> On 06/28/21 15:23, Anthony PERARD via groups.io wrote: >>> From: Anthony PERARD >>> >>> Unfortunately, Xen isn't ready to deal with mapping at the top of the >>> physical address space, so we relocate the mapping

Re: [edk2-devel] [PATCH] OvmfPkg/XenPlatformPei: Relocate shared_info page mapping

On 06/29/21 12:35, Andrew Cooper wrote: > On 29/06/2021 11:07, Jan Beulich wrote: >> On 29.06.2021 11:20, Laszlo Ersek wrote: >>> On 06/28/21 15:23, Anthony PERARD via groups.io wrote: From: Anthony PERARD Unfortunately, Xen isn't ready to deal with mapping at the top of the ph

Re: [edk2-devel] [PATCH v3 2/5] OvmfPkg/X86QemuLoadImageLib: plug cmdline blob leak on success

On 06/28/21 12:51, Dov Murik wrote: > When QemuLoadKernelImage() ends successfully, the command-line blob is > not freed, even though it is not used elsewhere (its content is already > copied to KernelLoadedImage->LoadOptions). The memory leak bug was > introduced in commit 7c47d89003a6 ("OvmfPkg:

Re: [edk2-devel] [PATCH v3 4/5] OvmfPkg/GenericQemuLoadImageLib: Read cmdline from QemuKernelLoaderFs

On 06/28/21 12:51, Dov Murik wrote: > Remove the QemuFwCfgLib interface used to read the QEMU cmdline > (-append argument) and the initrd size. Instead, use the synthetic > filesystem QemuKernelLoaderFs which has three files: "kernel", "initrd", > and "cmdline". > > Cc: Laszlo Ersek > Cc: Ard Bi

Re: [edk2-devel] [PATCH v3 3/5] Revert "OvmfPkg/QemuKernelLoaderFsDxe: don't expose kernel command line"

On 06/28/21 12:51, Dov Murik wrote: > This reverts commit efc52d67e1573ce174d301b52fa1577d552c8441. > > Manually fixed conflicts in: > OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c > > Note that besides re-exposing the kernel command line as a file in the > synthetic filesystem, we also

Re: [edk2-devel] [PATCH v3 1/5] OvmfPkg/GenericQemuLoadImageLib: plug cmdline blob leak on success

On 06/28/21 12:51, Dov Murik wrote: > When QemuLoadKernelImage() ends successfully, the command-line blob is > not freed, even though it is not used elsewhere (its content is already > copied to KernelLoadedImage->LoadOptions). The memory leak bug was > introduced in commit ddd2be6b0026 ("OvmfPkg:

Re: [edk2-devel] [PATCH v3 5/5] OvmfPkg/X86QemuLoadImageLib: State fw_cfg dependency in file header

On 06/28/21 12:51, Dov Murik wrote: > Make it clear that X86QemuLoadImageLib relies on fw_cfg; prepare the > ground to add a warning about the incompatibility with boot verification > process. > > Cc: Laszlo Ersek > Cc: Ard Biesheuvel > Cc: Jordan Justen > Cc: James Bottomley > Cc: Tobin Feldm

Re: [edk2-devel] [PATCH v3 4/5] OvmfPkg/GenericQemuLoadImageLib: Read cmdline from QemuKernelLoaderFs

On 06/28/21 12:51, Dov Murik wrote: > Remove the QemuFwCfgLib interface used to read the QEMU cmdline > (-append argument) and the initrd size. Instead, use the synthetic > filesystem QemuKernelLoaderFs which has three files: "kernel", "initrd", > and "cmdline". > > Cc: Laszlo Ersek > Cc: Ard Bi

Re: [edk2-devel] [PATCH v3 3/5] Revert "OvmfPkg/QemuKernelLoaderFsDxe: don't expose kernel command line"

On 06/28/21 12:51, Dov Murik wrote: > This reverts commit efc52d67e1573ce174d301b52fa1577d552c8441. > > Manually fixed conflicts in: > OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c > > Note that besides re-exposing the kernel command line as a file in the > synthetic filesystem, we also

Re: [edk2-devel] [PATCH v3 2/5] OvmfPkg/X86QemuLoadImageLib: plug cmdline blob leak on success

On 06/28/21 12:51, Dov Murik wrote: > When QemuLoadKernelImage() ends successfully, the command-line blob is > not freed, even though it is not used elsewhere (its content is already > copied to KernelLoadedImage->LoadOptions). The memory leak bug was > introduced in commit 7c47d89003a6 ("OvmfPkg:

Re: [edk2-devel] [PATCH v3 1/5] OvmfPkg/GenericQemuLoadImageLib: plug cmdline blob leak on success

On 06/28/21 12:51, Dov Murik wrote: > When QemuLoadKernelImage() ends successfully, the command-line blob is > not freed, even though it is not used elsewhere (its content is already > copied to KernelLoadedImage->LoadOptions). The memory leak bug was > introduced in commit ddd2be6b0026 ("OvmfPkg:

Re: [edk2-devel] [PATCH] OvmfPkg/XenPlatformPei: Relocate shared_info page mapping

On 06/28/21 15:23, Anthony PERARD via groups.io wrote: > From: Anthony PERARD > > Unfortunately, Xen isn't ready to deal with mapping at the top of the > physical address space, so we relocate the mapping after the LAPIC > location. > > See this thread about the issue with the mapping: > - > ht

Re: [edk2-devel] [PATCH v3 3/3] ArmVirtCloudHv: support Cloud Hypervisor in edk2

Hi Sami, Thanks, it works. Also, I will fix that path. Thanks Jianyong > -Original Message- > From: Sami Mujawar > Sent: Tuesday, June 29, 2021 4:16 PM > To: Jianyong Wu ; devel@edk2.groups.io > Cc: ler...@redhat.com; ardb+tianoc...@kernel.org; Justin He > ; nd > Subject: Re: [PATCH v3

Re: [EXTERNAL] Re: [edk2-devel] [PATCH v1 0/5] EDK2 Code First: PI Specification: Update EFI_MM_COMMUNICATE_HEADER

Generally yes, but gladly not for EDK II. Default GNU ABI uses 32-bit alignment for 64-bit integers on IA32 (which led to a (non-critical) mistake in our PE paper :( ) for example, but UEFI / EDK II (seem to) successfully dictate natural alignment consistently. Possibly we could introduce some

Re: 回复: [edk2-devel] error C0DE: Unknown fatal error when processing [edk2/ArmVirtPkg/ArmVirtQemu.dsc]

On 06/29/21 08:08, Lange Tang wrote: > hi gaoliming: > I'm glad to hear from you！ > I want to build ArmVirtPkg to get QEMU_EFI.fd firmware to support videoo > qxl. > The following two files have been modified: > 1. ArmVirtPkg/ArmVirtQemu.dsc > 2. ArmVirtPkg/ArmVirtQemu.fdf (a)

Re: 回复: [edk2-devel] error C0DE: Unknown fatal error when processing [edk2/ArmVirtPkg/ArmVirtQemu.dsc]

hi gaoliming: I'm glad to hear from you！ I want to build ArmVirtPkg to get QEMU_EFI.fd firmware to support videoo qxl. The following two files have been modified: 1. ArmVirtPkg/ArmVirtQemu.dsc 2. ArmVirtPkg/ArmVirtQemu.fdf At 2021-06-29 10:16:35, "gaoliming

Re: [edk2-devel] [PATCH v3 3/3] ArmVirtCloudHv: support Cloud Hypervisor in edk2

Hi Jianyong, You should be able to remove the TPM dependency by keeping only the else part of TPM2_ENABLE and TPM2_CONFIG_ENABLE in both the DSC and FDF files. Also, can you fix the path to ArmVirtPciHostBridgeUtilityLib.inf in the dsc file? It should be 'PciHostBridgeUtilityLib|ArmVirtPkg/Lib