xen: introduce a per-arch scratch mapping ranges

The current approach is to create foreign mappings in any unpopulated address
on the memory map. This however can cause issues, as late-loaded drive

xen: introduce a per-arch scratch mapping ranges

The current approach is to create foreign mappings in any unpopulated address
on the memory map. This however can cause issues, as late-loaded drivers could
then found their MMIO region has been stolen to be used as foreign mapping
scratch space (due to the Xen drivers having started first).

Add a local resource manager to the xenpv bus driver, architectures can add
suitable resources to that resource manager at boot in order to be used in
preference of the generic MMIO resource allocator.

No functional change, as the introduced scratch mapping range is not yet
populated.

Sponsored by: Cloud Software Group
MFC after: 1 week
Reviewed by: Elliott Mitchell <ehem+freebsd@m5p.com>
Differential revision: https://reviews.freebsd.org/D46122

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

xen: add atomic #defines to accomodate differing xen_ulong_t sizes

Alas, ARM declared xen_ulong_t to be 64-bits long, unlike i386 where
it matches the word size. As a result, compatibility wrappers

xen: add atomic #defines to accomodate differing xen_ulong_t sizes

Alas, ARM declared xen_ulong_t to be 64-bits long, unlike i386 where
it matches the word size. As a result, compatibility wrappers are
needed for Xen atomic operations.

Reviewed by: royger

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: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\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 ...

xen: bump used interface version

This is required for a further change that will make use of a field
that was added in version 0x00040d00.

No functional change expected.

Sponsored by: Citrix Syste

xen: bump used interface version

This is required for a further change that will make use of a field
that was added in version 0x00040d00.

No functional change expected.

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

xen: introduce xen_pv_disks_disabled()

ARM guest is considered as HVM in Freebsd but they only support PV disk
(no emulation available).

Submitted by: Elliott Mitchell <ehem+freebsd@m5p.com>
Review

xen: introduce xen_pv_disks_disabled()

ARM guest is considered as HVM in Freebsd but they only support PV disk
(no emulation available).

Submitted by: Elliott Mitchell <ehem+freebsd@m5p.com>
Reviewed by: royger
Differential Revision: https://reviews.freebsd.org/D29403

show more ...

xen/netfront: introduce xen_pv_nics_disabled()

ARM guest is considered as HVM but it only supports PV nics (no
emulation available).

Submitted by: Elliott Mitchell <ehem+freebsd@m5p.com>
Reviewed b

xen/netfront: introduce xen_pv_nics_disabled()

ARM guest is considered as HVM but it only supports PV nics (no
emulation available).

Submitted by: Elliott Mitchell <ehem+freebsd@m5p.com>
Reviewed by: royger
Differential Revision: https://reviews.freebsd.org/D29405

show more ...

xen/xen-os: move inclusion of machine/xen-os.h later

Several of x86 enable/disable functions depend upon the xen*domain()
functions. As such the xen*domain() functions need to be declared
before ma

xen/xen-os: move inclusion of machine/xen-os.h later

Several of x86 enable/disable functions depend upon the xen*domain()
functions. As such the xen*domain() functions need to be declared
before machine/xen-os.h.

Officially declare direct inclusion of machine/xen/xen-os.h verboten as
such will break these functions/macros. Remove one such soon to be
broken inclusion.

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

show more ...

xen/xen-os: don't let anyone else defining __XEN_INTERFACE_VERSION__

FreeBSD should always use the same version across the source. If not
it's a call for problem.

Submitted by: Elliott Mitchell <eh

xen/xen-os: don't let anyone else defining __XEN_INTERFACE_VERSION__

FreeBSD should always use the same version across the source. If not
it's a call for problem.

Submitted by: Elliott Mitchell <ehem+freebsd@m5p.com>
Reviewed by: royger
Differential Revision: https://reviews.freebsd.org/D29407

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

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 hype

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

show more ...

xen: add support for canceled suspend

When running on Xen, it's possible that a suspend request to the hypervisor
fails (return from HYPERVISOR_suspend different than 0). This means that the
suspend

xen: add support for canceled suspend

When running on Xen, it's possible that a suspend request to the hypervisor
fails (return from HYPERVISOR_suspend different than 0). This means that the
suspend hasn't succeed, and the resume procedure needs to properly handle this
case.

First of all, when such situation happens there's no need to reset the vector
callback, hypercall page, shared info, event channels or grant table, because
it's state is preserved. Also, the PV drivers don't need to be reset to the
initial state, since the connection with the backed has not been interrupted.

Submitted by: Liuyingdong <liuyingdong@huawei.com>
Reviewed by: royger
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D9635

show more ...

xen: Correct typo in #undef for symbol NBPL

Submitted by: Akshay Jaggi <akshay1994.leo@gmail.com>
Reviewed by: royger

MFH r289384-r293170

Sponsored by: The FreeBSD Foundation

Catch up with head (r291075).

Merge from head r290483

xen/intr: fix the event channel enabled per-cpu mask

Fix two issues with the current event channel code, first ENABLED_SETSIZE is
not correctly defined and then using a BITSET to store the per-cpu m

xen/intr: fix the event channel enabled per-cpu mask

Fix two issues with the current event channel code, first ENABLED_SETSIZE is
not correctly defined and then using a BITSET to store the per-cpu masks is
not portable to other arches, since on arm32 the event channel arrays shared
with the hypervisor are of type uint64_t and not long. Partially restore the
previous code but switch the bit operations to use the recently introduced
xen_{set/clear/test}_bit versions.

Reviewed by: Julien Grall <julien.grall@citrix.com>
Sponsored by: Citrix Systems R&D
Differential Revision: https://reviews.freebsd.org/D4080

show more ...

Merge from head

Merge from head

Sponsored by: Gandi.net

xen: Code cleanup and small bug fixes

xen/hypervisor.h:
- Remove unused helpers: MULTI_update_va_mapping, is_initial_xendomain,
is_running_on_xen
- Remove unused define CONFIG_X86_PAE
- Remove

xen: Code cleanup and small bug fixes

xen/hypervisor.h:
- Remove unused helpers: MULTI_update_va_mapping, is_initial_xendomain,
is_running_on_xen
- Remove unused define CONFIG_X86_PAE
- Remove unused variable xen_start_info: note that it's used inpcifront
which is not built at all
- Remove forward declaration of HYPERVISOR_crash

xen/xen-os.h:
- Remove unused define CONFIG_X86_PAE
- Drop unused helpers: test_and_clear_bit, clear_bit,
force_evtchn_callback
- Implement a generic version (based on ofed/include/linux/bitops.h) of
set_bit and test_bit and prefix them by xen_ to avoid any use by other
code than Xen. Note that It would be worth to investigate a generic
implementation in FreeBSD.
- Replace barrier() by __compiler_membar()
- Replace cpu_relax() by cpu_spinwait(): it's exactly the same as rep;nop
= pause

xen/xen_intr.h:
- Move the prototype of xen_intr_handle_upcall in it: Use by all the
platform

x86/xen/xen_intr.c:
- Use BITSET* for the enabledbits: Avoid to use custom helpers
- test_bit/set_bit has been renamed to xen_test_bit/xen_set_bit
- Don't export the variable xen_intr_pcpu

dev/xen/blkback/blkback.c:
- Fix the string format when XBB_DEBUG is enabled: host_addr is typed
uint64_t

dev/xen/balloon/balloon.c:
- Remove set but not used variable
- Use the correct type for frame_list: xen_pfn_t represents the frame
number on any architecture

dev/xen/control/control.c:
- Return BUS_PROBE_WILDCARD in xs_probe: Returning 0 in a probe callback
means the driver can handle this device. If by any chance xenstore is the
first driver, every new device with the driver is unset will use
xenstore.

dev/xen/grant-table/grant_table.c:
- Remove unused cmpxchg
- Drop unused include opt_pmap.h: Doesn't exist on ARM64 and it doesn't
contain anything required for the code on x86

dev/xen/netfront/netfront.c:
- Use the correct type for rx_pfn_array: xen_pfn_t represents the frame
number on any architecture

dev/xen/netback/netback.c:
- Use the correct type for gmfn: xen_pfn_t represents the frame number on
any architecture

dev/xen/xenstore/xenstore.c:
- Return BUS_PROBE_WILDCARD in xctrl_probe: Returning 0 in a probe callback
means the driver can handle this device. If by any chance xenstore is the
first driver, every new device with the driver is unset will use xenstore.

Note that with the changes, x86/include/xen/xen-os.h doesn't contain anymore
arch-specific code. Although, a new series will add some helpers that differ
between x86 and ARM64, so I've kept the headers for now.

Submitted by: Julien Grall <julien.grall@citrix.com>
Reviewed by: royger
Differential Revision: https://reviews.freebsd.org/D3921
Sponsored by: Citrix Systems R&D

show more ...

Finish merging from head, messed up in previous attempt

Merge r286744-r287584 from head.