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

Michael, Below PCDs are in MinPlatformPkg. Can you use them instead of adding new ones in IntelSiliconPkg? ## Indicates the MMIO base address of the microcode FV in flash. gMinPlatformPkgTokenSpaceGuid.PcdFlashFvMicrocodeBase|0xFFE6|UINT32|0x3004 ## Indicates the size of the

[edk2-devel] Cancelled Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, June 29, 2021 #cal-cancelled

BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Groups.io Inc//Groups.io Calendar//EN METHOD:CANCELLED CALSCALE:GREGORIAN BEGIN:VTIMEZONE TZID:America/Los_Angeles LAST-MODIFIED:20201011T015911Z TZURL:http://tzurl.org/zoneinfo-outlook/America/Los_Angeles X-LIC-LOCATION:America/Los_Angeles BEGIN:DAYLIGHT

Re: [edk2-devel] [PATCH v2 1/2] OvmfPkg/Bhyve: add USB support

Hi Corvin, + # + # Usb Support + # + MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf + MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf + MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf + MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf + MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf +

Re: [edk2-devel] [PATCH v3 2/3] Acpi: Install Acpi tables for Cloud hypervisor

Hi Sami, All comments are accepted. Thanks for your elaborate review work! BR Jianyong > -Original Message- > From: Sami Mujawar > Sent: Monday, June 28, 2021 8:22 PM > To: Jianyong Wu ; devel@edk2.groups.io > Cc: ler...@redhat.com; ardb+tianoc...@kernel.org; Justin He > ; nd >

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

Hi Sami, All comments are accepted. Thanks. BR Jianyong > -Original Message- > From: Sami Mujawar > Sent: Monday, June 28, 2021 8:43 PM > To: Jianyong Wu ; devel@edk2.groups.io > Cc: ler...@redhat.com; ardb+tianoc...@kernel.org; Justin He > ; nd > Subject: Re: [PATCH v3 3/3]

Re: [edk2-devel] [PATCH v3 1/3] Acpi: reimplement PlatformHasAcpi for Cloud Hypervisor

Hi Sami, I'm glad to get this precious "Reviewed-by", thanks! BR Jianyong > -Original Message- > From: Sami Mujawar > Sent: Monday, June 28, 2021 8:45 PM > To: Jianyong Wu ; devel@edk2.groups.io > Cc: ler...@redhat.com; ardb+tianoc...@kernel.org; Justin He > ; nd > Subject: Re:

