More similar to other implementation.
posix_memalign was adde in NetBSD 8.0, released on July 17, 2018
and went out of support on May 4, 2024.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
If a SR-IOV card presents an I/O space inside a BAR the
code will continue to loop on the same card.
This is due to the missing increment of the cycle variable.
Fixes: a1a6d59862 ("pci: split code to size BARs from pci_add_device")
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Right now on migrate/resume, all guest memory is allocated with 4k
small pages. This was an intended oversight in the original Migration
v2 implementation.
With some test memory program stressing TLB (many small random memory
accesses) superpages can show a 15% performance improvement.
On the first memory iteration the sender is currently sending memory
in 4MB aligned chunks of GFN space which allows the receiver to
allocate most pages as 2MB superpages instead of single 4KB pages.
This change does not handle 1GB superpages as this will require
changes to the migration protocol.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
EFI code path split options from EFI LoadOptions fields in 2
pieces, first EFI options, second Xen options.
"get_argv" function is called first to get the number of arguments
in the LoadOptions, second, after allocating enough space, to
fill some "argc"/"argv" variable. However the first parsing could
be different from second as second is able to detect "--" argument
separator. So it was possible that "argc" was bigger than the
initialized portion of "argv" array, leading to potential
uninitialized pointer dereference, in particular a string like
"-- a b c" would lead to crashes.
Using EFI shell is possible to pass any kind of string in
LoadOptions.
Fixes: bf6501a62e ("x86-64: EFI boot code")
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
The symbols declared with DECLARE_IMPORT are meant to be
used by the 32 bit code.
The __base_relocs_{start,end} symbols were not used by the
code.
No functional changes.
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
This change removes some piece of code working around with
some compiler warnings.
No functional change.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
The function is similar to PrintStr with an implicit newline
added to the string.
In Xen this is not a common pattern and this is used in EFI
ARM code only making it not much coherent with X86 code
so use PrintStr directly to make the code more coherent.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Use more explicit goto statements to handle common error code
path instead of a lot of if/else.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
A boot loader can load files from outside ESP.
In these cases device could be not provided or path could
be something not supported.
In these cases allows to boot anyway, all information
could be provided using UKI or using other boot loader
features.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Show string message instead of code.
This happened trying some different ways to boot Xen, specifically
trying loading xen.efi using GRUB2 "linux" command.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Using UKI it's possible to embed Linux kernel into xen.efi file.
In this case the signature for Secure Boot is applied to the
whole xen.efi, including the kernel.
So checking for specific signature for the kernel is not
needed.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
The comment is similar to extended capabilities in the function
below.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
bogus_real_magic code uses fs segment so it should be initialised.
Fixes: d8c8fef090 ("Provide basic Xen PM infrastructure")
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Currently, building with LLVM's LLD fails:
ld -melf_i386_fbsd --orphan-handling=error -N -T ...
ld: error: <internal>:(.symtab) is being placed in '.symtab'
ld: error: <internal>:(.shstrtab) is being placed in '.shstrtab'
ld: error: <internal>:(.strtab) is being placed in '.strtab'
gmake[11]: *** [arch/x86/boot/Makefile:69: arch/x86/boot/built-in-32.base.bin] Error 1
This is a consequence of --orphan-handling, and it appears that Binutils
doesn't diagnose some orphaned sections even explicitly asked to do so.
List the sections explicitly.
Fixes: aa9045e771 ('x86/boot: Rework how 32bit C is linked/included for early boot')
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
combine_two_binaries.py only understands GNU LD's format, and does
not work with LLVM's LLD.
Use nm command instead to get list of symbols; specifically
BSD format as it does not truncate symbols names like sysv one.
Fixes: aa9045e771 ('x86/boot: Rework how 32bit C is linked/included for early boot')
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The "base" and "offset" definition were inverted, "base" file should be the
files without offsets applied while "offset" should have the offsets applied.
Also update an old usage of "final" to "apply offset" to make more clear and
consistent (in former commit messages the "final" term was used instead of
"offset").
Fixes: aa9045e771 ('x86/boot: Rework how 32bit C is linked/included for early boot')
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Move code from efi-boot.h to a separate, new, reloc-trampoline.c file.
Reuse this new code, compiling it for 32bit as well, to replace assembly
code in head.S doing the same thing.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Right now, the two functions which were really too complicated to write
in asm are compiled as 32bit PIC, linked to a blob and included
directly, using global asm() to arrange for them to have function semantics.
This is limiting and fragile; the use of data relocations will compile
fine but malfunction when used, creating hard-to-debug bugs.
Furthermore, we would like to increase the amount of C, to
deduplicate/unify Xen's boot logic, as well as making it easier to
follow. Therefore, rework how the 32bit objects are included.
Link all 32bit objects together first. This allows for sharing of logic
between translation units. Use differential linking and explicit
imports/exports to confirm that we only have the expected relocations,
and write the object back out as an assembly file so it can be linked
again as if it were 64bit, to integrate with the rest of Xen.
This allows for the use of external references (e.g. access to global
variables) with reasonable assurance of doing so safely.
No functional change.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Most of Xen is built with a stack alignment of 8 bytes, but the UEFI spec
mandates 16 and UEFI services will fault if the stack is misaligned.
While the caller of efi_multiboot2_prelude() takes care to align the stack,
mbi2.c accidentally got the Xen-wide default of 8, and has a 50% chance of
crashing depending on how many variables the compiler decided to spill to the
stack.
Compile mbi2.c with the appropriate alignment for UEFI functionality.
Also take the opportunity to make it a fully .init object.
Fixes: eb21ce14d7 ('x86/boot: Rewrite EFI/MBI2 code partly in C')
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
[rewrite the commit message]
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Broken out of the subsequent patch for clarity.
* Rename head-bin-objs to obj32
* Use a .32.o suffix to distinguish these objects
* Factor out $(LD32)
No functional change.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Strip all related content out of the root .gitignore, and provide a
more local .gitignore's with up-to-date patterns.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Both reloc.S and cmdline.S are not generated since commit
1ab7c128d9 ("x86/build: Don't convert boot/{cmdline,head}.bin back to .S")
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The header already uses standard types for many fields, extend
their usage.
No functional change.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Most of the tools nowadays assume this encoding.
These files do not specify any encoding so convert them to the default.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The 2 code paths were sharing quite some common code, reuse it instead
of having duplications.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Allows to call C code earlier.
In order to safely call C code we need to setup stack, selectors and BSS.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
We are compiling Xen source code so we should define __XEN__ macro.
We don't want to import all definitions from XEN_CFLAGS (as done for
other options) because most of them are processor dependent and
do not apply to 32 bit.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The various filters are removing all optimisations.
No need to have all optimisations turned off.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
All code and data from this file will go into a text section
which we want to not be writeable.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Right now, Xen clobbers the value at 0xffc when performing it's load-base
calculation. We've got plenty of free registers at this point, so the value
can be preserved easily.
This fixes a real bug booting under Coreboot+SeaBIOS, where 0xffc happens to
be the cbmem pointer (e.g. Coreboot's dmesg ring, among other things).
However, there's also a better choice of memory location to use than 0xffc, as
all our supported boot protocols have a pointer to an info structure in %ebx.
Update the documentation to match.
Fixes: 1695e53851 ("x86/boot: Fix the boot time relocation calculations")
Fixes: d96bb172e8 ("x86/entry: Early PVH boot code")
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
On many entries we push 8-bytes zero and exception constants are
small so we can just write a single byte saving 3 bytes for
instruction.
With ENDBR64 this reduces the size of many entry points from 32 to
16 bytes (due to alignment).
The push and the mov are overlapping stores either way. Swapping
between movl and movb will make no difference at all on performance.
Similar code is already used in autogen_stubs.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Use 32 bit versions in all cases, not only for registers till 8th.
This reduces the encoding from (example with r14):
49 c7 c6 ff 7f 00 00 mov $0x7fff,%r14
to
41 be ff 7f 00 00 mov $0x7fff,%r14d
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
__HYPERVISOR_arch_1 and __HYPERVISOR_paging_domctl_cont for x86
have the same value but this function is handling
"paging_domctl_cont" hypercall so using the latter mnemonic in
the code is more clear.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
In case it's not possible to enable memory sharing (mem_sharing_control
fails) we just return the error code without releasing the domain
acquired some lines above by rcu_lock_live_remote_domain_by_id().
Fixes: 72f8d45d69 ("x86/mem_sharing: enable mem_sharing on first memop")
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Frediano Ziglio