Commit Graph

74 Commits

Author SHA1 Message Date
Tan, Ming 7fe5022f28 OvmfPkg/OvmfPkg*.dsc: Change PCDs type about status code
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2786

Since the type of PcdStatusCodeUseSerial and PcdStatusCodeUseMemory
in MdeModulePkg.dec are changed, so change them from
PcdsFeatureFlag to PcdsFixedAtBuild in dsc files.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Ming Tan <ming.tan@intel.com>
2020-06-18 05:39:09 +00:00
Roman Bolshakov bcf181a33b OvmfPkg: Skip initrd command on Xcode toolchain
OVMF booting stops with the assert if built with Xcode on macOS:

  Loading driver at 0x0001FAB8000 EntryPoint=0x0001FABF249 LinuxInitrdDynamicShellCommand.efi
  InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 1F218398
  ProtectUefiImageCommon - 0x1F218140
    - 0x000000001FAB8000 - 0x0000000000008A60

  ASSERT_EFI_ERROR (Status = Unsupported)
  ASSERT LinuxInitrdDynamicShellCommand.c(378): !EFI_ERROR (Status)

The assert comes from InitializeHiiPackage() after an attempt to
retrieve HII package list from ImageHandle.

Xcode still doesn't support HII resource section and
LinuxInitrdDynamicShellCommand depends on it. Likewise 277a3958d9
("OvmfPkg: Don't include TftpDynamicCommand in XCODE5 tool chain"),
disable initrd command if built with Xcode toolchain

Fixes: ec41733cfd ("OvmfPkg: add the 'initrd' dynamic shell command")
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Message-Id: <20200514134820.62047-1-r.bolshakov@yadro.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-05-14 17:11:07 +00:00
Lendacky, Thomas b304d2807b OvmfPkg: Use toolchain appropriate CpuExceptionHandlerLib
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2340

During the SEC phase, use the XCODE5 CpuExceptionHandlerLib library in
place of the standard library when building with the XCODE5 toolchain.
The SEC XCODE5 version of the library performs binary patching and should
only be used when building with the XCODE5 toolchain.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <0cfdd51deb6d39e08380645f2022b9b76e29f66f.1588856809.git.thomas.lendacky@amd.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
2020-05-11 19:25:33 +00:00
Anthony PERARD 3a402f9611 OvmfPkg/OvmfXen: Introduce DEBUG_ON_HYPERVISOR_CONSOLE build flag
Introduce DEBUG_ON_HYPERVISOR_CONSOLE build flag to enable logging
debug output to the Xen console.

This will work with both Xen HVM guest and Xen PVH guest whereas the
default PlatformDebugLibIoPort works only in HVM when QEMU is present.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20200423095358.2518197-6-anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-04-28 21:12:01 +00:00
Anthony PERARD d5d60a4331 OvmfPkg/OvmfXen: Remove DEBUG_ON_SERIAL_PORT
Remove support for DEBUG_ON_SERIAL_PORT because OvmfXen can't be build
with it due to a circular dependency:
  DebugLib        : BaseDebugLibSerialPort ->
  SerialPortLib   : XenConsoleSerialPortLib ->
  XenHypercallLib : XenHypercallLib ->
  DebugLib

Also, if that dependency is fixed, I think it would be harder to find
which console the debug is sent to when running an HVM guest. The xen
console isn't the serial console used by default. Furthermore,
XenHypercallLib isn't initialised early enough, so we would loose
debug output from the SEC phase and early PEI phase.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200423095358.2518197-2-anthony.perard@citrix.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-04-28 21:12:01 +00:00
Laszlo Ersek 93f6df5f3b OvmfPkg/ResetSystemLib: introduce the DxeResetSystemLib instance
The BaseResetSystemLib instance is not suitable for OS runtime, because
its ResetShutdown() implementation calls PciRead16 (OVMF_HOSTBRIDGE_DID).
On q35, this boils down to a memory-mapped config space access -- but we
never ask the OS to map MMCONFIG for runtime.

There are at least three alternatives to approach this:

(1) Investigate "MdePkg/Library/DxeRuntimePciExpressLib", which offers
    some kind of runtime mapping for MMCONFIG.