回复: [edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - 06/29/2021 #cal-reminder

There is no new issue to be reviewed this week. Let’s cancel this week meeting. Thanks Liming 发件人: devel@edk2.groups.io 代表 devel@edk2.groups.io Calendar 发送时间: 2021年6月29日 9:30 收件人: devel@edk2.groups.io 主题: [edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - 06/29/2021 #cal-reminder

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

Do you change ArmVirtQemu.fdf? The error reports the issue in this file GenFds.FdfParser.Warning: expected [FD.] near line 115, column 3: } Thanks Liming 发件人: devel@edk2.groups.io 代表 Lange Tang 发送时间: 2021年6月29日 9:36 收件人: devel@edk2.groups.io 主题: [edk2-devel] error C0DE: Unknown fatal

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

Hello, I'm interested in the edk2 CI unit tests(https://github.com/tianocore/edk2/tree/master/.pytool). I tested it in my local. It works well in Windows but does not work in Linux. It looks the NuGet in pytool only has windows version

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

build.py... : error C0DE: Unknown fatal error when processing [/home/lange/uefi/edk2/ArmVirtPkg/ArmVirtQemu.dsc] (Please send email to devel@edk2.groups.io for help, attaching following call stack trace!) (Python 3.6.9 on linux) Traceback (most recent call last): File

[edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - 06/29/2021 #cal-reminder

BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Groups.io Inc//Groups.io Calendar//EN METHOD:PUBLISH CALSCALE:GREGORIAN BEGIN:VTIMEZONE TZID:America/Los_Angeles LAST-MODIFIED:20201011T015911Z TZURL:http://tzurl.org/zoneinfo-outlook/America/Los_Angeles X-LIC-LOCATION:America/Los_Angeles BEGIN:DAYLIGHT

Re: [edk2-devel] [PATCH] MdeModulePkg/RamDiskDxe: RamDisk driver to assign non-zero SPA range index

> -Original Message- > From: devel@edk2.groups.io On Behalf Of Wu, Hao A > Sent: Tuesday, June 29, 2021 8:24 AM > To: devel@edk2.groups.io; Bassa, Damian > Cc: Rusocki, Krzysztof > Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/RamDiskDxe: RamDisk driver > to assign non-zero SPA range

Re: [edk2-devel] [PATCH] MdeModulePkg/RamDiskDxe: RamDisk driver to assign non-zero SPA range index

> -Original Message- > From: devel@edk2.groups.io On Behalf Of Bassa, > Damian > Sent: Tuesday, June 29, 2021 2:22 AM > To: devel@edk2.groups.io > Cc: Rusocki, Krzysztof > Subject: [edk2-devel] [PATCH] MdeModulePkg/RamDiskDxe: RamDisk driver to > assign non-zero SPA range index > >

Re: [edk2-devel] [edk2-platforms][PATCH v4 20/41] CometlakeOpenBoardPkg: Update SpiFvbService & SpiFlashCommonLib

Reviewed-by: Sai Chaganty -Original Message- From: mikub...@linux.microsoft.com Sent: Friday, June 25, 2021 2:21 PM To: devel@edk2.groups.io Cc: Chiu, Chasel ; Desimone, Nathaniel L ; Chaganty, Rangasai V ; Kethi Reddy, Deepika ; Esakkithevar, Kathappan Subject:

Re: [edk2-devel] [edk2-platforms][PATCH v4 26/41] CoffeelakeSiliconPkg: Remove SmmSpiFlashCommonLib

Reviewed-by: Sai Chaganty -Original Message- From: mikub...@linux.microsoft.com Sent: Friday, June 25, 2021 2:21 PM To: devel@edk2.groups.io Cc: Chiu, Chasel ; Chaganty, Rangasai V ; Desimone, Nathaniel L Subject: [edk2-platforms][PATCH v4 26/41] CoffeelakeSiliconPkg: Remove

Re: [edk2-devel] [edk2-platforms][PATCH v4 37/41] IntelSiliconPkg: Identify flash regions by GUID

Reviewed-by: Sai Chaganty -Original Message- From: mikub...@linux.microsoft.com Sent: Friday, June 25, 2021 2:21 PM To: devel@edk2.groups.io Cc: Ni, Ray ; Chaganty, Rangasai V ; Desimone, Nathaniel L Subject: [edk2-platforms][PATCH v4 37/41] IntelSiliconPkg: Identify flash regions

Re: [edk2-devel] [edk2-platforms][PATCH v4 36/41] IntelSiliconPkg: Add flash region GUIDs

Reviewed-by: Sai Chaganty -Original Message- From: mikub...@linux.microsoft.com Sent: Friday, June 25, 2021 2:21 PM To: devel@edk2.groups.io Cc: Ni, Ray ; Chaganty, Rangasai V ; Desimone, Nathaniel L Subject: [edk2-platforms][PATCH v4 36/41] IntelSiliconPkg: Add flash region GUIDs

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

Hi Michael, Is this change relevant to BZ 3307 ? Not sure if we need this change in IntelSiliconPkg. Recently as part of https://edk2.groups.io/g/devel/topic/82355106#74406, the microcode related PCDs were consolidated and moved into MinPlatformPkg. Did you find use case of microcode related

Re: [edk2-devel] [edk2-platforms][PATCH v4 09/41] IntelSiliconPkg: Add SmmSpiFlashCommonLib

Reviewed-by: Sai Chaganty -Original Message- From: mikub...@linux.microsoft.com Sent: Friday, June 25, 2021 2:21 PM To: devel@edk2.groups.io Cc: Ni, Ray ; Chaganty, Rangasai V ; Desimone, Nathaniel L Subject: [edk2-platforms][PATCH v4 09/41] IntelSiliconPkg: Add

Re: [edk2-devel] [edk2-platforms][PATCH v4 08/41] IntelSiliconPkg: Add SpiFlashCommonLib

Reviewed-by: Sai Chaganty -Original Message- From: mikub...@linux.microsoft.com Sent: Friday, June 25, 2021 2:21 PM To: devel@edk2.groups.io Cc: Ni, Ray ; Chaganty, Rangasai V ; Desimone, Nathaniel L Subject: [edk2-platforms][PATCH v4 08/41] IntelSiliconPkg: Add SpiFlashCommonLib

Re: [edk2-devel] [edk2-platforms][PATCH v4 06/41] IntelSiliconPkg: Add PCH SPI PPI

Reviewed-by: Sai Chaganty -Original Message- From: mikub...@linux.microsoft.com Sent: Friday, June 25, 2021 2:21 PM To: devel@edk2.groups.io Cc: Ni, Ray ; Chaganty, Rangasai V ; Desimone, Nathaniel L Subject: [edk2-platforms][PATCH v4 06/41] IntelSiliconPkg: Add PCH SPI PPI From:

Re: [edk2-devel] [edk2-platforms][PATCH v4 04/41] IntelSiliconPkg: Add BIOS area base address and size PCDs

Reviewed-by: Sai Chaganty -Original Message- From: mikub...@linux.microsoft.com Sent: Friday, June 25, 2021 2:21 PM To: devel@edk2.groups.io Cc: Ni, Ray ; Chaganty, Rangasai V ; Desimone, Nathaniel L Subject: [edk2-platforms][PATCH v4 04/41] IntelSiliconPkg: Add BIOS area base

Re: [edk2-devel] [edk2-platforms][PATCH v4 03/41] CometlakeOpenBoardPkg/PeiPolicyUpdateLib: Add missing GUID to INF

Reviewed-by: Sai Chaganty -Original Message- From: mikub...@linux.microsoft.com Sent: Friday, June 25, 2021 2:21 PM To: devel@edk2.groups.io Cc: Chiu, Chasel ; Desimone, Nathaniel L ; Chaganty, Rangasai V ; Kethi Reddy, Deepika ; Esakkithevar, Kathappan Subject:

Re: [edk2-devel] [edk2-platforms][PATCH v4 02/41] WhiskeylakeOpenBoardPkg: Remove redundant IntelSiliconPkg.dec entry

Reviewed-by: Sai Chaganty -Original Message- From: mikub...@linux.microsoft.com Sent: Friday, June 25, 2021 2:21 PM To: devel@edk2.groups.io Cc: Ni, Ray ; Chaganty, Rangasai V ; Desimone, Nathaniel L Subject: [edk2-platforms][PATCH v4 02/41] WhiskeylakeOpenBoardPkg: Remove

Re: [edk2-devel] [edk2-platforms][PATCH v4 01/41] CometlakeOpenBoardPkg: Remove redundant IntelSiliconPkg.dec entry

Reviewed-by: Sai Chaganty -Original Message- From: mikub...@linux.microsoft.com Sent: Friday, June 25, 2021 2:21 PM To: devel@edk2.groups.io Cc: Chiu, Chasel ; Desimone, Nathaniel L ; Chaganty, Rangasai V ; Kethi Reddy, Deepika ; Esakkithevar, Kathappan Subject:

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

Can you please help us on this issues? Get Outlook for Android From: devel@edk2.groups.io on behalf of LathaKannan Arumugam via groups.io Sent: Friday, June 25, 2021 1:11:42 PM To: Bret Barkelew ; Rabeda, Maciej ; devel@edk2.groups.io

[edk2-devel] [PATCH] MdeModulePkg/RamDiskDxe: RamDisk driver to assign non-zero SPA range index

Driver should not use default zero value to assign SPA range since it is invalid value according to ACPI spec. After the change driver will look for highest index existing in the table. If maximum number is already taken it will look for holes in table. Signed-off-by: Damian Bassa ---

[edk2-devel] [RFC PATCH v4 27/27] OvmfPkg/AmdSev: expose the SNP reserved pages through configuration table

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Now that both the secrets and cpuid pages are reserved in the HOB, extract the location details through fixed PCD and make it available to the guest OS through the configuration table. Cc: James Bottomley Cc: Min Xu Cc: Jiewen Yao Cc:

[edk2-devel] [RFC PATCH v4 25/27] UefiCpuPkg/MpInitLib: Use SEV-SNP AP Creation NAE event to launch APs

From: Tom Lendacky BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Use the SEV-SNP AP Creation NAE event to create and launch APs under SEV-SNP. This capability will be advertised in the SEV Hypervisor Feature Support PCD (PcdSevEsHypervisorFeatures). Cc: Eric Dong Cc: Ray Ni Cc:

[edk2-devel] [RFC PATCH v4 19/27] OvmfPkg/PlatformPei: set the SEV-SNP enabled PCD

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The MpInitLib uses the PcdSevSnpIsEnabled to determine whether the SEV-SNP is active. If the SEV-SNP is active, then set the PCD to TRUE. Cc: James Bottomley Cc: Min Xu Cc: Jiewen Yao Cc: Tom Lendacky Cc: Jordan Justen Cc: Ard

[edk2-devel] [RFC PATCH v4 26/27] OvmfPkg/PlatformPei: mark cpuid and secrets memory reserved in EFI map

When SEV-SNP is active, the CPUID and Secrets memory range contains the information that is used during the VM boot. The content need to be persist across the kexec boot. Mark the memory range as Reserved in the EFI map so that guest OS or firmware does not use the range as a system RAM. Cc:

[edk2-devel] [RFC PATCH v4 21/27] MdePkg/GHCB: increase the GHCB protocol max version

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Now that OvmfPkg supports version 2 of the GHCB specification, bump the protocol version. Cc: Ray Ni Cc: Rahul Kumar Cc: Eric Dong Cc: James Bottomley Cc: Min Xu Cc: Jiewen Yao Cc: Tom Lendacky Cc: Jordan Justen Cc: Ard Biesheuvel

[edk2-devel] [RFC PATCH v4 24/27] OvmfPkg/MemEncryptSevLib: skip page state change for Mmio address

The SetMemoryEncDec() is used by the higher level routines to set or clear the page encryption mask for system RAM and Mmio address. When SEV-SNP is active, in addition to set/clear page mask it also updates the RMP table. The RMP table updates are required for the system RAM address and not the

[edk2-devel] [RFC PATCH v4 23/27] OvmfPkg/MemEncryptSevLib: change the page state in the RMP table

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The MemEncryptSev{Set,Clear}PageEncMask() functions are used to set or clear the memory encryption attribute in the page table. When SEV-SNP is active, we also need to change the page state in the RMP table so that it is in sync with the

[edk2-devel] [RFC PATCH v4 22/27] UefiCpuPkg/MpLib: add support to register GHCB GPA when SEV-SNP is enabled

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 An SEV-SNP guest requires that the physical address of the GHCB must be registered with the hypervisor before using it. See the GHCB specification section 2.3.2 for more details. Cc: Eric Dong Cc: Ray Ni Cc: Rahul Kumar Cc: James

[edk2-devel] [RFC PATCH v4 20/27] OvmfPkg/PlatformPei: set the Hypervisor Features PCD

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Version 2 of the GHCB specification added the support to query the hypervisor feature bitmap. The feature bitmap provide information such as whether to use the AP create VmgExit or use the AP jump table approach to create the APs. The

[edk2-devel] [RFC PATCH v4 18/27] OvmfPkg/PlatformPei: validate the system RAM when SNP is active

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 When SEV-SNP is active, a memory region mapped encrypted in the page table must be validated before access. There are two approaches that can be taken to validate the system RAM detected during the PEI phase: 1) Validate on-demand OR 2)

