summaryrefslogtreecommitdiffstats
path: root/src/interface/efi/efi_block.c
Commit message (Collapse)AuthorAgeFilesLines
* [efi] Release SNP devices before starting SAN boot imageMichael Brown2018-03-261-0/+4
| | | | | | | | Release SNP devices to allow the SAN booted image to use our EFI_SIMPLE_NETWORK_PROTOCOL instance, and to ensure that the image is started at TPL_APPLICATION. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [block] Provide sandev_read() and sandev_write() as global symbolsMichael Brown2017-04-261-9/+8Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [block] Allow use of a non-default EFI SAN boot filenameMichael Brown2017-04-121-6/+16
| | | | | | | | | | | | | | | | | | | | | | | Some older operating systems (e.g. RHEL6) use a non-default filename on the root disk and rely on setting an EFI variable to point to the bootloader. This does not work when performing a SAN boot on a machine where the EFI variable is not present. Fix by allowing a non-default filename to be specified via the "sanboot --filename" option or the "san-filename" setting. For example: sanboot --filename \efi\redhat\grub.efi \ iscsi:192.168.0.1::::iqn.2010-04.org.ipxe.demo:rhel6 or option ipxe.san-filename code 188 = string; option ipxe.san-filename "\\efi\\redhat\\grub.efi"; option root-path "iscsi:192.168.0.1::::iqn.2010-04.org.ipxe.demo:rhel6"; Originally-implemented-by: Vishvananda Ishaya Abrams <vish.ishaya@oracle.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [block] Describe all SAN devices via ACPI tablesMichael Brown2017-03-281-64/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Describe all SAN devices via ACPI tables such as the iBFT. For tables that can describe only a single device (i.e. the aBFT and sBFT), one table is installed per device. For multi-device tables (i.e. the iBFT), all devices are described in a single table. An underlying SAN device connection may be closed at the time that we need to construct an ACPI table. We therefore introduce the concept of an "ACPI descriptor" which enables the SAN boot code to maintain an opaque pointer to the underlying object, and an "ACPI model" which can build tables from a list of such descriptors. This separates the lifecycles of ACPI descriptions from the lifecycles of the block device interfaces, and allows for construction of the ACPI tables even if the block device interface has been closed. For a multipath SAN device, iPXE will wait until sufficient information is available to describe all devices but will not wait for all paths to connect successfully. For example: with a multipath iSCSI boot iPXE will wait until at least one path has become available and name resolution has completed on all other paths. We do this since the iBFT has to include IP addresses rather than DNS names. We will commence booting without waiting for the inactive paths to either become available or close; this avoids unnecessary boot delays. Note that the Linux kernel will refuse to accept an iBFT with more than two NIC or target structures. We therefore describe only the NICs that are actually required in order to reach the described targets. Any iBFT with at most two targets is therefore guaranteed to describe at most two NICs. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [block] Add basic multipath supportMichael Brown2017-03-261-6/+19
| | | | | | | | | | | Add basic support for multipath block devices. The "sanboot" and "sanhook" commands now accept a list of SAN URIs. We open all URIs concurrently. The first connection to become available for issuing block device commands is marked as the active path and used for all subsequent commands; all other connections are then closed. Whenever the active path fails, we reopen all URIs and repeat the process. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide ACPI table description for SAN devicesMichael Brown2017-03-131-0/+69
| | | | | | | | | Provide a basic proof of concept ACPI table description (e.g. iBFT for iSCSI) for SAN devices in a UEFI environment, using a control flow that is functionally identical to that used in a BIOS environment. Originally-implemented-by: Vishvananda Ishaya Abrams <vish.ishaya@oracle.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Refactor to use centralised SAN device abstractionMichael Brown2017-03-071-650/+161Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [block] Centralise "san-drive" settingMichael Brown2017-03-071-1/+0Star
| | | | | | | | | | | | The concept of the SAN drive number is meaningful only in a BIOS environment, where it represents the INT13 drive number (0x80 for the first hard disk). We retain this concept in a UEFI environment to allow for a simple way for iPXE commands to refer to SAN drives. Centralise the concept of the default drive number, since it is shared between all supported environments. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add basic EFI SAN booting capabilityMichael Brown2016-11-171-0/+1062
Signed-off-by: Michael Brown <mcb30@ipxe.org>