Re: [edk2-devel] [edk2-InfSpecification PATCH] Document: Add new MODULE_TYPE HOST_APPLICATION

> -Original Message- > From: Gao, Liming > Sent: Friday, July 5, 2019 1:54 PM > To: Yao, Jiewen ; Lu, XiaoyuX > ; devel@edk2.groups.io > Subject: RE: [edk2-InfSpecification PATCH] Document: Add new > MODULE_TYPE HOST_APPLICATION > > Jiewen and Xiaoyu: > > > -Original Message-

Re: [edk2-devel] [edk2-InfSpecification PATCH] Document: Add new MODULE_TYPE HOST_APPLICATION

Jiewen and Xiaoyu: > -Original Message- > From: Yao, Jiewen > Sent: Friday, July 5, 2019 1:02 PM > To: Gao, Liming ; Lu, XiaoyuX ; > devel@edk2.groups.io > Subject: RE: [edk2-InfSpecification PATCH] Document: Add new MODULE_TYPE > HOST_APPLICATION > > Answer below: > > > -Original

Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol

Hi, Please note that these 2 tags are automatically added when the mail is sent with the formatted patch of the commit [edk2-devel] [PATCH] I could add the branch name tag when I sent the commit in the Edk2-staging branch for review with the community - [Edk2-staging\Branch name]. This tags

Re: [edk2-devel] [edk2-InfSpecification PATCH] Document: Add new MODULE_TYPE HOST_APPLICATION

Answer below: > -Original Message- > From: Gao, Liming > Sent: Friday, July 5, 2019 12:59 PM > To: Lu, XiaoyuX ; devel@edk2.groups.io > Cc: Yao, Jiewen > Subject: RE: [edk2-InfSpecification PATCH] Document: Add new > MODULE_TYPE HOST_APPLICATION > > Xiaoyu: > I would like to clarify

Re: [edk2-devel] [edk2-InfSpecification PATCH] Document: Add new MODULE_TYPE HOST_APPLICATION

Xiaoyu: I would like to clarify that HOST_APPLICATION is for the execute file that can run in OS environment directly. It may be exe for Windows or be ELF for Linux. And, this new type module will directly run in OS environment. So, they will not be built into BIOS image, and not be

Re: [edk2-devel] [Patch] Maintainers.txt: Change SecurityPkg Maintainer Role

Reviewed-by: Jian J Wang > -Original Message- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > Zhang, Chao B > Sent: Friday, July 05, 2019 12:46 PM > To: devel@edk2.groups.io > Cc: Wang, Jian J > Subject: [edk2-devel] [Patch] Maintainers.txt: Change SecurityPkg

[edk2-devel] [Patch] Maintainers.txt: Change SecurityPkg Maintainer Role

Change Chao's role to Reviewer Cc: Wang Jian J Signed-off-by: Zhang, Chao B --- Maintainers.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Maintainers.txt b/Maintainers.txt index e52f044bec..2b15cee5c1 100644 --- a/Maintainers.txt +++ b/Maintainers.txt @@ -191,13

[edk2-devel] [Patch] Maintainers.txt: Change SecurityPkg Maintainer Role

Change Chao's role to Reviewer Cc: Wang, Jian J Signed-off-by: Zhang, Chao B --- Maintainers.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Maintainers.txt b/Maintainers.txt index e52f044bec..2b15cee5c1 100644 --- a/Maintainers.txt +++ b/Maintainers.txt @@ -191,13

[edk2-devel] [PATCH] UefiCpuPkg/CpuFeature: Introduce FirstX to indicate 1st unit in parent scope.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1584 The flow of CPU feature initialization logic is: 1. BSP calls GetConfigDataFunc() for each thread/AP; 2. Each thread/AP calls SupportFunc() to detect its own capability; 3. BSP calls InitializeFunc() for each thead/AP. There is a design

Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol

Ray: > -Original Message- > From: Ni, Ray > Sent: Friday, July 5, 2019 11:14 AM > To: Gao, Liming ; devel@edk2.groups.io; > ler...@redhat.com; Javeed, Ashraf > Cc: Kinney, Michael D > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI > encodings to PCI Plat