[edk2-devel] [RFC PATCH v4 17/27] OvmfPkg/SecMain: pre-validate the memory used for decompressing Fv

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The VMM launch sequence should have pre-validated all the data pages used in the Reset vector. The range does not cover the data pages used during the SEC phase (mainly PEI and DXE firmware volume decompression memory). When SEV-SNP is

[edk2-devel] [RFC PATCH v4 16/27] OvmfPkg/MemEncryptSevLib: add support to validate > 4GB memory in PEI phase

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The initial page built during the SEC phase is used by the MemEncryptSevSnpValidateSystemRam() for the system RAM validation. The page validation process requires using the PVALIDATE instruction; the instruction accepts a virtual address of

[edk2-devel] [RFC PATCH v4 12/27] OvmfPkg/PlatformPei: register GHCB gpa for the SEV-SNP guest

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The SEV-SNP guest requires that GHCB GPA must be registered before using. See the GHCB specification section 2.3.2 for more details. Cc: James Bottomley Cc: Min Xu Cc: Jiewen Yao Cc: Tom Lendacky Cc: Jordan Justen Cc: Ard Biesheuvel

[edk2-devel] [RFC PATCH v4 15/27] OvmfPkg/BaseMemEncryptSevLib: skip the pre-validated system RAM

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The MemEncryptSevSnpPreValidateSystemRam() is used for pre-validating the system RAM. As the boot progress, each phase validates a fixed region of the RAM. In the PEI phase, the PlatformPei detects all the available RAM and calls to

