Commit Graph

52 Commits

Author SHA1 Message Date
Laszlo Ersek c4df7fd01f OvmfPkg/PlatformPei: set PCI IO port aperture dynamically
Make PcdPciIoBase and PcdPciIoSize dynamic PCDs, and set them in
MemMapInitialization(), where we produce our EFI_RESOURCE_IO descriptor
HOB. (The PCD is consumed by the core PciHostBridgeDxe driver, through our
PciHostBridgeLib instance.)

Take special care to keep the GCD IO space map unchanged on all platforms
OVMF runs on.

Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
2016-05-17 20:48:41 +02:00
Laszlo Ersek b2f4da3956 OvmfPkg: replace PcdAcpiPmBaseAddress with PIIX4_PMBA_VALUE
In the next patches, we'll differentiate the PMBA IO port address that we
program on PIIX4 vs. Q35.

Normally we'd just turn PcdAcpiPmBaseAddress into a dynamic PCD. However,
because we need this value in BaseRomAcpiTimerLib too (which cannot access
RAM and dynamic PCDs), it must remain a build time constant. We will
introduce its Q35 counterpart later.

As first step, replace the PCD with a new macro in "OvmfPlatforms.h";
Jordan prefers the latter to fixed PCDs in this instance.

Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
2016-05-17 20:48:33 +02:00
Laszlo Ersek 7e5b1b670c OvmfPkg: PlatformPei: determine the 64-bit PCI host aperture for X64 DXE
The main observation about the 64-bit PCI host aperture is that it is the
highest part of the useful address space. It impacts the top of the GCD
memory space map, and, consequently, our maximum address width calculation
for the CPU HOB too.

Thus, modify the GetFirstNonAddress() function to consider the following
areas above the high RAM, while calculating the first non-address (i.e.,
the highest inclusive address, plus one):

- the memory hotplug area (optional, the size comes from QEMU),

- the 64-bit PCI host aperture (we set a default size).

While computing the first non-address, capture the base and the size of
the 64-bit PCI host aperture at once in PCDs, since they are natural parts
of the calculation.

(Similarly to how PcdPciMmio32* are not rewritten on the S3 resume path
(see the InitializePlatform() -> MemMapInitialization() condition), nor
are PcdPciMmio64*. Only the core PciHostBridgeDxe driver consumes them,
through our PciHostBridgeLib instance.)

Set 32GB as the default size for the aperture. Issue#59 mentions the
NVIDIA Tesla K80 as an assignable device. According to nvidia.com, these
cards may have 24GB of memory (probably 16GB + 8GB BARs).

As a strictly experimental feature, the user can specify the size of the
aperture (in MB) as well, with the QEMU option

  -fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536

The "X-" prefix follows the QEMU tradition (spelled "x-" there), meaning
that the property is experimental, unstable, and might go away any time.
Gerd has proposed heuristics for sizing the aperture automatically (based
on 1GB page support and PCPU address width), but such should be delayed to
a later patch (which may very well back out "X-PciMmio64Mb" then).

For "everyday" guests, the 32GB default for the aperture size shouldn't
impact the PEI memory demand (the size of the page tables that the DXE IPL
PEIM builds). Namely, we've never reported narrower than 36-bit addresses;
the DXE IPL PEIM has always built page tables for 64GB at least.