Re: [edk2-devel] [PATCH 0/5] MdePkg, SecurityPkg, OvmfPkg: revert unreviewed SM3 patches

Hi Laszlo, > -Original Message- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > Laszlo Ersek > Sent: Friday, July 05, 2019 12:05 AM > To: edk2-devel-groups-io ; Desai, Imran > > Cc: Ard Biesheuvel ; Zhang, Chao B > ; Wang, Jian J ; Yao, > Jiewen ; Justen, Jordan

Re: [edk2-devel] [PATCH v2 5/5] OvmfPkg: link SM3 support into Tcg2Pei and Tcg2Dxe

Hi Laszlo, Very sorry for the mistake. I'm totally responsible for it. Regards, Jian > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Thursday, July 04, 2019 4:38 AM > To: Desai, Imran ; Wang, Jian J > > Cc: devel@edk2.groups.io; Justen, Jordan L ; > Ard

Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol

Ray: Yes. Please see https://github.com/tianocore/edk2-staging Thanks Liming >-Original Message- >From: Ni, Ray >Sent: Friday, July 05, 2019 10:39 AM >To: Gao, Liming ; devel@edk2.groups.io; >ler...@redhat.com; Javeed, Ashraf >Cc: Kinney, Michael D >Subject: RE: [edk2-devel] [PATCH]

Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol

Liming, I understand Laszlo's comment requiring repo name in the patch title to tell everyone where the code will be. But before the patch is pushed, the patch owner in theory cannot guarantee the branch can be successfully created after the R-b is got. Because someone may create a branch with the

Re: [edk2-devel] [PATCH] BaseTools: Fix encoding typos

Hi Antoine, Patch looks fine. Would you attach the patch file again? I can't extract the patch file from the mail. Pccts is the predecessor of ANTLR. It's dead. Thanks, Bob -Original Message- From: Leif Lindholm [mailto:leif.lindh...@linaro.org] Sent: Thursday, July 4, 2019 9:07 PM

Re: [edk2-devel] [PATCH 0/5] MdePkg, SecurityPkg, OvmfPkg: revert unreviewed SM3 patches

On 7/4/19 6:05 PM, Laszlo Ersek wrote: > On 07/04/19 11:46, Laszlo Ersek wrote: >> Repo: https://github.com/lersek/edk2.git >> Branch: revert_unreviewed_bz1781 >> >> The MdePkg patch and the OvmfPkg patch committed for >> had not been >>

[edk2-devel] [edk2-platforms: PATCH v2 2/2] Platform/Rpi3: Add custom CPU frequency support

Allow users to set a custom CPU frequency [100 - 1600 MHz] in 'Device Manager' -> 'Raspberry Pi Configuration'. Signed-off-by: Pete Batard --- Platform/RaspberryPi/RPi3/Drivers/ConfigDxe/ConfigDxe.c | 13 +++- Platform/RaspberryPi/RPi3/Drivers/ConfigDxe/ConfigDxe.inf

[edk2-devel] [edk2-platforms: PATCH v2 0/2] Platform/RPi3: Improve boot order and add custom freqs

v2 to: - Break a long line PlatformBm.c. - Use a BOOLEAN for the SkipTurbo parameter. - Keep already defined gRaspberryPiTokenSpaceGuid.### values as they are. Note that, as opposed to what was discussed, EFI_VARIABLE_RUNTIME_ACCESS was not removed because doing so effectively prevents the custom

[edk2-devel] [PATCH v3 22/35] OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h

The informations to make a XENMEM_memory_map hypercall is copied over from the public header of the Xen Project, with the type name modified to build on OVMF. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD Acked-by: Laszlo Ersek --- Notes: v3: -

[edk2-devel] [PATCH v3 29/35] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH

When running in a Xen PVH guest, there's nothing to do in PciAcpiInitialization() because there isn't any PCI bus. When the Host Bridge DID isn't recognised, simply continue. (The value of PcdOvmfHostBridgePciDevId would be 0 because it isn't set.) Ref:

[edk2-devel] [PATCH v3 32/35] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn

