OvmfPkg/PlatformPei: Call PublishPeiMemory in one place

The Xen and QEMU/KVM paths were calling this at nearly
the same time in the boot flow anyhow, so just make
the call in one spot.

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: svn://svn.code.sf.net/p/edk2/code/trunk/edk2/OvmfPkg@15195 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg/PlatformPei: Move BootMode detection before mem-init

This will be needed to update the boot flow for S3 resume.

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: svn://svn.code.sf.net/p/edk2/code/trunk/edk2/OvmfPkg@15196 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: QemuBootOrder: handle QEMU's "-boot strict=on" option

When this option is passed to qemu, it appends the word HALT to the
"bootorder" fw_cfg file, as last entry. For example,

  /pci@i0cf8/ethernet@3/ethernet-phy@0
  /pci@i0cf8/scsi@4/disk@0,0
  HALT

The option's purpose is to prevent SeaBIOS from booting from devices that
have not been specified explicitly (with bootindex=N device properties nor
-boot options). When SeaBIOS sees HALT, it doesn't proceed to boot from
default locations (after boot fails from all of the listed locations).

The HALT string currently causes OVMF to reject the entire "bootorder"
fw_cfg contents, with "parse error". This is not good, because since a
recent libvirt commit, libvirt unconditionally passes "-boot strict=on" to
qemu. Consequently, the boot order logic in QemuBootOrder.c has stopped
working for libvirt users.

OVMF's SetBootOrderFromQemu() function actually implements the idea behind
"-boot strict=on": it drops all boot options not in the fw_cfg list. (*)
Therefore, let's recognize HALT, and just do what we've been doing all
along.

(*) Except the UEFI shell, according to the survival policy in
BootOrderComplete(), but the memory mapped UEFI shell is not expressible
via fw_cfg anyway, and its preservation has been requested on edk2-devel.
Hence it's a good boot option to keep in any case.

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: svn://svn.code.sf.net/p/edk2/code/trunk/edk2/OvmfPkg@15197 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg/PlatformPei: Don't allocate ACPI NVS memory

Once we support ACPI S3, then we can restore this to
being allocated as ACPI NVS memory.

At that time we should also have a way to disable
S3 support in QEMU. When we detect that S3 is
disabled in QEMU, then we can allocate this as regular
Boot Services Data memory.

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

git-svn-id: svn://svn.code.sf.net/p/edk2/code/trunk/edk2/OvmfPkg@15198 6f19259b-4bc3-4df7-8a09-765794883524