Mike,
Looks perfect to me. For everyone: the only change from V7 is an addition of
DEBUG_VERBOSE message, which can indeed be useful.
Best wishes,
Vitaly
> 20 мая 2020 г., в 06:01, Michael D Kinney
> написал(а):
>
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2054
>
> Runtime
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2716
Add definitions for ACPI NVDIMM Device Path following UEFI spec.
Cc: Michael D Kinney
Cc: Liming Gao
Signed-off-by: James Anandraj
---
MdePkg/Include/Protocol/DevicePath.h | 15 +++
1 file changed, 15 insertions(+)
diff
On 5/19/20 4:50 PM, Tom Lendacky wrote:
This patch series provides support for running EDK2/OVMF under SEV-ES.
Over the next few days I'll work on the Wiki page that has been requested,
as well as getting the feature added to the request plan page.
Thanks,
Tom
Secure Encrypted
No need to resend new patch, you can go ahead with Nate's review after the
correction.
> -Original Message-
> From: Chiu, Chasel
> Sent: Wednesday, May 20, 2020 12:25 PM
> To: Zeng, Star ; Desimone, Nathaniel L
> ; devel@edk2.groups.io
> Cc: Ma, Maurice
> Subject: RE: [PATCH]
Yes, thanks for good catch! I will correct it.
> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, May 20, 2020 12:21 PM
> To: Desimone, Nathaniel L ; Chiu, Chasel
> ; devel@edk2.groups.io
> Cc: Ma, Maurice ; Zeng, Star
> Subject: RE: [PATCH] IntelFsp2Pkg: Add
equilivant is a typo?
> -Original Message-
> From: Desimone, Nathaniel L
> Sent: Wednesday, May 20, 2020 12:12 PM
> To: Chiu, Chasel ; devel@edk2.groups.io
> Cc: Ma, Maurice ; Zeng, Star
> Subject: RE: [PATCH] IntelFsp2Pkg: Add FunctionParametePtr to
> FspGlobalData.
>
> Reviewed-by:
Reviewed-by: Nate DeSimone
> -Original Message-
> From: Chiu, Chasel
> Sent: Tuesday, May 19, 2020 8:34 PM
> To: devel@edk2.groups.io
> Cc: Ma, Maurice ; Desimone, Nathaniel L
> ; Zeng, Star
> Subject: [PATCH] IntelFsp2Pkg: Add FunctionParametePtr to FspGlobalData.
>
> REF:
From: Pankaj Bansal
Chassis3V2 is the new chassis on which LS1028A and LX2160A SOCs
are based.
Add the Chassis3V2 package.
Signed-off-by: Pankaj Bansal
---
Silicon/NXP/Chassis3V2/Chassis3V2.dec| 22 ++
Silicon/NXP/Chassis3V2/Chassis3V2.dsc.inc| 10 +++
From: Pankaj Bansal
LX2160A Reference Design Board (RDB) is a high-performance development
platform that supports the QorIQ LX2160A Layerscape Architecture SOCs.
Signed-off-by: Pankaj Bansal
---
Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.dec
| 23 +++
From: Pankaj Bansal
edk2 recommends to use MDEPKG_NDEBUG for release builds and to use
DISABLE_NEW_DEPRECATED_INTERFACES for all new platforms.
Therefore, enable these flags for NXP platforms as well
Signed-off-by: Pankaj Bansal
---
Silicon/NXP/NxpQoriqLs.dsc.inc | 7 ++-
1 file changed,
From: Pankaj Bansal
Monotonic counter module from EmbeddedPkg doesn't treat the
high 32 bit as non volatile, which is needed as per spec.
Therefore, use Monotonic counter module from MdeModulePkg
Signed-off-by: Pankaj Bansal
---
Silicon/NXP/NxpQoriqLs.dsc.inc | 2 +-
From: Pankaj Bansal
LX2160A is QorIq Layerscape multicore communications processor with
sixteen Arm Cortex-A72 cores.
This SOC is based on Layerscape Chassis v3.2.
Signed-off-by: Pankaj Bansal
---
Silicon/NXP/LX2160A/LX2160A.dec | 13
Silicon/NXP/LX2160A/LX2160A.dsc.inc
From: Pankaj Bansal
There are two implementations of Metronome protocol.
EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
MdeModulePkg/Universal/Metronome/Metronome.inf
Although nowhere it has been specified, which one to use, but we are
going by the general practice of preferring MdeModulePkg/MdePkg
From: Pankaj Bansal
In NXP SOCs the UART clock is derived from System clock after PLL
multiplication. Therefore, add the PL011UartClockLib implementation
for NXP platforms.
Signed-off-by: Pankaj Bansal
---
Silicon/NXP/Library/PL011UartClockLib/PL011UartClockLib.inf | 24
From: Pankaj Bansal
LX2160A Reference Design Board (RDB) is a high-performance development
platform that supports the QorIQ LX2160A Layerscape Architecture SOCs.
This Platform is based on Layerscape Chassis3V2.
The code structure is same as Chassis2 and LS1043A SOC and LS1043ARDB
platform.
From: Pankaj Bansal
Add VarStore Fd. This Fd is used to store non volatile variables in
flash.
Signed-off-by: Pankaj Bansal
---
Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.fdf | 1 +
Platform/NXP/LX2160aRdbPkg/VarStore.fdf.inc | 91
2 files changed, 92 insertions(+)
diff
I am not sure what the community wants to do with it. It was created
for the CI build so it is tailored to the needs of the CI build but I
have no problem with updates.
I agree with your feedback and see no reason either of those would be a
problem for the CI use case.
Although not
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2726
When FSP switching stack and calling bootloader functions,
the function parameter in stack may not be accessible easily.
We can store the function parameter pointer to FspGlobalData
and retrieve it after stack switched.
Also need to add
> -Original Message-
> From: Ard Biesheuvel
> Sent: Thursday, May 14, 2020 6:12 AM
> To: devel@edk2.groups.io
> Cc: samer.el-haj-mahm...@arm.com; Ard Biesheuvel
> ; Jin, Eric ; G Edhaya
> Chandran ; Andrew Fish ;
> Laszlo Ersek ; Leif Lindholm ;
> Kinney, Michael D
> Subject: [PATCH
I'm wondering if using BaseTools/Edk2ToolsBuild.py will become the
official/standard way users are expected to build BaseTools? If so,
there are a few problems that I'd like to see fixed, which I'll see if I
can find some time to work on.
For example: on Linux, running it without arguments
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2054
V8 Add DEBUG_VERBOSE message and unit test
V7 addressed review comments (only documentation changes).
Current implementation of SafeString does not let one parse untrusted
data with its interfaces as they ASSERT on failing runtime checks
Use the safe string function StrCpyS() in BaseLib to test the
SAFE_STRING_CONSTRAINT_CHECK() macro.
Cc: Andrew Fish
Cc: Ard Biesheuvel
Cc: Bret Barkelew
Cc: Brian J. Johnson
Cc: Chasel Chiu
Cc: Jordan Justen
Cc: Laszlo Ersek
Cc: Leif Lindholm
Cc: Liming Gao
Cc: Marvin H?user
Cc: Michael
From: Vitaly Cheptsov
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2054
Runtime checks returned via status return code should not work as
assertions to permit parsing not trusted data with SafeString
interfaces. Replace ASSERT() with a DEBUG_VERBOSE message.
Cc: Andrew Fish
Cc: Ard
Hi,
For this patch, I'd like to catch this stable tag.
Thanks,
Shenglei
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Zhang, Shenglei
> Sent: Wednesday, May 20, 2020 11:09 AM
> To: devel@edk2.groups.io
> Cc: Maciej Rabeda ; Fu, Siyuan
> ;
The condition, NET_HEADSPACE(&(Nbuf->BlockOp[Index])) < Len, is
meaningless if Index = 0. So checking 'Index != 0' should be
performed first in the if statement.
Cc: Maciej Rabeda
Cc: Siyuan Fu
Cc: Jiaxin Wu
Signed-off-by: Shenglei Zhang
---
v2: Update 'Index > 0' to 'Index != 0'
Use the safe string function StrCpyS() in BaseLib to test the
SAFE_STRING_CONSTRAINT_CHECK() macro.
Cc: Andrew Fish
Cc: Ard Biesheuvel
Cc: Bret Barkelew
Cc: Brian J. Johnson
Cc: Chasel Chiu
Cc: Jordan Justen
Cc: Laszlo Ersek
Cc: Leif Lindholm
Cc: Liming Gao
Cc: Marvin H?user
Cc: Michael
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2054
V8 Add DEBUG_VERBOSE message and unit test
V7 addressed review comments (only documentation changes).
Current implementation of SafeString does not let one parse untrusted
data with its interfaces as they ASSERT on failing runtime checks
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2054
Runtime checks returned via status return code should not work as
assertions to permit parsing not trusted data with SafeString
interfaces. Replace ASSERT() with a DEBUG_VERBOSE message.
Cc: Andrew Fish
Cc: Ard Biesheuvel
Cc: Bret
Hi Vitaly,
I think this should work. ASSERT() removed. DEBUG_VERBOSE message added.
#define SAFE_STRING_CONSTRAINT_CHECK(Expression, Status) \
do { \
if (!(Expression)) { \
DEBUG ((DEBUG_VERBOSE, "SAFE_STRING_CONSTRAINT_CHECK(%a) failed. Return
%r\n", #Expression, Status)); \
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#59909): https://edk2.groups.io/g/devel/message/59909
Mute This Topic: https://groups.io/mt/74341614/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:PUBLISH
CALSCALE:GREGORIAN
BEGIN:VEVENT
UID:mlda.1580078539586725120.r...@groups.io
DTSTAMP:20200520T023210Z
ORGANIZER;CN=Brian Richardson:mailto:brian.richard...@intel.com
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:PUBLISH
CALSCALE:GREGORIAN
BEGIN:VEVENT
UID:mlda.1580078539586725120.r...@groups.io
DTSTAMP:20200520T023040Z
ORGANIZER;CN=Brian Richardson:mailto:brian.richard...@intel.com
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:PUBLISH
CALSCALE:GREGORIAN
BEGIN:VEVENT
UID:mlda.1580078539586725120.r...@groups.io
DTSTAMP:20200520T022952Z
ORGANIZER;CN=Brian Richardson:mailto:brian.richard...@intel.com
*Reminder:* TianoCore Bug Triage - APAC / NAMO
*When:* Wednesday, 20 May 2020, 9:30am to 10:30am, (GMT+08:00) Asia/Chongqing
*Where:* https://bluejeans.com/889357567?src=join_info
View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=805106 )
*Organizer:* Brian Richardson
Sorry for reply later.
I understood and the series is good to me.
Reviewed-by: Guomin Jiang
> -Original Message-
> From: Oleksiy Yakovlev
> Sent: Thursday, May 14, 2020 10:17 PM
> To: Jiang, Guomin ; devel@edk2.groups.io
> Cc: Feng, Bob C ; Gao, Liming
> ; Kinney, Michael D ;
> Felix
Reviewed-by: Guomin Jiang
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Nate
> DeSimone
> Sent: Tuesday, May 19, 2020 2:21 PM
> To: devel@edk2.groups.io
> Cc: Marcin Wojtas ; Leif Lindholm
> Subject: [edk2-devel] [edk2-platforms] [PATCH] SpiTool: Fix spelling errors
>
For the patch series.
Reviewed-by: Ashley DeSimone
-Original Message-
From: Bjorge, Erik C
Sent: Tuesday, May 19, 2020 2:51 PM
To: devel@edk2.groups.io
Cc: Desimone, Ashley E ; Desimone, Nathaniel L
; Pandya, Puja ; Bret
Barkelew ; Agyeman, Prince
Subject: [edk2-staging/EdkRepo]
Add comment inline
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Nate
> DeSimone
> Sent: Tuesday, May 19, 2020 2:18 PM
> To: devel@edk2.groups.io
> Cc: Sun, Zailiang ; Qian, Yi
> Subject: [edk2-devel] [edk2-platforms] [PATCH 2/5] Vlv2TbltDevicePkg: Fix
> spelling errors
Reviewed-by: Chasel Chiu
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of
> Kathappan Esakkithevar
> Sent: Tuesday, May 12, 2020 11:45 PM
> To: devel@edk2.groups.io
> Cc: Chaganty, Rangasai V ; Chiu, Chasel
> ; Desimone, Nathaniel L
> ; Kethi Reddy, Deepika
>
> Subject:
Hi,
You may be interested with the pre-built Raspberry Pi 3 UEFI images
from: https://github.com/pftf/RPi3
At the very least it should tell you if your serial setup works or not,
as, if properly configured (115200 bauds), you should get some serial
output regardless of whether you are using
Laszlo,
First let me be clear, there is no desire or intent in any of these
conversations/discussions for anyone to feel so distraught to give up
this project, let alone someone so active and involved as yourself.
The basis for my perspective goes back to the conversations we had
numerous
Hi!
I'm trying to get EDK2 working on a Raspberry Pi 3 B+ and am running
into some issues.
Setup:
First, I created a Guix package for EDK2, to make it nice and
reproducible. It can be found on
https://git.sr.ht/~raingloom/guix-packages in bootloaders.scm.
It took a few tries to compile it,
On 5/19/20 4:51 PM, Tom Lendacky wrote:
> Register reviewers for the SEV-related files in OvmfPkg.
>
> Cc: Andrew Fish
> Cc: Laszlo Ersek
> Cc: Leif Lindholm
> Cc: Michael D Kinney
> Cc: Brijesh Singh
> Signed-off-by: Tom Lendacky
Acked-By: Brijesh Singh
> ---
> Maintainers.txt | 10
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Allocate memory for the GHCB pages and the per-CPU variable pages during
SEV initialization for use during Pei and Dxe phases. The GHCB page(s)
must be shared pages, so clear the encryption mask from the current page
table entries. Upon
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
The SEV support will clear the C-bit from non-RAM areas. The early GDT
lives in a non-RAM area, so when an exception occurs (like a #VC) the GDT
will be read as un-encrypted even though it is encrypted. This will result
in a failure to be
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Protect the memory used by an SEV-ES guest when S3 is supported. This
includes the page table used to break down the 2MB page that contains
the GHCB so that it can be marked un-encrypted, as well as the GHCB
area.
Regarding the lifecycle of
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Create an SEV-ES workarea PCD. This PCD will be used for BSP communication
during SEC and for AP startup during PEI and DXE phases, the latter is the
reason for creating it in the UefiCpuPkg.
Cc: Eric Dong
Cc: Ray Ni
Cc: Laszlo Ersek
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
An SEV-ES guest will generate a #VC exception when it encounters a
non-automatic exit (NAE) event. It is expected that the #VC exception
handler will communicate with the hypervisor using the GHCB to handle
the NAE event.
NAE events can
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
During BSP startup, the reset vector code will issue a CPUID instruction
while in 32-bit mode. When running as an SEV-ES guest, this will trigger
a #VC exception.
Add exception handling support to the early reset vector code to catch
these
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Protect the SEV-ES work area memory used by an SEV-ES guest.
Regarding the lifecycle of the SEV-ES memory area:
PcdSevEsWorkArea
(a) when and how it is initialized after first boot of the VM
If SEV-ES is enabled, the SEV-ES area is
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
The flash detection routine will attempt to determine how the flash
device behaves (e.g. ROM, RAM, Flash). But when SEV-ES is enabled and
the flash device behaves as a ROM device (meaning it is marked read-only
by the hypervisor), this check
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Currently, the OVMF code relies on the hypervisor to enable the cache
support on the processor in order to improve the boot speed. However,
with SEV-ES, the hypervisor is not allowed to change the CR0 register
to enable caching.
Update the
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Reserve a fixed area of memory for SEV-ES use and set a fixed PCD,
PcdSevEsWorkAreaBase, to this value.
This area will be used by SEV-ES support for two purposes:
1. Communicating the SEV-ES status during BSP boot to SEC:
Using a
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a VMMCALL intercept generates a #VC exception. VMGEXIT must
be used to allow the hypervisor to handle this intercept.
Cc: Jordan Justen
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Signed-off-by: Tom Lendacky
---
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
GHCB pages must be mapped as shared pages, so modify the process of
creating identity mapped pagetable entries so that GHCB entries are
created without the encryption bit set. The GHCB range consists of
two pages per CPU, the first being the
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a INVD intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.
Cc: Jordan Justen
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Signed-off-by: Tom Lendacky
---
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a IOIO_PROT intercept generates a #VC exception. VMGEXIT
must be used to allow the hypervisor to handle this intercept.
Add support to construct the required GHCB values to support a IOIO_PROT
NAE event. Parse the instruction
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a MSR_PROT intercept generates a #VC exception. VMGEXIT must
be used to allow the hypervisor to handle this intercept.
Add support to construct the required GHCB values to support an MSR_PROT
NAE event. Parse the instruction
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Various CpuExceptionHandlerLib libraries will updated to use the new
VmgExitLib library. To prevent any build breakage, update the OvmfPkg
DSC files that use a form of the CpuExceptionHandlerLib library to
include the VmgExitLib library.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a RDPMC intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.
Cc: Jordan Justen
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Signed-off-by: Tom Lendacky
---
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a MONITOR/MONITORX intercept generates a #VC exception.
VMGEXIT must be used to allow the hypervisor to handle this intercept.
Cc: Jordan Justen
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Signed-off-by: Tom Lendacky
---
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a RDTSC intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.
Cc: Jordan Justen
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Signed-off-by: Tom Lendacky
---
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
VMGEXIT is a new instruction used for Hypervisor/Guest communication when
running as an SEV-ES guest. A VMGEXIT will cause an automatic exit (AE)
to occur, resulting in a #VMEXIT with an exit code value of 0x403.
Provide the necessary
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a NPF intercept for an NPT entry with a reserved bit set
generates a #VC exception. This condition is assumed to be an MMIO access.
VMGEXIT must be used to allow the hypervisor to handle this intercept.
Add support to
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
A new dynamic UefiCpuPkg PCD is needed to support SEV-ES under OVMF:
- PcdSevEsIsEnabled: BOOLEAN value used to indicate if SEV-ES is enabled
Cc: Eric Dong
Cc: Ray Ni
Cc: Laszlo Ersek
Signed-off-by: Tom Lendacky
---
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
The GHCB is used by an SEV-ES guest for communicating between the guest
and the hypervisor. Create the GHCB definition as defined by the GHCB
protocol definition.
Cc: Michael D Kinney
Cc: Liming Gao
Signed-off-by: Tom Lendacky
---
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a CPUID instruction requires the current value of the XCR0
register. In order to retrieve that value, the XGETBV instruction needs
to be executed.
Provide the necessary support to execute the XGETBV instruction.
Cc: Michael D
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Create a function that can be used to determine if the VM is running
as an SEV-ES guest.
Cc: Jordan Justen
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Reviewed-by: Laszlo Ersek
Signed-off-by: Tom Lendacky
---
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Add support to the #VC exception handler to handle string IO. This
requires expanding the IO instruction parsing to recognize string based
IO instructions as well as preparing an un-encrypted buffer to be used
to transfer (either to or from
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a DR7 read or write intercept generates a #VC exception.
The #VC handler must provide special support to the guest for this. On
a DR7 write, the #VC handler must cache the value and issue a VMGEXIT
to notify the hypervisor of
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Add base support to handle #VC exceptions. Update the common exception
handlers to invoke the VmgExitHandleVc () function of the VmgExitLib
library when a #VC is encountered. A non-zero return code will propagate
to the targeted exception
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
For SEV-ES, the GHCB page address is stored in the GHCB MSR register
(0xc0010130). Define the register and the format used for register
during GHCB protocol negotiation.
Cc: Michael D Kinney
Cc: Liming Gao
Signed-off-by: Tom Lendacky
---
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a RDTSCP intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.
Cc: Jordan Justen
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Signed-off-by: Tom Lendacky
---
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a MWAIT/MWAITX intercept generates a #VC exception.
VMGEXIT must be used to allow the hypervisor to handle this intercept.
Cc: Jordan Justen
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Signed-off-by: Tom Lendacky
---
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a WBINVD intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.
Cc: Jordan Justen
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Signed-off-by: Tom Lendacky
---
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a CPUID intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.
Add support to construct the required GHCB values to support a CPUID NAE
event. Additionally, CPUID
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
To support handling #VC exceptions and issuing VMGEXIT instructions,
create a library with functions that can be used to perform these
#VC/VMGEXIT related operations. This includes functions for:
- Handling #VC exceptions
- Preparing for
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Various CpuExceptionHandlerLib libraries will updated to use the new
VmgExitLib library. To prevent any build breakage, update the
UefiPayloadPkg DSC files that use a form of the CpuExceptionHandlerLib
library to include the VmgExitLib
This patch series provides support for running EDK2/OVMF under SEV-ES.
Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
SEV support to protect the guest register state from the hypervisor. See
"AMD64 Architecture Programmer's Manual Volume 2: System Programming",
section
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
A GHCB page is needed during the Sec phase, so this new page must be
created. Since the #VC exception handler routines assume that a per-CPU
variable area is immediately after the GHCB, this per-CPU variable area
must also be created. Since
The base VmgExitLib library provides a default limited interface. As it
does not provide full support, create an OVMF version of this library to
begin the process of providing full support of SEV-ES within OVMF.
SEV-ES support is only provided for X64 builds, so only OvmfPkgX64.dsc is
updated to
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
When SEV-ES is enabled, then SEV is also enabled. Add support to the SEV
initialization function to also check for SEV-ES being enabled, and if
enabled, set the SEV-ES enabled PCD (PcdSevEsIsEnabled).
Cc: Jordan Justen
Cc: Laszlo Ersek
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Two new dynamic MdeModulePkg PCDs are needed to support SEV-ES under OVMF:
- PcdGhcbBase: UINT64 value that is the base address of the GHCB
allocation.
- PcdGhcbSize: UINT64 value that is the size, in
Enabling the ability to select the submodules to be initialized and maintained
via the manifest file.
project_utils.submodule contains the submodule logic and also functions as a
command line script.
Includes code review feedback.
Signed-off-by: Erik Bjorge
Cc: Ashley E Desimone
Cc: Nate
Replaced use of maintain_submodules to use new common code. This allows
for selective submodule initialization via the manifest file.
Cc: Ashley E Desimone
Cc: Nate DeSimone
Cc: Puja Pandya
Cc: Bret Barkelew
Cc: Prince Agyeman
Cc: Erik Bjorge
Signed-off-by: Erik Bjorge
---
Adds selective submodule support functions and command line scripting
support. The existing support will be ported over to use this
functionality.
Signed-off-by: Erik Bjorge
Cc: Ashley E Desimone
Cc: Nate DeSimone
Cc: Puja Pandya
Cc: Bret Barkelew
Cc: Prince Agyeman
Cc: Erik Bjorge
---
Agreed. :)
- Bret
From: devel@edk2.groups.io on behalf of Nate DeSimone
via groups.io
Sent: Tuesday, May 19, 2020 2:35:37 PM
To: devel@edk2.groups.io ; ler...@redhat.com
; Bret Barkelew ;
spbro...@outlook.com ; r...@edk2.groups.io
; Kinney, Michael D ; Leif
Hi Laszlo,
I think both myself and Bret may have gotten a little chippy. I think both of
us are passionate about our work and that shows in the debate. I am happy to
forgive Bret and hopefully he is with me as well.
Thanks,
Nate
On 5/19/20, 2:22 PM, "devel@edk2.groups.io on behalf of Laszlo
On 05/19/20 21:34, Bret Barkelew wrote:
> Nate, I believe you missed Sean’s point.
>
> Each one of those packages should have been a separate PR.
And then we get to wrangle inter-PR dependencies.
Even if github.com supports that, it's a heavy-weight tool, and should
be used sparingly. Patches
I’ll pour another cup of tea to that.
- Bret
From: Desimone, Nathaniel L
Sent: Tuesday, May 19, 2020 2:02:49 PM
To: r...@edk2.groups.io ; Bret Barkelew
; devel@edk2.groups.io ;
spbro...@outlook.com ; ler...@redhat.com
; Kinney, Michael D
Subject: [EXTERNAL]
Hi Bret,
To be completely fair, I think we are splitting hairs on details here. I think
both of us are in 90% agreement, and we are both passionate enough about our
work to argue that last 10% to the grave.
I totally understand the desire for bisectability by the way. TianoCore is a
huge
(+Leif, +Andrew)
Sean,
On 05/19/20 18:54, Sean Brogan wrote:
> Nate/Laszlo,
>
> Regarding a squash merge workflow. I agree it can be abused and we all
> have seen terrible examples. But a patch series that contains 500+ file
> changes isn't really much better. Just because it is broken into
I will honor Mike Kinney’s efforts with my vote of confidence.
I think we’re headed in the right direction, even with some of the things that
I disagree with.
In my history with TianoCore, I have learned to not be so quick to say “this is
fucking stupid”. Every time I’ve done that, I’ve later
Hi Bret,
I believe you missed my point. I don’t want my patch series to be merged piece
by piece; I want it merged all at once, in the order that I specified.
I tend to agree with Laszlo that you are choosing not to learn how to use Git
properly. Commit early, commit often, perfect later,
Reviewed-by: G Edhaya Chandran < edhaya.chand...@arm.com >
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#59844): https://edk2.groups.io/g/devel/message/59844
Mute This Topic: https://groups.io/mt/74193175/21656
Group Owner:
Nate, I believe you missed Sean’s point.
Each one of those packages should have been a separate PR.
Ergo, no information would have been lost in the squash.
Also, it’s not so much that we *can’t* learn. It’s that we choose not to.
Around here, it’s a mark of prestige to not open doors with your
Hi Sean,
My recent spelling fix patch series is a good example of why this is a bad idea
actually:
https://edk2.groups.io/g/devel/message/59779
https://edk2.groups.io/g/devel/message/59780
https://edk2.groups.io/g/devel/message/59781
https://edk2.groups.io/g/devel/message/59782
> On 5/19/20 01:40, Laszlo Ersek wrote:
>
> That seems strange. I have one rule per edk2-* list, for moving such incoming
> email into the appropriate list folder. That's all.
>
> While I read all the subject lines (skim all the threads) on edk2-devel,
> generally, if you share reviewer or
Good feedback.
- I will move _display_git_output to edkrepo.common.common_repo_functions and
remove leading '_' from the name
- I will clean up the comments in init_submodules
- I will rename init_submodules to maintain_submodules to remove the confusion
I will submit a new patch set today.
Hi Liming,
I did a GitHub Pull Request to verify the change and it passed all checks. The
patch also passes the checks done by BaseTools\Scripts\PatchCheck.py.
Ideally, we would like to have this patch merged in edk2 stable tag 202005.
Regards,
Sami Mujawar
From: Gao, Liming
Sent: 18 May
1 - 100 of 160 matches
Mail list logo