On a Xen PVH guest, none of the existing serial or console interface works, so we add a new one, based on XenConsoleSerialPortLib, and implemented via SerialDxe. That is a simple console implementation that can works on both PVH guest and HVM guests, even if it rarely going to be use on HVM.

[edk2-devel] [PATCH v3 23/35] OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercall

When the Xen PVH entry point has been used, hvmloader hasn't run and hasn't prepared an E820 table. The only way left to get an E820 table is to ask Xen via an hypercall, the call can only be made once so keep the result cached for later. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689

[edk2-devel] [PATCH v3 28/35] OvmfPkg/PlatformBootManagerLib: Use XenDetected from XenPlatformLib

Replace the XenDetected() implementation by the one from XenPlatformLib. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD --- Notes: v3: - new patch .../PlatformBootManagerLib.inf| 1 + .../PlatformBootManagerLib/BdsPlatform.c

[edk2-devel] [PATCH v3 35/35] OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg

A Xen PVH guest doesn't have a RTC that OVMF would expect, so PcatRealTimeClockRuntimeDxe fails to initialize and prevent the firmware from finish to boot. To prevent that, we will use XenRealTimeClockLib which simply always return the same time. This will work on both Xen PVH and HVM guests.

[edk2-devel] [PATCH v3 25/35] OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot Linux

Linux panic if the VGA region isn't reserved. When Linux is booted on EFI system, it expects the memory at 0xa to _not_ be conventional memory. Otherwise a variable isn't initialised properly and Linux panic when a virtual console/terminal is asked to be created. See for more detail:

[edk2-devel] [PATCH v3 12/35] OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct

Check if there's a start of the day struct provided to PVH guest, save the ACPI RSDP address for later. This patch import import arch-x86/hvm/start_info.h from xen.git. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD Acked-by: Laszlo Ersek --- Notes:

[edk2-devel] [PATCH v3 27/35] OvmfPkg/XenPlatformLib: Cache result for XenDetected

We are going to replace XenDetected() implementation in PlatformBootManagerLib by the one in XenPlatformLib. PlatformBootManagerLib's implementation does cache the result of GetFirstGuidHob(), so we do something similar in XenPlatformLib. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689

[edk2-devel] [PATCH v3 21/35] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected

XenPvhDetected() can be used to figure out if OVMF has started via the Xen PVH entry point. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD Acked-by: Laszlo Ersek --- OvmfPkg/XenPlatformPei/Platform.h | 5 + OvmfPkg/XenPlatformPei/Xen.c | 13

[edk2-devel] [PATCH v3 30/35] OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency

PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib implementation. It will also be used by XenTimerDxe. Override PcdFSBClock to match Xen vLAPIC timer frequency. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD Acked-by: Laszlo Ersek --- Notes:

[edk2-devel] [PATCH v3 14/35] OvmfPkg/AcpiPlatformDxe: Use XenPlatformLib

This patch replace the XenDetected() function by the one in XenPlatformLib. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD --- Notes: v3: - new patch, splited from the next patch (which was OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist)

[edk2-devel] [PATCH v3 24/35] OvmfPkg/XenPlatformPei: Rework memory detection

When running as a Xen PVH guest, there is no CMOS to read the memory size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can works without CMOS by reading the e820 table. Rework XenPublishRamRegions for PVH, handle the Reserve type and explain about the ACPI type. MTRR settings

[edk2-devel] [PATCH v3 31/35] OvmfPkg/OvmfXen: Introduce XenTimerDxe

"PcAtChipsetPkg/8254TimerDxe" is replaced with a Xen-specific EFI_TIMER_ARCH_PROTOCOL implementation. Also remove 8259InterruptControllerDxe as it is not used anymore. This Timer uses the local APIC timer as time source as it can work on both a Xen PVH guest and an HVM one. Based on the

[edk2-devel] [PATCH v3 26/35] OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH

When the device ID of the host bridge is unknown, check if we are running as a PVH guest as there is no PCI bus in that case. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD --- Notes: v3: - Remove use of XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID, and

[edk2-devel] [PATCH v3 13/35] OvmfPkg/Library/XenPlatformLib: New library

The purpose of XenPlatformLib is to regroup the few functions that are used in several places to detect if Xen is detected, and to get the XenInfo HOB. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD --- Notes: v3: - use SPDX - add

