sys: make the kernel metadata pointer global

The way we got the kernel metadata pointer was by calling
preload_search_by_type with one of the following three: "elf kernel",
"elf32 kernel" and "elf64

sys: make the kernel metadata pointer global

The way we got the kernel metadata pointer was by calling
preload_search_by_type with one of the following three: "elf kernel",
"elf32 kernel" and "elf64 kernel". Which one(s) we used wasn't
consistent though. Sometimes we would only try "elf kernel", and other
times we would try one of the latter two if the first failed. However,
the loader only ever sets "elf kernel" as the kernel type.

Now, the kmdp is a global, preload_kmdp, and it's initialized using
preload_initkmdp in machdep.c (or machdep_boot.c on arm/64).
preload_initkmdp takes a single boolean argument that tells us whether
not finding the kmdp is fatal or not.

Reviewed by: imp, kib
Pull Request: https://github.com/freebsd/freebsd-src/pull/1394

show more ...

x86/xen: ignore error to fetch memory map in xen_arch_init_physmem()

Some implementations of Xen don't expose the XENMEM_memory_map hypercall.
Shallow the error from XENMEM_memory_map in xen_arch_in

x86/xen: ignore error to fetch memory map in xen_arch_init_physmem()

Some implementations of Xen don't expose the XENMEM_memory_map hypercall.
Shallow the error from XENMEM_memory_map in xen_arch_init_physmem() and just
return 0. This will fallback to using the non-arch specific mechanism for
allocating scratch space.

Reported by: cperciva
Reviewed by: Elliott Mitchell
Fixes: 69c47485b5f9 ('x86/xen: use UNUSABLE e820 regions for external mappings')
Sponsored by: Cloud Software Group
Differential revision: https://reviews.freebsd.org/D46205

show more ...

x86/xen: use UNUSABLE e820 regions for external mappings

Using holes in the memory map to create external mappings (for example grants
or foreign maps) can be dangerous, as the guest might not have

x86/xen: use UNUSABLE e820 regions for external mappings

Using holes in the memory map to create external mappings (for example grants
or foreign maps) can be dangerous, as the guest might not have enough knowledge
of whether such holes are maybe MMIO of some devices.

Workaround this by using UNUSABLE e820 ranges as scratch space for external
mappings. The e820 memory map provided to dom0 is based on the native one, but
since PVH dom0 uses second stage translation, the UNUSABLE ranges on the host
memory map doesn't affect it, and we can also guarantee no device MMIO uses
those.

Additionally, any RAM in the e820 not available to dom0 because dom0
memory has been limited on the command line, or because those are in use by
Xen, are converted to UNUSABLE in the dom0 memory map.

Note that domU don't usually have UNUSABLE ranges in their memory maps, and
hence the logic introduced here won't help in avoiding conflicts with MMIO
regions. However the usage of external mappings on domUs is in general
limited, and the logic introduced here simply won't be helpful to them, but
won't regress the current state.

Sponsored by: Cloud Software Group
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D46123

show more ...

x86/xen: use correct printf specifier.

Use %p instead of wrongly casting to uintptr_t and printing with %lx.

Reported by: bapt
Fixes: 9a687d1fe3af ('x86/xen: introduce a Xen early init function')
S

x86/xen: use correct printf specifier.

Use %p instead of wrongly casting to uintptr_t and printing with %lx.

Reported by: bapt
Fixes: 9a687d1fe3af ('x86/xen: introduce a Xen early init function')
Sponsored by: Cloud Software Group

show more ...

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

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

show more ...

x86/xen: replace xen_cpuid_base with hv_base

Where possible, replace the usage of xen_cpuid_base for hv_base in preparation
for removing xen_cpuid_base.

No functional change intended.

Sponsored by

x86/xen: replace xen_cpuid_base with hv_base

Where possible, replace the usage of xen_cpuid_base for hv_base in preparation
for removing xen_cpuid_base.

No functional change intended.

Sponsored by: Cloud Software Group
Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D43935

show more ...

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 ta

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

show more ...

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 helpe

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

show more ...

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

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

show more ...

x86/xen: introduce non-hypercall based emergency print

The current xc_printf() function uses an hypercall in order to send character
buffers to the hypervisor for it to print on the hypervisor conso

x86/xen: introduce non-hypercall based emergency print

The current xc_printf() function uses an hypercall in order to send character
buffers to the hypervisor for it to print on the hypervisor console (if the
hypervisor is configured to print such messages).

This requires the hypercall page to be initialized, which is extra work and can
go wrong.

On x86 instead of using the console IO hypercall use the debug console IO port,
also called "port E9 hack". This allows sending characters to Xen using an
outb instruction, without any initialization required.

Keep the previous hypervisor based implementation by using the weak attribute,
which allows each architecture to provide an alternate (arch-specific)
implementation.

Sponsored by: Cloud Software Group
Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D43929

show more ...

x86/xen: fix HVM guest hypercall page setup

c7368ccb6801 didn't take into account that vm_guest will also get setup by
generic identify CPU code, and hence by the time xen_hvm_init() gets called
vm_

