openslx-ng/ipxe.git/src/arch/x86_64, branch master

[build] Prevent use of MMX and SSE registers

2018-03-20T20:01:08+00:00

The existence of MMX and SSE is required by the System V x86_64 ABI and so is assumed by gcc, but these registers are not preserved by our own interrupt handlers and are unlikely to be preserved by other context switch handlers in a boot firmware environment. Explicitly prevent gcc from using MMX or SSE registers to avoid potential problems due to silent register corruption. We must remove the %xmm0-%xmm5 clobbers from the x86_64 version of hv_call() since otherwise gcc will complain about unknown register names. Theoretically, we should probably add code to explicitly preserve the %xmm0-%xmm5 registers across a hypercall, in order to guarantee to external code that these registers remain unchanged. In practice this is difficult since SSE registers are disabled by default: for background information see commits 71560d1 ("[librm] Preserve FPU, MMX and SSE state across calls to virt_call()") and dd9a14d ("[librm] Conditionalize the workaround for the Tivoli VMM's SSE garbling"). Signed-off-by: Michael Brown

[legal] Add missing FILE_LICENCE declarations

2017-12-29T11:57:00+00:00

Add missing FILE_LICENCE declarations to x86_64 headers based on the corresponding i386 headers (from which the x86_64 headers were originally derived). Signed-off-by: Michael Brown

[dhcp] Automatically generate vendor class identifier string

2016-07-04T14:07:05+00:00

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

[dhcp] Allow for variable encapsulation of architecture-specific options

2016-07-04T12:15:05+00:00

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

[gdb] Add support for x86_64

2016-03-22T08:44:32+00:00

Signed-off-by: Michael Brown

[hyperv] Use generic set_bit() function

2016-03-16T22:33:41+00:00

Signed-off-by: Michael Brown

[build] Fix building on older versions of binutils

2016-02-19T20:03:30+00:00

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

[librm] Generate page tables for 64-bit builds

2016-02-19T03:21:38+00:00

Signed-off-by: Michael Brown

[librm] Prepare for long-mode memory map

2016-02-19T02:58:09+00:00

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

[librm] Provide an abstraction wrapper for prot_call

2016-02-18T23:23:38+00:00

Signed-off-by: Michael Brown