[edk2-devel] [PATCH v3 34/35] OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg

Move XenRealTimeClockLib from ArmVirtPkg to OvmfPkg so it can be used from the OvmfPkg by the following patch, "OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg" Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD Reviewed-by: Laszlo Ersek ---

[edk2-devel] [PATCH v3 20/35] OvmfPkg/XenPlatformPei: Setup HyperPages earlier

We are going to need to make an hypercall in order to retreive the E820 table from the hypervisor before been able to setup the memory. Calling XenConnect earlier will allow to setup the XenHypercallLib earlier to allow to make hypercalls. While here, add some comments in XenConnect(). Ref:

[edk2-devel] [PATCH v3 10/35] OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader

EFI_XEN_OVMF_INFO is only useful to retrieve the E820 table. The mXenHvmloaderInfo isn't used yet, but will be use in a further patch to retrieve the E820 table. Also remove the unused pointer from the XenInfo HOB as that information is only useful in the XenPlatformPei. Ref:

[edk2-devel] [PATCH v3 15/35] OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it exist

If the firmware have been started via the Xen PVH entry point, a RSDP pointer would have been provided. Use it. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD --- Notes: v3: - patch splited from the previous one - Fix DEBUG format string, use

[edk2-devel] [PATCH v3 17/35] OvmfPkg/XenPlatformPei: Reinit XenHypercallLib

The XenPlatformPei needs to make hypercalls, but the XenHypercallLib was initialised before the HyperPage was ready. Now that XenPlatformPei has initialised the HyperPage, reinitialise the XenHypercallLib. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD ---

[edk2-devel] [PATCH v3 16/35] OvmfPkg/XenHypercallLib: Enable it in PEIM

Allow to use Xen hypercalls earlier, during the PEIM stage, but XenHypercallLibInit() must be called once the XenInfo HOB is created with the HyperPage setup. Change the return value of XenHypercallLibInit so failure can be detected when the call shouldn't fail, but still have the constructor

[edk2-devel] [PATCH v3 11/35] OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820

Use the already checked pointer mXenHvmloaderInfo to retrieve the E820 table produced by hvmloader. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD Acked-by: Laszlo Ersek --- OvmfPkg/XenPlatformPei/Xen.c | 18 +- 1 file changed, 9

[edk2-devel] [PATCH v3 00/35] Specific platform to run OVMF in Xen PVH and HVM guests

Patch series available in this git branch: https://xenbits.xen.org/git-http/people/aperard/ovmf.git br.platform-xen-pvh-v3 Hi, I've started to create a Xen specific platform, in OvmfPkg/XenOvmf.dsc with the goal to make it work on both Xen HVM and Xen PVH. The first few patches only create the

[edk2-devel] [PATCH v3 07/35] OvmfPkg/XenResetVector: Saving start of day pointer for PVH guests

As described in the Xen PVH documentation [1], "ebx: contains the physical memory address where the loader has placed the boot start info structure". To have this pointer saved to be able to use it later in the PEI phase, we allocate some space in the MEMFD for it. We use 'XPVH' as a signature

[edk2-devel] [PATCH v3 01/35] OvmfPkg/ResetSystemLib: Add missing dependency on PciLib

Add missing dependency on PciLib and remove extra includes of OvmfPlatforms.h. Signed-off-by: Anthony PERARD Reviewed-by: Laszlo Ersek --- Notes: v2: - also add PciLib.h include to the .c - and remove extra include of OvmfPlatforms.h

[edk2-devel] [PATCH v3 02/35] OvmfPkg: Create platform OvmfXen

OvmfXen is a copy of OvmfX64, removing VirtIO and some SMM. This new platform will be changed to make it works on two types of Xen guest: HVM and PVH. Compare to OvmfX64, this patch: - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION - removed: VirtioLib class resolution - removed:

[edk2-devel] [PATCH v3 03/35] OvmfPkg: Introduce XenResetVector

Introduce XenResetVector, a copy of OvmfPkg/ResetVector, with one changes: - SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0) Xen copies the OVMF code to RAM, there is no need to disable cache. This new module will later be modified to add a new entry point, more detail in a following

