openslx-ng/ipxe.git/src/arch/x86/drivers/xen, branch openslx

[uaccess] Remove redundant copy_from_user() and copy_to_user()

2025-04-30T14:32:03+00:00

Remove the now-redundant copy_from_user() and copy_to_user() wrapper functions. Signed-off-by: Michael Brown

[malloc] Rename malloc_dma() to malloc_phys()

2020-11-05T19:13:52+00:00

The malloc_dma() function allocates memory with specified physical alignment, and is typically (though not exclusively) used to allocate memory for DMA. Rename to malloc_phys() to more closely match the functionality, and to create name space for functions that specifically allocate and map DMA-capable buffers. Signed-off-by: Michael Brown

[pci] Update drivers to use pci_ioremap()

2020-09-25T13:17:07+00:00

Signed-off-by: Michael Brown

[cpuid] Allow input %ecx value to be specified

2017-06-16T00:17:48+00:00

For some CPUID leaves (e.g. %eax=0x00000004), the result depends on the input value of %ecx. Allow this subfunction number to be specified as a parameter to the cpuid() wrapper. The subfunction number is exposed via the ${cpuid/...} settings mechanism using the syntax ${cpuid/.0x40..} e.g. ${cpuid/0.0x40.0.0x0000000b} ${cpuid/1.0x40.0.0x0000000b} to retrieve the CPU topology information. Signed-off-by: Michael Brown

[build] Fix the REQUIRE_SYMBOL mechanism

2015-03-05T00:59:38+00:00

At some point in the past few years, binutils became more aggressive at removing unused symbols. To function as a symbol requirement, a relocation record must now be in a section marked with @progbits and must not be in a section which gets discarded during the link (either via --gc-sections or via /DISCARD/). Update REQUIRE_SYMBOL() to generate relocation records meeting these criteria. To minimise the impact upon the final binary size, we use existing symbols (specified via the REQUIRING_SYMBOL() macro) as the relocation targets where possible. We use R_386_NONE or R_X86_64_NONE relocation types to prevent any actual unwanted relocation taking place. Where no suitable symbol exists for REQUIRING_SYMBOL() (such as in config.c), the macro PROVIDE_REQUIRING_SYMBOL() can be used to generate a one-byte-long symbol to act as the relocation target. If there are versions of binutils for which this approach fails, then the fallback will probably involve killing off REQUEST_SYMBOL(), redefining REQUIRE_SYMBOL() to use the current definition of REQUEST_SYMBOL(), and postprocessing the linked ELF file with something along the lines of "nm -u | wc -l" to check that there are no undefined symbols remaining. Signed-off-by: Michael Brown

[legal] Relicense files under GPL2_OR_LATER_OR_UBDL

2015-03-02T14:17:31+00:00

Relicense files for which I am the sole author (as identified by util/relicense.pl). Signed-off-by: Michael Brown

[xen] Use version 1 grant tables by default

2014-08-13T18:21:42+00:00

Using version 1 grant tables limits guests to using 16TB of grantable RAM, and prevents the use of subpage grants. Some versions of the Xen hypervisor refuse to allow the grant table version to be set after the first grant references have been created, so the loaded operating system may be stuck with whatever choice we make here. We therefore currently use version 2 grant tables, since they give the most flexibility to the loaded OS. Current versions (7.2.0) of the Windows PV drivers have no support for version 2 grant tables, and will merrily create version 1 entries in what the hypervisor believes to be a version 2 table. This causes some confusion. Avoid this problem by attempting to use version 1 tables, since otherwise we may render Windows unable to boot. Play nicely with other potential bootloaders by accepting either version 1 or version 2 grant tables (if we are unable to set our requested version). Note that the use of version 1 tables on a 64-bit system introduces a possible failure path in which a frame number cannot fit into the 32-bit field within the v1 structure. This in turn introduces additional failure paths into netfront_transmit() and netfront_refill_rx(). Signed-off-by: Michael Brown

[xen] Accept alternative Xen platform PCI device ID 5853:0002

2014-08-13T12:17:33+00:00

At some point during XenServer development history, the Windows PV drivers changed to using a PCI device ID of 5853:0002 rather than 5853:0001. Current (7.2.0) drivers will bind to either 5853:0001 or 5853:0002, and the general approach taken by the world at large (including Amazon EC2) seems to be to use only 5853:0001. However, the current version of XenServer (6.2.0) will create the platform device as 5853:0002 (via the platform:device_id VM parameter) for any VMs created using the built-in templates for Windows Vista or later. Accept either PCI ID, since the underlying device is identical. Signed-off-by: Michael Brown

[xen] Add support for Xen netfront virtual NICs

2014-07-29T14:57:56+00:00

Signed-off-by: Michael Brown

[xen] Add basic support for PV-HVM domains

2014-07-29T14:57:44+00:00

Add basic support for Xen PV-HVM domains (detected via the Xen platform PCI device with IDs 5853:0001), including support for accessing configuration via XenStore and enumerating devices via XenBus. Signed-off-by: Michael Brown