summaryrefslogtreecommitdiffstats
path: root/src/arch
Commit message (Collapse)AuthorAgeFilesLines
...
* [bzimage] Fix page alignment of initrd imagesMichael Brown2016-10-291-3/+5
| | | | | | | | | | | | The initrd_addr_max field represents the highest byte address that may be used to hold initrd images, and is therefore almost certainly not aligned to a page boundary: a typical value might be 0x7fffffff. Fix the address calculations to ensure that the initrd images are always aligned to a page boundary. Reported-by: Sitsofe Wheeler <sitsofe@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Allow time for ACPI power off to take effectMichael Brown2016-07-111-0/+6
| | | | | | | | | The ACPI power off sequence may not take effect immediately. Delay for one second, to eliminate potentially confusing log messages such as "Could not power off: Error 0x43902001 (http://ipx". Reported-by: Leonid Vasetsky <leonidv@velostrata.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [acpi] Add support for ACPI power offMichael Brown2016-07-117-4/+170
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [rng] Check for functioning RTC interruptMichael Brown2016-07-102-0/+57
| | | | | | | | | | | | | | | | | | | | | On some platforms (observed in a small subset of Microsoft Azure (Hyper-V) virtual machines), the RTC appears to be incapable of generating an interrupt via the legacy PIC. The RTC status registers show that a periodic interrupt has been asserted, but the PIC IRR shows that IRQ8 remains inactive. On such systems, iPXE will currently freeze during the "iPXE initialising devices..." message. Work around this problem by checking that RTC interrupts are being raised before returning from rtc_entropy_enable(). If no interrupt is seen within 100ms, then we assume that the RTC interrupt mechanism is broken. In these circumstances, iPXE will continue to initialise but any subsequent attempt to generate entropy will fail. In particular, HTTPS connections will fail with an error indicating that no entropy is available. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Automatically generate vendor class identifier stringMichael Brown2016-07-046-30/+0Star
| | | | | | | | | | | | The vendor class identifier strings in DHCP_ARCH_VENDOR_CLASS_ID are out of sync with the (correct) client architecture values in DHCP_ARCH_CLIENT_ARCHITECTURE. Fix by removing all definitions of DHCP_ARCH_VENDOR_CLASS_ID, and instead generating the vendor class identifier string automatically based on DHCP_ARCH_CLIENT_ARCHITECTURE and DHCP_ARCH_CLIENT_NDI. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Allow for variable encapsulation of architecture-specific optionsMichael Brown2016-07-046-42/+36Star
| | | | | | | | | | | | | DHCPv4 and DHCPv6 share some values in common for the architecture- specific options (such as the client system architecture type), but use different encapsulations: DHCPv4 has a single byte for the option length while DHCPv6 has a 16-bit field for the option length. Move the containing DHCP_OPTION() and related wrappers from the individual dhcp_arch.h files to dhcp.c, thus allowing for the architecture-specific values to be reused in dhcpv6.c. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pxe] Disable interrupts on the PIC before starting NBPMichael Brown2016-07-031-0/+5
| | | | | | | | | | | | | | | | | | | | | | Some BIOSes (observed with an HP Gen9) seem to spuriously enable interrupts at the PIC. This causes problems with NBPs such as GRUB which use the UNDI API (thereby enabling interrupts on the NIC) without first hooking an interrupt service routine. In this situation, the interrupt will end up being handled by the default BIOS ISR, which will typically just send an EOI and return. Since nothing in this handler causes the NIC to deassert the interrupt, this will result in an interrupt storm. Entertainingly, some BIOSes are immune to this problem because the default ISR sends the EOI only to the slave PIC; this effectively disables the interrupt. Work around this problem by disabling the interrupt on the PIC before invoking the PXE NBP. An NBP that expects to make use of interrupts will need to be configuring the PIC anyway, so it is probably safe to assume that it will explicitly reenable the interrupt. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bios] Do not enable interrupts when printing to the consoleMichael Brown2016-07-031-14/+4Star
| | | | | | | | There seems to be no reason for the sti/cli pair used around each call to INT 10. Remove these instructions, so that printing debug messages from within an ISR does not temporarily reenable interrupts. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Support systems with multiple PCI root bridgesMichael Brown2016-06-091-2/+4
| | | | | | | | | Extend the 16-bit PCI bus:dev.fn address to a 32-bit seg:bus:dev.fn address, assuming a segment value of zero in contexts where multiple segments are unsupported by the underlying data structures (e.g. in the iBFT or BOFM tables). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Use correct DHCP client architecture valuesMichael Brown2016-05-262-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [undi] Work around broken HP EliteBook 745 G3 PXE ROMMichael Brown2016-05-131-0/+2
| | | | | | Reported-by: Arturino Mazzei <mazzeia@hotmail.com> Tested-by: Arturino Mazzei <mazzeia@hotmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Use CNTVCT_EL0 as profiling timestampMichael Brown2016-05-121-3/+1Star
| | | | | | | | | | | | The raw cycle counter at PMCCNTR_EL0 works in qemu but seems to always read as zero on physical hardware (tested on Juno r1 and Cavium ThunderX), even after ensuring that PMCR_EL0.E and PMCNTENSET_EL0.C are both enabled. Use CNTVCT_EL0 instead; this seems to count at a lower resolution (tens of CPU cycles), but is usable for profiling. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Add optimised TCP/IP checksumming for 64-bit ARMMichael Brown2016-05-113-0/+190
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Add optimised string functions for 64-bit ARMMichael Brown2016-05-113-0/+355
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Add support for 64-bit ARM (Aarch64)Michael Brown2016-05-0818-14/+1033
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Split out 32-bit-specific code to arch/arm32Michael Brown2016-05-0820-38/+54
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Add support for 32-bit ARMMichael Brown2016-05-0640-0/+1805
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Generalise EFI entropy generation to non-x86 CPUsMichael Brown2016-05-042-224/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tcpip] Do not fall back to using unoptimised TCP/IP checksummingMichael Brown2016-05-042-6/+4Star
| | | | | | | | Require architecture-specific code to make a deliberate choice to use the unoptimised generic_tcpip_continue_chksum() function, if there is no optimised version available. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Preserve FPU, MMX and SSE state across calls to virt_call()Michael Brown2016-05-021-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The IBM Tivoli Provisioning Manager for OS Deployment (also known as TPMfOSD, Rembo-ia32, or Rembo Auto-Deploy) has a serious bug in some older versions (observed with v5.1.1.0, apparently fixed by v7.1.1.0) which can lead to arbitrary data corruption. As mentioned in commit 87723a0 ("[libflat] Test A20 gate without switching to flat real mode"), Tivoli's NBP sets up a VMM and makes calls to the PXE stack in VM86 mode. This appears to be some kind of attempt to run PXE API calls inside a sandbox. The VMM is fairly sophisticated: for example, it handles our attempts to switch into protected mode and patches our GDT so that our protected-mode code runs in ring 1 instead of ring 0. However, it neglects to apply any memory protections. In particular, it does not enable paging and leaves us with 4GB segment limits. We can therefore trivially break out of the sandbox by simply overwriting the GDT (or by modifying any of Tivoli's VMM code or data structures). When we attempt to execute privileged instructions (such as "lidt"), the CPU raises an exception and control is passed to the Tivoli VMM. This may result in a call to Tivoli's memcpy() function. Tivoli's memcpy() function includes optimisations which use the SSE registers %xmm0-%xmm3 to speed up aligned memory copies. Unfortunately, the Tivoli VMM's exception handler does not save or restore %xmm0-%xmm3. The net effect of this bug in the Tivoli VMM is that any privileged instruction (such as "lidt") issued by iPXE may result in unexpected corruption of the %xmm0-%xmm3 registers. Even more unfortunately, this problem affects the code path taken in response to a hardware interrupt from the NIC, since that code path will call PXENV_UNDI_ISR. The net effect therefore becomes that any NIC hardware interrupt (e.g. due to a received packet) may result in unexpected corruption of the %xmm0-%xmm3 registers. If a packet arrives while Tivoli is in the middle of using its memcpy() function, then the unexpected corruption of the %xmm0-%xmm3 registers will result in unexpected corruption in the destination buffer. The net effect therefore becomes that any received packet may result in a 16-byte block of corruption somewhere in any data that Tivoli copied using its memcpy() function. We can work around this bug in the Tivoli VMM by saving and restoring the %xmm0-%xmm3 registers across calls to virt_call(). To work around the problem, we need to save registers before attempting to execute any privileged instructions, and ensure that we attempt no further privileged instructions after restoring the registers. This is less simple than it may sound. We can use the "movups" instruction to save and restore individual registers, but this will itself generate an undefined opcode exception if SSE is not currently enabled according to the flags in %cr0 and %cr4. We can't access %cr0 or %cr4 before attempting the "movups" instruction, because access a control register is itself a privileged instruction (which may therefore trigger corruption of the registers that we're trying to save). The best solution seems to be to use the "fxsave" and "fxrstor" instructions. If SSE is not enabled, then these instructions may fail to save and restore the SSE register contents, but will not generate an undefined opcode exception. (If SSE is not enabled, then we don't really care about preserving the SSE register contents anyway.) The use of "fxsave" and "fxrstor" introduces an implicit assumption that the CPU supports SSE instructions (even though we make no assumption about whether or not SSE is currently enabled). SSE was introduced in 1999 with the Pentium III (and added by AMD in 2001), and is an architectural requirement for x86_64. Experimentation with current versions of gcc suggest that it may generate SSE instructions even when using "-m32", unless an explicit "-march=i386" or "-mno-sse" is used to inhibit this. It therefore seems reasonable to assume that SSE will be supported on any hardware that might realistically be used with new iPXE builds. As a side benefit of this change, the MMX register %mm0 will now be preserved across virt_call() even in an i386 build of iPXE using a driver that requires readq()/writeq(), and the SSE registers %xmm0-%xmm5 will now be preserved across virt_call() even in an x86_64 build of iPXE using the Hyper-V netvsc driver. Experimentation suggests that this change adds around 10% to the number of cycles required for a do-nothing virt_call(), most of which are due to the extra bytes copied using "rep movsb". Since the number of bytes copied is a compile-time constant local to librm.S, we could potentially reduce this impact by ensuring that we always copy a whole number of dwords and so can use "rep movsl" instead of "rep movsb". Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Reduce real-mode stack consumption in virt_call()Michael Brown2016-04-291-59/+103
| | | | | | | | | | | | | | | | | | Some PXE NBPs are known to make PXE API calls with very little space available on the real-mode stack. For example, the Rembo-ia32 NBP from some versions of IBM's Tivoli Provisioning Manager for Operating System Deployment (TPMfOSD) will issue calls with the real-mode stack placed at 0000:03d2; this is at the end of the interrupt vector table and leaves only 498 bytes of stack space available before overwriting the hardware IRQ vectors. This limits the amount of state that we can preserve before transitioning to protected mode. Work around these challenging conditions by preserving everything other than the initial register dump in a temporary static buffer within our real-mode data segment, and copying the contents of this buffer to the protected-mode stack. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [comboot] Support COMBOOT in 64-bit buildsMichael Brown2016-04-1512-101/+179
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [prefix] Use CRC32 to verify each block prior to decompressionMichael Brown2016-03-242-35/+118
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pxe] Implicitly open network device in PXENV_UDP_OPENMichael Brown2016-03-221-0/+10
| | | | | | | | | | | | | | | Some end-user configurations have been observed in which the first NBP (such as GRUB2) uses the UNDI API and then transfers control to a second NBP (such as pxelinux) which uses the UDP API. The first NBP closes the network device using PXENV_UNDI_CLOSE, which renders the UDP API unable to transmit or receive packets. The correct behaviour under these circumstances is (as often) simply not documented by the PXE specification. Testing with the Intel PXE stack suggests that PXENV_UDP_OPEN will implicitly reopen the network device if necessary, so match this behaviour. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [int13] Allow default drive to be specified via "san-drive" settingMichael Brown2016-03-222-12/+28
| | | | | | | | | | | The DHCP option 175.189 has been defined (by us) since 2006 as containing the drive number to be used for a SAN boot, but has never been automatically used as such by iPXE. Use this option (if specified) to override the default SAN drive number. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [int13] Allow drive to be hooked using the natural drive numberMichael Brown2016-03-221-2/+6
| | | | | | | Interpret the maximum drive number (0xff for hard disks, 0x7f for floppy disks) as meaning "use natural drive number". Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [gdb] Add support for x86_64Michael Brown2016-03-227-221/+470
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Do not use "objcopy -O binary" for objects with relocation recordsMichael Brown2016-03-211-4/+8
| | | | | | | | | | | | | | | | | | | | The mbr.bin and usbdisk.bin standalone blobs are currently generated using "objcopy -O binary", which does not process relocation records. For the i386 build, this does not matter since the section start address is zero and so the ".rel" relocation records are effectively no-ops anyway. For the x86_64 build, the ".rela" relocation records are not no-ops, since the addend is included as part of the relocation record (rather than inline). Using "objcopy -O binary" will silently discard the relocation records, with the result that all symbols are effectively given a value of zero. Fix by using "ld --oformat binary" instead of "objcopy -O binary" to generate mbr.bin and usbdisk.bin. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Move architecture-independent EFI prefixes to interface/efiMichael Brown2016-03-172-182/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [test] Move i386-specific tests to arch/i386/testsMichael Brown2016-03-175-0/+347
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xen] Use generic test_and_clear_bit() functionMichael Brown2016-03-161-19/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [hyperv] Use generic set_bit() functionMichael Brown2016-03-162-46/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bitops] Add generic atomic bit test, set, and clear functionsMichael Brown2016-03-161-0/+94
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow assembler section type character to vary by architectureMichael Brown2016-03-131-0/+5
| | | | | | | | | | | | | | | On some architectures (such as ARM) the "@" character is used as a comment delimiter. A section type argument such as "@progbits" therefore becomes "%progbits". This is further complicated by the fact that the "%" character has special meaning for inline assembly when input or output operands are used, in which cases "@progbits" becomes "%%progbits". Allow the section type character(s) to be defined via Makefile variables. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Centralise architecture-independent EFI Makefile and linker scriptMichael Brown2016-03-122-153/+3Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Do not unconditionally preserve flags across virt_call()Michael Brown2016-03-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 196f0f2 ("[librm] Convert prot_call() to a real-mode near call") introduced a regression in which any deliberate modification to the low 16 bits of the CPU flags (in struct i386_all_regs) would be overwritten with the original flags value at the time of entry to prot_call(). The regression arose because the alignment requirements of the protected-mode stack necessitated the insertion of two bytes of padding immediately below the prot_call() return address. The solution chosen was to extend the existing "pushfl / popfl" pair to "pushfw;pushfl / popfl;popfw". The extra "pushfw / popfw" appears at first glance to be a no-op, but fails to take into account the fact that the flags restored by popfl may have been deliberately modified by the protected-mode function. Fix by replacing "pushfw / popfw" with "pushw %ss / popw %ss". While %ss does appear within struct i386_all_regs, any modification to the stored value has always been ignored by prot_call() anyway. The most visible symptom of this regression was that SAN booting would fail since every INT 13 call would be chained to the original INT 13 vector. Reported-by: Vishvananda Ishaya <vishvananda@gmail.com> Reported-by: Jamie Thompson <forum.ipxe@jamie-thompson.co.uk> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pcbios] Restrict external memory allocations to the low 4GBMichael Brown2016-03-081-0/+53
| | | | | | | | | | | | When running the 64-bit BIOS version of iPXE, restrict external memory allocations to the low 4GB to ensure that allocations (such as for initrds) fall within our identity-mapped memory region, and will be accessible to the potentially 32-bit operating system. Move largest_memblock() back to memtop_umalloc.c, since this change imposes a restriction that applies only to BIOS builds. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Support ioremap() for addresses above 4GB in a 64-bit buildMichael Brown2016-02-265-0/+210
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ioapi] Split ioremap() out to a separate IOMAP APIMichael Brown2016-02-263-19/+13Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Add support for running in 64-bit long modeMichael Brown2016-02-243-61/+495
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for running the BIOS version of iPXE in 64-bit long mode. A 64-bit BIOS version of iPXE can be built using e.g. make bin-x86_64-pcbios/ipxe.usb make bin-x86_64-pcbios/8086100e.mrom The 64-bit BIOS version should appear to function identically to the normal 32-bit BIOS version. The physical memory layout is unaltered: iPXE is still relocated to the top of the available 32-bit address space. The code is linked to a virtual address of 0xffffffffeb000000 (in the negative 2GB as required by -mcmodel=kernel), with 4kB pages created to cover the whole of .textdata. 2MB pages are created to cover the whole of the 32-bit address space. The 32-bit portions of the code run with VIRTUAL_CS and VIRTUAL_DS configured such that truncating a 64-bit virtual address gives a 32-bit virtual address pointing to the same physical location. The stack pointer remains as a physical address when running in long mode (although the .stack section is accessible via the negative 2GB virtual address); this is done in order to simplify the handling of interrupts occurring while executing a portion of 32-bit code with flat physical addressing via PHYS_CODE(). Interrupts may be enabled in either 64-bit long mode, 32-bit protected mode with virtual addresses, 32-bit protected mode with physical addresses, or 16-bit real mode. Interrupts occurring in any mode other than real mode will be reflected down to real mode and handled by whichever ISR is hooked into the BIOS interrupt vector table. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Rename prot_call() to virt_call()Michael Brown2016-02-224-39/+39
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Support userptr_t in 64-bit buildsMichael Brown2016-02-211-1/+23
| | | | | | | | | | | | | | In a 64-bit build, the entirety of the 32-bit address space is identity-mapped and so any valid physical address may immediately be used as a virtual address. Conversely, a virtual address that is already within the 32-bit address space may immediately be used as a physical address. A valid virtual address that lies outside the 32-bit address space must be an address within .textdata, and so can be converted to a physical address by adding virt_offset. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Mark virt_offset, text16, data16, rm_cs, and rm_ds as constantMichael Brown2016-02-211-5/+5
| | | | | | | | The physical locations of .textdata, .text16 and .data16 are constant from the point of view of C code. Mark the relevant variables as constant to allow gcc to optimise out redundant reads. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Do not preserve flags unnecessarilyMichael Brown2016-02-211-17/+11Star
| | | | | | | No callers of prot_to_phys, phys_to_prot, or intr_to_prot require the flags to be preserved. Remove the unnecessary pushfl/popfl pairs. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Add phys_call() wrapper for calling code with physical addressingMichael Brown2016-02-213-153/+212
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a phys_call() wrapper function (analogous to the existing real_call() wrapper function) for calling code with flat physical addressing, and use this wrapper within the PHYS_CODE() macro. Move the relevant functionality inside librm.S, where it more naturally belongs. The COMBOOT code currently uses explicit calls to _virt_to_phys and _phys_to_virt. These will need to be rewritten if our COMBOOT support is ever generalised to be able to run in a 64-bit build. Specifically: - com32_exec_loop() should be restructured to use PHYS_CODE() - com32_wrapper.S should be restructured to use an equivalent of prot_call(), passing parameters via a struct i386_all_regs - there appears to be no need for com32_wrapper.S to switch between external and internal stacks; this could be omitted to simplify the design. For now, librm.S continues to expose _virt_to_phys and _phys_to_virt for use by com32.c and com32_wrapper.S. Similarly, librm.S continues to expose _intr_to_virt for use by gdbidt.S. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Fix building on older versions of binutilsMichael Brown2016-02-192-10/+20
| | | | | | | | | | | | | Some older versions of binutils have issues with both the use of PROVIDE() and the interpretation of numeric literals within a section description. Work around these older versions by defining the required numeric literals outside of any section description, and by automatically determining whether or not to generate extra space for page tables rather than relying on LDFLAGS. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Generate page tables for 64-bit buildsMichael Brown2016-02-193-2/+197
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Prepare for long-mode memory mapMichael Brown2016-02-196-35/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bulk of the iPXE binary (the .textdata section) is physically relocated at runtime to the top of the 32-bit address space in order to allow space for an OS to be loaded. The relocation is achieved with the assistance of segmentation: we adjust the code and data segment bases so that the link-time addresses remain valid. Segmentation is not available (for normal code and data segments) in long mode. We choose to compile the C code with -mcmodel=kernel and use a link-time address of 0xffffffffeb000000. This choice allows us to identity-map the entirety of the 32-bit address space, and to alias our chosen link-time address to the physical location of our .textdata section. (This requires the .textdata section to always be aligned to a page boundary.) We simultaneously choose to set the 32-bit virtual address segment bases such that the link-time addresses may simply be truncated to 32 bits in order to generate a valid 32-bit virtual address. This allows symbols in .textdata to be trivially accessed by both 32-bit and 64-bit code. There is no (sensible) way in 32-bit assembly code to generate the required R_X86_64_32S relocation records for these truncated symbols. However, subtracting the fixed constant 0xffffffff00000000 has the same effect as truncation, and can be represented in a standard R_X86_64_32 relocation record. We define the VIRTUAL() macro to abstract away this truncation operation, and apply it to all references by 32-bit (or 16-bit) assembly code to any symbols within the .textdata section. We define "virt_offset" for a 64-bit build as "the value to be added to an address within .textdata in order to obtain its physical address". With this definition, the low 32 bits of "virt_offset" can be treated by 32-bit code as functionally equivalent to "virt_offset" in a 32-bit build. We define "text16" and "data16" for a 64-bit build as the physical addresses of the .text16 and .data16 sections. Since a physical address within the 32-bit address space may be used directly as a 64-bit virtual address (thanks to the identity map), this definition provides the most natural access to variables in .text16 and .data16. Note that this requires a minor adjustment in prot_to_real(), which accesses .text16 using 32-bit virtual addresses. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [relocate] Preserve page alignment during relocationMichael Brown2016-02-191-12/+10Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [librm] Transition to protected mode within init_librm()Michael Brown2016-02-192-107/+127
| | | | | | | | | | | | | Long-mode operation will require page tables, which are too large to sensibly fit in our .data16 segment in base memory. Add a portion of init_librm() running in 32-bit protected mode to provide access to high memory. Use this portion of init_librm() to initialise the .textdata variables "virt_offset", "text16", and "data16", eliminating the redundant (re)initialisation currently performed on every mode transition as part of real_to_prot(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-05-28 22:36:59 +0200