[edk2-devel] [PATCH v3 05/35] OvmfPkg/OvmfXen: Creating an ELF header

This patch changes the flash device image of OvmfXen to make it look like it's an ELF. For this, we replace the empty embedded variable store by a binary array, which is a ELF file header. The ELF header explain to a loader to load the binary at the address 1MB, then jump to the PVH entry point

[edk2-devel] [PATCH v3 04/35] OvmfPkg: Introduce XenPlatformPei

Introduce XenPlatformPei, a copy of OvmfPkg/PlatformPei without some of QEMU specific initialization, Xen does not support QemuFwCfg. This new module will be adjusted to accommodate Xen PVH. fw_cfg dependents that have been removed, which are dynamically skipped when running PlatformPei on Xen:

[edk2-devel] [PATCH v3 09/35] OvmfPkg/OvmfXen: use a TimerLib instance that depends only on the CPU

ACPI Timer does not work in a PVH guest, but local APIC works on both PVH and HVM. Note that the use of SecPeiDxeTimerLibCpu might be an issue with a driver of type DXE_RUNTIME_DRIVER. I've attemptde to find out which of the DXE_RUNTIME_DRIVER uses the TimerLib at runtime. I've done that by

[edk2-devel] [PATCH v3 06/35] OvmfPkg/XenResetVector: Add new entry point for Xen PVH

Add a new entry point for Xen PVH that enter directly in 32bits. Information on the expected state of the machine when this entry point is used can be found at: https://xenbits.xenproject.org/docs/unstable/misc/pvh.html Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by:

Re: [edk2-devel] [RFC PATCH 2/3] Maintainers.txt: add wildcard path association for Arm/AArch64

