Gerd Hoffmann [Wed, 15 Dec 2021 11:39:19 +0000 (12:39 +0100)]
OvmfPkg: create Tcg12ConfigPei.inf
Split Tcg2ConfigPei.inf into two variants: Tcg12ConfigPei.inf with
TPM 1.2 support included and Tcg2ConfigPei.inf supporting TPM 2.0 only.
This allows x86 builds to choose whenever TPM 1.2 support should be
included or not by picking the one or the other inf file.
Switch x86 builds to Tcg12ConfigPei.inf, so they continue to
have TPM 1.2 support.
No functional change.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Gerd Hoffmann [Wed, 15 Dec 2021 11:39:17 +0000 (12:39 +0100)]
OvmfPkg: move tcg configuration to dsc and fdf include files
With this in place the tpm configuration is not duplicated for each of
our four ovmf config variants (ia32, ia32x64, x64, amdsev) and it is
easier to keep them all in sync when updating the tpm configuration.
No functional change.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Current FvLib will hit parse issue when encountering LARGE file, then
ignore latter ffs/section, thus causing required drivers not being
dispatched. Therefore, need to add support for EFI_FFS_FILE_HEADER2
and EFI_COMMON_SECTION_HEADER2 in FvLib to fix this issue.
Pierre Gondois [Thu, 9 Dec 2021 09:32:51 +0000 (10:32 +0100)]
DynamicTablesPkg: Add DynamicPlatRepo library
The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.
A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).
This patch add the inf file of the module and the main module
functionnalities and update the dsc file of the package.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.
A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).
This patch add the TokenMapper files, allowing to retrieve a CmObj
from a token/CmObjId couple.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:32:49 +0000 (10:32 +0100)]
DynamicTablesPkg: DynamicPlatRepo: Add TokenFixer
The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.
A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).
This patch add the TokenFixer files, allowing to update the
self-token some CmObj have.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.
A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).
This patch add the TokenGenerator files.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:32:47 +0000 (10:32 +0100)]
DynamicTablesPkg: Definition for DynamicPlatRepoLib interface
The DynamicPlatRepoLib library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.
A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to
retrieve dynamic CmObjs among all CmObj (static CmObj for instance).
This patch defines the library interface of the DynamicPlatRepo.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:32:08 +0000 (10:32 +0100)]
DynamicTablesPkg: Handle 16550_WITH_GAS id
Handle the EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_16550_WITH_GAS
id when generating an AML description of a serial port. The same
_HID/_CID as the EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_FULL_16550
are generated.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:32:07 +0000 (10:32 +0100)]
DynamicTablesPkg: Add FdtHwInfoParser library
Hardware information parser is an optional module defined
by the Dynamic Tables Framework. It can either parse an
XML, a Device Tree or a Json file containing the platform
hardware information to populate the platform information
repository.
FdtHwInfoParser library is an instance of a HwInfoParser
that parses a Device Tree and populates the Configuration
Manager Platform information repository.
FdtHwInfoParser library is aimed at providing a solution
for generating ACPI tables for Guest Partitions launched
by virtual machine managers (VMMs). One such use case is
Kvmtool where the Device Tree for the Guest is passed on
to the firmware by Kvmtool. The Configuration Manager for
Kvmtool firmware shall invoke the FdtHwInfoParser to parse
the Device Tree to populate the hardware information in
the Platform Info Repository. The Kvmtool Configuration
Manager can the process this information to generate the
required ACPI tables for the Guest VM.
This approach also scales well if the number of CPUs or
if the hardware configuration of the Guest partition is
varied.
FdtHwInfoParser thereby introduces 'Dynamic Tables for
Virtual Machines'.
Ref:https://bugzilla.tianocore.org/show_bug.cgi?id=3741 Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
On platforms that implement PCIe, the PCIe configuration space
information must be described to a standards-based operating
system in the Memory mapped configuration space base address
Description (MCFG) table.
The PCIe information is described in the platform Device Tree,
the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/pci/
host-generic-pci.yaml
The FdtHwInfoParser implements a PCI configuration space Parser
that parses the platform Device Tree to create
CM_ARM_PCI_CONFIG_SPACE_INFO objects which are encapsulated in a
Configuration Manager descriptor object and added to the platform
information repository.
The platform Configuration Manager can then utilise this
information when generating the MCFG table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The GIC Dispatcher is the top-level component that is responsible
for invoking the respective parsers for GICC, GICD, GIC MSI Frame,
GIC ITS and the GICR.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The GIC Redistributor (GICR) structure is part of the Multiple
APIC Description Table (MADT) that enables the discovery of
GIC Redistributor base addresses by providing the Physical Base
Address of a page range containing the GIC Redistributors. More
than one GICR Structure may be presented in the MADT. The GICR
structures should only be used when describing GIC version 3 or
higher.
The GIC Redistributor information is described in the platform
Device Tree, the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic-v3.yaml
The FdtHwInfoParser implements a GIC Redistributor Parser that
parses the platform Device Tree to create CM_ARM_GIC_REDIST_INFO
objects which are encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.
The platform Configuration Manager can then utilise this
information when generating the MADT table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:32:03 +0000 (10:32 +0100)]
DynamicTablesPkg: FdtHwInfoParser: Add ITS parser
Arm GIC v3/v4 optionally includes support for GIC Interrupt
Translation Service (ITS). The GIC ITS Structure is part of
the Multiple APIC Description Table (MADT) that describes
the GIC Interrupt Translation service to the OS.
The GIC Interrupt Translation Service information is described
in the platform Device Tree, the bindings for which can be
found at:
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic-v3.yaml
The FdtHwInfoParser implements a GIC ITS Parser that parses the
platform Device Tree to create CM_ARM_GIC_ITS_INFO objects which
are encapsulated in a Configuration Manager descriptor object and
added to the platform information repository.
The platform Configuration Manager can then utilise this information
when generating the MADT table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Arm GIC version 2 systems that support Message Signalled Interrupts
implement GICv2m MSI frame(s). Each GICv2m MSI frame consists of a
4k page which includes registers to generate message signalled
interrupts to an associated GIC distributor. The frame also includes
registers to discover the set of distributor lines which may be
signalled by MSIs from that frame. A system may have multiple MSI
frames, and separate frames may be defined for secure and non-secure
access.
A MSI Frame structure is part of the Multiple APIC Description Table
(MADT) and must only be used to describe non-secure MSI frames.
The MSI Frame information is described in the platform Device Tree,
the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic.yaml
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic-v3.yaml
The FdtHwInfoParser implements a MSI Frame Parser that parses
the platform Device Tree to create CM_ARM_GIC_MSI_FRAME_INFO
objects which are encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.
The platform Configuration Manager can then utilise this
information when generating the MADT table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
On ARM-based systems the Generic Interrupt Controller (GIC)
manages interrupts on the system. Each interrupt is identified
in the GIC by an interrupt identifier (INTID). ACPI GSIVs map
one to one to GIC INTIDs for peripheral interrupts, whether
shared (SPI) or private (PPI). The GIC distributor provides
the routing configuration for the interrupts.
The GIC Distributor (GICD) structure is part of the Multiple
APIC Description Table (MADT) that describes the GIC
distributor to the OS. The MADT table is a mandatory table
required for booting a standards-based operating system.
The GIC Distributor information is described in the platform
Device Tree, the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic.yaml
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic-v3.yaml
The FdtHwInfoParser implements a GIC Distributor Parser that
parses the platform Device Tree to create CM_ARM_GICD_INFO
object which is encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.
The platform Configuration Manager can then utilise this
information when generating the MADT table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The GIC CPU Interface (GICC) structure is part of the Multiple
APIC Description Table (MADT) that describes the interrupt model
for the platform. The MADT table is a mandatory table required
for booting a standards-based operating system.
Arm requires the GIC interrupt model, in which the logical
processors are required to have a Processor Device object in
the DSDT, and must convey each processor's GIC information to
the OS using the GICC structure.
The CPU and GIC information is described in the platform Device
Tree, the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/arm/cpus.yaml
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic.yaml
- linux/Documentation/devicetree/bindings/interrupt-controller/
arm,gic-v3.yaml
The FdtHwInfoParser implements a GIC CPU Interface Parser that
parses the platform Device Tree to create CM_ARM_GICC_INFO
objects which are encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.
The platform Configuration Manager can then utilise this
information when generating the MADT and the SSDT CPU
information tables.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:31:59 +0000 (10:31 +0100)]
DynamicTablesPkg: FdtHwInfoParser: Add Serial port parser
The Microsoft Debug Port Table 2 (DBG2), the Serial Port Console
Redirector (SPCR) table are mandatory tables required for booting
a standards-based operating system. The DBG2 table is used by the
OS debugger while the SPCR table is used to configure the serial
terminal. Additionally, the serial ports available on a platform
for generic use also need to be described in DSDT/SSDT for an OS
to be able to use the serial ports.
The Arm Base System Architecture 1.0 specification a lists of
supported serial port hardware for Arm Platforms. This list
includes the following serial port UARTs:
- SBSA/Generic UART
- a fully 16550 compatible UART.
Along, with these the PL011 UART is the most commonly used serial
port hardware on Arm platforms.
The serial port hardware information is described in the platform
Device Tree, the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/serial/serial.yaml
- linux/Documentation/devicetree/bindings/serial/8250.txt
- linux/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
- linux/Documentation/devicetree/bindings/serial/pl011.yaml
The FdtHwInfoParser implements a Serial Port Parser that parses
the platform Device Tree to create CM_ARM_SERIAL_PORT_INFO objects
with the following IDs:
- EArmObjSerialConsolePortInfo (for use by SPCR)
- EArmObjSerialDebugPortInfo (for use by DBG2)
- EArmObjSerialPortInfo (for use as generic Serial Ports)
The Serial Port for use by SPCR is selected by parsing the Device
Tree for the '/chosen' node with the 'stdout-path' property. The
next Serial Port is selected for use as the Debug Serial Port and
the remaining serial ports are used as generic serial ports.
The CM_ARM_SERIAL_PORT_INFO objects are encapsulated in Configuration
Manager descriptor objects with the respective IDs and are added to
the platform information repository.
The platform Configuration Manager can then utilise this information
when generating the DBG2, SPCR and the SSDT serial port tables.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The Generic Timer Description Table (GTDT) is a mandatory table
required for booting a standards-based operating system. It
provides an OSPM with information about a system's Generic Timer
configuration. The Generic Timer (GT) is a standard timer interface
implemented on ARM processor-based systems. The GTDT provides OSPM
with information about a system's GT interrupt configurations, for
both per-processor timers, and platform (memory-mapped) timers.
The Generic Timer information is described in the platform Device
Tree. The Device Tree bindings for the Generic timers can be found
at:
- linux/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
The FdtHwInfoParser implements a Generic Timer Parser that parses
the platform Device Tree to create a CM_ARM_GENERIC_TIMER_INFO
object. The CM_ARM_GENERIC_TIMER_INFO object is encapsulated in a
Configuration Manager descriptor object and added to the platform
information repository.
The platform Configuration Manager can then utilise this information
when generating the GTDT table.
Note: The Generic Timer Parser currently does not support parsing
of memory-mapped platform timers.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The Fixed ACPI Description Table (FADT) is a mandatory table
required for booting a standards-based operating system. The
FADT table has an 'ARM Boot Architecture Flags' field that is
used by an OS at boot time to determine the code path during
boot. This field is used to specify if the platform complies
with the PSCI specification. It is also used to describe the
conduit (SMC/HVC) to be used for PSCI.
The PSCI compliance information for a platform is described
in the platform Device Tree, the bindings for which can be
found at:
- linux/Documentation/devicetree/bindings/arm/psci.yaml
The FdtHwInfoParser implements a Boot Arch Parser that parses
the platform Device Tree to create a CM_ARM_BOOT_ARCH_INFO
object. The CM_ARM_BOOT_ARCH_INFO object is encapsulated in
a Configuration Manager descriptor object and added to the
platform information repository.
The platform Configuration Manager can then utilise this
information when generating the FADT table.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:31:55 +0000 (10:31 +0100)]
DynamicTablesPkg: FdtHwInfoParser: CM Object descriptor helper
FdtHwInfoParserLib is an instance of the HwInfoParser. The
FdtHwInfoParser parses a platform Device Tree and populates
the Platform Information repository with Configuration
Manager objects that describe the platform hardware.
These Configuration Manager objects are encapsulated in
Configuration Manager Object Descriptors.
Therefore, add helper functions to create and free the
Configuration Manager Object descriptors.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:31:54 +0000 (10:31 +0100)]
DynamicTablesPkg: Definition for HwInfoParser interface
Hardware information parser is an optional module defined
by the Dynamic Tables Framework. It can either parse an
XML, a Device Tree or a Json file containing the platform
hardware information to populate the platform information
repository.
The Configuration Manager can then utilise this information
to generate ACPI tables for the platform.
Therefore, define an interface for the HwInfoParser library
class.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Co-authored-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Rebecca Cran [Mon, 13 Dec 2021 18:30:56 +0000 (11:30 -0700)]
ArmPkg: Update SMC calls to use the new ArmCallSmc0/1/2/3 functions
New SMC helper functions have been added to reduce the amount of
template code. Update ArmSmcPsciResetSystemLib and
Smbios/ProcessorSubClassDxe to use them.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Rebecca Cran [Sun, 9 May 2021 19:26:47 +0000 (13:26 -0600)]
EmulatorPkg: Update lldbefi.py to work with current lldb which uses python3
The version of lldb shipping with macOS Big Sur is lldb-1205.0.27.3, and
it uses python3. Update lldbefi.py to work with it, including removing
the unused 'commands' import and fixing the print statements.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Andrew Fish <afish@apple.com>
Gerd Hoffmann [Wed, 8 Dec 2021 07:01:45 +0000 (08:01 +0100)]
OvmfPkg/PlatformPei: prefer etc/e820 for memory detection
Prefer the e820 map provided via qemu firmware config interface
for memory detection. Use rtc cmos only as fallback, which should
be rarely needed these days as qemu supports etc/e820 since 2013.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3593 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Add a bool parameter to ScanOrAdd64BitE820Ram to explicitly specify
whenever ScanOrAdd64BitE820Ram should add HOBs for high memory (above
4G) or scan only.
Also add a lowmem parameter so ScanOrAdd64BitE820Ram
can report the memory size below 4G.
This allows a more flexible usage of ScanOrAdd64BitE820Ram,
a followup patch will use it for all memory detection.
No functional change.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3593 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Pierre Gondois [Thu, 9 Dec 2021 09:25:05 +0000 (10:25 +0100)]
DynamicTablesPkg: Fix multiple objects parsing
When a CmObjDesc contains multiple objects, only the first one is
parsed as the buffer doesn't progress. Fix this.
Also check that the whole buffer has been parsed with an asset.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:25:04 +0000 (10:25 +0100)]
DynamicTablesPkg: SSDT Pci express generator
This generator allows to generate a SSDT table describing
a Pci express Bus. It uses the following CmObj:
- EArmObjCmRef
- EArmObjPciConfigSpaceInfo
- EArmObjPciAddressMapInfo
- EArmObjPciInterruptMapInfo
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:25:03 +0000 (10:25 +0100)]
DynamicTablesPkg: Add Pci related objects
Introduce the following CmObj in the ArmNameSpaceObjects:
- CM_ARM_PCI_ADDRESS_MAP_INFO
- CM_ARM_PCI_INTERRUPT_MAP_INFO
These objects allow to describe address range mapping
of Pci busses and interrupt mapping of Pci devices.
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:25:02 +0000 (10:25 +0100)]
DynamicTablesPkg: Add AmlAttachNode()
This function allows to add a node as the last node of a parent node
in an AML tree. For instance,
ASL code corresponding to NewNode:
Name (_UID, 0)
ASL code corresponding to ParentNode:
Device (PCI0) {
Name(_HID, EISAID("PNP0A08"))
}
"AmlAttachNode (ParentNode, NewNode)" will result in:
ASL code:
Device (PCI0) {
Name(_HID, EISAID("PNP0A08"))
Name (_UID, 0)
}
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:25:01 +0000 (10:25 +0100)]
DynamicTablesPkg: AML Code generation to add _PRT entries
_PRT entries can describe interrupt mapping for Pci devices. The
object is described in ACPI 6.4 s6.2.13 "_PRT (PCI Routing Table)".
Add AmlCodeGenPrtEntry() helper function to add _PRT entries
to an existing _PRT object.
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:25:00 +0000 (10:25 +0100)]
DynamicTablesPkg: AML Code generation to create a named ResourceTemplate()
Add AmlCodeGenNameResourceTemplate() to generate code for a
ResourceTemplate().
AmlCodeGenNameResourceTemplate ("REST", ParentNode, NewObjectNode) is
equivalent of the following ASL code:
Name(REST, ResourceTemplate () {})
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:24:59 +0000 (10:24 +0100)]
DynamicTablesPkg: AML Code generation to create a named Package()
Add AmlCodeGenNamePackage() to generate code for a Package().
AmlCodeGenNamePackage ("PACK", ParentNode, NewObjectNode) is
equivalent of the following ASL code:
Name(PACK, Package () {})
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Thu, 9 Dec 2021 09:24:58 +0000 (10:24 +0100)]
DynamicTablesPkg: AML Code generation for memory ranges
Add helper functions to generate AML Resource Data describing memory
ranges. Memory ranges can be one, double or four words long. They
can be of 'normal', IO or bus number memory type. The following
APIs are exposed:
- AmlCodeGenRdDWordIo ()
- AmlCodeGenRdDWordMemory ()
- AmlCodeGenRdWordBusNumber ()
- AmlCodeGenRdQWordMemory ()
To: Sami Mujawar <sami.mujawar@arm.com>
To: Alexei Fedorov <Alexei.Fedorov@arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Gerd Hoffmann [Mon, 13 Dec 2021 08:16:57 +0000 (09:16 +0100)]
OvmfPkg/Microvm/virtio: add virtio-mmio support
Add virtio-mmio support (VirtioMmioDeviceLib and VirtioFdtDxe).
With this patch added and a new enough qemu version (6.2+) edk2
will detect virtio-mmio devices, so it is possible to boot from
storage (virtio-blk, virtio-scsi) or network (virtio-net).
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3689 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Gerd Hoffmann [Mon, 13 Dec 2021 08:16:56 +0000 (09:16 +0100)]
OvmfPkg/Microvm/fdt: add empty fdt
FdtClient is unhappy without a device tree, so add an empty fdt
which we can use in case etc/fdt is not present in fw_cfg.
On ARM machines a device tree is mandatory for hardware detection,
that's why FdtClient fails hard.
On microvm the device tree is only used to detect virtio-mmio devices
(this patch series) and the pcie host (future series). So edk2 can
continue with limited functionality in case no device tree is present:
no storage, no network, but serial console and direct kernel boot
works.
qemu release 6.2 & newer will provide a device tree for microvm.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3689 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Gerd Hoffmann [Mon, 13 Dec 2021 08:14:42 +0000 (09:14 +0100)]
OvmfPkg/PlatformCI: dummy grub.efi for AmdSev
Building grub.efi for AmdSev is difficult because it depends on patches
not yet merged to upstream grub. So shortcut the grub build by simply
creating an empty grub.efi file. That allows to at least build-test the
AmdSev variant.
Gerd Hoffmann [Mon, 13 Dec 2021 08:14:37 +0000 (09:14 +0100)]
OvmfPkg/PlatformCI: factor out PlatformBuildLib.py
Move SettingsManager and PlatformBuilder classes to PlatformBuildLib.py
file, keep only CommonPlatform class in PlatformBuild.py. Allows
reusing these classes for other builds. Pure code motion, no functional
change.
Gerd Hoffmann [Mon, 13 Dec 2021 07:30:48 +0000 (08:30 +0100)]
OvmfPkg/Bhyve: add MemEncryptSevLib
Fixes build failure:
build.py...
/home/kraxel/projects/edk2/OvmfPkg/Bhyve/BhyveX64.dsc(...): error 1001: Module type [SEC] is not supported by library instance [/home/kraxel/projects/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf]
consumed by [/home/kraxel/projects/edk2/OvmfPkg/Sec/SecMain.inf]
/home/kraxel/projects/edk2/OvmfPkg/PlatformPei/AmdSev.c: In function ‘AmdSevInitialize’:
/home/kraxel/projects/edk2/MdePkg/Include/Library/PcdLib.h:511:38: error: implicit declaration of function ‘_PCD_SET_MODE_64_S_PcdConfidentialComputingGuestAttr’ [-Werror=implicit-function-declaration]
511 | #define PcdSet64S(TokenName, Value) _PCD_SET_MODE_64_S_##TokenName ((Value))
| ^~~~~~~~~~~~~~~~~~~
/home/kraxel/projects/edk2/OvmfPkg/PlatformPei/AmdSev.c:410:17: note: in expansion of macro ‘PcdSet64S’
410 | PcdStatus = PcdSet64S (PcdConfidentialComputingGuestAttr, CCAttrAmdSevSnp);
| ^~~~~~~~~
cc1: all warnings being treated as errors
DxeTpmMeasurementLib supports TPM based measurement in DXE phase.
After CcMeasurementProtocol is introduced, CC based measurement needs
to be supported in DxeTpmMeasurementLib as well.
A platform should have only one RTS/RTR. Only one of (virtual)TPM1.2,
(virtual)TPM2.0 and CC MR exists. Then only one TCG_SERVICE_PROTOCOL,
TCG2_PROTOCOL, CC_MEASUREMENT_PROTOCOL is exposed.
In this library when do measurement only one of above 3 protocols will
be called.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
DxeTpm2MeasureBootLib supports TPM2 based measure boot. After
CcMeasurementProtocol is introduced, CC based measure boot needs to
be supported in DxeTpm2MeasureBootLib as well.
There are 2 major changes in this commit.
1. A platform should have only one RTS/RTR. Only one of (virtual)TPM1.2,
(virtual)TPM2.0 and CC MR exists. Then only one TCG_SERVICE_PROTOCOL,
TCG2_PROTOCOL, CC_MEASUREMENT_PROTOCOL is exposed. In this library when
do measure boot only one of TCG2_PROTOCOL / CC_MEASUREMENT_PROTOCOL
will be called. MEASURE_BOOT_PROTOCOLS is defined to store the instances
of TCG2 protocol and CC Measurement protocol.
2. CcEvent is similar to Tcg2Event except the MrIndex and PcrIndex.
So in the code Tcg2Event will be first created and intialized. If
CcMeasurementProtocol is called to do the measure boot, then CcEvent
points to Tcg2Event and the MrIndex is adjusted.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
CC guest is a Confidential Computing guest. If CC Guest firmware
supports measurement and an event is created, CC Guest firmware
is designed to report the event log with the same data structure
in TCG-Platform-Firmware-Profile specification with
EFI_TCG2_EVENT_LOG_FORMAT_TCG_2 format.
The CC Guest firmware supports measurement. It is designed to
produce EFI_CC_MEASUREMENT_PROTOCOL with new GUID
EFI_CC_MEASUREMENT_PROTOCOL_GUID to report event log and provides
hash capability.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ken Lu <ken.lu@intel.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
lixianglai [Thu, 9 Dec 2021 11:28:01 +0000 (19:28 +0800)]
OvmfPkg-EmuVariableFvbRuntimeDxe: Support Access To Memory Above 4G
In FvbInitialize Function,
PcdFlashNvStorageVariableBase64 PcdFlashNvStorageFtwWorkingBase
PcdFlashNvStorageFtwSpareBase will not exceed 0x100000000,
Due to truncation and variable type limitations.
That leads to the NV variable cannot be saved to the memory above 4G.
Modify as follows:
1.Remove the forced type conversion of UINT32.
2.Use UINT64 type variables.
Signed-off-by: xianglai li <lixianglai@loongson.cn> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Jason Andryuk [Fri, 10 Dec 2021 19:05:52 +0000 (03:05 +0800)]
OvmfPkg/OvmfXen: Fix Xen build
commit 202fb22be6e9 "OvmfPkg/SecMain: validate the memory used for
decompressing Fv" broke building OvmfXen with:
edk2/OvmfPkg/OvmfXen.dsc(...): error 1001: Module type [SEC] is not
supported by library instancer
[edk2/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf]
consumed by [edk2/OvmfPkg/Sec/SecMain.inf]
The above commit added a reference to MemEncryptSevLib into SecMain.inf,
but OvmfXen.dsc doesn't have a MemEncryptSevLib entry for SEC. Add one
like OvmfPkgX64.dsc has.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
ACPI 6.3A deprecated PPTT ID (type 2) structure which was subsequently
removed in ACPI 6.4. Therefore remove support for generating PPTT ID
structures.
Mantis ID for removing PPTT type 2 structure:
2072 (https://mantis.uefi.org/mantis/view.php?id=2072)
Signed-off-by: Chris Jones <christopher.jones@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Update the Acpiview PPTT parser with the Cache ID field and relevant
validations as defined in tables 5.140 and 5.141 of the ACPI 6.4
specification.
Signed-off-by: Chris Jones <christopher.jones@arm.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Update the Acpiview PPTT parser to use Acpi64.h. As part of the changes,
remove support for parsing PPTT type 2 ID structure.
Mantis ID for removing PPTT type 2 structure:
2072 (https://mantis.uefi.org/mantis/view.php?id=2072)
Signed-off-by: Chris Jones <christopher.jones@arm.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Chris Jones <christopher.jones@arm.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add Cache ID valid/invalid defines to Acpi64.h which were not initially
added when the CacheIdValid field was added to
EFI_ACPI_6_4_PPTT_STRUCTURE_CACHE_FLAGS.
Signed-off-by: Chris Jones <christopher.jones@arm.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
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: Michael Roth <michael.roth@amd.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ray Ni <ray.ni@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
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: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
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: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Brijesh Singh [Thu, 9 Dec 2021 03:27:57 +0000 (11:27 +0800)]
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 Mmio address.
Add a new parameter in SetMemoryEncDec() to tell whether the specified
address is Mmio. If its Mmio then skip the page state change in the RMP
table.
Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
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 memory encryption attribute change.
Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Michael Roth [Thu, 9 Dec 2021 03:27:55 +0000 (11:27 +0800)]
UefiCpuPkg/MpInitLib: use BSP to do extended topology check
During AP bringup, just after switching to long mode, APs will do some
cpuid calls to verify that the extended topology leaf (0xB) is available
so they can fetch their x2 APIC IDs from it. In the case of SEV-ES,
these cpuid instructions must be handled by direct use of the GHCB MSR
protocol to fetch the values from the hypervisor, since a #VC handler
is not yet available due to the AP's stack not being set up yet.
For SEV-SNP, rather than relying on the GHCB MSR protocol, it is
expected that these values would be obtained from the SEV-SNP CPUID
table instead. The actual x2 APIC ID (and 8-bit APIC IDs) would still
be fetched from hypervisor using the GHCB MSR protocol however, so
introducing support for the SEV-SNP CPUID table in that part of the AP
bring-up code would only be to handle the checks/validation of the
extended topology leaf.
Rather than introducing all the added complexity needed to handle these
checks via the CPUID table, instead let the BSP do the check in advance,
since it can make use of the #VC handler to avoid the need to scan the
SNP CPUID table directly, and add a flag in ExchangeInfo to communicate
the result of this check to APs.
Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ray Ni <ray.ni@intel.com> Suggested-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
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: Michael Roth <michael.roth@amd.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ray Ni <ray.ni@Intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
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 MpInitLib will use the
PcdGhcbHypervisorFeatures to determine which method to use for creating
the AP.
Query the hypervisor feature and set the PCD accordingly.
Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Version 2 of the GHCB specification added a new VMGEXIT that the guest
could use for querying the hypervisor features. One of the immediate
users for it will be an AP creation code. When SEV-SNP is enabled, the
guest can use the newly added AP_CREATE VMGEXIT to create the APs.
The MpInitLib will check the hypervisor feature, and if AP_CREATE is
available, it will use it.
See GHCB spec version 2 for more details on the VMGEXIT.
Cc: Michael Roth <michael.roth@amd.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ray Ni <ray.ni@Intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Previous commit introduced a generic confidential computing PCD that can
determine whether AMD SEV-ES is enabled. Update the MpInitLib to drop the
PcdSevEsIsEnabled in favor of PcdConfidentialComputingAttr.
Cc: Michael Roth <michael.roth@amd.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ray Ni <ray.ni@intel.com> Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
The MpInitLib uses the ConfidentialComputingAttr PCD to determine whether
AMD SEV is active so that it can use the VMGEXITs defined in the GHCB
specification to create APs.
Cc: Michael Roth <michael.roth@amd.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
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) Validate before access
On-demand
=========
If memory is not validated before access, it will cause a #VC
exception with the page-not-validated error code. The VC exception
handler can perform the validation steps.
The pages that have been validated will need to be tracked to avoid
the double validation scenarios. The range of memory that has not
been validated will need to be communicated to the OS through the
recently introduced unaccepted memory type
https://github.com/microsoft/mu_basecore/pull/66, so that OS can
validate those ranges before using them.
Validate before access
======================
Since the PEI phase detects all the available system RAM, use the
MemEncryptSevSnpValidateSystemRam() function to pre-validate the
system RAM in the PEI phase.
For now, choose option 2 due to the dependency and the complexity
of the on-demand validation.
Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
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 active, the memory must be pre-validated before the access.
Add support to pre-validate the memory range from SnpSecPreValidatedStart
to SnpSecPreValidatedEnd. This should be sufficent to enter into the PEI
phase.
Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
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 the memory region that needs
to be validated. If hardware encounters a page table walk failure (due
to page-not-present) then it raises #GP.
The initial page table built in SEC phase address up to 4GB. Add an
internal function to extend the page table to cover > 4GB. The function
builds 1GB entries in the page table for access > 4GB. This will provide
the support to call PVALIDATE instruction for the virtual address >
4GB in PEI phase.
Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
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 pre-validate the detected system RAM.
While validating the system RAM in PEI phase, we must skip previously
validated system RAM to avoid the double validation.
Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Virtual Machine Privilege Level (VMPL) feature in the SEV-SNP
architecture allows a guest VM to divide its address space into four
levels. The level can be used to provide the hardware isolated
abstraction layers with a VM. The VMPL0 is the highest privilege, and
VMPL3 is the least privilege. Certain operations must be done by the
VMPL0 software, such as:
* Validate or invalidate memory range (PVALIDATE instruction)
* Allocate VMSA page (RMPADJUST instruction when VMSA=1)
The initial SEV-SNP support assumes that the guest is running on VMPL0.
Let's add function in the MemEncryptSevLib that can be used for checking
whether guest is booted under the VMPL0.
Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
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 table via the Page State Change VMGEXIT
defined in the GHCB specification section 2.5.1 and 4.1.6. Inside each RMP
entry is a Validated flag; this flag is automatically cleared to 0 by the
CPU hardware when a new RMP entry is created for a guest. Each VM page
can be either validated or invalidated, as indicated by the Validated
flag in the RMP entry. Memory access to a private page that is not
validated generates a #VC. A VM can use the PVALIDATE instruction to
validate the private page before using it.
During the guest creation, the boot ROM memory is pre-validated by the
AMD-SEV firmware. The MemEncryptSevSnpValidateSystemRam() can be called
during the SEC and PEI phase to validate the detected system RAM.
One of the fields in the Page State Change NAE is the RMP page size. The
page size input parameter indicates that either a 4KB or 2MB page should
be used while adding the RMP entry. During the validation, when possible,
the MemEncryptSevSnpValidateSystemRam() will use the 2MB entry. A
hypervisor backing the memory may choose to use the different page size
in the RMP entry. In those cases, the PVALIDATE instruction should return
SIZEMISMATCH. If a SIZEMISMATCH is detected, then validate all 512-pages
constituting a 2MB region.
Upon completion, the PVALIDATE instruction sets the rFLAGS.CF to 0 if
instruction changed the RMP entry and to 1 if the instruction did not
change the RMP entry. The rFlags.CF will be 1 only when a memory region
is already validated. We should not double validate a memory
as it could lead to a security compromise. If double validation is
detected, terminate the boot.
Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
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 by the MemEncryptSevLib to
clear the memory encryption mask from the page table. If the
MemEncryptSevLib is extended to include VmgExitLib then depedency
chain will look like this:
OvmfPkg/AmdSevDxe/AmdSevDxe.inf
-----> MemEncryptSevLib class
-----> "OvmfPkg/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf" instance
-----> VmgExitLib class
-----> "OvmfPkg/VmgExitLib" instance
-----> LocalApicLib class
-----> "UefiCpuPkg/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf" instance
-----> TimerLib class
-----> "OvmfPkg/AcpiTimerLib/DxeAcpiTimerLib.inf" instance
-----> PciLib class
-----> "OvmfPkg/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf" instance
-----> PciExpressLib class
-----> "MdePkg/BasePciExpressLib/BasePciExpressLib.inf" instance
The LocalApicLib provides a constructor that gets called before the
AmdSevDxe can clear the memory encryption mask from the MMIO regions.
When running under the Q35 machine type, the call chain looks like this:
The PciExpressRead32 () reads the MMIO region. The MMIO regions are not
yet mapped un-encrypted, so the check introduced in the commit 85b8eac59b8c5bd9c7eb9afdb64357ce1aa2e803 raises a #GP.
The AmdSevDxe driver does not require the access to the extended PCI
config space. Accessing a normal PCI config space, via IO port should be
sufficent. Use the module-scope override to make the AmdSevDxe use the
BasePciLib instead of BasePciExpressLib so that PciRead32 () uses the
IO ports instead of the extended config space.
Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Michael Roth [Thu, 9 Dec 2021 03:27:39 +0000 (11:27 +0800)]
OvmfPkg/VmgExitLib: use SEV-SNP-validated CPUID values
SEV-SNP firmware allows a special guest page to be populated with
guest CPUID values so that they can be validated against supported
host features before being loaded into encrypted guest memory to be
used instead of hypervisor-provided values [1].
Add handling for this in the CPUID #VC handler and use it whenever
SEV-SNP is enabled. To do so, existing CPUID handling via VmgExit is
moved to a helper, GetCpuidHyp(), and a new helper that uses the CPUID
page to do the lookup, GetCpuidFw(), is used instead when SNP is
enabled. For cases where SNP CPUID lookups still rely on fetching
specific CPUID fields from hypervisor, GetCpuidHyp() is used there as
well.
[1]: SEV SNP Firmware ABI Specification, Rev. 0.8, 8.13.2.6
Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Michael Roth [Thu, 9 Dec 2021 03:27:36 +0000 (11:27 +0800)]
OvmfPkg/ResetVector: use SEV-SNP-validated CPUID values
CPUID instructions are issued during early boot to do things like probe
for SEV support. Currently these are handled by a minimal #VC handler
that uses the MSR-based GHCB protocol to fetch the CPUID values from
the hypervisor. When SEV-SNP is enabled, use the firmware-validated
CPUID values from the CPUID page instead [1].
[1]: SEV SNP Firmware ABI Specification, Rev. 0.8, 8.13.2.6
Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
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 C-bit).
Note: If the processor is in non-PAE mode, then all the memory accesses
are considered private.
2) Add the memory range as private in the RMP table. This can be performed
using the Page State Change VMGEXIT defined in the GHCB specification.
3) Use the PVALIDATE instruction to set the Validated Bit in the RMP table.
During the guest creation time, the VMM encrypts the OVMF_CODE.fd using
the SEV-SNP firmware provided LAUNCH_UPDATE_DATA command. In addition to
encrypting the content, the command also validates the memory region.
This allows us to execute the code without going through the validation
sequence.
During execution, the reset vector need to access some data pages
(such as page tables, SevESWorkarea, Sec stack). The data pages are
accessed as private memory. The data pages are not part of the
OVMF_CODE.fd, so they were not validated during the guest creation.
There are two approaches we can take to validate the data pages before
the access:
a) Enhance the OVMF reset vector code to validate the pages as described
above (go through step 2 - 3).
OR
b) Validate the pages during the guest creation time. The SEV firmware
provides a command which can be used by the VMM to validate the pages
without affecting the measurement of the launch.
Approach #b seems much simpler; it does not require any changes to the
OVMF reset vector code.
Update the OVMF metadata with the list of regions that must be
pre-validated by the VMM before the boot.
Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
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 potentially lead to a security issue. The SEV-SNP
firmware provides a feature to filter the CPUID results through the PSP.
The filtered CPUID values are saved on a special page for the guest to
consume. Reserve a page in MEMFD that will contain the results of
filtered CPUID values.
Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
projects / mirror_edk2.git / log