[edk2-devel] [RFC PATCH v4 14/27] OvmfPkg/MemEncryptSevLib: add support to validate system RAM

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Many of the integrity guarantees of SEV-SNP are enforced through the Reverse Map Table (RMP). Each RMP entry contains the GPA at which a particular page of DRAM should be mapped. The guest can request the hypervisor to add pages in the RMP

[edk2-devel] [RFC PATCH v4 11/27] OvmfPkg/SecMain: register GHCB gpa for the SEV-SNP guest

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The SEV-SNP guest requires that GHCB GPA must be registered before using. See the GHCB specification section 2.3.2 for more details. Cc: James Bottomley Cc: Min Xu Cc: Jiewen Yao Cc: Tom Lendacky Cc: Jordan Justen Cc: Ard Biesheuvel

[edk2-devel] [RFC PATCH v4 09/27] UefiCpuPkg: Define the SEV-SNP specific dynamic PCDs

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Define the PCDs used by the MpInitLib while creating the AP when SEV-SNP is active in the guest VM. Cc: Ray Ni Cc: Rahul Kumar Cc: Eric Dong Cc: James Bottomley Cc: Min Xu Cc: Jiewen Yao Cc: Tom Lendacky Cc: Jordan Justen Cc: Ard

[edk2-devel] [RFC PATCH v4 10/27] OvmfPkg/MemEncryptSevLib: add MemEncryptSevSnpEnabled()

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Create a function that can be used to determine if VM is running as an SEV-SNP guest. Cc: James Bottomley Cc: Min Xu Cc: Jiewen Yao Cc: Tom Lendacky Cc: Jordan Justen Cc: Ard Biesheuvel Cc: Laszlo Ersek Cc: Erdem Aktas