On Thu, Jul 04, 2019 at 06:14:04AM +, Wu, Hao A wrote: > I do met a little problem that for a patch that touches multiple features, > the contacts order in the output is not ideally perfect: > > Content in Maintainers.txt: > ''' > MdeModulePkg > F: MdeModulePkg/ > W:

Re: [edk2-devel] [PATCH] EmbeddedPkg: Fix various typos

On Thu, Jul 04, 2019 at 07:03:37AM -0700, Cœur wrote: > On Thu, Jul 4, 2019 at 09:01 PM, Leif Lindholm wrote: > > > > > Urgh, don't make me elaborate on the implications of public domain > > versus copyright... If you're interested, have a look at > >

Re: [edk2-devel] [PATCH] EmbeddedPkg: Fix various typos

On Thu, Jul 4, 2019 at 09:01 PM, Leif Lindholm wrote: > > Urgh, don't make me elaborate on the implications of public domain > versus copyright... If you're interested, have a look at > https://wiki.spdx.org/view/Legal_Team/Decisions/Dealing_with_Public_Domain_within_SPDX_Files > This link

Re: [edk2-devel] [PATCH v2] OvmfPkg: use DxeTpmMeasurementLib if and only if TPM2_ENABLE

On 07/04/19 06:07, Gary Lin wrote: > (a) OvmfPkg first had to resolve the TpmMeasurementLib class -- for > SECURE_BOOT_ENABLE only -- when the DxeImageVerificationLib instance > became dependent on TpmMeasurementLib. For details, refer to commit > 0d28d286bf4d ("OvmfPkg: resolve

Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol

Please note that this new feature change would be moved to Edk2-staging after obtaining the Reviewed-By. Regards Ashraf > -Original Message- > From: devel@edk2.groups.io On Behalf Of Javeed, > Ashraf > Sent: Thursday, July 4, 2019 6:42 PM > To: devel@edk2.groups.io > Cc: Kinney, Michael

[edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1954 New interface added to PCI Platform Protocol / PCI Override Protocol to retrieve device-specific platform policy for the following PCI standard features, like Maximum Payload Size (MPS), Maximum Read Request Size (MRRS),Extended Tags, Relax

Re: [edk2-devel] [PATCH] FatPkg: Fix various typos

+Ray On Sat, Jun 29, 2019 at 04:29:10AM -0700, Cœur wrote: > Fix various typos in FatPkg. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Coeur > --- > FatPkg/EnhancedFatDxe/Delete.c          |  2 +- > FatPkg/EnhancedFatDxe/DirectoryManage.c | 10 +- >

Re: [edk2-devel] [PATCH] BaseTools: Fix encoding typos

+Bob, Liming Personally, I'm not sure what should be done here. Normally for an imported piece of code, I would say "fix this upstream", but Pccts is as far as I can tell _long_ dead. On Sat, Jun 29, 2019 at 05:02:03AM -0700, Cœur wrote: > Fix encoding typos in BaseTools by using UTF-8. > >

Re: [edk2-devel] [PATCH v2 0/7] EmulatorPkg: Fix various typos

+Jordan, Andrew, Ray On Tue, Jul 02, 2019 at 09:39:21AM -0700, Cœur wrote: > Each commit can be reviewed/merged independently. Each commit is roughly 20 > lines modified. > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#43269):

Re: [edk2-devel] [PATCH] BaseTools: Fix various typos

+Bob, Liming On Wed, Jul 03, 2019 at 08:08:59AM -0700, Cœur wrote: > Fix various typos in BaseTools. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Coeur > --- > BaseTools/Conf/XMLSchema/DistributionPackage.xsd          | 8 >

Re: [edk2-devel] [PATCH] EmbeddedPkg: Fix various typos

On Wed, Jul 03, 2019 at 09:58:56AM -0700, Cœur wrote: > > Normally, we expect patches to be submitted via git send-email, as > > opposed to through the groups.io web interface (it introduces > > spectacular levels of corruption to the original patch). > > Hello Leif, and thank you for the message

Re: [edk2-devel] [PATCH] BaseTools: Fix various typos

Sorry about that, I won't copy-paste anymore. Can you see it with an attachment? Antoine -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#43266): https://edk2.groups.io/g/devel/message/43266 Mute This Topic:

Re: [edk2-devel] [PATCH] BaseTools: Fix various typos

On 7/4/19 1:16 PM, Philippe Mathieu-Daudé wrote: > Hi Antoine, > > On 7/3/19 5:08 PM, Cœur wrote: >> Fix various typos in BaseTools. >>   >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Coeur >> --- >>  BaseTools/Conf/XMLSchema/DistributionPackage.xsd          | 8

Re: [edk2-devel] [PATCH 0/5] MdePkg, SecurityPkg, OvmfPkg: revert unreviewed SM3 patches

On 7/4/19 11:46 AM, Laszlo Ersek wrote: > Repo: https://github.com/lersek/edk2.git > Branch: revert_unreviewed_bz1781 > > The MdePkg patch and the OvmfPkg patch committed for > had not been > reviewed appropriately, so they must be reverted.

Re: [edk2-devel] [PATCH 0/5] MdePkg, SecurityPkg, OvmfPkg: revert unreviewed SM3 patches

On Thu, Jul 04, 2019 at 11:46:19AM +0200, Laszlo Ersek wrote: > Repo: https://github.com/lersek/edk2.git > Branch: revert_unreviewed_bz1781 > > The MdePkg patch and the OvmfPkg patch committed for > had not been > reviewed appropriately, so

[edk2-devel] [PATCH 3/5] Revert "SecurityPkg/HashLibBaseCryptoRouter: recognize the SM3 digest algorithm"

This reverts commit 542d04e2a4fec0df0340d2ad7b59f011f20d03cc. The reason is that said commit indirectly depends on commit 49c1e683c452 ("MdePkg/Protocol/Hash: introduce GUID for SM3", 2019-07-03), and the latter commit is going to be reverted, due to its review process not having followed

[edk2-devel] [PATCH 5/5] Revert "MdePkg/Protocol/Hash: introduce GUID for SM3"

This reverts commit 49c1e683c452f68c7315454280d81449f7d94d2b. The reason is that said commit had not been reviewed by MdePkg maintainers, before it was pushed. Cc: Imran Desai Cc: Leif Lindholm Cc: Liming Gao Cc: Michael D Kinney Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1781

[edk2-devel] [PATCH 2/5] Revert "SecurityPkg: set SM3 bit in TPM 2.0 hash mask by default"

This reverts commit d5af8fc5a975feb6c745587d0d834733ad2048fd. The reason is that said commit indirectly depends on commit 49c1e683c452 ("MdePkg/Protocol/Hash: introduce GUID for SM3", 2019-07-03), and the latter commit is going to be reverted, due to its review process not having followed

[edk2-devel] [PATCH 1/5] Revert "OvmfPkg: link SM3 support into Tcg2Pei and Tcg2Dxe"

This reverts commit a7c7d21ffa9ad14b418e728a882df0a9b8815bf6. The reason is that said commit had not been reviewed by OvmfPkg maintainers/reviewers, before it was pushed. Cc: Ard Biesheuvel Cc: Imran Desai Cc: Jordan Justen Cc: Leif Lindholm Cc: Marc-André Lureau Cc: Stefan Berger Ref:

Re: [edk2-devel] [PATCH v5 edk2-platforms 1/1] Silicon/DesignWare/Driver: DwEmacSnpDxe: Add DesignWare EMAC driver

Hi Tzy Way, On Thu, Jul 04, 2019 at 06:17:25AM +, Ooi, Tzy Way wrote: > Thank you for reviewing the source code. I will change the source > code according to the comment. I would like to confirm with you > about my understanding about the comment as shown below: > > == 1 == > >>- Use recent

Re: [edk2-devel] [PATCH 1/1] OvmfPkg: Only import DxeTpmMeasurementLib when TPM is enabled

On Thu, Jul 04, 2019 at 10:33:55AM +0200, Laszlo Ersek wrote: > On 07/04/19 05:58, Gary Lin wrote: > > On Wed, Jul 03, 2019 at 09:49:26PM +0200, Laszlo Ersek wrote: > >> Hi Gary, > >> > >> On 07/03/19 12:22, Gary Lin wrote: > >>> DxeTpmMeasurementLib is only useful when TPM is enabled. > >>> >

Re: [edk2-devel] [PATCH 1/1] OvmfPkg: Only import DxeTpmMeasurementLib when TPM is enabled

On 07/04/19 05:58, Gary Lin wrote: > On Wed, Jul 03, 2019 at 09:49:26PM +0200, Laszlo Ersek wrote: >> Hi Gary, >> >> On 07/03/19 12:22, Gary Lin wrote: >>> DxeTpmMeasurementLib is only useful when TPM is enabled. >>> >>> Cc: Jordan Justen >>> Cc: Laszlo Ersek >>> Cc: Marc-André Lureau >>> Cc:

Re: [edk2-devel] [PATCH v2 5/5] OvmfPkg: link SM3 support into Tcg2Pei and Tcg2Dxe

On 07/04/19 00:48, Desai, Imran wrote: > Hello Lersek/ Leif, > > Like Lersek hinted, this in fact was an inadvertent issue with the git > configuration. > I suspect the suppresscc in my configuration may have been the source of all > confusion. My apologies. That explains why the CC's didn't

Re: [edk2-devel] [PATCH] SecurityPkg: Don't Verify the enrolled PK in setup mode

Add SecurityPkg maintainers. Thanks, Derek From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of derek.l...@hpe.com Sent: Tuesday, July 2, 2019 1:25 PM To: devel@edk2.groups.io Subject: [edk2-devel] [PATCH] SecurityPkg: Don't Verify the enrolled PK in setup mode Patch is

Re: [edk2-devel] [Patch v3 2/2] UefiCpuPkg/PiSmmCpuDxeSmm: Enable MM MP Protocol.

1. mMaxNumberOfCpus and gSmmCpuPrivate->SmmCoreEntryContext.NumberOfCpus are both used. Can you please refine the code to use only one? 2. I do think that MM_MP code needs to maintain a internal linked list containing all created tokens. Because it's possible that caller is written in below

Re: [edk2-devel] [RFC PATCH 2/3] Maintainers.txt: add wildcard path association for Arm/AArch64

> -Original Message- > From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > Sent: Wednesday, July 03, 2019 6:44 PM > To: Wu, Hao A > Cc: devel@edk2.groups.io > Subject: Re: [RFC PATCH 2/3] Maintainers.txt: add wildcard path association > for Arm/AArch64 > > On Wed, Jul 03, 2019 at