(2) Consume PciCf8Lib directly, rather than PciLib, in ResetSystemLib.
    Then we'll read OVMF_HOSTBRIDGE_DID from the config space with IO port
    accesses on q35 too, not just on i440fx. IO ports don't depend on page
    tables.

(3) In the lib constructor, cache "mAcpiPmBaseAddress" based on
    "PcdOvmfHostBridgePciDevId" (which is set by PlatformPei). Then the
    host bridge type will be known at runtime without PCI config space
    accesses.

This patch follows approach (3), in order to mirror AcpiTimerLib.

Notes:

* This patch is best viewed with "git show --find-copies-harder -C43".

* PCDs are not usable in the DXE_CORE, as the PCD PPI is gone, and the PCD
  protocol is not available yet. (The DXE_CORE does consume ResetSystemLib
  in practice, when OVMF is built with -D SOURCE_DEBUG_ENABLE.)

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200417153751.7110-7-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
[lersek@redhat.com: move third Note (with repro info) to BZ comment]
2020-04-22 19:42:32 +00:00
Laszlo Ersek d70cdcf0b5 OvmfPkg/ResetSystemLib: rename to BaseResetSystemLib
In preparation for introducing DxeResetSystemLib, rename the current
(only) ResetSystemLib instance to BaseResetSystemLib.

In the DSC files, keep the ResetSystemLib resolution in the same
[LibraryClasses] section, but move it near the TimerLib resolution, as the
differences between the ResetSystemLib instances will mostly follow those
seen under OvmfPkg/Library/AcpiTimerLib.

(While OvmfXen does not use "OvmfPkg/Library/AcpiTimerLib", perform the
same movement there too, for keeping future DSC diffing simple.)

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200417153751.7110-6-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
2020-04-22 19:42:32 +00:00
Ard Biesheuvel af4ee6953c OvmfPkg: remove handling of properties table
The UEFI properties table and the associated memory protection feature was
severely broken from the start, and has been deprecated for a while. Let's
drop all references to it from OVMF so we can safely remove it from the
DXE core as well.

Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2633
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
2020-04-07 08:15:46 +00:00
Vitaly Cheptsov 4fb393aaa8 OvmfPkg: Fix SMM/RT driver section alignment for XCODE5/CLANGPDB
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2642