For the aperture to bump the address width above 36 bits, either the guest
must have quite a bit of memory itself (in which case the additional PEI
memory demand shouldn't matter), or the user must specify a large aperture
manually with "X-PciMmio64Mb" (and then he or she is also responsible for
giving enough RAM to the VM, to satisfy the PEI memory demand).

Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Thomas Lamprecht <t.lamprecht@proxmox.com>
Ref: https://github.com/tianocore/edk2/issues/59
Ref: http://www.nvidia.com/object/tesla-servers.html
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-23 17:47:27 +01:00
Laszlo Ersek 9116c9c5d8 OvmfPkg: introduce gRootBridgesConnectedEventGroupGuid
QEMU's ACPI table generator can only create meaningful _CRS objects --
apertures -- for the root buses if all of the PCI devices behind those
buses are actively decoding their IO and MMIO resources, at the time of
the firmware fetching the "etc/table-loader" fw_cfg file. This is not a
QEMU error; QEMU follows the definition of BARs (which are meaningless
when decoding is disabled).

Currently we hook up AcpiPlatformDxe to the PCI Bus driver's
gEfiPciEnumerationCompleteProtocolGuid cue. Unfortunately, when the PCI
Bus driver installs this protocol, it's *still* not the right time for
fetching "etc/table-loader": although resources have been allocated and
BARs have been programmed with them, the PCI Bus driver has also cleared
IO and MMIO decoding in the command registers of the devices.

Furthermore, we couldn't reenable IO and MMIO decoding temporarily in our
gEfiPciEnumerationCompleteProtocolGuid callback even if we wanted to,
because at that time the PCI Bus driver has not produced PciIo instances
yet.

Our Platform BDSes are responsible for connecting the root bridges, hence
they know exactly when the PciIo instances become available -- not when
PCI enumeration completes (signaled by the above protocol), but when the
ConnectController() calls return.

This is when our Platform BDSes should explicitly cue in AcpiPlatformDxe.
Then AcpiPlatformDxe can temporarily enable IO and MMIO decoding for all
devices, while it contacts QEMU for the ACPI payload.

This patch introduces the event group GUID that we'll use for unleashing
AcpiPlatformDxe from our Platform BDSes.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-23 17:38:09 +01:00
Laszlo Ersek 29ebe47cbf OvmfPkg: OvmfPkg.dec: add horizontal whitespace under Guids and Protocols
We'll need more room in the next patch. No functional changes.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-23 17:37:49 +01:00
Laszlo Ersek 03845e90cc OvmfPkg: factor the MMIO aperture shared by all PCI root bridges into PCDs
Going forward, two modules will need to know about the aperture:
PlatformPei (as before), and OVMF's upcoming PciHostBridgeLib instance
(because the core PciHostBridgeDxe driver requires the library to state
the exact apertures for all root bridges).

On QEMU, all root bridges share the same MMIO aperture, hence one pair of
PCDs suffices.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03 18:18:28 +01:00
Laszlo Ersek e705f899af OvmfPkg: factor the IO aperture shared by all PCI root bridges into PCDs
At the moment we don't intend to customize this aperture at runtime, but
going forward, two modules will need to know about it: PlatformPei (as
before), and OVMF's upcoming PciHostBridgeLib instance (because the core
PciHostBridgeDxe driver requires the library to state the exact apertures
for all root bridges).

On QEMU, all root bridges share the same IO port aperture, hence one pair
of PCDs suffices.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03 10:19:32 +01:00
Laszlo Ersek d54c5fdcaa OvmfPkg: remove superfluous [PcdsFixedAtBuild] section header
At the location of this header an earlier [PcdsFixedAtBuild] section is in
effect already.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03 10:19:32 +01:00
Laszlo Ersek b09c1c6f25 OvmfPkg: PlatformPei: account for TSEG size with PcdSmmSmramRequire set
PlatformPei calls GetSystemMemorySizeBelow4gb() in three locations:

- PublishPeiMemory(): on normal boot, the permanent PEI RAM is installed
  so that it ends with the RAM below 4GB,

- QemuInitializeRam(): on normal boot, memory resource descriptor HOBs are
  created for the RAM below 4GB; plus MTRR attributes are set
  (independently of S3 vs. normal boot)

- MemMapInitialization(): an MMIO resource descriptor HOB is created for
  PCI resource allocation, on normal boot, starting at max(RAM below 4GB,
  2GB).

The first two of these is adjusted for the configured TSEG size, if
PcdSmmSmramRequire is set:

- In PublishPeiMemory(), the permanent PEI RAM is kept under TSEG.

- In QemuInitializeRam(), we must keep the DXE out of TSEG.

  One idea would be to simply trim the [1MB .. LowerMemorySize] memory
  resource descriptor HOB, leaving a hole for TSEG in the memory space
  map.

  The SMM IPL will however want to massage the caching attributes of the
  SMRAM range that it loads the SMM core into, with
  gDS->SetMemorySpaceAttributes(), and that won't work on a hole. So,
  instead of trimming this range, split the TSEG area off, and report it
  as a cacheable reserved memory resource.

  Finally, since reserved memory can be allocated too, pre-allocate TSEG
  in InitializeRamRegions(), after QemuInitializeRam() returns. (Note that
  this step alone does not suffice without the resource descriptor HOB
  trickery: if we omit that, then the DXE IPL PEIM fails to load and start
  the DXE core.)

