audk/OvmfPkg/ResetVector/ResetVector.inf

66 lines
2.2 KiB
INI
Raw Normal View History

## @file
# Reset Vector
#
# Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
##
[Defines]
INF_VERSION = 0x00010005
BASE_NAME = ResetVector
FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09
MODULE_TYPE = SEC
VERSION_STRING = 1.1
#
# The following information is for reference only and not required by the build tools.
#
# VALID_ARCHITECTURES = IA32 X64
#
[Sources]
ResetVector.nasmb
[Packages]
OvmfPkg/OvmfPkg.dec
MdePkg/MdePkg.dec
OvmfPkg: Create a GHCB page for use during Sec phase 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 GHCB must be marked as an un-encrypted, or shared, page, an additional pagetable page is required to break down the 2MB region where the GHCB page lives into 4K pagetable entries. Create a new entry in the OVMF memory layout for the new page table page and for the SEC GHCB and per-CPU variable pages. After breaking down the 2MB page, update the GHCB page table entry to remove the encryption mask. The GHCB page will be used by the SEC #VC exception handler. The #VC exception handler will fill in the necessary fields of the GHCB and exit to the hypervisor using the VMGEXIT instruction. The hypervisor then accesses the GHCB in order to perform the requested function. Four new fixed PCDs are needed to support the SEC GHCB page: - PcdOvmfSecGhcbBase UINT32 value that is the base address of the GHCB used during the SEC phase. - PcdOvmfSecGhcbSize UINT32 value that is the size, in bytes, of the GHCB area used during the SEC phase. - PcdOvmfSecGhcbPageTableBase UINT32 value that is address of a page table page used to break down the 2MB page into 512 4K pages. - PcdOvmfSecGhcbPageTableSize UINT32 value that is the size, in bytes, of the page table page. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
2020-08-12 22:21:40 +02:00
MdeModulePkg/MdeModulePkg.dec
UefiCpuPkg/UefiCpuPkg.dec
[BuildOptions]
*_*_IA32_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
*_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
[Pcd]
gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase
OvmfPkg: Create a GHCB page for use during Sec phase 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 GHCB must be marked as an un-encrypted, or shared, page, an additional pagetable page is required to break down the 2MB region where the GHCB page lives into 4K pagetable entries. Create a new entry in the OVMF memory layout for the new page table page and for the SEC GHCB and per-CPU variable pages. After breaking down the 2MB page, update the GHCB page table entry to remove the encryption mask. The GHCB page will be used by the SEC #VC exception handler. The #VC exception handler will fill in the necessary fields of the GHCB and exit to the hypervisor using the VMGEXIT instruction. The hypervisor then accesses the GHCB in order to perform the requested function. Four new fixed PCDs are needed to support the SEC GHCB page: - PcdOvmfSecGhcbBase UINT32 value that is the base address of the GHCB used during the SEC phase. - PcdOvmfSecGhcbSize UINT32 value that is the size, in bytes, of the GHCB area used during the SEC phase. - PcdOvmfSecGhcbPageTableBase UINT32 value that is address of a page table page used to break down the 2MB page into 512 4K pages. - PcdOvmfSecGhcbPageTableSize UINT32 value that is the size, in bytes, of the page table page. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
2020-08-12 22:21:40 +02:00
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase
OvmfPkg: Add IntelTdxMetadata.asm RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 In TDX when host VMM creates a new guest TD, some initial set of TD-private pages are added using the TDH.MEM.PAGE.ADD function. These pages typically contain Virtual BIOS code and data along with some clear pages for stacks and heap. In the meanwhile, some configuration data need be measured by host VMM. Tdx Metadata is designed for this purpose to indicate host VMM how to do the above tasks. More detailed information of Metadata is in [TDVF] Section 11. Tdx Metadata describes the information about the image for VMM use. For example, the base address and length of the TdHob, Bfv, Cfv, etc. The offset of the Metadata is stored in a GUID-ed structure which is appended in the GUID-ed chain from a fixed GPA (0xffffffd0). In this commit there are 2 new definitions of BFV & CFV. Tdx Virtual Firmware (TDVF) includes one Firmware Volume (FV) known as the Boot Firmware Volume (BFV). The FV format is defined in the UEFI Platform Initialization (PI) spec. BFV includes all TDVF components required during boot. TDVF also include a configuration firmware volume (CFV) that is separated from the BFV. The reason is because the CFV is measured in RTMR, while the BFV is measured in MRTD. In practice BFV is the code part of Ovmf image (OVMF_CODE.fd). CFV is the vars part of Ovmf image (OVMF_VARS.fd). Since AMD SEV has already defined some SEV specific memory region in MEMFD. TDX re-uses some of the memory regions defined by SEV. - MailBox : PcdOvmfSecGhcbBackupBase|PcdOvmfSecGhcbBackupSize - TdHob : PcdOvmfSecGhcbBase|PcdOvmfSecGhcbSize [TDVF] https://software.intel.com/content/dam/develop/external/us/en/ documents/tdx-virtual-firmware-design-guide-rev-1.pdf Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2021-09-28 04:47:29 +02:00
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupSize
gUefiOvmfPkgTokenSpaceGuid.PcdCfvBase
gUefiOvmfPkgTokenSpaceGuid.PcdCfvRawDataOffset
gUefiOvmfPkgTokenSpaceGuid.PcdCfvRawDataSize
gUefiOvmfPkgTokenSpaceGuid.PcdBfvBase
gUefiOvmfPkgTokenSpaceGuid.PcdBfvRawDataOffset
gUefiOvmfPkgTokenSpaceGuid.PcdBfvRawDataSize
[FixedPcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidSize
gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase
gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize
gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase
gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsSize