2017-11-27 15:11:47 +00:00
|
|
|
/*-
|
|
|
|
* SPDX-License-Identifier: BSD-2-Clause-NetBSD
|
|
|
|
*
|
2014-03-11 10:07:01 +00:00
|
|
|
* Copyright (c) 2004 Christian Limpach.
|
|
|
|
* Copyright (c) 2004-2006,2008 Kip Macy
|
2014-09-26 09:05:55 +00:00
|
|
|
* Copyright (c) 2008 The NetBSD Foundation, Inc.
|
2014-03-11 10:07:01 +00:00
|
|
|
* Copyright (c) 2013 Roger Pau Monné <roger.pau@citrix.com>
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS AS IS'' AND
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <sys/cdefs.h>
|
|
|
|
__FBSDID("$FreeBSD$");
|
|
|
|
|
2014-09-25 08:28:10 +00:00
|
|
|
#include "opt_ddb.h"
|
2015-07-16 10:46:52 +00:00
|
|
|
#include "opt_kstack_pages.h"
|
2014-09-25 08:28:10 +00:00
|
|
|
|
2014-03-11 10:07:01 +00:00
|
|
|
#include <sys/param.h>
|
|
|
|
#include <sys/bus.h>
|
|
|
|
#include <sys/kernel.h>
|
|
|
|
#include <sys/reboot.h>
|
|
|
|
#include <sys/systm.h>
|
2014-03-11 10:27:57 +00:00
|
|
|
#include <sys/malloc.h>
|
2014-09-25 08:28:10 +00:00
|
|
|
#include <sys/linker.h>
|
2014-03-11 10:07:01 +00:00
|
|
|
#include <sys/lock.h>
|
|
|
|
#include <sys/rwlock.h>
|
2014-03-11 10:13:06 +00:00
|
|
|
#include <sys/boot.h>
|
2014-03-11 10:15:25 +00:00
|
|
|
#include <sys/ctype.h>
|
2014-03-11 10:27:57 +00:00
|
|
|
#include <sys/mutex.h>
|
|
|
|
#include <sys/smp.h>
|
2014-03-11 10:07:01 +00:00
|
|
|
|
|
|
|
#include <vm/vm.h>
|
|
|
|
#include <vm/vm_extern.h>
|
|
|
|
#include <vm/vm_kern.h>
|
|
|
|
#include <vm/vm_page.h>
|
|
|
|
#include <vm/vm_map.h>
|
|
|
|
#include <vm/vm_object.h>
|
|
|
|
#include <vm/vm_pager.h>
|
|
|
|
#include <vm/vm_param.h>
|
|
|
|
|
2014-07-15 15:40:33 +00:00
|
|
|
#include <machine/intr_machdep.h>
|
|
|
|
#include <x86/apicvar.h>
|
2014-03-11 10:15:25 +00:00
|
|
|
#include <x86/init.h>
|
2014-03-11 10:23:03 +00:00
|
|
|
#include <machine/pc/bios.h>
|
2014-03-11 10:27:57 +00:00
|
|
|
#include <machine/smp.h>
|
2014-09-30 16:46:45 +00:00
|
|
|
#include <machine/intr_machdep.h>
|
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>
2015-01-15 16:27:20 +00:00
|
|
|
#include <machine/metadata.h>
|
2014-03-11 10:15:25 +00:00
|
|
|
|
2014-03-11 10:07:01 +00:00
|
|
|
#include <xen/xen-os.h>
|
|
|
|
#include <xen/hypervisor.h>
|
2014-04-05 22:43:18 +00:00
|
|
|
#include <xen/xenstore/xenstorevar.h>
|
2014-06-16 08:43:45 +00:00
|
|
|
#include <xen/xen_pv.h>
|
2014-09-30 16:46:45 +00:00
|
|
|
#include <xen/xen_msi.h>
|
2014-03-11 10:07:01 +00:00
|
|
|
|
2014-03-11 10:27:57 +00:00
|
|
|
#include <xen/interface/vcpu.h>
|
|
|
|
|
2014-03-11 10:20:42 +00:00
|
|
|
#include <dev/xen/timer/timer.h>
|
|
|
|
|
2014-09-25 08:28:10 +00:00
|
|
|
#ifdef DDB
|
|
|
|
#include <ddb/ddb.h>
|
|
|
|
#endif
|
|
|
|
|
2014-03-11 10:07:01 +00:00
|
|
|
/* Native initial function */
|
|
|
|
extern u_int64_t hammer_time(u_int64_t, u_int64_t);
|
|
|
|
/* Xen initial function */
|
|
|
|
uint64_t hammer_time_xen(start_info_t *, uint64_t);
|
|
|
|
|
2014-03-11 10:23:03 +00:00
|
|
|
#define MAX_E820_ENTRIES 128
|
|
|
|
|
2014-03-11 10:15:25 +00:00
|
|
|
/*--------------------------- Forward Declarations ---------------------------*/
|
|
|
|
static caddr_t xen_pv_parse_preload_data(u_int64_t);
|
2014-03-11 10:23:03 +00:00
|
|
|
static void xen_pv_parse_memmap(caddr_t, vm_paddr_t *, int *);
|
2014-03-11 10:15:25 +00:00
|
|
|
|
2014-03-11 10:27:57 +00:00
|
|
|
#ifdef SMP
|
|
|
|
static int xen_pv_start_all_aps(void);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*---------------------------- Extern Declarations ---------------------------*/
|
|
|
|
#ifdef SMP
|
|
|
|
/* Variables used by amd64 mp_machdep to start APs */
|
|
|
|
extern char *doublefault_stack;
|
2018-02-15 07:23:41 +00:00
|
|
|
extern char *mce_stack;
|
2014-03-11 10:27:57 +00:00
|
|
|
extern char *nmi_stack;
|
2018-05-24 10:22:57 +00:00
|
|
|
extern char *dbg_stack;
|
2014-03-11 10:27:57 +00:00
|
|
|
#endif
|
|
|
|
|
2014-09-25 08:28:10 +00:00
|
|
|
/*
|
|
|
|
* Placed by the linker at the end of the bss section, which is the last
|
|
|
|
* section loaded by Xen before loading the symtab and strtab.
|
|
|
|
*/
|
|
|
|
extern uint32_t end;
|
|
|
|
|
2014-03-11 10:15:25 +00:00
|
|
|
/*-------------------------------- Global Data -------------------------------*/
|
|
|
|
/* Xen init_ops implementation. */
|
|
|
|
struct init_ops xen_init_ops = {
|
2014-06-16 08:41:57 +00:00
|
|
|
.parse_preload_data = xen_pv_parse_preload_data,
|
|
|
|
.early_clock_source_init = xen_clock_init,
|
|
|
|
.early_delay = xen_delay,
|
|
|
|
.parse_memmap = xen_pv_parse_memmap,
|
2014-03-11 10:27:57 +00:00
|
|
|
#ifdef SMP
|
2014-06-16 08:41:57 +00:00
|
|
|
.start_all_aps = xen_pv_start_all_aps,
|
2014-03-11 10:27:57 +00:00
|
|
|
#endif
|
2018-05-02 10:20:55 +00:00
|
|
|
.msi_init = xen_msi_init,
|
2014-03-11 10:15:25 +00:00
|
|
|
};
|
|
|
|
|
2014-03-11 10:23:03 +00:00
|
|
|
static struct bios_smap xen_smap[MAX_E820_ENTRIES];
|
|
|
|
|
2018-07-19 07:54:45 +00:00
|
|
|
static start_info_t *legacy_start_info;
|
|
|
|
|
|
|
|
/*----------------------- Legacy PVH start_info accessors --------------------*/
|
|
|
|
static vm_paddr_t
|
|
|
|
legacy_get_xenstore_mfn(void)
|
|
|
|
{
|
|
|
|
|
|
|
|
return (legacy_start_info->store_mfn);
|
|
|
|
}
|
|
|
|
|
|
|
|
static evtchn_port_t
|
|
|
|
legacy_get_xenstore_evtchn(void)
|
|
|
|
{
|
|
|
|
|
|
|
|
return (legacy_start_info->store_evtchn);
|
|
|
|
}
|
|
|
|
|
|
|
|
static vm_paddr_t
|
|
|
|
legacy_get_console_mfn(void)
|
|
|
|
{
|
|
|
|
|
|
|
|
return (legacy_start_info->console.domU.mfn);
|
|
|
|
}
|
|
|
|
|
|
|
|
static evtchn_port_t
|
|
|
|
legacy_get_console_evtchn(void)
|
|
|
|
{
|
|
|
|
|
|
|
|
return (legacy_start_info->console.domU.evtchn);
|
|
|
|
}
|
|
|
|
|
|
|
|
static uint32_t
|
|
|
|
legacy_get_start_flags(void)
|
|
|
|
{
|
|
|
|
|
|
|
|
return (legacy_start_info->flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct hypervisor_info legacy_info = {
|
|
|
|
.get_xenstore_mfn = legacy_get_xenstore_mfn,
|
|
|
|
.get_xenstore_evtchn = legacy_get_xenstore_evtchn,
|
|
|
|
.get_console_mfn = legacy_get_console_mfn,
|
|
|
|
.get_console_evtchn = legacy_get_console_evtchn,
|
|
|
|
.get_start_flags = legacy_get_start_flags,
|
|
|
|
};
|
|
|
|
|
2014-03-11 10:15:25 +00:00
|
|
|
/*-------------------------------- Xen PV init -------------------------------*/
|
2014-03-11 10:07:01 +00:00
|
|
|
/*
|
2018-07-19 07:54:45 +00:00
|
|
|
* First function called by the Xen legacy PVH boot sequence.
|
2014-03-11 10:07:01 +00:00
|
|
|
*
|
|
|
|
* Set some Xen global variables and prepare the environment so it is
|
|
|
|
* as similar as possible to what native FreeBSD init function expects.
|
|
|
|
*/
|
|
|
|
uint64_t
|
|
|
|
hammer_time_xen(start_info_t *si, uint64_t xenstack)
|
|
|
|
{
|
|
|
|
uint64_t physfree;
|
|
|
|
uint64_t *PT4 = (u_int64_t *)xenstack;
|
|
|
|
uint64_t *PT3 = (u_int64_t *)(xenstack + PAGE_SIZE);
|
|
|
|
uint64_t *PT2 = (u_int64_t *)(xenstack + 2 * PAGE_SIZE);
|
|
|
|
int i;
|
|
|
|
|
|
|
|
xen_domain_type = XEN_PV_DOMAIN;
|
|
|
|
vm_guest = VM_GUEST_XEN;
|
|
|
|
|
|
|
|
if ((si == NULL) || (xenstack == 0)) {
|
2014-03-11 10:09:23 +00:00
|
|
|
xc_printf("ERROR: invalid start_info or xen stack, halting\n");
|
2014-03-11 10:07:01 +00:00
|
|
|
HYPERVISOR_shutdown(SHUTDOWN_crash);
|
|
|
|
}
|
|
|
|
|
2014-03-11 10:09:23 +00:00
|
|
|
xc_printf("FreeBSD PVH running on %s\n", si->magic);
|
|
|
|
|
2014-03-11 10:07:01 +00:00
|
|
|
/* We use 3 pages of xen stack for the boot pagetables */
|
|
|
|
physfree = xenstack + 3 * PAGE_SIZE - KERNBASE;
|
|
|
|
|
|
|
|
/* Setup Xen global variables */
|
2018-07-19 07:54:45 +00:00
|
|
|
legacy_start_info = si;
|
2014-03-11 10:07:01 +00:00
|
|
|
HYPERVISOR_shared_info =
|
|
|
|
(shared_info_t *)(si->shared_info + KERNBASE);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Use the stack Xen gives us to build the page tables
|
|
|
|
* as native FreeBSD expects to find them (created
|
|
|
|
* by the boot trampoline).
|
|
|
|
*/
|
|
|
|
for (i = 0; i < (PAGE_SIZE / sizeof(uint64_t)); i++) {
|
2014-06-16 08:41:57 +00:00
|
|
|
/*
|
|
|
|
* Each slot of the level 4 pages points
|
|
|
|
* to the same level 3 page
|
|
|
|
*/
|
2014-03-11 10:07:01 +00:00
|
|
|
PT4[i] = ((uint64_t)&PT3[0]) - KERNBASE;
|
|
|
|
PT4[i] |= PG_V | PG_RW | PG_U;
|
|
|
|
|
2014-06-16 08:41:57 +00:00
|
|
|
/*
|
|
|
|
* Each slot of the level 3 pages points
|
|
|
|
* to the same level 2 page
|
|
|
|
*/
|
2014-03-11 10:07:01 +00:00
|
|
|
PT3[i] = ((uint64_t)&PT2[0]) - KERNBASE;
|
|
|
|
PT3[i] |= PG_V | PG_RW | PG_U;
|
|
|
|
|
2014-06-16 08:41:57 +00:00
|
|
|
/*
|
|
|
|
* The level 2 page slots are mapped with
|
|
|
|
* 2MB pages for 1GB.
|
|
|
|
*/
|
2014-03-11 10:07:01 +00:00
|
|
|
PT2[i] = i * (2 * 1024 * 1024);
|
|
|
|
PT2[i] |= PG_V | PG_RW | PG_PS | PG_U;
|
|
|
|
}
|
|
|
|
load_cr3(((uint64_t)&PT4[0]) - KERNBASE);
|
|
|
|
|
2014-03-11 10:15:25 +00:00
|
|
|
/* Set the hooks for early functions that diverge from bare metal */
|
|
|
|
init_ops = xen_init_ops;
|
2014-06-16 08:43:45 +00:00
|
|
|
apic_ops = xen_apic_ops;
|
2018-07-19 07:54:45 +00:00
|
|
|
hypervisor_info = legacy_info;
|
2014-03-11 10:15:25 +00:00
|
|
|
|
2014-03-11 10:07:01 +00:00
|
|
|
/* Now we can jump into the native init function */
|
|
|
|
return (hammer_time(0, physfree));
|
|
|
|
}
|
2014-03-11 10:15:25 +00:00
|
|
|
|
|
|
|
/*-------------------------------- PV specific -------------------------------*/
|
2014-03-11 10:27:57 +00:00
|
|
|
#ifdef SMP
|
|
|
|
static bool
|
|
|
|
start_xen_ap(int cpu)
|
|
|
|
{
|
|
|
|
struct vcpu_guest_context *ctxt;
|
|
|
|
int ms, cpus = mp_naps;
|
2015-08-10 17:18:21 +00:00
|
|
|
const size_t stacksize = kstack_pages * PAGE_SIZE;
|
2014-03-11 10:27:57 +00:00
|
|
|
|
|
|
|
/* allocate and set up an idle stack data page */
|
|
|
|
bootstacks[cpu] =
|
|
|
|
(void *)kmem_malloc(kernel_arena, stacksize, M_WAITOK | M_ZERO);
|
|
|
|
doublefault_stack =
|
|
|
|
(char *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZERO);
|
2018-02-15 07:23:41 +00:00
|
|
|
mce_stack =
|
|
|
|
(char *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZERO);
|
2014-03-11 10:27:57 +00:00
|
|
|
nmi_stack =
|
|
|
|
(char *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZERO);
|
2018-05-24 10:22:57 +00:00
|
|
|
dbg_stack =
|
|
|
|
(void *)kmem_malloc(kernel_arena, PAGE_SIZE, M_WAITOK | M_ZERO);
|
2014-03-11 10:27:57 +00:00
|
|
|
dpcpu =
|
|
|
|
(void *)kmem_malloc(kernel_arena, DPCPU_SIZE, M_WAITOK | M_ZERO);
|
|
|
|
|
2015-08-10 17:18:21 +00:00
|
|
|
bootSTK = (char *)bootstacks[cpu] + kstack_pages * PAGE_SIZE - 8;
|
2014-03-11 10:27:57 +00:00
|
|
|
bootAP = cpu;
|
|
|
|
|
|
|
|
ctxt = malloc(sizeof(*ctxt), M_TEMP, M_WAITOK | M_ZERO);
|
|
|
|
|
|
|
|
ctxt->flags = VGCF_IN_KERNEL;
|
|
|
|
ctxt->user_regs.rip = (unsigned long) init_secondary;
|
|
|
|
ctxt->user_regs.rsp = (unsigned long) bootSTK;
|
|
|
|
|
|
|
|
/* Set the AP to use the same page tables */
|
|
|
|
ctxt->ctrlreg[3] = KPML4phys;
|
|
|
|
|
|
|
|
if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
|
|
|
|
panic("unable to initialize AP#%d", cpu);
|
|
|
|
|
|
|
|
free(ctxt, M_TEMP);
|
|
|
|
|
|
|
|
/* Launch the vCPU */
|
|
|
|
if (HYPERVISOR_vcpu_op(VCPUOP_up, cpu, NULL))
|
|
|
|
panic("unable to start AP#%d", cpu);
|
|
|
|
|
|
|
|
/* Wait up to 5 seconds for it to start. */
|
|
|
|
for (ms = 0; ms < 5000; ms++) {
|
|
|
|
if (mp_naps > cpus)
|
|
|
|
return (true);
|
|
|
|
DELAY(1000);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (false);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
xen_pv_start_all_aps(void)
|
|
|
|
{
|
|
|
|
int cpu;
|
|
|
|
|
|
|
|
mtx_init(&ap_boot_mtx, "ap boot", NULL, MTX_SPIN);
|
|
|
|
|
|
|
|
for (cpu = 1; cpu < mp_ncpus; cpu++) {
|
|
|
|
|
|
|
|
/* attempt to start the Application Processor */
|
|
|
|
if (!start_xen_ap(cpu))
|
|
|
|
panic("AP #%d failed to start!", cpu);
|
|
|
|
|
|
|
|
CPU_SET(cpu, &all_cpus); /* record AP in CPU map */
|
|
|
|
}
|
|
|
|
|
|
|
|
return (mp_naps);
|
|
|
|
}
|
|
|
|
#endif /* SMP */
|
|
|
|
|
2014-03-11 10:15:25 +00:00
|
|
|
/*
|
|
|
|
* Functions to convert the "extra" parameters passed by Xen
|
|
|
|
* into FreeBSD boot options.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
xen_pv_set_env(void)
|
|
|
|
{
|
|
|
|
char *cmd_line_next, *cmd_line;
|
|
|
|
size_t env_size;
|
|
|
|
|
2018-07-19 07:54:45 +00:00
|
|
|
cmd_line = legacy_start_info->cmd_line;
|
|
|
|
env_size = sizeof(legacy_start_info->cmd_line);
|
2014-03-11 10:15:25 +00:00
|
|
|
|
|
|
|
/* Skip leading spaces */
|
|
|
|
for (; isspace(*cmd_line) && (env_size != 0); cmd_line++)
|
|
|
|
env_size--;
|
|
|
|
|
|
|
|
/* Replace ',' with '\0' */
|
|
|
|
for (cmd_line_next = cmd_line; strsep(&cmd_line_next, ",") != NULL;)
|
|
|
|
;
|
|
|
|
|
2016-01-02 02:53:48 +00:00
|
|
|
init_static_kenv(cmd_line, 0);
|
2014-03-11 10:15:25 +00:00
|
|
|
}
|
|
|
|
|
2014-09-25 08:28:10 +00:00
|
|
|
#ifdef DDB
|
|
|
|
/*
|
|
|
|
* The way Xen loads the symtab is different from the native boot loader,
|
|
|
|
* because it's tailored for NetBSD. So we have to adapt and use the same
|
|
|
|
* method as NetBSD. Portions of the code below have been picked from NetBSD:
|
|
|
|
* sys/kern/kern_ksyms.c CVS Revision 1.71.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
xen_pv_parse_symtab(void)
|
|
|
|
{
|
|
|
|
Elf_Ehdr *ehdr;
|
|
|
|
Elf_Shdr *shdr;
|
|
|
|
vm_offset_t sym_end;
|
|
|
|
uint32_t size;
|
|
|
|
int i, j;
|
|
|
|
|
|
|
|
size = end;
|
2018-07-19 07:54:45 +00:00
|
|
|
sym_end = legacy_start_info->mod_start != 0 ?
|
|
|
|
legacy_start_info->mod_start : legacy_start_info->mfn_list;
|
2014-09-25 08:28:10 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure the size is right headed, sym_end is just a
|
|
|
|
* high boundary, but at least allows us to fail earlier.
|
|
|
|
*/
|
|
|
|
if ((vm_offset_t)&end + size > sym_end) {
|
|
|
|
xc_printf("Unable to load ELF symtab: size mismatch\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
ehdr = (Elf_Ehdr *)(&end + 1);
|
|
|
|
if (memcmp(ehdr->e_ident, ELFMAG, SELFMAG) ||
|
|
|
|
ehdr->e_ident[EI_CLASS] != ELF_TARG_CLASS ||
|
|
|
|
ehdr->e_version > 1) {
|
|
|
|
xc_printf("Unable to load ELF symtab: invalid symbol table\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
shdr = (Elf_Shdr *)((uint8_t *)ehdr + ehdr->e_shoff);
|
|
|
|
/* Find the symbol table and the corresponding string table. */
|
|
|
|
for (i = 1; i < ehdr->e_shnum; i++) {
|
|
|
|
if (shdr[i].sh_type != SHT_SYMTAB)
|
|
|
|
continue;
|
|
|
|
if (shdr[i].sh_offset == 0)
|
|
|
|
continue;
|
|
|
|
ksymtab = (uintptr_t)((uint8_t *)ehdr + shdr[i].sh_offset);
|
|
|
|
ksymtab_size = shdr[i].sh_size;
|
|
|
|
j = shdr[i].sh_link;
|
|
|
|
if (shdr[j].sh_offset == 0)
|
|
|
|
continue; /* Can this happen? */
|
|
|
|
kstrtab = (uintptr_t)((uint8_t *)ehdr + shdr[j].sh_offset);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ksymtab == 0 || kstrtab == 0) {
|
|
|
|
xc_printf(
|
|
|
|
"Unable to load ELF symtab: could not find symtab or strtab\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2014-03-11 10:15:25 +00:00
|
|
|
static caddr_t
|
|
|
|
xen_pv_parse_preload_data(u_int64_t modulep)
|
|
|
|
{
|
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>
2015-01-15 16:27:20 +00:00
|
|
|
caddr_t kmdp;
|
|
|
|
vm_ooffset_t off;
|
|
|
|
vm_paddr_t metadata;
|
2016-01-02 02:53:48 +00:00
|
|
|
char *envp;
|
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>
2015-01-15 16:27:20 +00:00
|
|
|
|
2018-07-19 07:54:45 +00:00
|
|
|
if (legacy_start_info->mod_start != 0) {
|
|
|
|
preload_metadata = (caddr_t)legacy_start_info->mod_start;
|
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>
2015-01-15 16:27:20 +00:00
|
|
|
|
|
|
|
kmdp = preload_search_by_type("elf kernel");
|
|
|
|
if (kmdp == NULL)
|
|
|
|
kmdp = preload_search_by_type("elf64 kernel");
|
|
|
|
KASSERT(kmdp != NULL, ("unable to find kernel"));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Xen has relocated the metadata and the modules,
|
|
|
|
* so we need to recalculate it's position. This is
|
|
|
|
* done by saving the original modulep address and
|
|
|
|
* then calculating the offset with mod_start,
|
|
|
|
* which contains the relocated modulep address.
|
|
|
|
*/
|
2015-01-20 12:28:24 +00:00
|
|
|
metadata = MD_FETCH(kmdp, MODINFOMD_MODULEP, vm_paddr_t);
|
2018-07-19 07:54:45 +00:00
|
|
|
off = legacy_start_info->mod_start - metadata;
|
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>
2015-01-15 16:27:20 +00:00
|
|
|
|
|
|
|
preload_bootstrap_relocate(off);
|
|
|
|
|
|
|
|
boothowto = MD_FETCH(kmdp, MODINFOMD_HOWTO, int);
|
2016-01-02 02:53:48 +00:00
|
|
|
envp = MD_FETCH(kmdp, MODINFOMD_ENVP, char *);
|
|
|
|
if (envp != NULL)
|
|
|
|
envp += off;
|
|
|
|
init_static_kenv(envp, 0);
|
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>
2015-01-15 16:27:20 +00:00
|
|
|
} else {
|
|
|
|
/* Parse the extra boot information given by Xen */
|
|
|
|
xen_pv_set_env();
|
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
2018-07-13 16:43:05 +00:00
|
|
|
boothowto |= boot_env_to_howto();
|
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>
2015-01-15 16:27:20 +00:00
|
|
|
kmdp = NULL;
|
|
|
|
}
|
2014-03-11 10:15:25 +00:00
|
|
|
|
2014-09-25 08:28:10 +00:00
|
|
|
#ifdef DDB
|
|
|
|
xen_pv_parse_symtab();
|
|
|
|
#endif
|
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>
2015-01-15 16:27:20 +00:00
|
|
|
return (kmdp);
|
2014-03-11 10:15:25 +00:00
|
|
|
}
|
2014-03-11 10:23:03 +00:00
|
|
|
|
|
|
|
static void
|
|
|
|
xen_pv_parse_memmap(caddr_t kmdp, vm_paddr_t *physmap, int *physmap_idx)
|
|
|
|
{
|
|
|
|
struct xen_memory_map memmap;
|
|
|
|
u_int32_t size;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
/* Fetch the E820 map from Xen */
|
|
|
|
memmap.nr_entries = MAX_E820_ENTRIES;
|
|
|
|
set_xen_guest_handle(memmap.buffer, xen_smap);
|
|
|
|
rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap);
|
|
|
|
if (rc)
|
|
|
|
panic("unable to fetch Xen E820 memory map");
|
|
|
|
size = memmap.nr_entries * sizeof(xen_smap[0]);
|
|
|
|
|
|
|
|
bios_add_smap_entries(xen_smap, size, physmap, physmap_idx);
|
|
|
|
}
|