- In MemMapInitialization(), the start of the PCI MMIO range is not
  affected.

We choose the largest option (8MB) for the default TSEG size. Michael
Kinney pointed out that the SMBASE relocation in PiSmmCpuDxeSmm consumes
SMRAM proportionally to the number of CPUs. From the three options
available, he reported that 8MB was both necessary and sufficient for the
SMBASE relocation to succeed with 255 CPUs:

- http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020/focus=3137
- http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020/focus=3177

Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19039 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 18:41:33 +00:00
Laszlo Ersek 9beac0d847 OvmfPkg: Sec: assert the build-time calculated end of the scratch buffer
The DecompressMemFvs() function in "OvmfPkg/Sec/SecMain.c" uses more
memory, temporarily, than what PEIFV and DXEFV will ultimately need.
First, it uses an output buffer for decompression, second, the
decompression itself needs a scratch buffer (and this scratch buffer is
the highest area that SEC uses).

DecompressMemFvs() used to be called on normal boots only (ie. not on S3
resume), which is why the decompression output buffer and the scratch
buffer were allowed to scribble over RAM. However, we'll soon start to
worry during S3 resume that the runtime OS might tamper with the
pre-decompressed PEIFV, and we'll decompress the firmware volumes on S3
resume too, from pristine flash. For this we'll need to know the end of
the scratch buffer in advance, so we can prepare a non-malicious OS for
it.

Calculate the end of the scratch buffer statically in the FDF files, and
assert in DecompressMemFvs() that the runtime decompression will match it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19036 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 18:41:20 +00:00
Laszlo Ersek 1f695483e6 OvmfPkg: introduce -D SMM_REQUIRE and PcdSmmSmramRequire
This build time flag and corresponding Feature PCD will control whether
OVMF supports (and, equivalently, requires) SMM/SMRAM support from QEMU.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19034 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 18:41:10 +00:00
Laszlo Ersek 6fbef93e9f OvmfPkg: introduce PcdQemuSmbiosValidated
This dynamic PCD will enable a small code de-duplication between
OvmfPkg/SmbiosPlatformDxe and OvmfPkg/Library/SmbiosVersionLib. Since both
of those are also used in ArmVirtQemu.dsc, and we should avoid
cross-package commits when possible, this patch declares
PcdQemuSmbiosValidated first, and sets defaults for it in the OvmfPkg DSC
files.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Wei Huang <wei@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18178 6f19259b-4bc3-4df7-8a09-765794883524
2015-08-06 10:13:55 +00:00
Ard Biesheuvel 0169352eaa ArmVirtualizationPkg: add XenIoMmioLib
This adds a XenIoMmioLib declaration and implementation that can
be invoked to install the XENIO_PROTOCOL and a corresponding
grant table address on a EFI handle.

Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16979 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28 20:34:16 +00:00
Ard Biesheuvel b0022ab871 Ovfm/Xen: add a Vendor Hardware device path GUID for the XenBus root
On non-PCI Xen guests (such as ARM), the XenBus root is not a PCI
device but an abstract 'platform' device. Add a dedicated Vendor
Hardware device path GUID to identify this node.

Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16978 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28 20:34:06 +00:00
Ard Biesheuvel b2165af423 Ovmf/Xen: introduce XENIO_PROTOCOL
This introduces the abstract XENIO_PROTOCOL that will be used to
communicate the Xen grant table address to drivers supporting this
protocol. Primary purpose is allowing us to change the XenBusDxe
implementation so that it can support non-PCI Xen implementations
such as Xen on ARM.

Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16971 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28 20:32:50 +00:00
Ard Biesheuvel cd8ff8fdda Ovmf/Xen: move XenBusDxe hypercall code to separate library
This moves all of the Xen hypercall code that was private to XenBusDxe
to a new library class XenHypercallLib. This will allow us to reimplement
it for ARM, and to export the Xen hypercall functionality to other parts
of the code, such as a Xen console SerialPortLib driver.

Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16970 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28 20:32:39 +00:00
Laszlo Ersek 4333691690 OvmfPkg: QemuBootOrderLib: OFW-to-UEFI translation for virtio-mmio
The TranslateMmioOfwNodes() function recognizes the following OpenFirmware
device paths:

  virtio-blk:       /virtio-mmio@000000000a003c00/disk@0,0
  virtio-scsi disk: /virtio-mmio@000000000a003a00/channel@0/disk@2,3
  virtio-net NIC:   /virtio-mmio@000000000a003e00/ethernet-phy@0

