summaryrefslogtreecommitdiff
path: root/OvmfPkg
AgeCommit message (Collapse)Author
2015-07-14OvmfPkg: QemuBootOrderLib: introduce ExtraRootBusMapLaszlo Ersek
SeaBIOS requires the OpenFirmware device paths exported in the "bootorder" fw-cfg file to refer to extra (PXB) root buses by their relative positions (in increasing bus number order) rather than by actual bus numbers. However, OVMF's PCI host bridge / root bridge driver creates PciRoot(UID) device path nodes for extra PCI root buses with UID=bus_nr, not position. (These ACPI devpath UID values must, and do, match the UID values exposed in QEMU's ACPI payload, generated for PXB root buses.) Therefore the boot order matching logic will have to map extra root bus positions to bus numbers. Add a small group of utility functions to help with that. 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> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17964 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: PciHostBridgeDxe: shorten search for extra root busesLaszlo Ersek
QEMU provides an fw_cfg file called "etc/extra-pci-roots", containing a little-endian UINT64 value that exposes the number of extra root buses. We can use this value to terminate the scan as soon as we find the last extra root bus. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17963 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: PciHostBridgeDxe: look for all root busesLaszlo Ersek
In this patch we assume that root bus number 0 is always there (same as before), and scan the rest of the extra root buses, up to and including 255. When an extra root bus is found, we install the PCI root bridge IO protocol for the previous root bus (which might be bus 0 or just the previous extra root bus). The root bridge protocol created thus will report the available bus number range [own bus number, next extra root bus number - 1] The LHS of this interval will be used for the root bus's own number, and the rest of the interval (which might encompass 0 additional elements too) can be used by the PCI bus driver to assign subordinate bus numbers from. (Subordinate buses are provided by PCI bridges that hang off the root bus in question.) For MMIO and IO space allocation, all the root buses share the original [0x8000_0000, 0xFFFF_FFFF] and [0x0, 0xFFFF] ranges, respectively. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17962 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: PciHostBridgeDxe: eliminate PCI_HOST_BRIDGE_INSTANCE.RootBridgeNumberLaszlo Ersek
This field was supposed to store the number of root buses created; however we don't need to keep that count persistently. After the entry point returns, nothing reads this field. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17961 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: PciHostBridgeDxe: use private buffer in RootBridgeIoConfiguration()Laszlo Ersek
On output, the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Configuration() function produces a pointer to a buffer of ACPI 2.0 resource descriptors: Resources A pointer to the ACPI 2.0 resource descriptors that describe the current configuration of this PCI root bridge. The storage for the ACPI 2.0 resource descriptors is allocated by this function. The caller must treat the return buffer as read-only data, and the buffer must not be freed by the caller. PciHostBridgeDxe currently provides this buffer in a structure with static storage duration. If multiple root bridges existed in parallel, the pointers returned by their Configuration() methods would point to the same static storage. A later Configuration() call would overwrite the storage pointed out by an earlier Configuration() call (which was possibly made for a different, but still alive, root bridge.) Fix this problem by embedding the configuration buffer in PCI_ROOT_BRIDGE_INSTANCE. While we're at it, correct some typos (Desp -> Desc), spell out a missing pack(1) pragma, and improve formatting. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17960 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: PciHostBridgeDxe: release resources on driver entry failureLaszlo Ersek
The entry point of the driver, InitializePciHostBridge(), leaks resources (and installed protocols) in the following cases: - The first root bridge protocol installation fails. In this case, the host bridge protocol is left installed, but the driver exits with an error. - The second or a later root bridge protocol installation fails. In this case, the host bridge protocol, and all prior root bridge protocols, are left installed, even though the driver exits with an error. Handle errors correctly: roll back / release / uninstall resources when aborting the driver. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17959 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: PciHostBridgeDxe: factor out InitRootBridge() functionLaszlo Ersek
This new function incorporates the current loop body found in the entry point function, InitializePciHostBridge(). It will be called once for each root bus discovered. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17958 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: PciHostBridgeDxe: embed device path in private root bridge structLaszlo Ersek
Currently we define a device path for each root bridge statically (for all one of them). Since we'll want to create a dynamic number of root bridges, replace the static device paths with a common template, embed the actual device path into the private root bridge structure, and distinguish the device paths from each other in the UID field (as required by ACPI). This patch is best viewed with "git show -b". Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17957 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: PciHostBridgeDxe: kill RootBridgeNumber and RootBridgeAttributeLaszlo Ersek
There is no need to store these constants in dedicated static storage duration objects; we can simply open-code them, simplifying the code. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17956 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: PciHostBridgeDxe: eliminate nominal support for multiple host bridgesLaszlo Ersek
The entry point function of this driver, InitializePciHostBridge(), and the static storage duration objects it relies on, are speculatively generic -- they nominally support more than one host bridges, but (a) the code hardwires the number of host bridges as 1, (b) it's very unlikely that we'd ever like to raise that number (especially by open-coding it). So let's just remove the the nominal support, and simplify the code. This patch is best viewed with "git show -b". Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17955 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: PlatformBdsLib: connect all PCI root busesLaszlo Ersek
Currently we only connect the root bus with bus number 0, by device path. Soon we will possibly have several extra root buses, so connect all root buses up-front (bus number zero and otherwise), by protocol GUID. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17954 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: PlatformBdsLib: refine PCI host bridge assertionLaszlo Ersek
The ASSERT() in SetPciIntLine() assumes that Device 0 on "the" root bus corresponds to the PCI host bridge (00:00). This used to be true, but because we're going to have extra root buses (with nonzero bus numbers), soon this assumption may no longer hold. Check for the zero root bus number explicitly. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17953 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: PlatformBdsLib: debug log interrupt line assignmentsLaszlo Ersek
These messages are helpful for comparing the assignments made by OVMF against those made by SeaBIOS. To SeaBIOS a small debug patch like the following can be applied: > diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c > index ac39d23..9e61c22 100644 > --- a/src/fw/pciinit.c > +++ b/src/fw/pciinit.c > @@ -308,8 +308,12 @@ static void pci_bios_init_device(struct pci_device *pci) > > /* map the interrupt */ > int pin = pci_config_readb(bdf, PCI_INTERRUPT_PIN); > - if (pin != 0) > - pci_config_writeb(bdf, PCI_INTERRUPT_LINE, pci_slot_get_irq(pci, pin)); > + if (pin != 0) { > + int irqline = pci_slot_get_irq(pci, pin); > + > + pci_config_writeb(bdf, PCI_INTERRUPT_LINE, irqline); > + dprintf(1, "assigned irq line %d\n", irqline); > + } > > pci_init_device(pci_device_tbl, pci, NULL); > Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17952 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: clone PciHostBridgeDxe from PcAtChipsetPkgLaszlo Ersek
The source code is copied verbatim, with the following two exceptions: - the UNI files are dropped, together with the corresponding UNI references in the INF file, - the INF file receives a new FILE_GUID. The OVMF DSC and FDF files are at once flipped to the cloned driver. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17951 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-10OvmfPkg: QemuFwCfgLib: avoid "variable set but not used" warning from GCCBill Paul
The FileReserved variable in QemuFwCfgFindFile() is only used to skip over the reserved field in file headers, which causes newer versions of GCC to flag it with a "variable set but not used" warning (which is normally not visible since as of right now these warnings are supressed). It's true that the value read into FileReserved is never used, but this is intentional. This patch adds a do-nothing reference to silence the warning. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Bill Paul <wpaul@windriver.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17920 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-10OvmfPkg: Remove Ip4ConfigDxe module from OvmfPkgJiaxin Wu
Ip4ConfigDxe driver is deprecated in UEFI 2.5, so we will not support original Ip4Config Protocol, which is replace by Ip4Config2 Protocol integrated in Ip4Dxe driver(git commit 1f6729ff (SVN r17853)). Therefore we can remove Ip4ConfigDxe driver from this build. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17914 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-09OvmfPkg: Fix GCC49 build hang in PeiCoreRuiyu Ni
PeiCore hang when loads a PEIM whose section alignment requirement is 0x40 but the actual base address is 0x20 aligned. The issue is caused by the following facts, in order: 1. GCC49 requires the section alignment of .data to be 0x40. So a new link script gcc4.9-ld-script was added for GCC49 to specify the 0x40 alignment. 2. GenFw tool was enhanced to sync ELF's section alignment to PE header. Before the enhancement, the section alignment of converted PE image always equals to 0x20. If only with #1 change, GCC49 build image won't hang in PeiCore because the converted PE image still claims 0x20 section alignment which is aligned to the align setting set in FDF file. But later with #2 change, the converted PE image starts to claims 0x40 section alignment, while build tool still puts the PEIM in 0x20 aligned address, resulting the PeCoffLoaderLoadImage() reports IMAGE_ERROR_INVALID_SECTION_ALIGNMENT error. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17902 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-08OvmfPkg: Fix the build.sh shebang line to avoid depending on location of bashBruce Cran
The bash binary can be in various locations depending on the system: on Linux it's in /bin while on BSD it's normally in /usr/local/bin. However, the env binary is almost always in /usr/bin and so can be used to find and start the shell. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Bruce Cran <bruce@cran.org.uk> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17883 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-02Revert tree to r17801Jordan Justen
Revert r17802 "BaseTools: AArch64: use explicit linker scripts" Revert r17803 "ArmVirtPkg: build runtime drivers with 64 KB section alignment" Revert r17804 "IntelFrameworkModulePkg: AcpiS3SaveDxe: prepare for End-of-Dxe callback" Revert r17805 "IntelFrameworkModulePkg: AcpiS3SaveDxe: call S3Ready() at End-of-Dxe" Revert r17806 "OvmfPkg: AcpiS3SaveDxe: prepare for End-of-Dxe callback" Requested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17807 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-02OvmfPkg: AcpiS3SaveDxe: prepare for End-of-Dxe callbackLaszlo Ersek
We are preparing for detaching the S3Ready() functionality from the EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() protocol member function. Instead, we will hook the same logic to the End-of-Dxe event group. The EFI_ACPI_S3_SAVE_PROTOCOL has another member: GetLegacyMemorySize(). According to the documenation, This function returns the size of the legacy memory (meaning below 1 MB) that is required during an S3 resume. Before the Framework-based firmware transfers control to the OS, it has to transition from flat mode into real mode in case the OS supplies only a real-mode waking vector. This transition requires a certain amount of legacy memory. After getting the size of legacy memory below, the caller is responsible for allocating the legacy memory below 1 MB according to the size that is returned. The specific implementation of allocating the legacy memory is out of the scope of this specification. When EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() is called, the address of the legacy memory allocated above must be passed to it, in the LegacyMemoryAddress parameter. In practice however: - The S3Ready() function ignores the LegacyMemoryAddress completely. - No code in the edk2 tree calls EFI_ACPI_S3_SAVE_PROTOCOL.GetLegacyMemorySize(), ever. - All callers of this specific implementation of EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() in the edk2 tree pass a NULL LegacyMemoryAddress: BdsLibBootViaBootOption() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c] For this reason, ASSERT() explicitly that LegacyGetS3MemorySize() is never called, and that the LegacyMemoryAddress parameter is always NULL. This fact is important to capture in the code, because in the End-of-Dxe callback, no LegacyMemoryAddress parameter can be taken. So let's make it clear that we actually don't even have any use for that parameter. This patch ports the identical change from IntelFrameworkModulePkg to OvmfPkg. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17806 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-01OvmfPkg: Use the merged Variable driverStar Zeng
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17767 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-01OvmfPkg: Link AuthVariableLib for following merged variable driver deployStar Zeng
AuthVariableLib and TpmMeasurementLib library classes are now linked with MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf to optionally support secure variables. For OvmfPkg, link AuthVariableLib and DxeTpmMeasurementLib in SecurityPkg when SECURE_BOOT_ENABLE = TRUE, and link AuthVariableLibNull and TpmMeasurementLibNull in MdeModulePkg when SECURE_BOOT_ENABLE = FALSE. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17760 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-26OvmfPkg: PlatformPei: invert MTRR setup in QemuInitializeRam()Laszlo Ersek
At the moment we work with a UC default MTRR type, and set three memory ranges to WB: - [0, 640 KB), - [1 MB, LowerMemorySize), - [4 GB, 4 GB + UpperMemorySize). Unfortunately, coverage for the third range can fail with a high likelihood. If the alignment of the base (ie. 4 GB) and the alignment of the size (UpperMemorySize) differ, then MtrrLib creates a series of variable MTRR entries, with power-of-two sized MTRR masks. And, it's really easy to run out of variable MTRR entries, dependent on the alignment difference. This is a problem because a Linux guest will loudly reject any high memory that is not covered my MTRR. So, let's follow the inverse pattern (loosely inspired by SeaBIOS): - flip the MTRR default type to WB, - set [0, 640 KB) to WB -- fixed MTRRs have precedence over the default type and variable MTRRs, so we can't avoid this, - set [640 KB, 1 MB) to UC -- implemented with fixed MTRRs, - set [LowerMemorySize, 4 GB) to UC -- should succeed with variable MTRRs more likely than the other scheme (due to less chaotic alignment differences). Effects of this patch can be observed by setting DEBUG_CACHE (0x00200000) in PcdDebugPrintErrorLevel. Cc: Maoming <maoming.maoming@huawei.com> Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com> Cc: Wei Liu <wei.liu2@citrix.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Maoming <maoming.maoming@huawei.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17722 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-26OvmfPkg: PlatformPei: beautify memory HOB order in QemuInitializeRam()Laszlo Ersek
Build the memory HOBs in a tight block, in increasing base address order. Cc: Maoming <maoming.maoming@huawei.com> Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com> Cc: Wei Liu <wei.liu2@citrix.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Maoming <maoming.maoming@huawei.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17721 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-26OvmfPkg: PlatformPei: create the CPU HOB with dynamic memory space widthLaszlo Ersek
Maoming reported that guest memory sizes equal to or larger than 64GB were not correctly handled by OVMF. Enabling the DEBUG_GCD (0x00100000) bit in PcdDebugPrintErrorLevel, and starting QEMU with 64GB guest RAM size, I found the following error in the OVMF debug log: > GCD:AddMemorySpace(Base=0000000100000000,Length=0000000F40000000) > GcdMemoryType = Reserved > Capabilities = 030000000000000F > Status = Unsupported This message is emitted when the DXE core is initializing the memory space map, processing the "above 4GB" memory resource descriptor HOB that was created by OVMF's QemuInitializeRam() function (see "UpperMemorySize"). The DXE core's call chain fails in: CoreInternalAddMemorySpace() [MdeModulePkg/Core/Dxe/Gcd/Gcd.c] CoreConvertSpace() // // Search for the list of descriptors that cover the range BaseAddress // to BaseAddress+Length // CoreSearchGcdMapEntry() CoreSearchGcdMapEntry() fails because the one entry (with type "nonexistent") in the initial GCD memory space map is too small, and cannot be split to cover the memory space range being added: > GCD:Initial GCD Memory Space Map > GCDMemType Range Capabilities Attributes > ========== ================================= ================ ================ > NonExist 0000000000000000-0000000FFFFFFFFF 0000000000000000 0000000000000000 The size of this initial entry is determined from the CPU HOB (CoreInitializeGcdServices()). Set the SizeOfMemorySpace field in the CPU HOB to mPhysMemAddressWidth, which is the narrowest valid value to cover the entire guest RAM. Reported-by: Maoming <maoming.maoming@huawei.com> Cc: Maoming <maoming.maoming@huawei.com> Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com> Cc: Wei Liu <wei.liu2@citrix.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Wei Liu <wei.liu2@citrix.com> Tested-by: Maoming <maoming.maoming@huawei.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17720 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-26OvmfPkg: PlatformPei: enable larger permanent PEI RAMLaszlo Ersek
We'll soon increase the maximum guest-physical RAM size supported by OVMF. For more RAM, the DXE IPL is going to build more page tables, and for that it's going to need a bigger chunk from the permanent PEI RAM. Otherwise CreateIdentityMappingPageTables() would fail with: > DXE IPL Entry > Loading PEIM at 0x000BFF61000 EntryPoint=0x000BFF61260 DxeCore.efi > Loading DXE CORE at 0x000BFF61000 EntryPoint=0x000BFF61260 > AllocatePages failed: No 0x40201 Pages is available. > There is only left 0x3F1F pages memory resource to be allocated. > ASSERT .../MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c(123): > BigPageAddress != 0 (The above example belongs to the artificially high, maximal address width of 52, clamped by the DXE core to 48. The address width of 48 bits corresponds to 256 TB or RAM, and requires a bit more than 1GB for paging structures.) Cc: Maoming <maoming.maoming@huawei.com> Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com> Cc: Wei Liu <wei.liu2@citrix.com> Cc: Brian J. Johnson <bjohnson@sgi.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Brian J. Johnson <bjohnson@sgi.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17719 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-23OvmfPkg/PlatformDxe: Convert Platform.uni to UTF-8Jordan Justen
This command was used to convert the file: iconv -f UTF-16 -t UTF-8 \ -o OvmfPkg/PlatformDxe/Platform.uni \ OvmfPkg/PlatformDxe/Platform.uni 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: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Yingke Liu <yingke.d.liu@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17700 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-23OvmfPkg: QemuVideoDxe: add virtio-vga supportGerd Hoffmann
Qemu commit c5d4dac ("virtio-vga: add virtio gpu device with vga compatibility") enables OVMF to drive the virtio-vga device: The vga compatibility part of virtio-vga is identical to the qemu standard vga, so supporting that is as easy as adding the PCI ID to the list. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> [lersek@redhat.com: subject fixup and QEMU commit reference in commit msg] Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17690 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-22OvmfPkg: PlatformPei: set SMBIOS entry point version dynamicallyLaszlo Ersek
Git commit 54753b60 (SVN r16870), "MdeModulePkg: Update SMBIOS revision to 3.0." changed PcdSmbiosVersion from 0x0208 to 0x0300. This controls the version number of the SMBIOS entry point table (and other things) that "MdeModulePkg/Universal/SmbiosDxe" installs. Alas, this change breaks older Linux guests, like RHEL-6 (up to RHEL-6.7); those are limited to 2.x (both in the guest kernel firmware driver, and in the dmidecode utility). The SMBIOS 3.0 entry point has a different GUID -- defined in UEFI 2.5 -- pointing to it in the UEFI Configuration Table, and guest kernels that lack upstream kernel commit e1ccbbc9d5 don't recognize it. The v2.1.0+ machine types of QEMU generate SMBIOS payload for the firmware to install. The payload includes the entry point table ("anchor" table). OvmfPkg/SmbiosPlatformDxe cannot install the anchor table (because that is the jurisdiction of the generic "MdeModulePkg/Universal/SmbiosDxe" driver); however, we can parse the entry point version from QEMU's anchor table, and instruct "MdeModulePkg/Universal/SmbiosDxe" to adhere to that version. On machine types older than v2.1.0, the feature is not available, but then, should anything in OVMF install SMBIOS tables, version 2.8 is simply safer / more widely supported than 3.0 -- hence the default 2.8 value for the dynamic PCD. We set the PCD in PlatformPei (when not on the S3 resume path), because that's an easy and certain way to set the PCD before a DXE driver reads it. This follows the example of PcdEmuVariableNvStoreReserved (which is read by EmuVariableFvbRuntimeDxe). RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1232876 Cc: Gabriel Somlo <somlo@cmu.edu> 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> Acked-by: Gabriel Somlo <somlo@cmu.edu> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17676 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-09OvmfPkg/PlatformPei: Initialise RCBA (B0:D31:F0 0xf0) registerPaulo Alcantara
This patch initialises root complex register block BAR in order to support TCO watchdog emulation features (e.g. reboot upon NO_REBOOT bit not set) on QEMU. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paulo Alcantara <pcacjr@zytor.com> Reviewed-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@17601 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-09OvmfPkg/PlatformPei: Query Host Bridge DID only oncePaulo Alcantara
Make HostBridgeDevId global so MemMapInitialization() can also use it to conditionally add RCRB MMIO address to HOB. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paulo Alcantara <pcacjr@zytor.com> Reviewed-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@17600 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-13OvmfPkg: AcpiS3SaveDxe: fix protocol usage hint in the INF fileLaszlo Ersek
SVN r15305 (git 5a217a06), "OvmfPkg: S3 Suspend: save boot script after ACPI context", made this driver install gEfiDxeSmmReadyToLockProtocolGuid in SaveS3BootScript() -- for valid reasons --, however in the INF file the protocol was marked as "ALWAYS_CONSUMED". Fix 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@17437 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-13OvmfPkg: extract some bits and port offsets common to Q35 and I440FXLaszlo Ersek
The PMBA_RTE and ACPI_TIMER_OFFSET macros apply equally to both boards, plus they are triplicated between the various AcpiTimerLib instances. Define them centrally in "OvmfPlatforms.h". Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17436 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-13OvmfPkg: consolidate POWER_MGMT_REGISTER_PIIX4() on "I440FxPiix4.h" macrosLaszlo Ersek
All POWER_MGMT_REGISTER_PIIX4() macro invocations in OvmfPkg should use the macros in "I440FxPiix4.h" as arguments. Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17435 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-13OvmfPkg: consolidate POWER_MGMT_REGISTER_Q35() on "Q35MchIch9.h" macrosLaszlo Ersek
All POWER_MGMT_REGISTER_Q35() macro invocations in OvmfPkg should use the macros in "Q35MchIch9.h" as arguments. Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17434 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-13OvmfPkg: new macros for platform specific register addresses and valuesLaszlo Ersek
Define some new macros for register addresses (both PCI and IO) and register values (bits) that we're going to use soon. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17433 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-13OvmfPkg: split Include/OvmfPlatforms.hLaszlo Ersek
Move platform specific macros to their own include files. 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@17432 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-08OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI bridgesLaszlo Ersek
When the Q35 machine type(s) of QEMU are used with libvirt, libvirt tends to place some devices behind PCI bridges. This is then reflected in the "bootorder" fw_cfg file. For example: /pci@i0cf8/pci-bridge@1e/pci-bridge@1/scsi@5/disk@0,0 /pci@i0cf8/pci-bridge@1e/pci-bridge@1/scsi@3/channel@0/disk@0,0 As yet QemuBootOrderLib doesn't support such OFW device paths. Add code that translates a sequence of pci-bridge nodes. In practice libvirt seems to insert two such nodes (*), hence increment EXAMINED_OFW_NODES with the same number. (* Background, paraphrasing Laine Stump's words: When the machine type is Q35, we create a dmi-to-pci bridge coming off of the pcie root controller, and a pci-to-pci bridge coming off of that, then attach most devices to the pci-to-pci bridge. This is done because you can't hotplug into pcie-root, can't (or at least shouldn't) plug a pci-to-pci bridge into pcie-root (so the next one has to be dmi-to-pci-bridge), and can't hotplug into dmi-to-pci-bridge (so you need to have a pci-to-pci bridge).) 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@17385 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-06OvmfPkg: Use the new PCDs defined in MdePkg and MdeModulePkg.Ruiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17318 6f19259b-4bc3-4df7-8a09-765794883524
2015-04-01OvmfPkg/XenBusDxe: Fix build issue with VS2010Jordan Justen
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@17091 6f19259b-4bc3-4df7-8a09-765794883524
2015-04-01OvmfPkg/SmbiosPlatformDxe: Fix build issue with VS2010Jordan Justen
VS2010 doesn't accept an unsized array within a structure. 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@17090 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-27OvmfPkg: XenConsoleSerialPortLib: deal with output overflowArd Biesheuvel
It is the responsibility of the SerialPortLib implementation to deal with flow control if the underlying medium cannot keep up with the inflow of data. So in our SerialPortWrite () function, we should spin as long as we need to in order to deliver all the data instead of giving up and returning a smaller value than the number of bytes we were given. Also, remove the 'if (Sent > 0)' condition on the signalling of the event channel: if the buffer is full and we haven't been able to add any more data, it makes perfect sense to signal the event channel again, even if we have done so before when we did write the data. Also, this patch brings the implementation of XenSerialPortLib in sync with the library class documentation. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: replace DebugLib dependency with open-coded ASSERT()] git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17079 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-26OvmfPkg: Q35: Use correct ACPI PM control register:bitGabriel Somlo
On PIIX4, function 3, the PMREGMISC register at offset 0x80, with default value 0x00 has its bit 0 (PMIOSE) indicate whether the PM IO space given in the PMBA register (offset 0x40) is enabled. PMBA must be configured *before* setting this bit. On Q35/ICH9+, function 0x1f, the equivalent role is fulfilled by bit 7 (ACPI_EN) in the ACPI Control Register (ACPI_CNTL) at offset 0x44, also with a default value of 0x00. Currently, OVMF hangs when Q35 reboots, because while PMBA is reset by QEMU, the register at offset 0x80 (matching PMREGMISC on PIIX4) is not reset, since it has a completely different meaning on LPC. As such, the power management initialization logic in OVMF finds the "PMIOSE" bit enabled after a reboot and decides to skip setting PMBA. This causes the ACPI timer tick routine to read a constant value from the wrong register, which in turn causes the ACPI delay loop to hang indefinitely. This patch modifies the Base[Rom]AcpiTimerLib constructors and the PlatformPei ACPI PM init routines to use ACPI_CNTL:ACPI_EN instead of PMREGMISC:PMIOSE when running on Q35. Reported-by: Reza Jelveh <reza.jelveh@tuhh.de> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17076 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-16OvmfPkg: include XHCI driverLaszlo Ersek
QEMU commit aa685789 ("xhci: generate a Transfer Event for each Transfer TRB with the IOC bit set") fixed an emulation problem in QEMU; we can now drive that host controller with edk2's XhciDxe. Include it in OvmfPkg, as XHCI emulation is reportedly more virtualization-friendly than EHCI, consuming less CPU. The driver can be tested with the following QEMU command line options: -device nec-usb-xhci -device usb-kbd This patch should not regress existing QEMU command lines (ie. trigger an ASSERT() in XhciDxe that fails on pre-aa685789 QEMU) because QEMU's "-device nec-usb-xhci" has never before resulted in USB devices that worked with edk2 firmware builds, hence users have never had a reason to add that option. Now that they learn about XHCI support in OVMF by reading this commit message, they (or their packagers) will also know to update qemu to aa685789 or later (in practice that means the upcoming 2.3 release), at least if they want to use '-device nec-usb-xhci' with edk2, for the first time ever. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Alexander Graf <agraf@suse.de> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17055 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-03OvmfPkg: replace strict XenHypercallLib construction with explicit queryLaszlo Ersek
XenHypercallLib has two clients at the moment: XenBusDxe and XenConsoleSerialPortLib. Currently, when XenBusDxe starts on a non-Xen X86 platform (ie. as part of OVMF not running on Xen), the X86XenHypercallLib instance built into it fails to initialize, which triggers an ASSERT() in auto-generated code. Instead, let's call XenHypercallIsAvailable() in the driver's entry point, and exit cleanly when the driver is started on a non-Xen platform. Modify the constructor of XenConsoleSerialPortLib similarly; we shouldn't proceed if Xen is not available. In practice this check should never fail, because XenConsoleSerialPortLib is only used on ARM, and ArmXenHypercallLib is always available; but nonetheless we should be pedantic. Reported-by: Gabriel L. Somlo <gsomlo@gmail.com> Suggested-by: 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> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17001 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-03OvmfPkg: XenHypercallLib: introduce XenHypercallIsAvailable()Laszlo Ersek
Similarly to QemuFwCfgLib, we prefer mellow library construction code and an explicit "are you available" query function in the XenHypercallLib class. In this step we introduce that query function, but move no client code to it yet. Suggested-by: 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> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17000 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-03OvmfPkg: XenHypercallLib: add empty constructor for ARM & AARCH64Laszlo Ersek
In the next patch we'll add a simple query function to the XenHypercallLib library class that is supposed to be called by initialization code in modules. Among those, in constructors of dependent libraries too. Library construction ordering is ensured only between libraries with constructors, plus we shouldn't allow a dependent library with a constructor to call into any XenHypercallLib instances (the simple query function) before XenHypercallLib is constructed itself. For this reason, introduce an (empty) constructor for ARM & AARCH64 too. 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: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16999 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-03OvmfPkg, ArmVirtualizationPkg: clean up XenHypercallLib namesLaszlo Ersek
Perform the following renames in order to stick with edk2 tradition more closely: XenHypercallLibArm, XenHypercallLibIntel -> XenHypercallLib XenHypercallIntel -> X86XenHypercall In addition, we unify the INF files. This patch modifies ArmVirtualizationPkg and OvmfPkg at once, in order to keep both bisectable (client code shouldn't break). Suggested-by: 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> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16998 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28ArmVirtualizationPkg: add XenIoMmioLibArd Biesheuvel
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-28Ovfm/Xen: add a Vendor Hardware device path GUID for the XenBus rootArd Biesheuvel
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
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-16 12:53:49 +0000