summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/Library/QemuBootOrderLib
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: replace old EFI_D_ debug levels with new DEBUG_ onesRebecca Cran2020-04-301-1/+1
| | | | | | | | | | | | | Generated mechanically with: find OvmfPkg -type f -exec sed -i -e 's/EFI_D_/DEBUG_/g' {} \; Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200429215327.606467-1-rebecca@bsdio.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Qemu: Fix various typosAntoine Coeur2020-02-101-1/+1
| | | | | | | | | | | | | | | | | | | | Fix various typos in comments and documentation. When "VbeShim.asm" is modified, we have to re-run "VbeShim.sh" to update "VbeShim.h". The string modified by this patch is only used when the DEBUG macro (at the top of the file) is commented out. Since the string is not referenced, NASM eliminates it, resulting in the same byte array content in "VbeShim.h". Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-58-philmd@redhat.com>
* OvmfPkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-094-29/+4
| | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Removing ipf which is no longer supported from edk2.chenc22018-06-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Removing rules for Ipf sources file: * Remove the source file which path with "ipf" and also listed in [Sources.IPF] section of INF file. * Remove the source file which listed in [Components.IPF] section of DSC file and not listed in any other [Components] section. * Remove the embedded Ipf code for MDE_CPU_IPF. Removing rules for Inf file: * Remove IPF from VALID_ARCHITECTURES comments. * Remove DXE_SAL_DRIVER from LIBRARY_CLASS in [Defines] section. * Remove the INF which only listed in [Components.IPF] section in DSC. * Remove statements from [BuildOptions] that provide IPF specific flags. * Remove any IPF sepcific sections. Removing rules for Dec file: * Remove [Includes.IPF] section from Dec. Removing rules for Dsc file: * Remove IPF from SUPPORTED_ARCHITECTURES in [Defines] section of DSC. * Remove any IPF specific sections. * Remove statements from [BuildOptions] that provide IPF specific flags. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chen A Chen <chen.a.chen@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/QemuBootOrderLib: add ConnectDevicesFromQemu()Laszlo Ersek2018-03-141-2/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QemuBootOrderLib expects PlatformBootManagerLib to call the following triplet: (1) EfiBootManagerConnectAll(), (2) EfiBootManagerRefreshAllBootOption(), (3) SetBootOrderFromQemu(). This leads to bad performance, when many devices exist such that the firmware can drive them, but they aren't marked for booting in the "bootorder" fw_cfg file. Namely, (1) EfiBootManagerConnectAll() talks to all hardware, which takes long. Plus some DriverBindingStart() functions write NV variables, which is also slow. (For example, the IP config policy for each NIC is stored in an NV var that is named after the MAC). (2) EfiBootManagerRefreshAllBootOption() generates boot options from the protocol instances produced by (1). Writing boot options is slow. (3) Under the above circumstances, SetBootOrderFromQemu() removes most of the boot options produced by (2). Erasing boot options is slow. Introduce ConnectDevicesFromQemu() as a replacement for (1): only connect devices that the QEMU user actually wants to boot off of. (There's a slight loss of compatibility when a platform switches from EfiBootManagerConnectAll() to ConnectDevicesFromQemu(). EfiBootManagerConnectAll() may produce UEFI device paths that are unknown to QemuBootOrderLib (that is, for neither PCI- nor virtio-mmio-based devices). The BootOrderComplete() function lets such unmatched boot options survive at the end of the boot order. With ConnectDevicesFromQemu(), these options will not be auto-generated in the first place. They may still be produced by other means. SetBootOrderFromQemu() is not modified in any way; reordering+filtering boot options remains a separate task.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: Xiang Zheng <xiang.zheng@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
* OvmfPkg/QemuBootOrderLib: clean up translation of virtio-net over MMIOLaszlo Ersek2018-03-141-3/+3
| | | | | | | | | | | | | | | | | | | | The "/MAC(" suffix of the translated UEFI devpath prefix is unnecessary for matching, because the virtio-mmio base address in VenHwString is unique anyway. Furthermore, the partial string "MAC(" cannot be processed by ConvertTextToDevicePath(), which will become relevant later in this series. Remove "/MAC(". While at it, remove a bogus comment on PCI. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: Xiang Zheng <xiang.zheng@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
* OvmfPkg/QemuBootOrderLib: add missing EFIAPI specifiersLaszlo Ersek2018-03-141-0/+2
| | | | | | | | | | | | | | Public library APIs should be declared as EFIAPI. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: Xiang Zheng <xiang.zheng@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
* OvmfPkg/QemuBootOrderLib: wrap overlong lineLaszlo Ersek2018-03-141-1/+2
| | | | | | | | | | | | | | 81 characters is too many. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: Xiang Zheng <xiang.zheng@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
* OvmfPkg/QemuBootOrderLib: list "ExtraRootBusMap.h" in the INF fileLaszlo Ersek2018-03-131-0/+1
| | | | | | | | | | | | | | | The header file declares the CreateExtraRootBusMap(), DestroyExtraRootBusMap(), and MapRootBusPosToBusNr() functions. They are defined in "ExtraRootBusMap.c", and called from "QemuBootOrderLib.c". Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Michael Kinney <michael.d.kinney@intel.com> Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/QemuBootOrderLib: sort [Sources*] sections in the INF fileLaszlo Ersek2018-03-131-1/+1
| | | | | | | | | | | This makes it easier to insert future source files. No functional changes. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/QemuBootOrderLib: let an OFW devpath match multiple UEFI boot optsLaszlo Ersek2017-11-281-1/+0
| | | | | | | | | | | | | | | | | | | | | This means that SetBootOrderFromQemu() will preserve all UEFI boot options matched by any given OFW devpath, such as PXEv4, HTTPv4, PXEv6 and HTTPv6 boot options for the same NIC. Currently we stop the matching / appending for the OFW devpath coming from the outer loop whenever we find the first UEFI boot option match in the inner loop. (The previous patch was about multiple OFW devpaths matching a single UEFI boot option (which should never happen). This patch is about a single OFW devpath matching multiple UEFI boot options. With the "break" statement removed here, the small optimization from the last patch becomes a bit more relevant, because now the inner loop always counts up to ActiveCount.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/QemuBootOrderLib: skip already matched / appended UEFI boot optsLaszlo Ersek2017-11-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The SetBootOrderFromQemu() function implements a nested loop where - the outer loop iterates over all OpenFirmware (OFW) device paths in the QEMU boot order, and translates each to a UEFI device path prefix; - the inner loop matches the current (translated) prefix against all active UEFI boot options in turn; - if the UEFI boot option is matched by the translated prefix, the UEFI boot option is appended to the "new" UEFI boot order, and marked as "has been appended". This patch adds a micro-optimization where already matched / appended UEFI boot options are skipped in the inner loop. This is not a functional change. A functional change would be if, as a consequence of the patch, some UEFI boot options would no longer be *doubly* matched. For a UEFI boot option to be matched by two translated prefixes, one of those prefixes would have to be a (proper, or equal) prefix of the other prefix. The PCI and MMIO OFW translation routines output such only in the following cases: - When the original OFW device paths are prefixes of each other. This is not possible from the QEMU side. (Only leaf devices are bootable.) - When the translation rules in the routines are incomplete, and don't look at the OFW device paths for sufficient length (i.e., at nodes where they would already differ, and the difference would show up in the translation output). This would be a shortcoming of the translation routines and should be fixed in TranslatePciOfwNodes() and TranslateMmioOfwNodes(), whenever identified. Even in the second case, this patch would replace the double appending of a single UEFI boot option (matched by two different OFW device paths) with a correct, or cross-, matching of two different UEFI boot options. Again, this is not expected, but arguably it would be more correct than duplicate boot option appending, should it occur due to any (unexpected, unknown) lack of detail in the translation routines. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/QemuBootOrderLib: recognize "usb-storage" devices in XHCI portsLaszlo Ersek2017-09-221-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The feature is primarily useful for modern AARCH64 guests that have no built-in virtio block / SCSI drivers; as on "qemu-system-aarch64 -M virt", there are no IDE or AHCI controllers that could be used as fallback. XHCI is available in "-M virt" however, and because XHCI predates AARCH64 by several years, said guests are expected to have built-in drivers for it. Other device models ("usb-uas", "usb-bot") are out of scope for now, similarly to USB1.x (UHCI) and USB2 (EHCI) host controllers, and similarly to USB hubs (which are USB1.1 only). In particular, port mapping between EHCI and companion UHCI controllers is very complex; it even leads to PCI slot/function differences between the OpenFirmware device paths exported by QEMU and the the UEFI device paths generated by edk2. The number of ports on the XHCI controller defaults to 4, but it can be raised via the "p3" property to 15. In addition, several XHCI controllers can be grouped into a single-slot, multi-function PCI device. These allow for a good number of usb-storage devices, while their desired boot order remains recognizable to this patch. In the example below, we create two XHCI controllers, grouped into PCI slot 00:02 as functions 0 and 1. Both controllers are given 15 ports. We attach a "usb-storage" device to controller 1 at port 3 (ports are 1-based in QEMU, 0-based in edk2), and attach another "usb-storage" device to controller 2 at port 9. QEMU command line options (NB. they apply equally to aarch64/virt and x86_64/{i440fx,q35}): -device qemu-xhci,id=xhci1,p3=15,addr=02.0,multifunction=on \ -device qemu-xhci,id=xhci2,p3=15,addr=02.1 \ \ -drive id=disk1,if=none,format=qcow2,$DISK1_OPTIONS \ -drive id=disk2,if=none,format=qcow2,$DISK2_OPTIONS \ \ -device usb-storage,drive=disk1,bus=xhci1.0,port=3,bootindex=1 \ -device usb-storage,drive=disk2,bus=xhci2.0,port=9,bootindex=2 \ Libvirt domain XML fragment: <controller type='usb' index='1' model='qemu-xhci' ports='15'> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='2' model='qemu-xhci' ports='15'> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> </controller> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='...'/> <target dev='sda' bus='usb'/> <boot order='1'/> <address type='usb' bus='1' port='3'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='...'/> <target dev='sdb' bus='usb'/> <boot order='2'/> <address type='usb' bus='2' port='9'/> </disk> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/QemuBootOrderLib: Fix NOOPT build failureDandan Bi2017-02-101-1/+1
| | | | | | | | | | | | | | | | | | | | | This patch is to fix the IA32/NOOPT/VS Toolchain build failure. The VS2015 failure log as below: QemuBootOrderLib.lib(ExtraRootBusMap.obj) : error LNK2001: unresolved external symbol __allmul s:\..\Build\OvmfIa32\NOOPT_VS2015\IA32\MdeModulePkg\ Universal\BdsDxe\BdsDxe\DEBUG\BdsDxe.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 14.0\Vc\bin\link.exe"' : return code '0x460' Stop. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/QemuBootOrderLib: rebase to ARRAY_SIZE()Laszlo Ersek2016-10-271-6/+6
| | | | | | | 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>
* OvmfPkg/QemuBootOrderLib: drop too strict "/HD(" suffix from vblk prefixLaszlo Ersek2016-09-081-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Translating QEMU's virtio-block OpenFirmware device path to a UEFI device path prefix was one of the earliest case handled in QemuBootOrderLib. At that time, I terminated the translation output (the UEFI devpath prefix) with a "/HD(" suffix. The intent was for the translation to prefix-match only boot options with HD() device path nodes in them, that is, no auto-generated "device level" boot options. This was motivated by prioritizing specific boot options created by OS installers over auto-generated "device level" options. However, practice has shown that: - OS installers place their installed boot options first in the boot order anyway, - other device types (SATA disks, virtio-scsi disks), where "/HD(" is not appended, work just fine, - requiring "/HD(" actually causes problems: after the OS-installed specific boot option has been lost (or purposely removed), the auto-generated "device level" boot option does the right thing (see the Default Boot Behavior under <http://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/>). The "/HD(" requirement causes such boot options to be dropped, which prevents "fallback.efi" from running. Relax the matching by removing the "/HD(" suffix from the translated prefix. Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: e06a4cd134064590aa1a855ff4b973023279e805 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1373812 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg, ArmVirtPkg: rename QemuNewBootOrderLib to QemuBootOrderLibLaszlo Ersek2016-05-254-0/+2365
| | | | | | | | | | | | | | | This completes the transition to the new BDS. The FILE_GUID in "QemuBootOrderLib.inf" is intentionally not changed. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: remove QemuBootOrderLib instanceLaszlo Ersek2016-05-254-2312/+0
| | | | | | | | | | | | This library instance is no longer referenced. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@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>
* OvmfPkg/QemuBootOrderLib: adapt Q35 SATA PMPN to UEFI spec Mantis 1353Laszlo Ersek2016-05-121-5/+5
| | | | | | | | | | | | | | | | | | | | | On the Q35 machine type of QEMU, there is no port multiplier connected to the on-board SATA controller. Therefore the AtaAtapiPassThru driver update for Mantis ticket 1353 <https://mantis.uefi.org/mantis/view.php?id=1353> changes the middle number (the Port Multiplier Port Number) in the Sata() device path nodes from 0x0 to 0xFFFF. Adapt the translation from OpenFirmware in QemuBootOrderLib. (Note: QemuBootOrderLib is deprecated at this point (see USE_OLD_BDS in the DSC files), but until we remove it, it should be kept in sync with QemuNewBootOrderLib.) Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
* OvmfPkg: QemuBootOrderLib: recognize NVMe devicesLaszlo Ersek2016-02-021-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | This patch enables QemuBootOrderLib to parse OFW device paths formatted by QEMU commit a907ec52cc1a: nvme: generate OpenFirmware device path in the "bootorder" fw_cfg file With both patches applied, OVMF will honor the bootindex=N property of the NVMe device: -drive id=drive0,if=none,format=FORMAT,file=PATHNAME \ -device nvme,drive=drive0,serial=SERIAL,bootindex=N ^^^^^^^^^^^ Cc: Vladislav Vovchenko <vladislav.vovchenko@sk.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Reference: https://github.com/tianocore/edk2/issues/48 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: Vladislav Vovchenko <vladislav.vovchenko@sk.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19792 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuBootOrderLib: recognize Q35 SATA disks / CD-ROMsLaszlo Ersek2015-09-221-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OpenFirmware device paths that QEMU generates for these disks and CD-ROMs are very similar to those generated for the i440fx IDE disks and CD-ROMs (including the same number of devpath nodes necessary for unique parsing). The interpretations and the translation to UEFI devpath fragments are different, of course. (The spaces after "ide@1,1" are inserted below only for illustration purposes.) primary or secondary | master or slave v v i440fx IDE: /pci@i0cf8/ide@1,1 /drive@0/disk@0 Q35 SATA: /pci@i0cf8/pci8086,2922@1f,2/drive@1/disk@0 ^ ^ | device number | (fixed 0) channel (port) number The similarity is reflected in the translation output (spaces again inserted for illustration only): i440fx IDE: PciRoot(0x0)/Pci(0x1,0x1) /Ata(Primary,Master,0x0) Q35 SATA: PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0) ^ ^ ^ | | LUN; | | always 0 on Q35 | port multiplier port | number; always 0 on Q35 channel (port) number Cc: Alexander Graf <agraf@suse.de> Cc: Reza Jelveh <reza.jelveh@tuhh.de> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Gabriel L. Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> 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@18531 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuBootOrderLib: recognize extra PCI root busesLaszlo Ersek2015-07-141-24/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OFW device path that QEMU exports in the "bootorder" fw_cfg file, for a device that is plugged into the main PCI root bus, is: /pci@i0cf8/... Whereas the same device plugged into the N'th extra root bus results in: /pci@i0cf8,N/pci-bridge@0/... (N is in hex.) Extend TranslatePciOfwNodes() so that it not assume a single PCI root; instead it parse the extra root bus serial number if present, and resolve it in the translation to the UEFI devpath fragment. Note that the "pci-bridge@0" node is a characteristic of QEMU's PXB device. It reflects the actual emulated PCI hierarchy. We don't parse it specifically in this patch, because it is automatically handled by the bridge sequence translator added recently in SVN rev 17385 (git commit feca17fa4b) -- "OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI bridges". The macro EXAMINED_OFW_NODES need not be raised from 6. The longest OFW device paths that we wish to recognize under this new scheme comprise 5 nodes. The initial "extra root bus" OFW fragment, visible at the top, takes up 2 nodes, after which the longest device-specific patterns (IDE disk, IDE CD-ROM, ISA floppy, virtio-scsi disk) take 3 more nodes each. 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@17965 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuBootOrderLib: introduce ExtraRootBusMapLaszlo Ersek2015-07-143-0/+359
| | | | | | | | | | | | | | | | | | | | | | 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
* OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI bridgesLaszlo Ersek2015-05-081-26/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* OvmfPkg: Use the new PCDs defined in MdePkg and MdeModulePkg.Ruiyu Ni2015-05-061-2/+2
| | | | | | | | 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
* OvmfPkg: QemuBootOrderLib: expose QEMU's "-boot menu=on[,splash-time=N]"Laszlo Ersek2015-01-142-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The QEMU command line option -boot menu=on is meant to have the guest firmware wait for a firmware-specific interval for the user to enter the boot menu. During the wait, the user can opt to enter the boot menu, or interrupt the wait and proceed to booting at once. If the wait interval elapses, the firmware should boot as it normally would. The QEMU command line option -boot menu=on,splash-time=N means the same, except the firmware should wait for cca. N milliseconds instead of a firmware-specific interval. We can approximate this behavior quite well for edk2's virtual platforms because the Intel BDS front page already supports a progress bar, with semantics similar to the above. Let's distill the fw_cfg bits underlying "-boot menu=on,splash-time=N" for the BDS policies, in the form of a timeout value they can pass to Intel's PlatformBdsEnterFrontPage(). If the boot menu is not requested, we return "gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut", which is what the virtual platforms use right now. If the boot menu is requested without specifying the timeout, we return the same PCD, unless it would cause us to skip the boot menu at once. In the latter case, we return 3 seconds (as an approximation of the 2500 ms SeaBIOS default.) RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1170507 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: Olivier Martin <Olivier.martin@arm.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16610 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuBootOrderLib: OFW-to-UEFI translation for virtio-mmioLaszlo Ersek2015-01-022-1/+200
| | | | | | | | | | | | | | | | | | | | 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
* OvmfPkg: QemuBootOrderLib: widen ParseUnitAddressHexList() to UINT64Laszlo Ersek2015-01-021-15/+15
| | | | | | | | | | | | | | | The OpenFirmware device path nodes that QEMU generates for virtio-mmio transports contain 64-bit hexadecimal values (16 nibbles) -- the base addresses of the register blocks. In order to parse them soon, ParseUnitAddressHexList() must parse UINT64 values. Call sites need to be adapted, as expected. 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@16574 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuBootOrderLib: featurize PCI-like device path translationLaszlo Ersek2015-01-022-7/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* OvmfPkg: extract QemuBootOrderLibLaszlo Ersek2015-01-022-0/+1376
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
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-29 11:38:41 +0000