The new translation can be enabled with the
"PcdQemuBootOrderMmioTranslation" Feature PCD. This PCD also controls if
the "survival policy" covers unselected boot options that start with the
virtio-mmio VenHw() node.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16575 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02 12:08:19 +00:00
Laszlo Ersek 3765e030af OvmfPkg: introduce VIRTIO_MMIO_TRANSPORT_GUID
Soon there will be more than one modules (in separate packages) that need
to have an understanding about the GUID used in the VenHw() device path
nodes that describe virtio-mmio transports. Define such a GUID explicitly.

Preserve the current value (which happens to be the FILE_GUID of
ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf) for
compatibility with external users.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16572 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02 12:08:06 +00:00
Laszlo Ersek 2f9c55cc1d OvmfPkg: QemuBootOrderLib: featurize PCI-like device path translation
In preparation for adding OpenFirmware-to-UEFI translation for "MMIO-like"
OFW device path fragments, let's turn the currently exclusive "PCI-like"
translation into "just one" of the possible translations.

- Rename TranslateOfwNodes() to TranslatePciOfwNodes(), because it is
  tightly coupled to "PCI-like" translations.

- Rename REQUIRED_OFW_NODES to REQUIRED_PCI_OFW_NODES, because this macro
  is specific to TranslatePciOfwNodes().

- Introduce a new wrapper function under the original TranslateOfwNodes()
  name. This function is supposed to try translations in some order until
  a specific translation returns a status different from
  RETURN_UNSUPPORTED.

- Introduce a new Feature PCD that controls whether PCI translation is
  attempted at all.

- The boot option "survival policy" in BootOrderComplete() must take into
  account if the user was able to select PCI-like boot options. If the
  user had no such possibility (because the Feature PCD was off for
  PCI-like translation), then we ought to keep any such unselected boot
  options.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16571 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02 12:08:02 +00:00
Laszlo Ersek cca7475bcb OvmfPkg: extract QemuBootOrderLib
and rebase OvmfPkg's PlatformBdsLib on the standalone library.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16570 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02 12:07:57 +00:00
Gabriel Somlo d55004dac9 OvmfPkg: Add PCD for Host Bridge dev. ID (PcdOvmfHostBridgePciDevId)
Set from PEI, this PCD allows subsequent stages (specifically
DXE_DRIVER and DXE_RUNTIME_DRIVER) to infer the underlying platform
type (e.g. PIIX4 or Q35/MCH) without the need to further query the
Host Bridge for its Device ID.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16374 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14 00:37:39 +00:00
Anthony PERARD 12a16f2d1c OvmfPkg: Introduce XenBus Protocol.
This protocol will be used for communication between a PV driver (like a
PV block driver) and the XenBus/XenStore.

Change in V5:
- Replace the license by the commonly used file header text.

Change in V3:
- Add disclaimer about the volatile nature of the protocol.
- Add a description on the two introduced members to the protocol.

Change in V2:
- Comment, file header
- Protocol License
- Declare xen interface version earlier
- Rename protocol from Xenbus to XenBus

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16262 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-29 06:49:38 +00:00
Laszlo Ersek ad43bc6b2e OvmfPkg: PlatformPei: protect SEC's GUIDed section handler table thru S3
OVMF's SecMain is unique in the sense that it links against the following
two libraries *in combination*:

- IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/
                                               LzmaCustomDecompressLib.inf
- MdePkg/Library/BaseExtractGuidedSectionLib/
                                           BaseExtractGuidedSectionLib.inf

The ExtractGuidedSectionLib library class allows decompressor modules to
register themselves (keyed by GUID) with it, and it allows clients to
decompress file sections with a registered decompressor module that
matches the section's GUID.

BaseExtractGuidedSectionLib is a library instance (of type BASE) for this
library class. It has no constructor function.

LzmaCustomDecompressLib is a compatible decompressor module (of type
BASE). Its section type GUID is

  gLzmaCustomDecompressGuid == EE4E5898-3914-4259-9D6E-DC7BD79403CF

