#
8f5406c7 |
|
02-Feb-2024 |
Roger Pau Monné <royger@FreeBSD.org> |
x86/xen: implement early init hook Unify the HVM and PVH early setup, byt making both rely on the hypervisor initialization hook part of identify_hypervisor(). The current initialization takes care of the hypercall page, the sahred info page and does any fixup necessary to metadata video console information if FreeBSD is booted as the initial domain (so the video console is handed from Xen into FreeBSD). Note this has the nice side effect of also allowing to use the Xen console on HVM guests, which allows to get rid of the QEMU emulated uart and still get a nice text console. Sponsored by: Cloud Software Group Reviewed by: markj Differential revision: https://reviews.freebsd.org/D43764
|
#
027b66d6 |
|
02-Feb-2024 |
Roger Pau Monné <royger@FreeBSD.org> |
x86/xen: do video console fixup as part of early initialization When FreeBSD is running as dom0 the video console metadata provided by the bootloader might not be accurate, as Xen has very likely taken over the console and possibly changed the mode. Adjust the video console information in the kernel metadata as part of early Xen initialization. Sponsored by: Cloud Software Group Reviewed by: imp Differential revision: https://reviews.freebsd.org/D43934
|
#
5d62aba7 |
|
02-Feb-2024 |
Roger Pau Monné <royger@FreeBSD.org> |
x86/xen: move shared page setup to early init handler As done with the hypercall page, move the setup fo the shared info page into the newly introduced helper, which the aim of having a single helper and call site used by both HVM and PV in order to setup the basic Xen environment. Sponsored by: Cloud Software Group Reviewed by: markj Differential revision: https://reviews.freebsd.org/D43933
|
#
9a687d1f |
|
02-Feb-2024 |
Roger Pau Monné <royger@FreeBSD.org> |
x86/xen: introduce a Xen early init function Start by moving the hyeprcall setup to such function. The aim is to have a function that does all the required Xen early initialization for both HVM and PVH, instead of having it scattered across different paths. Sponsored by: Cloud Software Group Reviewed by: markj Differential revision: https://reviews.freebsd.org/D43932
|
#
848e2719 |
|
02-Feb-2024 |
Roger Pau Monné <royger@FreeBSD.org> |
x86/xen: remove parameter from fixup_console() And instead fetch the metadata inside of the function. This is done in preparation for changing the call site of fixup_console(), which will no longer have the kernel metedata pointer in context. No functional change intended. Sponsored by: Cloud Software Group Reviewed by: markj Differential revision: https://reviews.freebsd.org/D43931
|
#
c7368ccb |
|
06-Aug-2022 |
Elliott Mitchell <ehem+freebsd@m5p.com> |
xen: remove xen_domain_type enum/variable The vm_guest variable readily covers all uses of xen_domain_type, so merge them together. Since support for PV domains has been removed hard-core xen_pv_domain() to return false. Reviewed by: royger
|
#
685dc743 |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
9d6ae1e3 |
|
04-Jun-2023 |
Colin Percival <cperciva@FreeBSD.org> |
Revert "Revert "tslog: Annotate some early boot functions"" Now that <sys/tslog.h> is wrapped in #ifdef _KERNEL, it's safe to have tslog annotations in files which might be built from userland (i.e. in subr_boot.c, which is built as part of the boot loader). This reverts commit 59588a546f55523d6fd37ab42eb08b719311d7d6.
|
#
59588a54 |
|
04-Jun-2023 |
Colin Percival <cperciva@FreeBSD.org> |
Revert "tslog: Annotate some early boot functions" The change to subr_boot.c broke the libsa build because the TSLOG macros have their own definitions for the boot loader -- I didn't realize that the loader code used subr_boot.c. I'm currently testing a fix and I'll revert this revert once I'm satisfied that everything works, but I don't want to leave the tree broken for too long. This reverts commit 469cfa3c30ee7a5ddeb597d0a8c3e7cac909b27a.
|
#
469cfa3c |
|
22-May-2023 |
Colin Percival <cperciva@FreeBSD.org> |
tslog: Annotate some early boot functions Booting an amd64 kernel on Firecracker with 1 CPU and 128 MB of RAM, hammer_time takes roughly 2740 us: * 55 us in xen_pvh_parse_preload_data * 20 us in boot_parse_cmdline_delim * 20 us in boot_env_to_howto * 15 us in identify_hypervisor * 1320 us in link_elf_reloc * 1310 us in relocate_file1 handling ef->rela * 25 us in init_param1 * 30 us in dpcpu_init * 355 us in initializecpu * 255 us in initializecpu calling load_cr4 * 425 us in getmemsize * 280 us in pmap_bootstrap * 205 us in create_pagetables * 10 us in init_param2 * 25 us in pci_early_quirks * 60 us in cninit * 90 us in kdb_init * 105 us in msgbufinit * 20 us in fpuinit * 205 us elsewhere in hammer_time Some of these are unavoidable (e.g. identify_hypervisor uses CPUID and load_cr4 loads the CR4 register, both of which trap to the hypervisor) but others may deserve attention. Sponsored by: https://www.patreon.com/cperciva Differential Revision: https://reviews.freebsd.org/D40325
|
#
b61a5730 |
|
10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-NetBSD identifier is obsolete, drop -NetBSD The SPDX folks have obsoleted the BSD-2-Clause-NetBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
|
#
a78e46a7 |
|
13-Mar-2023 |
Roger Pau Monné <royger@FreeBSD.org> |
xen: take struct size into account for video information The xenpf_dom0_console_t structure can grow as more data is added, and hence we need to check that the fields we accesses have been filled by Xen. The only extra field FreeBSD currently uses is the top 32 bits for the frame buffer physical address. Note that this field is present in all the versions that make the information available from the platform hypercall interface, so the check here is mostly cosmetic, and to remember us that newly added fields require checking the size of the returned data. Fixes: 6f80738b228c ('xen: fetch dom0 video console information from Xen') Sponsored by: Citrix Systems R&D
|
#
6f80738b |
|
20-Nov-2022 |
Roger Pau Monné <royger@FreeBSD.org> |
xen: fetch dom0 video console information from Xen It's possible for Xen to switch the video mode set by the boot loader, so that the information passed in the kernel metadata is no longer valid. Fetch the video mode used by Xen using an hypercall and update the medatada for the kernel to use the correct video mode. Sponsored by: Citrix Systems R&D
|
#
13f34e21 |
|
12-Aug-2022 |
Colin Percival <cperciva@FreeBSD.org> |
PVH: Set bootmethod to PVH Now that we can PVH boot on a non-Xen hypervisor, we shouldn't set machdep.bootmethod to "XEN". Instead, set it to "PVH"; there are other ways to discern the hypervisor. Reviewed by: royger Sponsored by: https://www.patreon.com/cperciva Differential Revision: https://reviews.freebsd.org/D36191
|
#
c4a4011c |
|
12-Aug-2022 |
Colin Percival <cperciva@FreeBSD.org> |
PVH: support whitespace cmdline splitting For historical reasons, Xen kernel command lines have options separated by commas. Every other FreeBSD platform uses whitespace; this is also necessary in PVH in order to support the Firecracker VMM. Allow options to be separated by any combination of commas and whitespace. Reviewed by: imp Sponsored by: https://www.patreon.com/cperciva Differential Revision: https://reviews.freebsd.org/D36190
|
#
a8ea1540 |
|
12-Jul-2022 |
Colin Percival <cperciva@FreeBSD.org> |
x86: Distinguish Xen from non-Xen PVH boots The PVH boot protocol, introduced by Xen, is now used by some non-Xen platforms (e.g. the Firecracker VM) as well. In order to accommodate these, we use CPUID to detect Xen and only perform Xen-specific setup when running on that platform. The "isxen" function duplicates some work done by identcpu.c later in the boot process; but we need it here since this is the very first C code which runs when PVH booting (even before hammer_time). In many places the existing code had xc_printf(...); HYPERVISOR_shutdown(SHUTDOWN_crash); making use of Xen functionality to print a message and shut down; in the places where this idiom can be reached in the non-xen case, we replace it idiom with a CRASH(...) macro which calls those in the Xen case and halts in the non-Xen case. Reviewed by: royger Sponsored by: https://www.patreon.com/cperciva Differential Revision: https://reviews.freebsd.org/D35801
|
#
023a025b |
|
12-Jul-2022 |
Colin Percival <cperciva@FreeBSD.org> |
x86: Add support for PVH version 1 memmap Version 0 of PVH booting uses a Xen hypercall to retrieve the system memory map; in version 1 the memory map can be provided via the start_info structure. Using the memory map from the version 1 start_info structure allows FreeBSD to use PVH booting on systems other than Xen, e.g. on the Firecracker VM. Reviewed by: royger Sponsored by: https://www.patreon.com/cperciva Differential Revision: https://reviews.freebsd.org/D35800
|
#
77cb05db |
|
28-Jun-2022 |
Roger Pau Monné <royger@FreeBSD.org> |
x86/xen: stop assuming kernel memory loading order in PVH Do not assume that start_info will always be loaded at the highest memory address, and instead check the position of all the loaded elements in order to find the last loaded one, and thus a likely safe place to use as early boot allocation memory space. Reported by: markj, cperciva Sponsored by: Citrix Systems R&D Reviewed by: markj Differential revision: https://reviews.freebsd.org/D35628
|
#
ad7dd514 |
|
12-Oct-2021 |
Elliott Mitchell <ehem+freebsd@m5p.com> |
xen: switch to use headers in contrib These headers originate with the Xen project and shouldn't be mixed with the main portion of the FreeBSD kernel. Notably they shouldn't be the target of clean-up commits. Switch to use the headers in sys/contrib/xen. Reviewed by: royger
|
#
e7236a7d |
|
15-Dec-2021 |
Mateusz Guzik <mjg@FreeBSD.org> |
xen: plug some of set-but-not-used vars Sponsored by: Rubicon Communications, LLC ("Netgate")
|
#
8e3c56d6 |
|
29-Aug-2021 |
Dimitry Andric <dim@FreeBSD.org> |
xen: Fix warning by adding KERNBASE to modlist_paddr before casting Clang 13 produces the following warning for hammer_time_xen(): sys/x86/xen/pv.c:183:19: error: the pointer incremented by -2147483648 refers past the last possible element for an array in 64-bit address space containing 256-bit (32-byte) elements (max possible 576460752303423488 elements) [-Werror,-Warray-bounds] (vm_paddr_t)start_info->modlist_paddr + KERNBASE; ^ ~~~~~~~~ sys/xen/interface/arch-x86/hvm/start_info.h:131:5: note: array 'modlist_paddr' declared here uint64_t modlist_paddr; /* Physical address of an array of */ ^ This is because the expression first casts start_info->modlist_paddr to struct hvm_modlist_entry * (via vmpaddr_t), and *then* adds KERNBASE, which is then interpreted as KERNBASE * sizeof(struct hvm_modlist_entry). Instead, parenthesize the addition to get the intended result, and cast it to struct hvm_modlist_entry * afterwards. Also remove the cast to vmpaddr_t since it is not necessary. Reviewed by: royger MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D31711
|
#
9e14ac11 |
|
18-May-2021 |
Roger Pau Monné <royger@FreeBSD.org> |
x86/xen: further PVHv1 removal cleanup The AP startup extern variable declarations are not longer needed, since PVHv2 uses the native AP startup path using the lapic. Remove the declaration and make the variables static to mp_machdep.c Sponsored by: Citrix Systems R&D
|
#
4224dbf4 |
|
17-May-2021 |
Mark Johnston <markj@FreeBSD.org> |
xen: Remove leftover bits missed in commit ac3ede5371 Fixes: ac3ede5371 ("x86/xen: remove PVHv1 code") Reviewed by: royger Differential Revision: https://reviews.freebsd.org/D30316
|
#
ac3ede53 |
|
11-May-2021 |
Roger Pau Monné <royger@FreeBSD.org> |
x86/xen: remove PVHv1 code PVHv1 was officially removed from Xen in 4.9, so just axe the related code from FreeBSD. Note FreeBSD supports PVHv2, which is the replacement for PVHv1. Sponsored by: Citrix Systems R&D Reviewed by: kib, Elliott Mitchell Differential Revision: https://reviews.freebsd.org/D30228
|
#
c93e6ea3 |
|
06-May-2021 |
Mitchell Horne <mhorne@FreeBSD.org> |
xen: remove support for PVHv1 bootpath PVHv1 is a legacy interface supported only by Xen versions 4.4 through 4.9. Reviewed by: royger
|
#
a2495c36 |
|
08-Feb-2021 |
Roger Pau Monné <royger@FreeBSD.org> |
xen/boot: allow specifying boot method when booted from Xen Allow setting the bootmethod variable from the Xen PVH entry point, in order to be able to correctly set the underlying firmware mode when booted as a dom0. Move the bootmethod variable to be defined in x86/cpu_machdep.c instead so it can be shared by both i386 and amd64. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential revision: https://reviews.freebsd.org/D28619
|
#
b6d85a5f |
|
27-Jan-2021 |
Roger Pau Monné <royger@FreeBSD.org> |
stand/multiboot: adjust the protocol between loader and kernel There's a currently ad-hoc protocol to hand off the FreeBSD kernel payload between the loader and the kernel itself when Xen is in the middle of the picture. Such protocol wasn't very resilient to changes to the loader itself, because it relied on moving metadata around to package it using a certain layout. This has proven to be fragile, so replace it with a more robust version. The new protocol requires using a xen_header structure that will be used to pass data between the FreeBSD loader and the FreeBSD kernel when booting in dom0 mode. At the moment the only data conveyed is the offset of the start of the module metadata relative to the start of the module itself. This is a slightly disruptive change since it also requires a change to the kernel which is contained in this patch. In order to update with this change the kernel must be updated before updating the loader, as described in the handbook. Note this is only required when booting a FreeBSD/Xen dom0. This change doesn't affect the normal FreeBSD boot protocol. This fixes booting FreeBSD/Xen in dom0 mode after 3630506b9daec9167a89bc4525638ea45a00769e. Sponsored by: Citrix Systems R&D MFC after: 3 days Reviewed by: tsoome Differential Revision: https://reviews.freebsd.org/D28411
|
#
ab6c81a2 |
|
01-Sep-2020 |
Mateusz Guzik <mjg@FreeBSD.org> |
x86: clean up empty lines in .c and .h files
|
#
3f102f58 |
|
11-Oct-2018 |
Mateusz Guzik <mjg@FreeBSD.org> |
Provide string functions for use before ifuncs get resolved. The change is a no-op for architectures which don't ifunc memset, memcpy nor memmove. Convert places which need them. Xen bits by royger. Reviewed by: kib Approved by: re (gjb) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D17487
|
#
ddbc1b43 |
|
13-Sep-2018 |
Roger Pau Monné <royger@FreeBSD.org> |
xen: fix initial kenv setup for legacy PVH When adding support for the new PVH mode the kenv handling was switched to use a boot time allocated scratch space, however the legacy PVH early boot code was not modified to allocate such space. Approved by: re (gjb) Sponsored by: Citrix Systems R&D
|
#
83a90bff |
|
21-Aug-2018 |
Alan Cox <alc@FreeBSD.org> |
Eliminate kmem_malloc()'s unused arena parameter. (The arena parameter became unused in FreeBSD 12.x as a side-effect of the NUMA-related changes.) Reviewed by: kib, markj Discussed with: jeff, re@ Differential Revision: https://reviews.freebsd.org/D16825
|
#
b0663c33 |
|
19-Jul-2018 |
Roger Pau Monné <royger@FreeBSD.org> |
xen: implement early init helper for PVHv2 In order to setup an initial environment and jump into the generic hammer_time initialization function. Some of the code is shared with PVHv1, while other code is PVHv2 specific. This allows booting FreeBSD as a PVHv2 DomU and Dom0. Sponsored by: Citrix Systems R&D
|
#
cfa0b7b8 |
|
19-Jul-2018 |
Roger Pau Monné <royger@FreeBSD.org> |
xen: remove direct usage of HYPERVISOR_start_info HYPERVISOR_start_info is only available to PV and PVHv1 guests, HVM and PVHv2 guests get this data from HVM parameters that are fetched using a hypercall. Instead provide a set of helper functions that should be used to fetch this data. The helper functions have different implementations depending on whether FreeBSD is running as PVHv1 or HVM/PVHv2 guest type. This helps to cleanup generic Xen code by removing quite a lot of xen_pv_domain and xen_hvm_domain macro usages. Sponsored by: Citrix Systems R&D
|
#
52379d36 |
|
13-Jul-2018 |
Warner Losh <imp@FreeBSD.org> |
Create helper functions for parsing boot args. boot_parse_arg to parse a single arg boot_parse_cmdline to parse a command line string boot_parse_args to parse all the args in a vector boot_howto_to_env Convert howto bits to env vars boot_env_to_howto Return howto mask mased on what's set in the environment. All these routines return an int that's the bitmask of the args translated to RB_* flags. As a special case, the 'S' flag sets the comconsole_speed env var. Any arg that looks like a=b will set the env key 'a' to value 'b'. If =b is omitted, 'a' is set to '1'. This should help us reduce the number of redundant copies of these routines in the tree. It should also give a more uniform experience between platforms. Also, invent a new flag RB_PROBE that's set when 'P' is parsed. On x86 + BIOS, this means 'probe for the keyboard, and if it's not there set both RB_MULTIPLE and RB_SERIAL (which means show the output on both video and serial consoles, but make serial primary). Others it may be some similar concept of probing, but it's loader dependent what, exactly, it means. These routines are suitable for /boot/loader and/or the kernel, though they may not be suitable for the tightly hand-rolled-for-space environments like boot2. Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D16205
|
#
92849603 |
|
24-May-2018 |
Roger Pau Monné <royger@FreeBSD.org> |
xen/pvh: allocate dbg_stack Or else init_secondary will hit a page fault (or write garbage somewhere). Sponsored by: Citrix Systems R&D
|
#
9021fe72 |
|
02-May-2018 |
Roger Pau Monné <royger@FreeBSD.org> |
xen: fix formatting of xen_init_ops No functional change Sponsored by: Citrix Systems R&D
|
#
b345111b |
|
15-Feb-2018 |
Mateusz Guzik <mjg@FreeBSD.org> |
xen: fix smp boot after r328157 mce_stack was left unset leading to early crashes
|
#
ebf5747b |
|
27-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
sys/x86: further adoption of SPDX licensing ID tags. Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
|
#
084d2075 |
|
10-May-2016 |
Edward Tomasz Napierala <trasz@FreeBSD.org> |
Remove misc NULL checks after M_WAITOK allocations. MFC after: 1 month Sponsored by: The FreeBSD Foundation
|
#
69dcb7e7 |
|
01-Jan-2016 |
Ian Lepore <ian@FreeBSD.org> |
Make the 'env' directive described in config(5) work on all architectures, providing compiled-in static environment data that is used instead of any data passed in from a boot loader. Previously 'env' worked only on i386 and arm xscale systems, because it required the MD startup code to examine the global envmode variable and decide whether to use static_env or an environment obtained from the boot loader, and set the global kern_envp accordingly. Most startup code wasn't doing so. Making things even more complex, some mips startup code uses an alternate scheme that involves calling init_static_kenv() to pass an empty buffer and its size, then uses a series of kern_setenv() calls to populate that buffer. Now all MD startup code calls init_static_kenv(), and that routine provides a single point where envmode is checked and the decision is made whether to use the compiled-in static_kenv or the values provided by the MD code. The routine also continues to serve its original purpose for mips; if a non-zero buffer size is passed the routine installs the empty buffer ready to accept kern_setenv() values. Now if the size is zero, the provided buffer full of existing env data is installed. A NULL pointer can be passed if the boot loader provides no env data; this allows the static env to be installed if envmode is set to do so. Most of the work here is a near-mechanical change to call the init function instead of directly setting kern_envp. A notable exception is in xen/pv.c; that code was originally installing a buffer full of preformatted env data along with its non-zero size (like mips code does), which would have allowed kern_setenv() calls to wipe out the preformatted data. Now it passes a zero for the size so that the buffer of data it installs is treated as non-writeable.
|
#
b59f7a7a |
|
23-Dec-2015 |
Enji Cooper <ngie@FreeBSD.org> |
Remove redundant declarations in sys/x86/xen which are now handled in other sys/x86 headers Differential Revision: https://reviews.freebsd.org/D4685 X-MFC with: r291949 Sponsored by: EMC / Isilon Storage Division
|
#
edc82223 |
|
10-Aug-2015 |
Konstantin Belousov <kib@FreeBSD.org> |
Make kstack_pages a tunable on arm, x86, and powepc. On i386, the initial thread stack is not adjusted by the tunable, the stack is allocated too early to get access to the kernel environment. See TD0_KSTACK_PAGES for the thread0 stack sizing on i386. The tunable was tested on x86 only. From the visual inspection, it seems that it might work on arm and powerpc. The arm USPACE_SVC_STACK_TOP and powerpc USPACE macros seems to be already incorrect for the threads with non-default kstack size. I only changed the macros to use variable instead of constant, since I cannot test. On arm64, mips and sparc64, some static data structures are sized by KSTACK_PAGES, so the tunable is disabled. Sponsored by: The FreeBSD Foundation MFC after: 2 week
|
#
721555e7 |
|
16-Jul-2015 |
Zbigniew Bodek <zbb@FreeBSD.org> |
Fix KSTACK_PAGES issue when the default value was changed in KERNCONF If KSTACK_PAGES was changed to anything alse than the default, the value from param.h was taken instead in some places and the value from KENRCONF in some others. This resulted in inconsistency which caused corruption in SMP envorinment. Ensure all places where KSTACK_PAGES are used the opt_kstack_pages.h is included. The file opt_kstack_pages.h could not be included in param.h because was breaking the toolchain compilation. Reviewed by: kib Obtained from: Semihalf Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D3094
|
#
b829c841 |
|
19-Jan-2015 |
Roger Pau Monné <royger@FreeBSD.org> |
loader: fix the size of MODINFOMD_MODULEP The data in MODINFOMD_MODULEP is packed by the loader as a 4 byte type, but the amd64 kernel expects a vm_paddr_t, which is of size 8 bytes. Fix this by saving it as 8 bytes in the loader and retrieving it using the proper type in the kernel. Sponsored by: Citrix Systems R&D
|
#
ca49b334 |
|
15-Jan-2015 |
Roger Pau Monné <royger@FreeBSD.org> |
loader: implement multiboot support for Xen Dom0 Implement a subset of the multiboot specification in order to boot Xen and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot implementation is tailored to boot Xen and FreeBSD Dom0, and it will most surely fail to boot any other multiboot compilant kernel. In order to detect and boot the Xen microkernel, two new file formats are added to the bootloader, multiboot and multiboot_obj. Multiboot support must be tested before regular ELF support, since Xen is a multiboot kernel that also uses ELF. After a multiboot kernel is detected, all the other loaded kernels/modules are parsed by the multiboot_obj format. The layout of the loaded objects in memory is the following; first the Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to long mode by itself), after that the FreeBSD kernel is loaded as a RAW file (Xen will parse and load it using it's internal ELF loader), and finally the metadata and the modules are loaded using the native FreeBSD way. After everything is loaded we jump into Xen's entry point using a small trampoline. The order of the multiboot modules passed to Xen is the following, the first module is the RAW FreeBSD kernel, and the second module is the metadata and the FreeBSD modules. Since Xen will relocate the memory position of the second multiboot module (the one that contains the metadata and native FreeBSD modules), we need to stash the original modulep address inside of the metadata itself in order to recalculate its position once booted. This also means the metadata must come before the loaded modules, so after loading the FreeBSD kernel a portion of memory is reserved in order to place the metadata before booting. In order to tell the loader to boot Xen and then the FreeBSD kernel the following has to be added to the /boot/loader.conf file: xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga" xen_kernel="/boot/xen" The first argument contains the command line that will be passed to the Xen kernel, while the second argument is the path to the Xen kernel itself. This can also be done manually from the loader command line, by for example typing the following set of commands: OK unload OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga OK load kernel OK load zfs OK load if_tap OK load ... OK boot Sponsored by: Citrix Systems R&D Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D517 For the Forth bits: Submitted by: Julien Grall <julien.grall AT citrix.com>
|
#
b2537024 |
|
22-Oct-2014 |
Roger Pau Monné <royger@FreeBSD.org> |
xen: fix usage of kern_getenv in PVH code The value returned by kern_getenv should be freed using freeenv. Reported by: Coverity CID: 1248852 Sponsored by: Citrix Systems R&D
|
#
2be111bf |
|
16-Oct-2014 |
Davide Italiano <davide@FreeBSD.org> |
Follow up to r225617. In order to maximize the re-usability of kernel code in userland rename in-kernel getenv()/setenv() to kern_setenv()/kern_getenv(). This fixes a namespace collision with libc symbols. Submitted by: kmacy Tested by: make universe
|
#
44e06d15 |
|
30-Sep-2014 |
Roger Pau Monné <royger@FreeBSD.org> |
msi: add Xen MSI implementation This patch adds support for MSI interrupts when running on Xen. Apart from adding the Xen related code needed in order to register MSI interrupts this patch also makes the msi_init function a hook in init_ops, so different MSI implementations can have different initialization functions. Sponsored by: Citrix Systems R&D xen/interface/physdev.h: - Add the MAP_PIRQ_TYPE_MULTI_MSI to map multi-vector MSI to the Xen public interface. x86/include/init.h: - Add a hook for setting custom msi_init methods. amd64/amd64/machdep.c: i386/i386/machdep.c: - Set the default msi_init hook to point to the native MSI initialization method. x86/xen/pv.c: - Set the Xen MSI init hook when running as a Xen guest. x86/x86/local_apic.c: - Call the msi_init hook instead of directly calling msi_init. xen/xen_intr.h: x86/xen/xen_intr.c: - Introduce support for registering/releasing MSI interrupts with Xen. - The MSI interrupts will use the same PIC as the IO APIC interrupts. xen/xen_msi.h: x86/xen/xen_msi.c: - Introduce a Xen MSI implementation. x86/xen/xen_nexus.c: - Overwrite the default MSI hooks in the Xen Nexus to use the Xen MSI implementation. x86/xen/xen_pci.c: - Introduce a Xen specific PCI bus that inherits from the ACPI PCI bus and overwrites the native MSI methods. - This is needed because when running under Xen the MSI messages used to configure MSI interrupts on PCI devices are written by Xen itself. dev/acpica/acpi_pci.c: - Lower the quality of the ACPI PCI bus so the newly introduced Xen PCI bus can take over when needed. conf/files.i386: conf/files.amd64: - Add the newly created files to the build process.
|
#
9b4e54d3 |
|
26-Sep-2014 |
Roger Pau Monné <royger@FreeBSD.org> |
xen: add proper copyright attribution Noted by: jmallett
|
#
c98a2727 |
|
25-Sep-2014 |
Roger Pau Monné <royger@FreeBSD.org> |
ddb: allow specifying the exact address of the symtab and strtab When the FreeBSD kernel is loaded from Xen the symtab and strtab are not loaded the same way as the native boot loader. This patch adds three new global variables to ddb that can be used to specify the exact position and size of those tables, so they can be directly used as parameters to db_add_symbol_table. A new helper is introduced, so callers that used to set ksym_start and ksym_end can use this helper to set the new variables. It also adds support for loading them from the Xen PVH port, that was previously missing those tables. Sponsored by: Citrix Systems R&D Reviewed by: kib ddb/db_main.c: - Add three new global variables: ksymtab, kstrtab, ksymtab_size that can be used to specify the position and size of the symtab and strtab. - Use those new variables in db_init in order to call db_add_symbol_table. - Move the logic in db_init to db_fetch_symtab in order to set ksymtab, kstrtab, ksymtab_size from ksym_start and ksym_end. ddb/ddb.h: - Add prototype for db_fetch_ksymtab. - Declate the extern variables ksymtab, kstrtab and ksymtab_size. x86/xen/pv.c: - Add support for finding the symtab and strtab when booted as a Xen PVH guest. Since Xen loads the symtab and strtab as NetBSD expects to find them we have to adapt and use the same method. amd64/amd64/machdep.c: arm/arm/machdep.c: i386/i386/machdep.c: mips/mips/machdep.c: pc98/pc98/machdep.c: powerpc/aim/machdep.c: powerpc/booke/machdep.c: sparc64/sparc64/machdep.c: - Use the newly introduced db_fetch_ksymtab in order to set ksymtab, kstrtab and ksymtab_size.
|
#
fae92773 |
|
15-Jul-2014 |
John Baldwin <jhb@FreeBSD.org> |
Fix build with SMP disabled. CR: https://phabric.freebsd.org/D407 Reviewed by: royger
|
#
842471b3 |
|
16-Jun-2014 |
Roger Pau Monné <royger@FreeBSD.org> |
xen: add hooks for Xen PV APIC Create the necessary hooks in order to provide a Xen PV APIC implementation that can be used on PVH. Most of the lapic ops shouldn't be called on Xen, since we trap those operations at a higher layer. Sponsored by: Citrix Systems R&D Approved by: gibbs x86/xen/hvm.c: x86/xen/xen_apic.c: - Move IPI related code to xen_apic.c x86/xen/xen_apic.c: - Introduce Xen PV APIC implementation, most of the functions of the lapic interface should never be called when running as PV(H) guest, so make sure FreeBSD panics when trying to use one of those. - Define the Xen APIC implementation in xen_apic_ops. xen/xen_pv.h: - Extern declaration of the xen_apic struct. x86/xen/pv.c: - Use xen_apic_ops as apic_ops when running as PVH guest. conf/files.amd64: conf/files.i386: - Include the xen_apic.c file in the build of i386/amd64 kernels using XENHVM.
|
#
5f35f84f |
|
16-Jun-2014 |
Roger Pau Monné <royger@FreeBSD.org> |
xen: fix style in pv.c Fix the lenght of some comments, and also add proper indentation to xen_init_ops Sponsored by: Citrix Systems R&D Approved by: gibbs
|
#
b7df74ee |
|
05-Apr-2014 |
Warner Losh <imp@FreeBSD.org> |
Make this compile with gcc. Submitted by: royger@
|
#
079f7ef8 |
|
11-Mar-2014 |
Roger Pau Monné <royger@FreeBSD.org> |
xen: add a hook to perform AP startup AP startup on PVH follows the PV method, so we need to add a hook in order to diverge from bare metal. Approved by: gibbs Sponsored by: Citrix Systems R&D amd64/amd64/machdep.c: - Add hook for start_all_aps on native (using native_start_all_aps defined in mp_machdep). amd64/amd64/mp_machdep.c: - Make some variables global because they will also be used by the Xen PVH AP startup code. - Use the start_all_aps hook to start APs. - Rename start_all_aps to native_start_all_aps. amd64/include/smp.h: - Add declaration for native_start_all_aps. x86/include/init.h: - Declare start_all_aps hook in init_ops. x86/xen/pv.c: - Pick external declarations from mp_machdep. - Introduce Xen PV code to start APs on PVH. - Set start_all_aps init hook to use the Xen PVH implementation.
|
#
1e69553e |
|
11-Mar-2014 |
Roger Pau Monné <royger@FreeBSD.org> |
xen: implement hook to fetch and parse e820 memory map e820 memory map is fetched using a hypercall under Xen PVH, so add a hook to init_ops in oder to diverge from bare metal and implement a Xen variant. Approved by: gibbs Sponsored by: Citrix Systems R&D x86/include/init.h: - Add a parse_memmap hook to init_ops, that will be called to fetch and parse the memory map. amd64/amd64/machdep.c: - Decouple the fetch and the parse of the memmap, so the parse function can be shared with Xen code. - Move code around in order to implement the parse_memmap hook. amd64/include/pc/bios.h: - Declare bios_add_smap_entries (implemented in machdep.c). x86/xen/pv.c: - Implement fetching of e820 memmap when running as a PVH guest by using the XENMEM_memory_map hypercall.
|
#
5f05c794 |
|
11-Mar-2014 |
Roger Pau Monné <royger@FreeBSD.org> |
xen: implement an early timer for Xen PVH When running as a PVH guest, there's no emulated i8254, so we need to use the Xen PV timer as the early source for DELAY. This change allows for different implementations of the early DELAY function and implements a Xen variant for it. Approved by: gibbs Sponsored by: Citrix Systems R&D dev/xen/timer/timer.c: dev/xen/timer/timer.h: - Implement Xen early delay functions using the PV timer and declare them. x86/include/init.h: - Add hooks for early clock source initialization and early delay functions. i386/i386/machdep.c: pc98/pc98/machdep.c: amd64/amd64/machdep.c: - Set early delay hooks to use the i8254 on bare metal. - Use clock_init (that will in turn make use of init_ops) to initialize the early clock source. amd64/include/clock.h: i386/include/clock.h: - Declare i8254_delay and clock_init. i386/xen/clock.c: - Rename DELAY to i8254_delay. x86/isa/clock.c: - Introduce clock_init that will take care of initializing the early clock by making use of the init_ops hooks. - Move non ISA related delay functions to the newly introduced delay file. x86/x86/delay.c: - Add moved delay related functions. - Implement generic DELAY function that will use the init_ops hooks. x86/xen/pv.c: - Set PVH hooks for the early delay related functions in init_ops. conf/files.amd64: conf/files.i386: conf/files.pc98: - Add delay.c to the kernel build.
|
#
97baeefd |
|
11-Mar-2014 |
Roger Pau Monné <royger@FreeBSD.org> |
amd64: introduce hook for custom preload metadata parsers Add hooks to amd64 in order to have diverging implementations, since on Xen PV the metadata is passed to the kernel in a different form. Approbed by: gibbs Sponsored by: Citrix Systems R&D amd64/amd64/machdep.c: - Define init_ops for native. - Put native code inside of native_parse_preload_data hook. - Call the parse_preload_data in order to fill the metadata info. x86/include/init.h: - Declare the init_ops struct. x86/xen/pv.c: - Declare xen_init_ops that contains the Xen PV implementation of init_ops. - Implement the parse_preload_data for Xen PVH, the info is fetched from HYPERVISOR_start_info->cmd_line as provided by Xen.
|
#
aa389b4f |
|
11-Mar-2014 |
Roger Pau Monné <royger@FreeBSD.org> |
howto_names: unify declaration Approved by: gibbs Sponsored by: Citrix Systems R&D boot/i386/efi/bootinfo.c: boot/i386/libi386/bootinfo.c: boot/ia64/common/bootinfo.c: boot/powerpc/ofw/metadata.c: boot/powerpc/ps3/metadata.c: boot/sparc64/loader/metadata.c: boot/uboot/common/metadata.c: boot/userboot/userboot/bootinfo.c: i386/xen/xen_machdep.c: - Include sys/boot.h - Remove custom definition of howto_names. sys/boot.h: - Define howto_names. x86/xen/pv.c: - Include sys/boot.h
|
#
c203fa69 |
|
11-Mar-2014 |
Roger Pau Monné <royger@FreeBSD.org> |
xen: add and enable Xen console for PVH guests This adds and enables the PV console used on XEN kernels to GENERIC/XENHVM kernels in order for it to be used on PVH. Approved by: gibbs Sponsored by: Citrix Systems R&D dev/xen/console/console.c: - Define console_page. - Move xc_printf debug function from i386 XEN code to generic console code. - Rework xc_printf. - Use xen_initial_domain instead of open-coded checks for Dom0. - Gate the attach of the PV console to PV(H) guests. dev/xen/console/xencons_ring.c: - Allow the PV Xen console to output earlier by directly signaling the event channel in start_info if the event channel is not yet initialized. - Use HYPERVISOR_start_info instead of xen_start_info. i386/include/xen/xen-os.h: - Remove prototype for xc_printf since it's now declared in global xen-os.h i386/xen/xen_machdep.c: - Remove previous version of xc_printf. - Remove definition of console_page (now it's defined in the console itself). - Fix some printf formatting errors. x86/xen/pv.c: - Add some early boot debug messages using xc_printf. - Set console_page based on the value passed in start_info. xen/xen-os.h: - Declare console_page and add prototype for xc_printf.
|
#
1a9cdd37 |
|
11-Mar-2014 |
Roger Pau Monné <royger@FreeBSD.org> |
xen: add PV/PVH kernel entry point Add the PV/PVH entry point and the low level functions for PVH early initialization. Approved by: gibbs Sponsored by: Citrix Systems R&D amd64/amd64/genassym.c: - Add __FreeBSD_version define to assym.s so it can be used for the Xen notes. amd64/amd64/locore.S: - Make bootstack global so it can be used from Xen kernel entry point. amd64/amd64/xen-locore.S: - Add Xen notes to the kernel. - Add the Xen PV entry point, that is going to call hammer_time_xen. amd64/include/asmacros.h: - Add ELFNOTE macros. i386/xen/xen_machdep.c: - Define HYPERVISOR_start_info for the XEN i386 PV port, which is going to be used in some shared code between PV and PVH. x86/xen/hvm.c: - Define HYPERVISOR_start_info for the PVH port. x86/xen/pv.c: - Introduce hammer_time_xen which is going to perform early setup for Xen PVH: - Setup shared Xen variables start_info, shared_info and xen_store. - Set guest type. - Create initial page tables as FreeBSD expects to find them. - Call into native init function (hammer_time). xen/xen-os.h: - Declare HYPERVISOR_start_info. conf/files.amd64: - Add amd64/amd64/locore.S and x86/xen/pv.c to the list of files.
|