[edk2-devel] [RFC PATCH v4 13/27] OvmfPkg/AmdSevDxe: do not use extended PCI config space

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Commit 85b8eac59b8c5bd9c7eb9afdb64357ce1aa2e803 added support to ensure that MMIO is only performed against the un-encrypted memory. If MMIO is performed against encrypted memory, a #GP is raised. The AmdSevDxe uses the functions provided

[edk2-devel] [RFC PATCH v4 05/27] OvmfPkg: reserve CPUID page for SEV-SNP

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Platform features and capabilities are traditionally discovered via the CPUID instruction. Hypervisors typically trap and emulate the CPUID instruction for a variety of reasons. There are some cases where incorrect CPUID information can

[edk2-devel] [RFC PATCH v4 03/27] OvmfPkg/ResetVector: add the macro to request guest termination

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The upcoming SEV-SNP support will need to make a few additional guest termination requests depending on the failure type. Let's move the logic to request the guest termination into a macro to keep the code readable. Cc: James Bottomley Cc:

[edk2-devel] [RFC PATCH v4 08/27] OvmfPkg/ResetVector: invalidate the GHCB page

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The GHCB page is part of a pre-validated memory range specified through the SnpBootBlock GUID. When SEV-SNP is active, the GHCB page is pre-validated by the hyperivosr during the SNP guest creation. On boot, the reset vector maps the GHCB

[edk2-devel] [RFC PATCH v4 06/27] OvmfPkg/ResetVector: introduce SEV-SNP boot block GUID

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Introduce a new SEV-SNP boot-specific GUID block. The block is used to communicate the secrets and cpuid memory area reserved by the guest BIOS. When SEV-SNP is enabled, the hypervisor will locate the SEV-SNP boot block to get the location