When OVMF's SecMain module starts, the LzmaCustomDecompressLib constructor
function is executed, which registers its LZMA decompressor with the above
GUID, by calling into BaseExtractGuidedSectionLib:

  LzmaDecompressLibConstructor() [GuidedSectionExtraction.c]
    ExtractGuidedSectionRegisterHandlers() [BaseExtractGuidedSectionLib.c]
      GetExtractGuidedSectionHandlerInfo()
        PcdGet64 (PcdGuidedExtractHandlerTableAddress) -- NOTE THIS

Later, during a normal (non-S3) boot, SecMain utilizes this decompressor
to get information about, and to decompress, sections of the OVMF firmware
image:

  SecCoreStartupWithStack() [OvmfPkg/Sec/SecMain.c]
    SecStartupPhase2()
      FindAndReportEntryPoints()
        FindPeiCoreImageBase()
          DecompressMemFvs()
            ExtractGuidedSectionGetInfo() [BaseExtractGuidedSectionLib.c]
            ExtractGuidedSectionDecode() [BaseExtractGuidedSectionLib.c]

Notably, only the extraction depends on full-config-boot; the registration
of LzmaCustomDecompressLib occurs unconditionally in the SecMain EFI
binary, triggered by the library constructor function.

This is where the bug happens. BaseExtractGuidedSectionLib maintains the
table of GUIDed decompressors (section handlers) at a fixed memory
location; selected by PcdGuidedExtractHandlerTableAddress (declared in
MdePkg.dec). The default value of this PCD is 0x1000000 (16 MB).

This causes SecMain to corrupt guest OS memory during S3, leading to
random crashes. Compare the following two memory dumps, the first taken
right before suspending, the second taken right after resuming a RHEL-7
guest:

crash> rd -8 -p 1000000 0x50
1000000: c0 00 08 00 02 00 00 00 00 00 00 00 00 00 00 00  ................
1000010: d0 33 0c 00 00 c9 ff ff c0 10 00 01 00 88 ff ff  .3..............
1000020: 0a 6d 57 32 0f 00 00 00 38 00 00 01 00 88 ff ff  .mW2....8.......
1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f  ........signalmo
1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00  dule.so.........

vs.

crash> rd -8 -p 1000000 0x50
1000000: 45 47 53 49 01 00 00 00 20 00 00 01 00 00 00 00  EGSI.... .......
1000010: 20 01 00 01 00 00 00 00 a0 01 00 01 00 00 00 00   ...............
1000020: 98 58 4e ee 14 39 59 42 9d 6e dc 7b d7 94 03 cf  .XN..9YB.n.{....
1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f  ........signalmo
1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00  dule.so.........

The "EGSI" signature corresponds to EXTRACT_HANDLER_INFO_SIGNATURE
declared in
MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.c.

Additionally, the gLzmaCustomDecompressGuid (quoted above) is visible at
guest-phys offset 0x1000020.

Fix the problem as follows:
- Carve out 4KB from the 36KB gap that we currently have between

  PcdOvmfLockBoxStorageBase + PcdOvmfLockBoxStorageSize == 8220 KB
  and
  PcdOvmfSecPeiTempRamBase                              == 8256 KB.

- Point PcdGuidedExtractHandlerTableAddress to 8220 KB (0x00807000).

- Cover the area with an EfiACPIMemoryNVS type memalloc HOB, if S3 is
  supported and we're not currently resuming.

The 4KB size that we pick is an upper estimate for
BaseExtractGuidedSectionLib's internal storage size. The latter is
calculated as follows (see GetExtractGuidedSectionHandlerInfo()):

  sizeof(EXTRACT_GUIDED_SECTION_HANDLER_INFO) +         // 32
  PcdMaximumGuidedExtractHandler * (
    sizeof(GUID) +                                      // 16
    sizeof(EXTRACT_GUIDED_SECTION_DECODE_HANDLER) +     //  8
    sizeof(EXTRACT_GUIDED_SECTION_GET_INFO_HANDLER)     //  8
    )

OVMF sets PcdMaximumGuidedExtractHandler to 16 decimal (which is the
MdePkg default too), yielding 32 + 16 * (16 + 8 + 8) == 544 bytes.

Regarding the lifecycle of the new area:

(a) when and how it is initialized after first boot of the VM

  The library linked into SecMain finds that the area lacks the signature.
  It initializes the signature, plus the rest of the structure. This is
  independent of S3 support.

  Consumption of the area is also limited to SEC (but consumption does
  depend on full-config-boot).

(b) how it is protected from memory allocations during DXE

  It is not, in the general case; and we don't need to. Nothing else links
  against BaseExtractGuidedSectionLib; it's OK if DXE overwrites the area.

(c) how it is protected from the OS

  When S3 is enabled, we cover it with AcpiNVS in InitializeRamRegions().

  When S3 is not supported, the range is not protected.

(d) how it is accessed on the S3 resume path

  Examined by the library linked into SecMain. Registrations update the
  table in-place (based on GUID matches).

(e) how it is accessed on the warm reset path

  If S3 is enabled, then the OS won't damage the table (due to (c)), hence
  see (d).

  If S3 is unsupported, then the OS may or may not overwrite the
  signature. (It likely will.) This is identical to the pre-patch status.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15433 6f19259b-4bc3-4df7-8a09-765794883524
2014-04-05 21:26:09 +00:00
Laszlo Ersek 732295d149 OvmfPkg: introduce gOvmfPlatformConfigGuid
This GUID should become a new "namespace" for UEFI variables that are
specific to OVMF configuration (as opposed to standard UEFI global
variables). We'll also use it as the GUID of the related HII form-set (ie.
the interactive user interface).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15363 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-22 07:12:46 +00:00
Laszlo Ersek 6a7cba79b7 OvmfPkg: implement LockBoxLib
The S3 suspend/resume infrastructure depends on the LockBox library class.
The edk2 tree currently contains Null and SMM instances. The Null instance
is useless, and the SMM instance would require SMM emulation by including
the SMM core and adding several new drivers, which is deemed too complex.

