summaryrefslogtreecommitdiffstats
path: root/src/arch/i386
Commit message (Collapse)AuthorAgeFilesLines
...
* [undi] Apply quota only to number of complete received packetsMichael Brown2014-05-141-4/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [lkrnprefix] Function as a bzImage kernelMichael Brown2014-05-131-132/+83Star
| | | | | | | | | | | | | | | | | | | | The .lkrn prefix currently provides a zImage kernel with unused setup sectors and the whole iPXE binary placed within the "protected mode kernel" portion of the zImage. The work carried out years ago to create the .mrom format provides a mechanism allowing the iPXE binary to be split into a small real-mode header and a larger payload. This neatly matches the way that a bzImage is loaded: the "setup sectors" can contain the header and the "protected mode kernel" can contain the payload. This removes the size restrictions on an iPXE .lkrn image (and hence on derived image formats such as .iso). Also remove obsolete copyright information, since none of the original code or functionality now remains. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [profile] Allow interrupts to be excluded from profiling resultsMichael Brown2014-05-042-5/+32
| | | | | | | | | Interrupt processing adds noise to profiling results. Allow interrupts (from within protected mode) to be profiled separately, with time spent within the interrupt handler being excluded from any other profiling currently in progress. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [undi] Place an upper limit on the number of PXENV_UNDI_ISR calls per pollMichael Brown2014-05-031-1/+5
| | | | | | | | | PXENV_UNDI_ISR calls may implicitly refill the underlying receive ring, and so could continue to retrieve packets indefinitely. Place an upper limit on the number of calls to PXENV_UNDI_ISR per call to undinet_poll(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [undi] Do not switch to real mode to check for NIC interruptMichael Brown2014-05-031-4/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [undi] Report any PXENV_UNDI_ISR errors via netdev_rx_err()Michael Brown2014-05-031-1/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [undi] Profile transmit and receive datapathsMichael Brown2014-05-031-1/+33
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [undi] Profile all PXE API callsMichael Brown2014-05-031-6/+97
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pxe] Work around missing PXENV_UNDI_OPEN only when necessaryMichael Brown2014-05-031-2/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pxe] Profile UNDI transmit datapathMichael Brown2014-05-031-0/+8
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pxe] Profile all PXE API callsMichael Brown2014-05-031-0/+49
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Add profiling self-tests for complete real_call and prot_call cyclesMichael Brown2014-05-031-0/+38
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [profile] Provide methods for profiling individual stages of operationsMichael Brown2014-05-031-4/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Speed up protected-mode calls under KVMMichael Brown2014-05-021-19/+35
| | | | | | | | | | | | | When making a call from real mode to protected mode, we save and restore the global and interrupt descriptor table registers. The restore currently takes place after returning to real mode, which generates two EXCEPTION_NMIs and corresponding VM exits when running under KVM on an Intel CPU. Avoid the VM exits by restoring the descriptor table registers inside prot_to_real, while still running in protected mode. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Speed up real-to-protected mode transition under KVMMichael Brown2014-05-023-5/+22
| | | | | | | | | | | | | | | Ensure that all segment registers have zero in the low two bits before transitioning to protected mode. This allows the CPU state to immediately be deemed to be "valid", and eliminates the need for any further emulated instructions. Load the protected-mode interrupt descriptor table after switching to protected mode, since this avoids triggering an EXCEPTION_NMI and corresponding VM exit. This reduces the time taken by real_to_prot under KVM by around 50%. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Speed up protected-to-real mode transition under KVMMichael Brown2014-05-022-22/+20Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | On an Intel CPU supporting VMX, KVM will emulate instructions while the CPU state remains "invalid". In real mode, the CPU state is defined to be "invalid" if any segment register has a base which is not equal to (sreg<<4) or a limit which is not equal to 64kB. We don't actually use the base stored in the REAL_DS descriptor for any significant purpose. Change the base stored in this descriptor to be equal to (REAL_DS<<4). A segment register loaded with REAL_DS is then automatically valid in both real and protected modes. This allows KVM to stop emulating instructions much sooner. The only use of REAL_DS for memory accesses currently occurs in the indirect ljmp within prot_to_real. Change this to a direct ljmp, storing rm_cs in .text16 as part of the ljmp instruction. This removes the only memory access via REAL_DS (thereby allowing for the above descriptor base address hack), and also simplifies the ljmp instruction (which will still have to be emulated). Load the real-mode interrupt descriptor table register before switching to real mode, since this avoids triggering an EXCEPTION_NMI and corresponding VM exit. This reduces the time taken by prot_to_real under KVM by around 65%. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Add meaningful labels at section changesMichael Brown2014-05-021-12/+12
| | | | | | | | | | | | | The mode-transition code involves paths which switch back and forth between the .text and .text16 sections. At present, only the start of each function is labelled, which makes it difficult to decode addresses within the parts of the function existing in a different section. Add explicit labels at the start of each section change, so that addresses can be meaningfully decoded to the nearest label. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Add a profiling self-test for measuring mode transition timesMichael Brown2014-05-021-0/+77
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pcbios] Do not switch to real mode to sleep the CPUMichael Brown2014-04-291-3/+3
| | | | | | | Now that we can handle interrupts while in protected mode, there is no need to switch to real mode just to halt the CPU. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pcbios] Do not switch to real mode to check for timer interruptMichael Brown2014-04-291-4/+4
| | | | | | | | | | | | | The currticks() function is called at least once per TCP packet, and so is performance-critical. Switching to real mode just to allow the timer interrupt to fire is expensive when running inside a virtual machine, and imposes a significant performance cost. Fix by enabling interrupts without switching to real mode. This results in an approximately 100% increase in download speed when running under KVM. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [comboot] Use built-in interrupt reflectorMichael Brown2014-04-294-134/+6Star
| | | | | | | | We now have the ability to handle interrupts while in protected mode, and so no longer need to set up a dedicated interrupt descriptor table while running COM32 executables. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Allow interrupts in protected modeMichael Brown2014-04-297-135/+319
| | | | | | | | When running in a virtual machine, switching to real mode may be expensive. Allow interrupts to be enabled while in protected mode and reflected down to the real-mode interrupt handlers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Use genuine real mode to accelerate operation in virtual machinesMichael Brown2014-04-282-5/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use flat real mode wherever real mode is required. This guarantees that we will not surprise some unsuspecting external caller which has carefully set up flat real mode by suddenly reducing the segment limits to 64kB. However, operating in flat real mode imposes a severe performance penalty in some virtualisation environments, since some CPUs cannot fully virtualise flat real mode and so the hypervisor must fall back to emulation. In particular, operating under KVM on a pre-Westmere Intel CPU will be at least an order of magnitude slower, to the point that there is a visible teletype effect when printing anything to the BIOS console. (Older versions of KVM used to cheat and ignore the "flat" part of flat real mode, which masked the problem.) Switch (back) to using genuine real mode with 64kB segment limits instead of flat real mode. Hopefully this won't break anything. Add an explicit switch to flat real mode before returning to the BIOS from the ROM prefix, since we know that a PMM BIOS will call the ROM initialisation point (and potentially the BEV) in flat real mode. As noted in previous commit messages, it is not possible to restore the real-mode segment limits after a transition to protected mode, since there is no way to know which protected-mode segment descriptor was originally used to initialise the limit portion of the segment register. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [profile] Add generic profiling infrastructureMichael Brown2014-04-281-0/+28
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [libc] Add flsll()Michael Brown2014-04-271-0/+50
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Fix __libgcc attribute for recent gcc versionsMichael Brown2014-04-251-0/+11
| | | | | | | | | | | | | | | | | | We observed some time ago (in commit 4ce8d61 "Import various libgcc functions from syslinux") that gcc seems to treat calls to the implicit arithmetic functions (e.g. __udivdi3()) as being affected by -mregparm but unaffected by -mrtd. This seems to be no longer the case with current gcc versions, which treat calls to these functions as being affected by both -mregparm and -mrtd, as expected. There is nothing obvious in the gcc changelogs to indicate precisely when this happened. From experimentation with available gcc versions, the change occurred sometime between v4.6.3 and v4.7.2. We assume that only versions up to v4.6.x require the special treatment. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bios] Fix screen clearing on even more buggy BIOSesMichael Brown2014-03-211-1/+3
| | | | | | | | | | | | | | | | Some BIOSes (observed with a ProLiant DL360p Gen8 SE) perform no range checking whatsoever on the parameters passed to INT10,06 and will therefore happily write to an area beyond the end of video RAM. The area immediately following the video RAM tends to be the VGA BIOS ROM image. Overwriting the VGA BIOS leads to an interesting variety of crashes and reboots. Fix by specifying an exact width and height to be cleared, rather than passing in large values and relying upon the BIOS to truncate them to the appropriate range. Reported-by: Alex Davies <adavies@jumptrading.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Add "--timeout" parameter to image downloading commandsMichael Brown2014-03-101-2/+3
| | | | | | | | | | | | | | | | | | iPXE will detect timeout failures in several situations: network link-up, DHCP, TCP connection attempts, unacknowledged TCP data, etc. This does not cover all possible circumstances. For example, if a connection to a web server is successfully established and the web server acknowledges the HTTP request but never sends any data in response, then no timeout will be triggered. There is no timeout defined within the HTTP specifications, and the underlying TCP connection will not generate a timeout since it has no way to know that the HTTP layer is expecting to receive data from the server. Add a "--timeout" parameter to "imgfetch", "chain", etc. If no progress is made (i.e. no data is downloaded) within the timeout period, then the download will be aborted. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [romprefix] Do not clobber stack segment when returning to BIOSMichael Brown2014-03-051-2/+2
| | | | | | | | | | | | | | | | | | Commit c429bf0 ("[romprefix] Store boot bus:dev.fn address as autoboot device location") introduced a regression by using register %cx to temporarily hold the PCI bus:dev.fn address, despite the fact that %cx was already being used to hold the stored BIOS stack segment. Consequently, when returning to the BIOS after a failed or cancelled boot attempt, iPXE would end up calling INT 18 with the stack segment set equal to the PCI bus:dev.fn address. Writing to essentially random areas of memory tends to upset even the more robust BIOSes. Fix by using register %ax to temporarily hold the PCI bus:dev.fn address. Reported-by: Anton D. Kachalov <mouse@yandex-team.ru> Tested-by: Anton D. Kachalov <mouse@yandex-team.ru> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bzimage] Report exact initrd length via bzImage headerMichael Brown2014-03-041-14/+28
| | | | | | | | | | | | | | | | | | | | iPXE currently pads initrd images to a multiple of 4kB and inserts zero padding between images, as required by some versions of the Linux kernel. The overall length reported via the ramdisk_size field in the bzImage header includes this zero padding. This causes problems when using memdisk to load a gzip-compressed disk image. memdisk treats the ramdisk_size field as containing the exact length of the initrd image, and uses this length to locate the 8-byte gzip footer. This will generally cause memdisk to fail to decompress the disk image. Fix by reporting the exact length of the initrd image set, including any padding inserted between images but excluding any padding added at the end of the final image. Reported-by: Levente LEVAI <levail@aviatronic.hu> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [prefix] Ignore PCI autoboot device location if set to 00:00.0Michael Brown2014-03-031-2/+4
| | | | | | | | | | | | | | qemu can load an option ROM which is not associated with a particular PCI device using the "-option-rom" syntax. Under these circumstances, we should ignore the PCI bus:dev.fn address that we expect to find in %ax on entry to the initialisation vector. Fix by using the PCI bus:dev.fn address only if it is non-zero. Since 00:00.0 will always be the host bridge, it can never be the address of a network card. Reported-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [romprefix] Store boot bus:dev.fn address as autoboot device locationAlex Williamson2014-03-031-1/+11
| | | | | | | | | | | | | | | | | Per the BIOS Boot Specification, the initialization phase of the ROM is called with the PFA (PCI Function Address) in the %ax register. The intention is that the ROM code will store that device address somewhere and use it for booting from that device when the Boot Entry Vector (BEV) is called. iPXE does store the PFA, but doesn't use it to select the boot network device. This renders BIOS IPL lists fairly ineffective. Fix by using the BBS-specified bus:dev.fn address as the autoboot device location. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [prefix] Allow prefix to specify a PCI autoboot device locationAlex Williamson2014-03-031-0/+44
| | | | | | Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [romprefix] Allow ROM banner timeout to be configured independentlyAlex Williamson2014-03-031-7/+3Star
| | | | | | | | | | | | | | | | | iPXE currently prints a "Press Ctrl-B" banner twice: once when the ROM is first called for initialisation and again if we attempt to boot from the ROM. This slows boot, especially when the NIC is not the primary boot device. Tools such as libguestfs make use of QEMU VMs for performing maintenance on disk images and may make use of NICs in the VM for network support. If iPXE introduces a static init-time delay, that directly translates to increased runtime for the tools. Fix by allowing the ROM banner timeout to be configured independently of the main banner timeout. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uri] Refactor URI parsing and formattingMichael Brown2014-02-271-2/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | Add support for parsing of URIs containing literal IPv6 addresses (e.g. "http://[fe80::69ff:fe50:5845%25net0]/boot.ipxe"). Duplicate URIs by directly copying the relevant fields, rather than by formatting and reparsing a URI string. This relaxes the requirements on the URI formatting code and allows it to focus on generating human-readable URIs (e.g. by not escaping ':' characters within literal IPv6 addresses). As a side-effect, this allows relative URIs containing parameter lists (e.g. "../boot.php##params") to function as expected. Add validity check for FTP paths to ensure that only printable characters are accepted (since FTP is a human-readable line-based protocol with no support for character escaping). Construct TFTP next-server+filename URIs directly, rather than parsing a constructed "tftp://..." string, Add self-tests for URI functions. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cmdline] Rename "console" command's --bpp option to --depthMichael Brown2014-01-221-1/+1
| | | | | | | | | | Rename the "--bpp" option to "--depth", to free up the single-letter option "-b" for "--bottom" in preparation for adding margin support. This does not break backwards compatibility with documented features, since the "console" command has not yet been documented. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [vesafb] Allow for an arbitrary margin around the text areaMichael Brown2014-01-221-11/+31
| | | | | | | | | | | | | | Allow for an arbitrary margin to be specified in the console configuration. If the actual screen size does not match the requested screen size, then update any margins specified so that they remain in the same place relative to the requested screen size. If margins are unspecified (i.e. zero), then leave them as zero. The underlying assumption here is that any specified margins are likely to describe an area within a background picture, and so should remain in the same place relative to that background picture. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fbcon] Allow for an arbitrary margin around the text areaMichael Brown2014-01-221-2/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [vesafb] Handle failures from fbcon_init()Michael Brown2014-01-221-9/+27
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Add memcmp_user()Michael Brown2014-01-121-0/+7
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [vesafb] Set "magic" colour to transparent when a background picture is usedMichael Brown2013-12-091-0/+6
| | | | | | | Use the magic colour facility to cause the user interface background to become transparent when we have a background picture. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [lkrnprefix] Include iPXE version string in image headerMichael Brown2013-12-062-1/+8
| | | | | Originally-implemented-by: Christian Hesse <list@eworm.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [vesafb] Work around data corruption bug in bochs/qemu VBE implementationMichael Brown2013-12-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The vgabios used by bochs and qemu (and other virtualisation products) has a bug in its implementation of INT 10,4f00 which causes the high 16 bits of %ebx and %edx to become corrupted. The vgabios code uses a "pushaw"/"popaw" pair to preserve the low 16 bits of all non-segment registers. The vgabios code is compiled using bcc, which generates 8086-compatible code and so never touches the high 16 bits of the 32-bit registers. However, the function vbe_biosfn_return_controller_information() includes the line: size_64k = (Bit16u)((Bit32u)cur_info->info.XResolution * cur_info->info.XResolution * cur_info->info.BitsPerPixel) >> 19; which generates an implicit call to the "lmulul" function. This function is implemented in vbe.c as: ; helper function for memory size calculation lmulul: and eax, #0x0000FFFF shl ebx, #16 or eax, ebx SEG SS mul eax, dword ptr [di] mov ebx, eax shr ebx, #16 ret which modifies %eax, %ebx, and %edx (as a result of the "mul" instruction, which places its result into %edx:%eax). Work around this problem by marking %ebx and %edx as being clobbered by the call to INT 10,4f00. (%eax is already used as an output register, so does not need to be on the clobber list.) Reported-by: Oliver Rath <rath@mglug.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Provide access to SMBIOS via /dev/memMichael Brown2013-12-051-40/+12Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Explicitly separate the concept of a completed fetched settingMichael Brown2013-12-051-1/+1
| | | | | | | | | | The fetch_setting() family of functions may currently modify the definition of the specified setting (e.g. to add missing type information). Clean up this interface by requiring callers to provide an explicit buffer to contain the completed definition of the fetched setting, if required. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [vesafb] Select an optimal mode, rather than the first acceptable modeMichael Brown2013-11-281-49/+91
| | | | | | | | | | | | | | | | | | There is no requirement for VBE modes to be listed in increasing order of resolution. With the present logic, this can cause e.g. a 1024x768 mode to be selected if the user asks for 640x480, if the 1024x768 mode is earlier in the mode list. Define a scoring system for modes as score = ( width * height - bpp ) and choose the mode with the lowest score among all acceptable modes. This should prefer to choose the mode closest to the requested resolution, with a slight preference for higher colour depths. Reported-by: Robin Smidsrød <robin@smidsrod.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [vesafb] Return meaningful error when no suitable mode is foundMichael Brown2013-11-281-44/+75
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [vesafb] Skip modes for which we cannot get mode informationMichael Brown2013-11-281-2/+1Star
| | | | | | | | | The VirtualBox BIOS fails to retrieve mode information (with status 0x0100) for some modes within the mode list. Skip any such modes, rather than treating this as a fatal error. Reported-by: Robin Smidsrød <robin@smidsrod.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [vesafb] Include raw status value within VBE error messagesMichael Brown2013-11-281-5/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [vesafb] Add VESA frame buffer consoleMichael Brown2013-11-282-0/+630
| | | | | | | | | | | The VESA frame buffer console uses the VESA BIOS extensions (VBE) to enumerate video modes, selects an appropriate mode, and then hands off to the generic frame buffer code. The font is extracted from the VGA BIOS, avoiding the need to provide an external font file. Signed-off-by: Michael Brown <mcb30@ipxe.org>