[edk2-devel] [RFC PATCH v4 07/27] OvmfPkg/ResetVector: pre-validate the data pages used in SEC phase

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 An SEV-SNP guest requires that private memory (aka pages mapped encrypted) must be validated before being accessed. The validation process consist of the following sequence: 1) Set the memory encryption attribute in the page table (aka

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

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The upcoming SEV-SNP support will need to make a few additional MSR protocol based VMGEXIT's. Add a macro that wraps the common setup and response validation logic in one place to keep the code readable. While at it, define SEV_STATUS_MSR

[edk2-devel] [RFC PATCH v4 01/27] OvmfPkg/ResetVector: move SEV specific code in a separate file

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The PageTables64.asm was created to provide routines to set the CR3 register for 64-bit paging. During the SEV support, it grew to include a lot of the SEV stuff. Before adding more SEV features, let's move all the SEV-specific routines into

[edk2-devel] [RFC PATCH v4 04/27] OvmfPkg: reserve SNP secrets page

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 During the SNP guest launch sequence, a special secrets page needs to be inserted by the VMM. The PSP will populate the page; it will contain the VM Platform Communication Key (VMPCKs) used by the guest to send and receive secure messages to

[edk2-devel] [RFC PATCH v4 00/27] Add AMD Secure Nested Paging (SEV-SNP) support

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 SEV-SNP builds upon existing SEV and SEV-ES functionality while adding new hardware-based memory protections. SEV-SNP adds strong memory integrity protection to help prevent malicious hypervisor-based attacks like data replay, memory

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

On 28.06.21 16:57, Laszlo Ersek wrote: On 06/25/21 20:47, Kun Qin wrote: Hi Mike, Thanks for the information. I can update the patch and proposed spec change to use flexible array in v-next if there is no other concerns. After switching to flexible array, OFFSET_OF (Data) should lead to the

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

On 06/25/21 20:47, Kun Qin wrote: > Hi Mike, > > Thanks for the information. I can update the patch and proposed spec > change to use flexible array in v-next if there is no other concerns. > > After switching to flexible array, OFFSET_OF (Data) should lead to the > same result as sizeof. This

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

Hi Maciej, [snipping liberally, comments below] On 06/25/21 16:56, Rabeda, Maciej wrote: > On 22-Jun-21 17:57, Laszlo Ersek wrote: >> On 06/11/21 13:54, Rabeda, Maciej wrote: >>> On 08-Jun-21 15:06, Laszlo Ersek wrote: +typedef struct { + UINT8 Algorithm; //

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

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: -

Re: [edk2-devel] [PATCH v3 1/3] Acpi: reimplement PlatformHasAcpi for Cloud Hypervisor

Hi Jianyong, Thank you for this patch. This patch looks good to me. Reviewed-by: Sami Mujawar Regards, Sami Mujawar On 28/06/2021 10:55 AM, Jianyong Wu wrote: The current implementation of PlatformHasAcpiDt is not a common library and is on behalf of qemu. So give a specific version for

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

Hi Jianyong, Please find my response inline marked [SAMI]. Regards, Sami Mujawar On 28/06/2021 10:55 AM, Jianyong Wu wrote: Cloud Hypervisor is KVM based VMM and is implemented in rust. Just like other VMMs it needs UEFI support to let ACPI work. That is why Cloud Hypervisor is introduced

Re: [edk2-devel] [PATCH] OvmfPkg/Bhyve: clean up TPM_ENABLE remnants

On 06/24/21 00:07, Kinney, Michael D wrote: > Hi Laszlo, > > I understand your point. > > I am trying to balance the ease of use for developers, reducing overhead for > maintainers, and > prevent bad commits. > > I think you are saying that you want to make sure a maintainer carefully >

Re: [edk2-devel] [PATCH v3 2/3] Acpi: Install Acpi tables for Cloud hypervisor

Hi Jianyong, Please find my response inline marked [SAMI]. Regards, Sami Mujawar On 28/06/2021 10:55 AM, Jianyong Wu wrote: There is no device like Fw-cfg in Qemu in Cloud Hypervisor, so a specific Acpi handler is introduced here. The handler implemented here is in a very simple way: 1.

Re: [edk2-devel] [PATCH] UefiPayloadPkg/PayloadLoader: Add more checks to verify ELF images

Hey Ray, Sorry for not having properly checked yet, I definitely plan to still. However, I probably won't till a pointer alignment macro lands (I plan to submit a bunch of things, including this, within the next two weeks). Once it has been merged, I think this patch can be improved with

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

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: provide a generic implementation of

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

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 Feldman-Fitzthum Ref:

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

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 Biesheuvel Cc: Jordan Justen Cc: James Bottomley

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

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. We already have a synthetic filesystem

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

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: implement QEMU loader library for X86 with

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

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 revert back to AllocatePool instead of

[edk2-devel] [PATCH v3 2/3] Acpi: Install Acpi tables for Cloud hypervisor

There is no device like Fw-cfg in Qemu in Cloud Hypervisor, so a specific Acpi handler is introduced here. The handler implemented here is in a very simple way: 1. acquire the RSDP from the PCD variable in the top ".dsc"; 2. get the XSDT address from RSDP structure; 3. get the ACPI tables

[edk2-devel] [PATCH v3 1/3] Acpi: reimplement PlatformHasAcpi for Cloud Hypervisor

The current implementation of PlatformHasAcpiDt is not a common library and is on behalf of qemu. So give a specific version for Cloud Hypervisor here. Signed-off-by: Jianyong Wu --- .../CloudHvHasAcpiDtDxe.inf | 43 .../CloudHvHasAcpiDtDxe.c |

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

Cloud Hypervisor is KVM based VMM and is implemented in rust. Just like other VMMs it needs UEFI support to let ACPI work. That is why Cloud Hypervisor is introduced here. Signed-off-by: Jianyong Wu --- ArmVirtPkg/ArmVirtCloudHv.dsc | 397 ++

[edk2-devel] [PATCH v3 0/3] Enable Cloud Hypervisor support in edk2

Cloud Hypervisor is an open source Virtual Machine Monitor (VMM) that runs on top of KVM. Cloud Hypervisor is implemented in Rust and is based on the rust-vmm crates. See [1] to find more. To support UEFI, Cloud Hypervisor is introduced here. There are 2 parts to be considered to do this

[edk2-devel] [PATCH 1/1] BaseTools: Remove non-ascii character of StructurePcd comment

Currently, the ConvertFceToStructurePcd.py tool generate StructurePcd dsc file with comments from UNI file including non-ascii character. Following DSC spec, there should not have non-ascii character in DSC file. This patch removes the non-ascii character when adding the comment and changes the

Re: [edk2-devel] [PATCH v2 4/8] ShellPkg: Acpiview: IORT parser update for IORT Rev E.b spec

Reviewed-by: Zhichao Gao Thanks, Zhichao > -Original Message- > From: Sami Mujawar > Sent: Thursday, June 17, 2021 5:56 PM > To: devel@edk2.groups.io > Cc: Sami Mujawar ; alexei.fedo...@arm.com; > steven.pr...@arm.com; lorenzo.pieral...@arm.com; > matteo.carl...@arm.com;

Re: [edk2-devel] [PATCH v2 3/8] ShellPkg: Acpiview: Abbreviate field names to preserve alignment

Reviewed-by: Zhichao Gao Thanks, Zhichao > -Original Message- > From: Sami Mujawar > Sent: Thursday, June 17, 2021 5:56 PM > To: devel@edk2.groups.io > Cc: Sami Mujawar ; alexei.fedo...@arm.com; > matteo.carl...@arm.com; ben.adder...@arm.com; Ni, Ray > ; Gao, Zhichao ; n...@arm.com >

Re: [edk2-devel] [PATCH v2 2/8] MdePkg: IORT header update for IORT Rev E.b spec

Reviewed-by: Zhichao Gao Thanks, Zhichao > -Original Message- > From: Sami Mujawar > Sent: Thursday, June 17, 2021 5:56 PM > To: devel@edk2.groups.io > Cc: Sami Mujawar ; alexei.fedo...@arm.com; > ardb+tianoc...@kernel.org; matteo.carl...@arm.com; > ben.adder...@arm.com;

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

Hello Kun and Bret, sorry for the delayed response. I think I agree with the approach mentioned by Bret below: "deprecate, break builds, fix code, move forward". If we just modify the structure, it is likely that platform drivers that consumes EFI_(S)MM_COMMUNICATE_HEADER may not be aware of