Hence add a simple LockBoxLib instance for OVMF.

jordan.l.justen@intel.com:
 * use PCDs instead of EmuNvramLib
   - clear memory in PlatformPei on non S3 boots
 * allocate NVS memory and store a pointer to that memory
   - reduces memory use at fixed locations

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15301 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04 08:03:23 +00:00
Jordan Justen 8e54500fd4 OvmfPkg: Add section of memory to use for PEI on S3 resume
This 32k section of RAM will be declared to the PEI Core on
S3 resume to allow memory allocations during S3 resume PEI.

If the boot mode is BOOT_ON_S3_RESUME, then we publish
the pre-reserved PcdS3AcpiReservedMemory range to PEI.

If the boot mode is not BOOT_ON_S3_RESUME, then we reserve
this range as ACPI NVS so the OS will not use it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15294 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04 08:02:16 +00:00
Jordan Justen b36f701d4f OvmfPkg: Split MAINFV into a separate PEI and DXE FVs
By splitting the PEI and DXE phases into separate FVs,
we can only reserve the PEI FV for ACPI S3 support.
This should save about 7MB.

Unfortunately, this all has to happen in a single commit.

DEC:
* Remove PcdOvmfMemFv(Base|Size)
* Add PcdOvmfPeiMemFv(Base|Size)
* Add PcdOvmfDxeMemFv(Base|Size)

FDF:
* Add new PEIFV. Move PEI modules here.
* Remove MAINFV
* Add PEIFV and DXEFV into FVMAIN_COMPACT
   - They are added as 2 sections of a file, and compressed
     together so they should retain good compression
* PcdOvmf(Pei|Dxe)MemFv(Base|Size) are set

SEC:
* Find both the PEI and DXE FVs after decompression.
   - Copy them separately to their memory locations.

Platform PEI driver:
* Fv.c: Publish both FVs as appropriate
* MemDetect.c: PcdOvmfMemFv(Base|Size) =>
                PcdOvmfDxeMemFv(Base|Size)

OVMF.fd before:

  Non-volatile data storage
  FVMAIN_COMPACT                    uncompressed
    FV FFS file                     LZMA compressed
      MAINFV                        uncompressed
        individual PEI modules      uncompressed
        FV FFS file                 compressed with PI_NONE
          DXEFV                     uncompressed
            individual DXE modules  uncompressed
  SECFV                             uncompressed