This patch resolves the problem of using memory protection
attributes when OVMF firmware is compiled with XCODE5 and CLANGPDB.

Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Marvin Häuser <mhaeuser@outlook.de>
Signed-off-by: Vitaly Cheptsov <vit9696@protonmail.com>
Message-Id: <20200329132158.35259-2-cheptsov@ispras.ru>
Acked-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: fix whitespace issues reported by git-am]
[lersek@redhat.com: replace "CC:" tags with "Cc:" ones for PatchCheck.py]
2020-04-01 14:12:09 +00:00
Ard Biesheuvel 8068188431 OvmfPkg/OvmfXen: fix build by providing QemuLoadImageLib resolution
Commit 859b55443a ("OvmfPkg/PlatformBootManagerLib: switch to
QemuLoadImageLib") replaced a dependency on LoadLinuxLib with one on
QemuLoadImageLib in the PlatformBootManagerLib implementation that is
shared between all OVMF builds, without taking into account that even
the Xen targeted builds incorporate this code, which is only used to
load kernels passed via the QEMU command line.

Since this is dead code on Xen, we can satisfy the dependency using
the generic version of QemuLoadImageLib, which does not rely on
LoadLinuxLib, which we can therefore drop from OvmfXen.dsc.

Fixes: 859b55443a
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-03-06 07:21:43 +00:00
Ard Biesheuvel ec41733cfd OvmfPkg: add the 'initrd' dynamic shell command
Add the 'initrd' dynamic shell command to the build so we can load
Linux initrds straight from the shell using the new generic protocol,
which does not rely on initrd= being passed on the command line.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-03-04 09:26:45 +00:00
Laszlo Ersek 50f911d25d OvmfPkg: introduce PcdCsmEnable feature flag
In the DXE phase and later, it is possible for a module to dynamically
determine whether a CSM is enabled. An example can be seen in commit
855743f717 ("OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no
CSM", 2016-05-25).

SEC and PEI phase modules cannot check the Legacy BIOS Protocol however.
For their sake, introduce a new feature PCD that simply reflects the
CSM_ENABLE build flag.

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200129214412.2361-11-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2020-02-05 12:59:32 +00:00
Laszlo Ersek 4ef78a39f0 OvmfPkg/OvmfXen.dsc: remove PcdCpu* dynamic defaults
PcdCpuMaxLogicalProcessorNumber and PcdCpuApInitTimeOutInMicroSeconds are
only referenced in "OvmfPkg/PlatformPei/PlatformPei.inf", and OvmfXen does
not include that module. Remove the unnecessary dynamic PCD defaults from
"OvmfXen.dsc".

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@arm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <20191022221554.14963-2-lersek@redhat.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
2020-01-29 17:28:22 +00:00
Peter Jones 46bb812007 OvmfPkg: Make SOURCE_DEBUG_ENABLE actually need to be set to TRUE
Currently some tests check the value of SOURCE_DEBUG_ENABLE, and some
tests check if it's defined or not.  Additionally, in UefiPayloadPkg as
well as some other trees, we define it as FALSE in the .dsc file.

This patch changes all of the Ovmf platforms to explicitly define it as
FALSE by default, and changes all of the checks to test if the value is
TRUE.

Signed-off-by: Peter Jones <pjones@redhat.com>
Message-Id: <20190920184507.909884-1-pjones@redhat.com>
[lersek@redhat.com: drop Contributed-under line, per TianoCore BZ#1373]
[lersek@redhat.com: replace "!= TRUE" with more idiomatic "== FALSE"]
Cc: Andrew Fish <afish@apple.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Peter Jones <pjones@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
2019-10-22 20:22:04 +02:00
Anthony PERARD 1237517b21 OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg
A Xen PVH guest doesn't have a RTC that OVMF would expect, so
PcatRealTimeClockRuntimeDxe fails to initialize and prevent the
firmware from finish to boot. To prevent that, we will use
XenRealTimeClockLib which simply always return the same time.
This will work on both Xen PVH and HVM guests.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-36-anthony.perard@citrix.com>
2019-08-21 18:03:50 +02:00
Anthony PERARD 833cd3e0c0 OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables
XenIoPvhDxe use XenIoMmioLib to reserve some space to be use by the
Grant Tables.

The call is only done if it is necessary, we simply detect if the
guest is PVH, as in this case there is currently no PCI bus, and no
PCI Xen platform device which would start the XenIoPciDxe and allocate
the space for the Grant Tables.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-34-anthony.perard@citrix.com>
2019-08-21 18:03:50 +02:00
Anthony PERARD 05480e2fd4 OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
On a Xen PVH guest, none of the existing serial or console interface
works, so we add a new one, based on XenConsoleSerialPortLib, and
implemented via SerialDxe.

That is a simple console implementation that can work on both PVH
guest and HVM guests, even if it is rarely going to be used on HVM.

Have PlatformBootManagerLib look for the new console, when running as a
Xen guest.

Since we use VENDOR_UART_DEVICE_PATH, fix its description and coding
style.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-32-anthony.perard@citrix.com>
2019-08-21 18:03:49 +02:00
Anthony PERARD d668c8bc55 OvmfPkg/OvmfXen: Introduce XenTimerDxe
"OvmfPkg/8254TimerDxe" is replaced with a Xen-specific
EFI_TIMER_ARCH_PROTOCOL implementation. Also remove
8259InterruptControllerDxe as it is not used anymore.

This Timer uses the local APIC timer as time source as it can work on
both a Xen PVH guest and an HVM one.

Based on the "OvmfPkg/8254TimerDxe" implementation.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-31-anthony.perard@citrix.com>
2019-08-21 18:03:49 +02:00
Anthony PERARD c8395d27f7 OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency
PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib
implementation. It will also be used by XenTimerDxe. Override
PcdFSBClock to match Xen vLAPIC timer frequency.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-30-anthony.perard@citrix.com>
2019-08-21 18:03:49 +02:00
Anthony PERARD f496443eb3 OvmfPkg/Library/XenPlatformLib: New library
The purpose of XenPlatformLib is to regroup the few functions that are
used in several places to detect if Xen is detected, and to get the
XenInfo HOB.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-14-anthony.perard@citrix.com>
2019-08-21 18:03:49 +02:00
Anthony PERARD 31d4e8b029 OvmfPkg/OvmfXen: use a TimerLib instance that depends only on the CPU
The ACPI Timer isn't present in a PVH guest, but local APIC works on
both PVH and HVM.

Note that the use of SecPeiDxeTimerLibCpu might be an issue with a
driver of type DXE_RUNTIME_DRIVER. I've attempted to find out which of
the DXE_RUNTIME_DRIVER uses the TimerLib at runtime. I've done that by
replacing the TimerLib evaluation in
[LibraryClasses.common.DXE_RUNTIME_DRIVER] by a different one and
checking every module that uses it (with the --report-file=report
build option).

ResetSystemRuntimeDxe is calling the TimerLib API at runtime to do the
operation "EfiResetCold", so this may never complete if the OS have
disabled the Local APIC Timer.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-10-anthony.perard@citrix.com>
2019-08-21 18:03:49 +02:00
Anthony PERARD 3b96221f77 OvmfPkg: Introduce XenPlatformPei
Introduce XenPlatformPei, a copy of OvmfPkg/PlatformPei without some
of QEMU specific initialization, Xen does not support QemuFwCfg.

This new module will be adjusted to accommodate Xen PVH.

fw_cfg dependents that have been removed, which are dynamically skipped
when running PlatformPei on Xen:
- GetFirstNonAddress(): controlling the 64-bit PCI MMIO aperture via the
(experimental) "opt/ovmf/X-PciMmio64Mb" file
- GetFirstNonAddress(): honoring the hotplug DIMM area
("etc/reserved-memory-end") in the placement of the 64-bit PCI MMIO
aperture
- NoexecDxeInitialization() is removed, so PcdPropertiesTableEnable and
PcdSetNxForStack are left constant FALSE (not set dynamically from
fw_cfg "opt/ovmf/PcdXxxx")
- MaxCpuCountInitialization(), PublishPeiMemory(): the max CPU count is
not taken from the QemuFwCfgItemSmpCpuCount fw_cfg key;
PcdCpuMaxLogicalProcessorNumber is used intact and
PcdCpuApInitTimeOutInMicroSeconds is never changed or used.
- InitializeXenPlatform(), S3Verification(): S3 is assumed disabled (not
consulting "etc/system-states" via QemuFwCfgS3Enabled()).
- InstallFeatureControlCallback(): the feature control MSR is not set
from "etc/msr_feature_control"
(also removed FeatureControl.c as there is nothing been executed)

Also removed:
- SMRAM/TSEG-related low mem size adjusting (PcdSmmSmramRequire is
assumed FALSE) in PublishPeiMemory(),
- QemuInitializeRam() entirely,

Xen related changes:
- Have removed the module variable mXen, as it should be always true.
- Have the platform PEI initialization fails if Xen has not been
  detected.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-5-anthony.perard@citrix.com>
2019-08-21 18:03:49 +02:00
Anthony PERARD c05de360ec OvmfPkg: Introduce XenResetVector
Introduce XenResetVector, a copy of OvmfPkg/ResetVector, with one
changes:
  - SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0)

Xen copies the OVMF code to RAM, there is no need to disable cache.

This new module will later be modified to add a new entry point, more
detail in a following commit "OvmfPkg/XenResetVector: Add new entry point
for Xen PVH"

Value FILE_GUID of XenResetVector have not changed compare to ResetVector
because it is a special value (gEfiFirmwareVolumeTopFileGuid).

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-4-anthony.perard@citrix.com>
2019-08-21 18:03:49 +02:00
Anthony PERARD 75e85e3382 OvmfPkg: Create platform OvmfXen
OvmfXen is a copy of OvmfX64, removing VirtIO and some SMM.

This new platform will be changed to make it works on two types of Xen
guest: HVM and PVH.

Compare to OvmfX64, this patch:

- changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
- removed: VirtioLib class resolution
- removed: all UEFI_DRIVER modules for virtio devices
- removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
- removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
- removed: Everything related to SMM_REQUIRE==true
- removed: Everything related to SECURE_BOOT_ENABLE==true
- removed: Everything related to TPM2_ENABLE==true
- changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
- changed: default FD_SIZE_IN_KB to 2M.
- reverted d272449d9e, "OvmfPkg: raise DXEFV size to 11 MB"

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-3-anthony.perard@citrix.com>
2019-08-21 18:03:49 +02:00