x86/xen: fix HVM guest hypercall page setup

c7368ccb6801 didn't take into account that vm_guest will also get setup by
generic identify CPU code, and hence by the time xen_hvm_init() gets called
vm_guest will always be set if running as a Xen guest, either by the PVH entry
point code, or by generic CPU identification.

xen_hvm_init() and xen_hvm_init_hypercall_stubs() were relying on xen_domain()
returning false when running as an HVM guest, and used that into order to
figure out whether hypercall page needed to be populated.

Get rid of such assumptions and simplify the code since legacy PVH is no
longer supported.

This fixes booting FreeBSD as a Xen HVM guest.

Fixes: c7368ccb6801 ('xen: remove xen_domain_type enum/variable')
Sponsored by: Cloud Software Group

show more ...

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_do

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

show more ...

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remov

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix

show more ...

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

xen: move vcpu_info to common, leave hook for setup

vcpu_info is crucial for the Xen event channel core. Since both the
data and setup steps are identical between architectures, move them to
the co

xen: move vcpu_info to common, leave hook for setup

vcpu_info is crucial for the Xen event channel core. Since both the
data and setup steps are identical between architectures, move them to
the common file. Since there is no cross-architecture method to call
a function on every processor during bring-up, simply leave the setup
function.

The number of vcpu_info structures available on the shared information
page varies by architecture. Instead of hard-coding the count use
nitems(). Add a warning message for this being used.

Switch to XEN_VCPUID() and use Xen's typedefs.

panic() on failure since >32 processors is no longer unusual.

royger: Specify 64-byte alignment for vcpu_info to try to defend
against vcpu_info crossing a page boundary. Add detection for this
limit.

Reviewed by: royger

show more ...

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD 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

show more ...

xen: move common variables off of sys/x86/xen/hvm.c

The xen_domain_type and HYPERVISOR_shared_info variables are shared by
all Xen architectures, so they should be in common rather than
reimplemente

xen: move common variables off of sys/x86/xen/hvm.c

The xen_domain_type and HYPERVISOR_shared_info variables are shared by
all Xen architectures, so they should be in common rather than
reimplemented by each architecture.

hvm_start_flags is used by xen_initial_domain() and so needs to be in
common.

Reviewed by: royger
Differential Revision: https://reviews.freebsd.org/D28982

show more ...

Fix various places which cast a pointer to a vm_paddr_t or vice versa.

GCC warns about the mismatched sizes on i386 where vm_paddr_t is 64
bits.

Reviewed by: imp, markj
Differential Revision: https

Fix various places which cast a pointer to a vm_paddr_t or vice versa.

GCC warns about the mismatched sizes on i386 where vm_paddr_t is 64
bits.

Reviewed by: imp, markj
Differential Revision: https://reviews.freebsd.org/D36750

show more ...

xen/blkback: do not use x86 CPUID in generic code

Move checker for whether Xen creates IOMMU mappings for foreign pages
into a helper that's defined in arch-specific code.

Reported by: Elliott Mitc

xen/blkback: do not use x86 CPUID in generic code

Move checker for whether Xen creates IOMMU mappings for foreign pages
into a helper that's defined in arch-specific code.

Reported by: Elliott Mitchell <ehem+freebsd@m5p.com>
Fixes: 1d528f95e8ce ('xen/blkback: remove bounce buffering mode')
Sponsored by: Citrix Systems R&D

show more ...

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-u

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

show more ...

x86/xen: use x{2}APIC if virtualized by hardware

Instead of using event channels or hypercalls to deal with IPIs and
NMIs.

Using a hardware virtualized APIC should be faster than using any PV
inter

x86/xen: use x{2}APIC if virtualized by hardware

Instead of using event channels or hypercalls to deal with IPIs and
NMIs.

Using a hardware virtualized APIC should be faster than using any PV
interface, since the VM exit can be avoided.

Xen exposes whether the domain is using hardware assisted x{2}APIC
emulation in a CPUID bit.

Sponsored by: Citrix Systems R&D

show more ...

xen: remove hypervisor_info

This was a source of indirection needed to support PVHv1. Now that that
support has been removed, we can eliminate it.

Reviewed by: royger

x86: clean up empty lines in .c and .h files

Merge ^/head r343571 through r343711.

xen: introduce a new way to setup event channel upcall

The main differences with the currently implemented method are:

- Requires a local APIC EOI, since it doesn't bypass the local APIC
as the

xen: introduce a new way to setup event channel upcall

The main differences with the currently implemented method are:

- Requires a local APIC EOI, since it doesn't bypass the local APIC
as the previous method used to do.
- Can be set to use different IDT vectors on each vCPU. Note that
FreeBSD doesn't make use of this feature since the event channel
IDT vector is reserved system wide.

Note that the old method of setting the event channel upcall is
not removed, and will be used as a fallback if this newly introduced
method is not available.

MFC after: 1 month
Sponsored by: Citrix Systems R&D

show more ...