OVMF.fd after:

  Non-volatile data storage
  FVMAIN_COMPACT                    uncompressed
    FV FFS file                     LZMA compressed
      PEIFV                         uncompressed
        individual PEI modules      uncompressed
      DXEFV                         uncompressed
        individual DXE modules      uncompressed
  SECFV                             uncompressed

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15151 6f19259b-4bc3-4df7-8a09-765794883524
2014-01-21 19:39:13 +00:00
Jordan Justen 7cb6b0e068 OvmfPkg: Move SEC/PEI Temporary RAM from 0x70000 to 0x810000
Note: The Temporary RAM memory size is being reduced from
      64KB to 32KB. This still appears to be more than
      adequate for OVMF's early PEI phase. We will be adding
      another 32KB range of RAM just above this range for
      use on S3 resume.

The range is declared as part of MEMFD, so it is easier
to identify the memory range.

We also now assign PCDs to the memory range.

The PCDs are used to set the initial SEC/PEI stack in
SEC's assembly code.

The PCDs are also used in the SEC C code to setup
the Temporary RAM PPI.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15147 6f19259b-4bc3-4df7-8a09-765794883524
2014-01-21 19:38:43 +00:00
Jordan Justen b382ede386 OvmfPkg X64 ResetVector: Move page tables from 512KB to 8MB
To help consolidate OVMF fixed memory uses, we declare this
range in MEMFD and thereby move it to 8MB.

We also now declare the table range in the FDF to set
PCDs. This allows us to ASSERT that CR3 is set as expected
in OVMF SEC.

OvmfPkgIa32.fdf and OvmfPkgIa32X64.fdf are updated simply
for consistency.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15146 6f19259b-4bc3-4df7-8a09-765794883524
2014-01-21 19:38:34 +00:00
Olivier Martin fc4d1ce574 OvmfPkg/VirtioDevice.h: Introduced VIRTIO_DEVICE_PROTOCOL protocol
This protocol introduces an abstraction to access the VirtIo
Configuration and Device spaces.
The registers in these spaces are located at a different offset and have
a different width whether the transport layer is either PCI or MMIO. This
protocol would also allow to support VirtIo PCI devices with MSI-X
capability in a transparent way (Device space is at a different offset
when a PCIe device has MSI-X capability).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>

v5:
- add disclaimer (two instances) about the protocol being work in progress

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14963 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 16:57:40 +00:00
Laszlo Ersek 9d35ac2611 OvmfPkg: indicate enablement of flash variables with a dedicated PCD
PcdFlashNvStorageVariableBase64 is used to arbitrate between
QemuFlashFvbServicesRuntimeDxe and EmuVariableFvbRuntimeDxe, but even the
latter driver sets it if we fall back to it.

Allow code running later than the startup of these drivers to know about
the availability of flash variables, through a dedicated PCD.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14843 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-12 18:35:23 +00:00
Jordan Justen 501e08fcfe OvmfPkg: Add flash PCD items
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14834 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-12 18:34:11 +00:00
jljusten f6c6c02028 OvmfPkg: Add LoadLinuxLib library interface
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13921 6f19259b-4bc3-4df7-8a09-765794883524
2012-11-02 18:26:48 +00:00
jljusten 37078a63b1 OvmfPkg: introduce virtio-scsi driver
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[jordan.l.justen@intel.com: fix build for VS2012]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13867 6f19259b-4bc3-4df7-8a09-765794883524
2012-10-18 17:07:48 +00:00
jljusten 830067bfa2 OvmfPkg: extract the PBMA used in AcpiTimerLib into a PCD
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13719 6f19259b-4bc3-4df7-8a09-765794883524
2012-09-12 07:18:35 +00:00
jljusten 67164dcd2e OvmfPkg: assorted whitespace removal
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13718 6f19259b-4bc3-4df7-8a09-765794883524
2012-09-12 07:18:21 +00:00
jljusten b90aefa9e4 OvmfPkg: add support for debug console on port 0x402
This patch adds support for a debug console on the same port that is used
by SeaBIOS.  This makes it easier to debug OVMF, because it does not mix
debug and serial output on the same device.  It also makes it easier to
leave some of the debug messages on even in release builds.

To enable it, pass "-debugcon stdio -global isa-debugcon.iobase=0x402" to
QEMU.

The new mechanism is enabled by default, but a regular serial console can
be chosen by adding -D DEBUG_ON_SERIAL_PORT to the build options.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[jordan.l.justen@intel.com: MAX_DEBUG_MESSAGE_LENGTH=>0x100, p=>Ptr]
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13562 6f19259b-4bc3-4df7-8a09-765794883524
2012-07-26 16:36:39 +00:00
jljusten f1ec65ba24 OvmfPkg: Add QemuFwCfgLib library class and implementation
QEMU's Firmware Configuration interface gives the firmware
access to various types of information.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13383 6f19259b-4bc3-4df7-8a09-765794883524
2012-05-30 23:14:38 +00:00
jljusten e05061c59f OvmfPkg: Add PcdSecureBootEnable
Signed-off-by: lgrosenb
Reviewed-by: jljusten
Reviewed-by: mdkinney

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13091 6f19259b-4bc3-4df7-8a09-765794883524
2012-03-09 17:38:21 +00:00
jljusten 84c1b22e84 OvmfPkg/Include/Guid: Add XenInfo GUID
XenInfo HOB is used to pass XenInfo from PEI to DXE.

Signed-off-by: Andrei Warkentin <andreiw@motorola.com>
Reviewed-by: gavinguan
Reviewed-by: jljusten

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12059 6f19259b-4bc3-4df7-8a09-765794883524
2011-07-29 23:59:12 +00:00
lzeng14 46293a4215 Clean up invalid keywords and missing keywords in [Define] section of INF/DEC files.
Signed-off-by: lzeng14
Reviewed-by: lhauch
Reviewed-by: jljusten

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11906 6f19259b-4bc3-4df7-8a09-765794883524
2011-06-28 02:24:46 +00:00
mdkinney 28b29a70f2 Clean up DEC files:
1) Remove section header comment blocks that do not provide any information
2) Combine PCDs listed in multiple sections into a single section that supports multiple PCD types to reduce maintenance overhead
3) Remove ModuleTypeList comments from [Includes], [Protocols], [Ppis], and [Guids] sections that do not properly describe the module type restrictions.
4) Clean up formatting of GUID structure declarations
5) Remove ".common" from section names if they are not required.
6) Order sections consistently as [Defines], [Includes], [LibraryClasses], [Guid], [Ppis], [Protocols], [PcdsFeatureFlag], [PcdsFixedAtBuild], [PcdsPatchableInModule], [PcdsDynamic], and [PcdsDynamicEx]


git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11633 6f19259b-4bc3-4df7-8a09-765794883524
2011-05-09 17:50:40 +00:00
mdkinney 70c66df5d7 Fix DEC files so any PCD declared as Dynamic is also declared as DynamicEx
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11625 6f19259b-4bc3-4df7-8a09-765794883524
2011-05-05 16:15:35 +00:00
jljusten e79f62f01c OvmfPkg: Add SerializeVariablesLib library class
This library provides an interface for converting the system
variables into a binary and also restoring the system variables
from that binary.

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11284 6f19259b-4bc3-4df7-8a09-765794883524
2011-01-30 19:49:37 +00:00
gikidy 85c0b5ee7f Fix PCD token value conflict issue.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10996 6f19259b-4bc3-4df7-8a09-765794883524
2010-11-02 05:27:15 +00:00
hhtian 56d7640a53 Update the copyright notice format
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10439 6f19259b-4bc3-4df7-8a09-765794883524
2010-04-28 12:43:04 +00:00
jljusten b0f5144676 OVMF: Add Block MMIO protocol definition
This protocol is similar to the standard UEFI BlockIo protocol,
except it has no function calls and simply defines a base address
in memory where reads & writes for the block device should occur.

One planned usage is to fill a memory region with a small disk
image, and allow it to be used as a normal disk by the
standard drivers.

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10295 6f19259b-4bc3-4df7-8a09-765794883524
2010-03-21 00:33:59 +00:00
lgao4 7b202cb0f9 1. Correct File header to ## @file
2. Remove unnecessary .common] postfix on section.

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10051 6f19259b-4bc3-4df7-8a09-765794883524
2010-02-23 23:58:38 +00:00
jljusten c1c2669c6b OVMF: Update OVMF FD/FV build to minimize ROM size
* Only SEC is uncompressed now
* The MAIN FV with PEI & DXE can easily shrink and grow as needed
* The final output will now be OVMF.Fv rather than OVMF.fd
* The final output size will be a multiple of 64kb

git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9672 6f19259b-4bc3-4df7-8a09-765794883524
2010-01-04 16:17:59 +00:00
jljusten 610698361d OVMF: Add library to customize the EMU Variable FVB driver.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9316 6f19259b-4bc3-4df7-8a09-765794883524
2009-09-26 07:15:48 +00:00