Andrew Cooper [Sat, 28 Dec 2024 16:45:14 +0000 (16:45 +0000)]
docs: FRED support in Xen
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- CC: Jan Beulich <JBeulich@suse.com> CC: Roger Pau Monné <roger.pau@citrix.com>
An initial RFC discussion and plan. Open TODOs are at the end.
I've got an 8-patch series doing the cpu_user_regs disentangling vs the public
API. That's in pretty good shape now.
FRED itself is orders and orders of magnitude more simple than IDT, both in
terms of setup and operation, but I'm in the middle of a very large
cleanup (35 patches and count) to setup.c and trap.c in order to make FRED
able to be cleanly integrated into Xen, and that's still before any of the GS
changes to keep PV guests functioning correctly.
Andrew Cooper [Mon, 25 Mar 2024 15:14:46 +0000 (15:14 +0000)]
x86/spec-ctrl: Support for SRSO_U/S_NO and SRSO_MSR_FIX
AMD have updated the SRSO whitepaper[1] with further information. These
features exist on AMD Zen5 CPUs and are necessary for Xen to use.
The two features are in principle unrelated:
* SRSO_U/S_NO is an enumeration saying that SRSO attacks can't cross the
User(CPL3) / Supervisor(CPL<3) boundary. i.e. Xen don't need to use
IBPB-on-entry for PV64. PV32 guests are explicitly unsupported for
speculative issues, and excluded from consideration for simplicity.
* SRSO_MSR_FIX is an enumeration identifying that the BP_SPEC_REDUCE bit is
available in MSR_BP_CFG. When set, SRSO attacks can't cross the host/guest
boundary. i.e. Xen don't need to use IBPB-on-entry for HVM.
Extend ibpb_calculations() to account for these when calculating
opt_ibpb_entry_{pv,hvm} defaults. Add a `bp-spec-reduce=<bool>` option to
control the use of BP_SPEC_REDUCE, with it active by default.
Because MSR_BP_CFG is core-scoped with a race condition updating it, repurpose
amd_check_erratum_1485() into amd_check_bp_cfg() and calculate all updates at
once.
Xen also needs to to advertise SRSO_U/S_NO to guests to allow the guest kernel
to skip SRSO mitigations too:
* This is trivial for HVM guests. It is also is accurate for PV32 guests
too, but we have already excluded them from consideration, and do so again
here to simplify the policy logic.
* As written, SRSO_U/S_NO does not help for the PV64 user->kernel boundary.
However, after discussing with AMD, an implementation detail of having
BP_SPEC_REDUCE active causes the PV64 user->kernel boundary to have the
property described by SRSO_U/S_NO, so we can advertise SRSO_U/S_NO to
guests when the BP_SPEC_REDUCE precondition is met.
Finally, fix a typo in the SRSO_NO's comment.
[1] https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
xen/arch/x86: make objdump output user locale agnostic
The objdump output is fed to grep, so make sure it doesn't change with
different user locales and break the grep parsing.
This problem was identified while updating xen in Debian and the fix is
needed for generating reproducible builds in varying environments.
Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Ian Jackson [Mon, 30 Dec 2024 21:00:29 +0000 (22:00 +0100)]
docs/man/xen-vbd-interface.7: Provide properly-formatted NAME section
This manpage was omitted from
docs/man: Provide properly-formatted NAME sections
(423c4def1f7a01eeff56fa70564180640ef3af43)
because I was previously building with markdown not installed.
Signed-off-by: Ian Jackson <ian.jackson@citrix.com> Tested-by: Maximilian Engelhardt <maxi@daemonizer.de> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Tue, 17 Jan 2023 12:45:37 +0000 (12:45 +0000)]
tools: Introduce a non-truncating xc_xenver_changeset()
Update libxl and the ocaml stubs to match. No API/ABI change in either.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Christian Lindig <christian.lindig@citrix.com>
Andrew Cooper [Tue, 17 Jan 2023 12:39:48 +0000 (12:39 +0000)]
tools: Introduce a non-truncating xc_xenver_capabilities()
Update libxl and the ocaml stubs to match. No API/ABI change in either.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Christian Lindig <christian.lindig@citrix.com>
Andrew Cooper [Mon, 16 Jan 2023 16:56:17 +0000 (16:56 +0000)]
tools: Introduce a non-truncating xc_xenver_extraversion()
... which uses XENVER_extraversion2.
In order to do this sensibly, use manual hypercall buffer handling. Not only
does this avoid an extra bounce buffer (we need to strip the xen_varbuf_t
header anyway), it's also shorter and easlier to follow.
Update libxl and the ocaml stubs to match. No API/ABI change in either.
With this change made, `xl info` can now correctly access a >15 char
extraversion:
# xl info xen_version
4.18-unstable+REALLY LONG EXTRAVERSION
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Christian Lindig <christian.lindig@citrix.com>
Andrew Cooper [Mon, 16 Jan 2023 14:40:07 +0000 (14:40 +0000)]
tools/libxc: Move xc_version() out of xc_private.c into its own file
kexec-tools uses xc_version(), meaning that it is not a private API. As we're
going to extend the functionality substantially, move it to its own file.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Andrew Cooper [Tue, 20 Dec 2022 16:45:23 +0000 (16:45 +0000)]
xen/version: Misc style fixes
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Andrew Cooper [Tue, 3 Jan 2023 19:06:43 +0000 (19:06 +0000)]
xen/version: Fold build_id handling into xenver_varbuf_op()
struct xen_build_id and struct xen_varbuf are identical from an ABI point of
view, so XENVER_build_id can reuse xenver_varbuf_op() rather than having it's
own almost identical copy of the logic.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
In XenServer, we have encountered problems caused by both XENVER_extraversion
and XENVER_commandline having fixed bounds.
More than just the invariant size, the APIs/ABIs also broken by typedef-ing an
array, and using an unqualified 'char' which has implementation-specific
signed-ness.
Provide brand new ops, which are capable of expressing variable length
strings, and mark the older ops as broken.
This fixes all issues around XENVER_extraversion being longer than 15 chars.
Further work beyond just this API is needed to remove other assumptions about
XENVER_commandline being 1023 chars long.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
---
Non-technical objections to this patch were raised, and subsequently rejected
by a community wide vote. The results of the vote have not been shared with
the community at the time of committing.
Andrew Cooper [Fri, 13 Jan 2023 17:20:41 +0000 (17:20 +0000)]
xen/version: Calculate xen_capabilities_info once at boot
The arch_get_xen_caps() infrastructure is horribly inefficient for something
that is constant after features have been resolved on boot.
Every instance used snprintf() to format constants into a string (which gets
shorter when %d gets resolved!), and which get double buffered on the stack.
Switch to using string literals with the "3.0" inserted - these numbers
haven't changed in 19 years; the Xen 3.0 release was Dec 5th 2005.
Use initcalls to format the data into xen_cap_info, which is deliberately not
of type xen_capabilities_info_t because a 1k array is a silly overhead for
storing a maximum of 77 chars (the x86 version) and isn't liable to need any
more space in the forseeable future. RISC-V and PPC have their stub dropped,
with the expectation that they won't carry this legacy interface forward.
This speeds up the the XENVER_capabilities hypercall, but the purpose of the
change is to allow us to introduce a better XENVER_* API that doesn't force
the use of a 1k buffer on the stack.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: Jan Beulich <jbeulich@suse.com>
Describe the layer which enables SCMI over SMC calls forwarding
to EL3 FW if issued by the Hardware domain. If the SCMI firmware
node is not found in the Host DT during initialization, it fails
silently as it's not mandatory.
The SCMI SMCs trapping at EL2 now lets hwdom perform SCMI ops for
interacting with system-level resources almost as if it would be
running natively.
Signed-off-by: Andrei Cherechesu <andrei.cherechesu@nxp.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com> Acked-by: Michal Orzel <michal.orzel@amd.com>
Platforms based on NXP S32G3 processors use the NXP LINFlexD
UART driver for console by default, and rely on Dom0 having
access to SCMI services for system-level resources from
firmware at EL3.
Signed-off-by: Andrei Cherechesu <andrei.cherechesu@nxp.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
xen/arm: firmware: Add SCMI over SMC calls handling layer
Introduce the SCMI-SMC layer to have some basic degree of
awareness about SCMI calls that are based on the ARM System
Control and Management Interface (SCMI) specification (DEN0056E).
The SCMI specification includes various protocols for managing
system-level resources, such as: clocks, pins, reset, system power,
power domains, performance domains, etc. The clients are named
"SCMI agents" and the server is named "SCMI platform".
Only support the shared-memory based transport with SMCs as
the doorbell mechanism for notifying the platform. Also, this
implementation only handles the "arm,scmi-smc" compatible,
requiring the following properties:
- "arm,smc-id" (unique SMC ID)
- "shmem" (one or more phandles pointing to shmem zones
for each channel)
The initialization is done as initcall, since we need
SMCs, and PSCI should already probe EL3 FW for SMCCC support.
If no "arm,scmi-smc" compatible node is found in the host
DT, the initialization fails silently, as it's not mandatory.
Otherwise, we get the 'arm,smc-id' DT property from the node,
to know the SCMI SMC ID we handle. The 'shmem' memory ranges
are not validated, as the SMC calls are only passed through
to EL3 FW if coming from the hardware domain.
Create a new 'firmware' folder to keep the SCMI code separate
from the generic ARM code.
Signed-off-by: Andrei Cherechesu <andrei.cherechesu@nxp.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: Michal Orzel <michal.orzel@amd.com>
Carlo Nonato [Tue, 17 Dec 2024 17:06:37 +0000 (18:06 +0100)]
xen/arm: add cache coloring support for Xen image
Xen image is relocated to a new colored physical space. Some relocation
functionalities must be brought back:
- the virtual address of the new space is taken from 0c18fb76323b
("xen/arm: Remove unused BOOT_RELOC_VIRT_START").
- relocate_xen() and get_xen_paddr() are taken from f60658c6ae47
("xen/arm: Stop relocating Xen").
setup_pagetables() must be adapted for coloring and for relocation. Runtime
page tables are used to map the colored space, but they are also linked in
boot tables so that the new space is temporarily available for relocation.
This implies that Xen protection must happen after the copy.
Finally, since the alternative framework needs to remap the Xen text and
inittext sections, this operation must be done in a coloring-aware way.
The function xen_remap_colored() is introduced for that.
Signed-off-by: Carlo Nonato <carlo.nonato@minervasys.tech> Signed-off-by: Marco Solieri <marco.solieri@minervasys.tech> Reviewed-by: Jan Beulich <jbeulich@suse.com> # common Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Carlo Nonato [Tue, 17 Dec 2024 17:06:36 +0000 (18:06 +0100)]
xen/arm: make consider_modules() available for xen relocation
Cache coloring must physically relocate Xen in order to color the hypervisor
and consider_modules() is a key function that is needed to find a new
available physical address.
672d67f339c0 ("xen/arm: Split MMU-specific setup_mm() and related code out")
moved consider_modules() under arm32. Move it to mmu/setup.c and make it
non-static so that it can be used outside.
Signed-off-by: Carlo Nonato <carlo.nonato@minervasys.tech> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Luca Miccio [Tue, 17 Dec 2024 17:06:35 +0000 (18:06 +0100)]
xen/arm: add Xen cache colors command line parameter
Add a new command line parameter to configure Xen cache colors.
These colors are dumped together with other coloring info.
Benchmarking the VM interrupt response time provides an estimation of
LLC usage by Xen's most latency-critical runtime task. Results on Arm
Cortex-A53 on Xilinx Zynq UltraScale+ XCZU9EG show that one color, which
reserves 64 KiB of L2, is enough to attain best responsiveness:
- Xen 1 color latency: 3.1 us
- Xen 2 color latency: 3.1 us
Since this is the most common target for Arm cache coloring, the default
amount of Xen colors is set to one.
More colors are instead very likely to be needed on processors whose L1
cache is physically-indexed and physically-tagged, such as Cortex-A57.
In such cases, coloring applies to L1 also, and there typically are two
distinct L1-colors. Therefore, reserving only one color for Xen would
senselessly partitions a cache memory that is already private, i.e.
underutilize it.
Signed-off-by: Luca Miccio <lucmiccio@gmail.com> Signed-off-by: Marco Solieri <marco.solieri@minervasys.tech> Signed-off-by: Carlo Nonato <carlo.nonato@minervasys.tech> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Carlo Nonato [Tue, 17 Dec 2024 17:06:34 +0000 (18:06 +0100)]
xen: add cache coloring allocator for domains
Add a new memory page allocator that implements the cache coloring mechanism.
The allocation algorithm enforces equal frequency distribution of cache
partitions, following the coloring configuration of a domain. This allows
for an even utilization of cache sets for every domain.
Pages are stored in a color-indexed array of lists. Those lists are filled
by a simple init function which computes the color of each page.
When a domain requests a page, the allocator extracts the page from the list
with the maximum number of free pages among those that the domain can access,
given its coloring configuration.
The allocator can only handle requests of order-0 pages. This allows for
easier implementation and since cache coloring targets only embedded systems,
it's assumed not to be a major problem.
The buddy allocator must coexist with the colored one because the Xen heap
isn't colored. For this reason a new Kconfig option and a command line
parameter are added to let the user set the amount of memory reserved for
the buddy allocator. Even when cache coloring is enabled, this memory
isn't managed by the colored allocator.
Colored heap information is dumped in the dump_heap() debug-key function.
Based on original work from: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Marco Solieri <marco.solieri@minervasys.tech> Signed-off-by: Carlo Nonato <carlo.nonato@minervasys.tech> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Michal Orzel <michal.orzel@amd.com>
Carlo Nonato [Tue, 17 Dec 2024 17:06:32 +0000 (18:06 +0100)]
xen/arm: add support for cache coloring configuration via device-tree
Add the "llc-colors" Device Tree property to express DomUs and Dom0less
color configurations.
Based on original work from: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Carlo Nonato <carlo.nonato@minervasys.tech> Signed-off-by: Marco Solieri <marco.solieri@minervasys.tech> Reviewed-by: Jan Beulich <jbeulich@suse.com> # non-Arm Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Carlo Nonato [Tue, 17 Dec 2024 17:06:31 +0000 (18:06 +0100)]
tools: add support for cache coloring configuration
Add a new "llc_colors" parameter that defines the LLC color assignment for
a domain. The user can specify one or more color ranges using the same
syntax used everywhere else for color config described in the
documentation.
The parameter is defined as a list of strings that represent the color
ranges.
Documentation is also added.
Golang bindings are regenerated.
Based on original work from: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Carlo Nonato <carlo.nonato@minervasys.tech> Signed-off-by: Marco Solieri <marco.solieri@minervasys.tech> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Carlo Nonato [Tue, 17 Dec 2024 17:06:30 +0000 (18:06 +0100)]
xen: extend domctl interface for cache coloring
Add a new domctl hypercall to allow the user to set LLC coloring
configurations. Colors can be set only once, just after domain creation,
since recoloring isn't supported.
Based on original work from: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Carlo Nonato <carlo.nonato@minervasys.tech> Signed-off-by: Marco Solieri <marco.solieri@minervasys.tech> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Carlo Nonato [Tue, 17 Dec 2024 17:06:29 +0000 (18:06 +0100)]
xen/arm: add Dom0 cache coloring support
Add a command line parameter to allow the user to set the coloring
configuration for Dom0.
A common configuration syntax for cache colors is introduced and
documented.
Take the opportunity to also add:
- default configuration notion.
- function to check well-formed configurations.
Direct mapping Dom0 isn't possible when coloring is enabled, so
CDF_directmap flag is removed when creating it.
Based on original work from: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Carlo Nonato <carlo.nonato@minervasys.tech> Signed-off-by: Marco Solieri <marco.solieri@minervasys.tech> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Carlo Nonato [Tue, 17 Dec 2024 17:06:28 +0000 (18:06 +0100)]
xen/arm: permit non direct-mapped Dom0 construction
Cache coloring requires Dom0 not to be direct-mapped because of its non
contiguous mapping nature, so allocate_memory() is needed in this case. 8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate module")
moved allocate_memory() in dom0less_build.c. In order to use it
in Dom0 construction bring it back to domain_build.c and declare it in
domain_build.h.
Adapt the implementation of allocate_memory() so that it uses the host
layout when called on the hwdom, via find_unallocated_memory().
Since gnttab information are needed in the process, move find_gnttab_region()
before allocate_memory() in construct_dom0().
Introduce add_hwdom_free_regions() callback to add hwdom banks in descending
order.
Signed-off-by: Carlo Nonato <carlo.nonato@minervasys.tech> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Carlo Nonato [Tue, 17 Dec 2024 17:06:27 +0000 (18:06 +0100)]
xen/arm: add initial support for LLC coloring on arm64
LLC coloring needs to know the last level cache layout in order to make the
best use of it. This can be probed by inspecting the CLIDR_EL1 register,
so the Last Level is defined as the last level visible by this register.
Note that this excludes system caches in some platforms.
Static memory allocation and cache coloring are incompatible because static
memory can't be guaranteed to use only colors assigned to the domain.
Panic during DomUs creation when both are enabled.
Based on original work from: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Carlo Nonato <carlo.nonato@minervasys.tech> Signed-off-by: Marco Solieri <marco.solieri@minervasys.tech> Reviewed-by: Michal Orzel <michal.orzel@amd.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Carlo Nonato [Tue, 17 Dec 2024 17:06:26 +0000 (18:06 +0100)]
xen/common: add cache coloring common code
Last Level Cache (LLC) coloring allows to partition the cache in smaller
chunks called cache colors.
Since not all architectures can actually implement it, add a HAS_LLC_COLORING
Kconfig option.
LLC_COLORS_ORDER Kconfig option has a range maximum of 10 (2^10 = 1024)
because that's the number of colors that fit in a 4 KiB page when integers
are 4 bytes long.
LLC colors are a property of the domain, so struct domain has to be extended.
Based on original work from: Luca Miccio <lucmiccio@gmail.com>
Signed-off-by: Carlo Nonato <carlo.nonato@minervasys.tech> Signed-off-by: Marco Solieri <marco.solieri@minervasys.tech> Acked-by: Michal Orzel <michal.orzel@amd.com>
Oleksii Kurochko [Thu, 19 Dec 2024 11:18:31 +0000 (12:18 +0100)]
automation: Pin down CONFIG_QEMU_PLATFORM for RISC-V's randconfig job
Except setting CONFIG_QEMU_PLATFORM=y in tiny64_defconfig,
CONFIG_QEMU_PLATFORM should be fixed for RISC-V's randconfig job.
Otherwise, an expected compilation error for RISC-V's randconfig job
will occur since clean_and_invalidate_dcache_va_range() and
clean_dcache_va_range() are currently implemented only for the QEMU
platform.
Additionally, sort the EXTRA_FIXED_RANDCONFIG list alphabetically.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Fixes: f92e2709bd ("xen/riscv: implement data and instruction cache operations") Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Sergiy Kibrik [Thu, 19 Dec 2024 11:13:26 +0000 (13:13 +0200)]
xen/ioreq: Fix check for CONFIG_ARCH_VCPU_IOREQ_COMPLETION
It should be CONFIG_ARCH_VCPU_IOREQ_COMPLETION (as in Kconfig) and not
misspelled CONFIG_VCPU_ARCH_IOREQ_COMPLETION.
Fixes: 979cfdd3e58c ("ioreq: do not build arch_vcpu_ioreq_completion() for non-VMX configurations") Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The important part: XZ decompression error: Memory usage limit reached
This looks to be related to the following change in Linux: 8653c909922743bceb4800e5cc26087208c9e0e6 ("xz: use 128 MiB dictionary and force single-threaded mode")
Fix this by increasing the block size to 256MiB. And remove the
misleading comment (from lack of better ideas).
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Anthony PERARD <anthony.perard@vates.tech> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Teddy Astie [Mon, 2 Dec 2024 09:49:14 +0000 (09:49 +0000)]
x86/hvm: Use constants for x86 modes
In many places of x86 HVM code, constants integer are used to indicate in what mode is
running the CPU (real, vm86, 16-bits, 32-bits, 64-bits). However, these constants are
are written directly as integer which hides the actual meaning of these modes.
This patch introduces X86_MODE_* macros and replace those occurences with it.
Signed-off-by: Teddy Astie <teddy.astie@vates.tech> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Andrew Cooper [Thu, 27 Jun 2024 12:55:51 +0000 (13:55 +0100)]
tools/libxg: Don't gunzip the guests initrd
Decompressing the kernel is necessary to inspect the ELF notes, but the
dombuilder will gunzip() secondary modules too. Specifically gunzip(), no
other decompression algorithms.
This may have been necessary in the dim and distant past, but it is broken
today. Linux specifically supports concatenating CPIO fragments of differing
compressions, and any attempt to interpret it with a single algorithm may
corrupt later parts.
This was an unexpected discovery while trying to test Xen's gunzip()
logic (Xen as a PVH guest, with a gzipped XTF kernel as dom0).
Interpreting secondary modules should be left as an exercise to the guest.
This reduces work done in dom0.
This is not expected to cause a practical difference to guests these days.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Andrew Cooper [Thu, 12 Sep 2024 01:18:40 +0000 (02:18 +0100)]
xen/sched: Untangle credit2 vs cpu_nr_siblings()
Credit2 has no buisness including asm/cpufeature.h or asm/processor.h.
This was caused by a bad original abstraction, and an even less wise attempt
to fix the build on my behalf. It is also the sole reason why PPC and RISC-V
need cpufeature.h header.
Worst of all, cpu_data[cpu].x86_num_siblings doesn't even have the same
meaning between vendors on x86 CPUS.
Implement cpu_nr_siblings() locally in credit2.c, leaving behind a TODO. Drop
the stub from each architecture.
Fixes: 8e2aa76dc167 ("xen: credit2: limit the max number of CPUs in a runqueue") Fixes: ad33a573c009 ("xen/credit2: Fix build following c/s 8e2aa76dc (take 2)") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Juergen Gross <jgross@suse.com> Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Acked-by: Shawn Anastasio <sanastasio@raptorengineering.com>
Oleksii Kurochko [Thu, 19 Dec 2024 09:23:48 +0000 (10:23 +0100)]
xen/riscv: relocating and unflattening host device tree
Introduce relocate_fdt() and call it to relocate FDT to Xen heap
instead of using early mapping as it is expected that discard_initial_modules()
( is supposed to call in the future ) discards the FDT boot module and
remove_early_mappings() destroys the early mapping.
Unflatten a device tree, creating the tree of struct device_node.
It also fills the "name" and "type" pointers of the nodes so the normal
device-tree walking functions can be used.
Set device_tree_flattened to NULL in the case when acpi_disabled is
equal to false.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Oleksii Kurochko [Thu, 19 Dec 2024 09:23:28 +0000 (10:23 +0100)]
xen/riscv: implement prereq for DTB relocation
DTB relocatin in Xen heap requires the following functions which are
introduced in current patch:
- xvmalloc_array()
- copy_from_paddr()
For internal use of xvmalloc, the functions flush_page_to_ram() and
virt_to_page() are introduced. virt_to_page() is also required for
free_xenheap_pages().
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Oleksii Kurochko [Thu, 19 Dec 2024 09:22:46 +0000 (10:22 +0100)]
xen/riscv: implement data and instruction cache operations
Implement following cache operations:
- clean_and_invalidate_dcache_va_range()
- clean_dcache_va_range()
- invalidate_icache()
The first two functions may require support for the CMO (Cache Management
Operations) extension and/or hardware-specific instructions.
Currently, only QEMU is supported, which does not model cache behavior.
Therefore, clean_and_invalidate_dcache_va_range() and clean_dcache_va_range()
are implemented to simply return 0. For other cases, generate compilation error
so a user won't miss to update this function if necessery.
If hardware supports CMO or hardware-specific instructions, these functions
should be updated accordingly. To support current implementation of these
function CONFIG_QEMU_PLATFORM is introduced.
invalidate_icache() is implemented using fence.i instruction as
mentioned in the unpriv spec:
The FENCE.I instruction was designed to support a wide variety of
implementations. A simple implementation can flush the local instruction
cache and the instruction pipeline when the FENCE.I is executed.
A more complex implementation might snoop the instruction (data) cache
on every data (instruction) cache miss, or use an inclusive unified
private L2 cache to invalidate lines from the primary instruction cache
when they are being written by a local store instruction.
If instruction and data caches are kept coherent in this way, or if the
memory system consists of only uncached RAMs, then just the fetch pipeline
needs to be flushed at a FENCE.I.
The FENCE.I instruction requires the presence of the Zifencei extension,
which might not always be available. However, Xen uses the RV64G ISA, which
guarantees the presence of the Zifencei extension. According to the
unprivileged ISA specification (version 20240411):
One goal of the RISC-V project is that it be used as a stable software
development target. For this purpose, we define a combination of a base ISA
(RV32I or RV64I) plus selected standard extensions (IMAFD, Zicsr, Zifencei)
as a "general-purpose" ISA, and we use the abbreviation G for the
IMAFDZicsr_Zifencei combination of instruction-set extensions.
Set CONFIG_QEMU_PLATFORM=y in tiny64_defconfig to have proper implemtation of
clean_and_invalidate_dcache_va_range() and clean_dcache_va_range() for CI.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Oleksii Kurochko [Thu, 19 Dec 2024 09:21:11 +0000 (10:21 +0100)]
xen/riscv: update layout table in config.h
Make all upper bounds (end addresses) for areas inclusive to align
with the corresponding definitions.
For the Direct map region, the upper bound was calculated incorrectly
in efadb18dd58aba ("xen/riscv: add VM space layout"). It should be
0x7f80000000 (considering that the value is exclusive, instead of
0x7f40000000). Therefore, the inclusive upper bound for that region
is 0x7f80000000 - 1.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Acked-by: Jan Beulich <jbeulich@suse.com>
PGC_static and PGC_extra need to be preserved when assigning a page.
Define a new macro that groups those flags and use it instead of or'ing
every time.
Signed-off-by: Carlo Nonato <carlo.nonato@minervasys.tech> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Ariel Otilibili [Mon, 16 Dec 2024 23:07:20 +0000 (00:07 +0100)]
tools: Fix regex syntax warnings with Python 3.12
Since Python 3.12, invalid escape sequences generate SyntaxWarning. In the
future, these invalid sequences will raise a SyntaxError, so changed to using
raw string notation.
Link: https://docs.python.org/3/whatsnew/3.12.html#other-language-changes Fixes: d8f3a67bf98 ("pygrub: further improve grub2 support") Fixes: dd03048708a ("xen/pygrub: grub2/grub.cfg from RHEL 7 has new commands in menuentry") Fixes: d1b93ea2615 ("tools/pygrub: Make pygrub understand default entry in string format") Fixes: 622e368758b ("Add ZFS libfsimage support patch") Fixes: 02b26c02c7c ("xen/scripts: add cppcheck tool to the xen-analysis.py script") Fixes: 56c0063f4e7 ("xen/misra: xen-analysis.py: Improve the cppcheck version check") Signed-off-by: Ariel Otilibili <Ariel.Otilibili-Anieli@eurecom.fr> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Thu, 28 Apr 2022 08:44:02 +0000 (09:44 +0100)]
x86/CET: Support cet=<bool> on the command line
... as a shorthand for setting both suboptions at once. Currently, an admin
needs to pass cet=no-shstk,no-ibt to turn both off, where cet=0 is a better
option.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Fixes: 631f535a3d4f ("xen: update ECLAIR service identifiers from MC3R1 to MC3A2.") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
xen: update ECLAIR service identifiers from MC3R1 to MC3A2.
Rename all instances of ECLAIR MISRA C:2012 service identifiers,
identified by the prefix MC3R1, to use the prefix MC3A2, which
refers to MISRA C:2012 Amendment 2 guidelines.
This update is motivated by the need to upgrade ECLAIR GitLab runners
that use the new naming scheme for MISRA C:2012 Amendment 2 guidelines.
Changes to the docs/misra directory are needed in order to keep
comment-based deviation up to date.
Andrew Cooper [Fri, 22 Nov 2024 16:00:37 +0000 (16:00 +0000)]
docs/guest-guide: Discuss when not use a hypercall page
The Linux rethunk and safe-ret speculative safety techniques involve
transforming `ret` to `jmp __x86_return_thunk` at compile time. Placing naked
`ret`s back in executable .text breaks these mitigations.
CET-IBT requires ENDBR instructions, and while we could in principle fix that,
the need to select between ENDBR32 or ENDBR64 means that the contents of the
hypercall page would need to become more mode-specific than it currently
is (HVM hypercall pages are currently 32bit and 64bit compatbile). However,
there's no feasible way to make a hypercall page compatible with fine-grain
CFI schemes such as FineIBT.
OSes which care about either of these things are better off avoiding the
hypercall page.
This is part of XSA-466.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monne [Mon, 16 Dec 2024 18:33:29 +0000 (19:33 +0100)]
x86/io-apic: prevent early exit from i8259 loop detection
Avoid exiting early from the loop when a pin that could be connected to the
i8259 is found, as such early exit would leave the EOI handler translation
array only partially allocated and/or initialized.
Otherwise on systems with multiple IO-APICs and an unmasked ExtINT pin on
any IO-APIC that's no the last one the following NULL pointer dereference
triggers:
(XEN) Enabling APIC mode. Using 2 I/O APICs
(XEN) ----[ Xen-4.20-unstable x86_64 debug=y Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: e008:[<ffff82d040328046>] __ioapic_write_entry+0x83/0x95
[...]
(XEN) Xen call trace:
(XEN) [<ffff82d040328046>] R __ioapic_write_entry+0x83/0x95
(XEN) [<ffff82d04027464b>] F amd_iommu_ioapic_update_ire+0x1ea/0x273
(XEN) [<ffff82d0402755a1>] F iommu_update_ire_from_apic+0xa/0xc
(XEN) [<ffff82d040328056>] F __ioapic_write_entry+0x93/0x95
(XEN) [<ffff82d0403283c1>] F arch/x86/io_apic.c#clear_IO_APIC_pin+0x7c/0x10e
(XEN) [<ffff82d040328480>] F arch/x86/io_apic.c#clear_IO_APIC+0x2d/0x61
(XEN) [<ffff82d0404448b7>] F enable_IO_APIC+0x2e3/0x34f
(XEN) [<ffff82d04044c9b0>] F smp_prepare_cpus+0x254/0x27a
(XEN) [<ffff82d04044bec2>] F __start_xen+0x1ce1/0x23ae
(XEN) [<ffff82d0402033ae>] F __high_start+0x8e/0x90
(XEN)
(XEN) Pagetable walk from 0000000000000000:
(XEN) L4[0x000] = 000000007dbfd063ffffffffffffffff
(XEN) L3[0x000] = 000000007dbfa063ffffffffffffffff
(XEN) L2[0x000] = 000000007dbcc063ffffffffffffffff
(XEN) L1[0x000] = 0000000000000000ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0002]
(XEN) Faulting linear address: 0000000000000000
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
Reported-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com> Fixes: 86001b3970fe ('x86/io-apic: fix directed EOI when using AMD-Vi interrupt remapping') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Penny Zheng [Fri, 13 Dec 2024 10:50:47 +0000 (10:50 +0000)]
xen/arm: Check for Static Heap feature when freeing resources
If the Xen heap is statically configured in Device Tree, its size is
definite, so only the defined memory shall be given to the boot
allocator. Have a check where init_domheap_pages() is called
which takes into account if static heap feature is used.
Extract static_heap flag from init data bootinfo, as it will be needed
after destroying the init data section, rename it to using_static_heap
and use it to tell whether the Xen static heap feature is enabled.
Bertrand Marquis [Wed, 27 Nov 2024 16:07:41 +0000 (17:07 +0100)]
xen/arm: ffa: Remove per VM notif_enabled
Remove the per VM flag to store if notifications are enabled or not as
the only case where they are not, if notifications are enabled globally,
will make the VM creation fail.
Also use the opportunity to always give the notifications interrupts IDs
to VM. If the firmware does not support notifications, there won't be
any generated and setting one will give back a NOT_SUPPORTED.
Bertrand Marquis [Wed, 27 Nov 2024 16:07:40 +0000 (17:07 +0100)]
xen/arm: ffa: move message function into ffa_msg.c
Move the direct message handling function in its own source file and
rename it to have a ffa_ prefix.
This is a preparation to add support for indirect messages which will
go into this newly created source file.
Bertrand Marquis [Wed, 27 Nov 2024 16:07:39 +0000 (17:07 +0100)]
xen/arm: ffa: Transmit RXTX buffers to the SPMC
When an RXTX buffer is mapped by a VM transmit it to the SPMC when it
supports RX_ACQUIRE.
As a consequence of that, we must acquire the RX buffer of a VM from the
SPMC when we want to use it:
- create a generic acquire and release function to get the rx buffer of
a VM which gets it from the SPMC when supported
- rename the rx_acquire to hyp_rx_acquire to remove confusion
- rework the rx_lock to only lock access to rx_is_free and only allow
usage of the rx buffer to one who managed to acquire it, thus removing
the trylock and returning busy if rx_is_free is false
As part of this change move some structure definition to ffa_private
from ffa_shm as those are need for the MAP call with the SPMC.
While there also fix ffa_handle_rxtx_map which was testing the wrong
variable after getting the page for the rx buffer, testing tx_pg
instead of rx_pg.
Bertrand Marquis [Wed, 27 Nov 2024 16:07:38 +0000 (17:07 +0100)]
xen/arm: ffa: Use bit 15 convention for SPs
Make use and required to have bit 15 convention respected by secure
world (having bit 15 of IDs set for secure endpoints and non-set for
non-secure ones).
If any secure partition has an ID with bit 15 not set, it will not be
possible to contact or detect them.
Print an error log during probe for each secure endpoint detected with
bit 15 not set.
We are switching to this convention because Xen is currently not using
VMIDs with bit 15 set so we are sure that no VM will have it set (this
is ensured by BUILD_BUG_ON in case this becomes false in the future).
It is allowing to easily distinguish between secure and non-secure
endpoints, preventing the need to store a list of secure endpoint IDs in
Xen.
Bertrand Marquis [Wed, 27 Nov 2024 16:07:37 +0000 (17:07 +0100)]
xen/arm: ffa: Rework partition info get
Rework the partition info get implementation to use the correct size of
structure depending on the version of the protocol and simplifies the
structure copy to use only memcpy and prevent recreating the structure
each time.
The goal here is to have an implementation that will be easier to
maintain in the long term as the specification is only adding fields to
structure with versions to simplify support of several protocol
versions and as such an SPMC implementation in the future could use this
and return a size higher than the one we expect.
The patch is fixing the part_info_get function for this and the
subscriber discovery on probe.
Bertrand Marquis [Wed, 27 Nov 2024 16:07:35 +0000 (17:07 +0100)]
xen/arm: ffa: Fix version negotiation
Fix FFA version negotiation with the firmware to follow the
specification guidance more closely (see FF-A Specification Version 1.1
in chapter 13.2.1).
When the firmware returns OK we can have several cases:
- the version requested is accepted but the firmware supports a greater
one in the same major.
- the firmware supports a greater major version. It could still return
OK even if the version requested is not accepted. Reject it.
- the firmware supports a lower version. It will return OK and give that
version. Check if we support it and use it or reject it if we do not.
Adapt the code to:
- reject any version lower than the one we support or not with the same
major version
- use the version returned if in our supported range (currently 1.1
only)
- use 1.1 if the version returned is greater.
Also adapt the handling of version requests from VM:
- use our version if same major but greater minor is requested
- use requested version if same major but lower minor is requested
- do not use if incompatible major is requested
- always return our version without error to the requester
Bertrand Marquis [Wed, 27 Nov 2024 16:07:33 +0000 (17:07 +0100)]
xen/arm: ffa: Rework firmware discovery
Rework firmware discovery during probe:
- move prints into the probe
- rename ffa_version to ffa_fw_version as the variable identifies the
version of the firmware and not the one we support
- add error prints when allocation fail during probe
Juergen Gross [Mon, 16 Dec 2024 12:07:19 +0000 (13:07 +0100)]
xen: add a domain unique id to each domain
Xenstore is referencing domains by their domid, but reuse of a domid
can lead to the situation that Xenstore can't tell whether a domain
with that domid has been deleted and created again without Xenstore
noticing the domain is a new one now.
Add a global domain creation unique id which is updated when creating
a new domain, and store that value in struct domain of the new domain.
The global unique id is initialized with the system time and updates
are done via the xorshift algorithm which is used for pseudo random
number generation, too (see https://en.wikipedia.org/wiki/Xorshift).
Juergen Gross [Mon, 16 Dec 2024 12:06:55 +0000 (13:06 +0100)]
xen/xsm: make getdomaininfo xsm dummy checks more stringent
Today the dummy XSM privilege checks for getdomaininfo are less
stringent than possible: they basically rely on the general
sysctl/domctl entry check to do all tests and then do the test with
the XSM_HOOK privilege, which is an "allow all" default.
Instead of XSM_HOOK use XSM_XS_PRIV, which is the privilege really
wanted. Note that this test is still wider than the sysctl entry test,
but there is no easy way to make both domctl and sysctl happy at the
same time.
Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Oleksii Kurochko [Mon, 16 Dec 2024 12:05:46 +0000 (13:05 +0100)]
xen/riscv: add {set,clear}_fixmap() functions for managing fixmap entries
Introduce set_fixmap() and clear_fixmap() functions to manage mappings
in the fixmap region. The set_fixmap() function maps a 4k page ( as only L0
is expected to be updated; look at setup_fixmap_mappings() ) at a specified
fixmap entry using map_pages_to_xen(), while clear_fixmap() removes the
mapping from a fixmap entry by calling destroy_xen_mappings().
Both functions ensure that the operations succeed by asserting that their
respective calls (map_pages_to_xen() and destroy_xen_mappings()) return 0.
`BUG()` is added to trigger a failure if any issues occur during
the mapping or unmapping process.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Oleksii Kurochko [Mon, 16 Dec 2024 12:05:05 +0000 (13:05 +0100)]
xen/riscv: add destroy_xen_mappings() to remove mappings in Xen page tables
Introduce the destroy_xen_mappings() function, which removes page
mappings in Xen's page tables between a start address s and an end
address e.
The function ensures that both s and e are page-aligned
and verifies that the start address is less than or equal to the end
address before calling pt_update() to invalidate the mappings.
The pt_update() function is called with INVALID_MFN and PTE_VALID=0
in the flags, which tell pt_update() to remove mapping. No additional
ASSERT() is required to check these arguments, as they are hardcoded in
the call to pt_update() within destroy_xen_mappings().
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Michal Orzel [Tue, 10 Dec 2024 10:10:01 +0000 (11:10 +0100)]
arm/domain_build: Make find_unallocated_memory() more generic
At the moment, find_unallocated_memory() is only used to retrieve free
memory ranges for direct mapped domains in order to find extended
regions. It is not generic as it makes assumptions as for the place at
which it's being called (domain memory already allocated, gnttab region
already found) and hardcodes the memory banks to be excluded.
Make the function more generic, so that it can be used for other
purposes whenever there is a need to find free host memory regions (e.g.
upcoming LLC coloring series). Allow passing array with memory banks as a
parameter together with a callback to populate free regions structure,
as the logic may differ depending on the needs.
Add find_host_extended_regions() to be called from make_hypervisor_node()
to contain the logic to find extended regions for domains using host
memory layout that are not permitted to use IOMMU.
MAINTAINERS: add Anthony, Michal, Roger to THE REST
In recognition of their outstanding work and years of service to the Xen
Community, please join me in welcoming Anthony, Michal, and Roger as
Committers and REST Maintainers.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Acked-by: Anthony PERARD <anthony.perard@vates.tech> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Bertrand Marquis <bertrand.marquis@arm.com> Acked-by: Michal Orzel <michal.orzel@amd.com>
Andrii Sultanov [Mon, 9 Dec 2024 17:57:49 +0000 (17:57 +0000)]
tools/ocaml: Specify rpath correctly for ocamlmklib
ocamlmklib has special handling for C-like '-Wl,-rpath' option, but does
not know how to handle '-Wl,-rpath-link', as evidenced by warnings like:
"Unknown option
-Wl,-rpath-link=$HOME/xen/tools/ocaml/libs/eventchn/../../../../tools/libs/toollog"
Pass this option directly to the compiler with -ccopt instead.
Also pass -L directly to the linker with -ldopt. This prevents embedding absolute
paths from buildtime into binary's RPATH.
Fixes: f7b4e4558b42 ("tools/ocaml: Fix OCaml libs rules") Reported-by: Fernando Rodrigues <alpha@sigmasquadron.net> Tested-by: Fernando Rodrigues <alpha@sigmasquadron.net> Signed-off-by: Andrii Sultanov <andrii.sultanov@cloud.com> Acked-by: Christian Lindig <christian.lindig@cloud.com>
Nicola Vetrini [Tue, 10 Dec 2024 17:04:20 +0000 (18:04 +0100)]
x86: p2m-pod: address violation of MISRA C Rule 2.1
Rule 2.1 states: "A project shall not contain unreachable code".
The placement of the loop after "out_unmap" can be moved earlier
in order to avoid the unconditional return to be marked as a cause of
unreachability for the loop, as this is a consequence of
"__builtin_unreachable" being configured in ECLAIR as being deliberately
unreachable, and therefore not reported as causing the code after the
"out_unmap" label to be unreachable.
Replacing one instance of "goto out_unmap" with the loop avoids
considering the unconditional return at the end of the function as a cause
of unreachability, while preserving the semantics of the function.
No functional change intended.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Tue, 10 Dec 2024 17:03:38 +0000 (18:03 +0100)]
x86/FPU: make vcpu_reset_fpu() build with old gcc
Fields of anonymous structs/unions may not be part of an initializer for
rather old gcc (4.6 and earlier).
Fixes: 49a068471d77 ("x86/fpu: Rework fpu_setup_fpu() uses to split it in two") Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Luca Fancellu [Tue, 3 Dec 2024 09:48:10 +0000 (09:48 +0000)]
xen/arm: Move setup_frametable_mappings to arm/mmu
Move the current setup_frametable_mappings implementation to
arm/mmu under a new file mm.c, this implementation depends on
virtual memory and won't be used as it is for MPU systems.
Take the occasion to fix code style issues related to the line
length.
Moved also frametable_virt_end since it is used only on MMU
systems.
Luca Fancellu [Tue, 3 Dec 2024 09:48:08 +0000 (09:48 +0000)]
xen/arm: Use vmap_contig instead of __vmap where it's possible
Currently the arm code uses __vmap function in few parts to map
physically contiguous pages, vmap_contig was introduced recently
and does the same because it's a wrapper for __vmap, so use the
latter instead of the direct __vmap function.
Luca Fancellu [Tue, 3 Dec 2024 09:48:07 +0000 (09:48 +0000)]
arm/setup: Move MMU specific extern declarations to mmu/setup.h
Move some extern declarations related to MMU structures and define
from asm/setup.h to asm/mmu/setup.h, in order to increase encapsulation
and allow the MPU part to build, since it has no clue about them.
Luca Fancellu [Tue, 3 Dec 2024 09:48:06 +0000 (09:48 +0000)]
common/vmap: Fall back to simple allocator when !HAS_VMAP
When HAS_VMAP is disabled, the xv{malloc,zalloc,...} functions
should fall back to the simple x{malloc,zalloc,...} variant,
implement that because MPU systems won't have virtual memory.
Additionally remove VMAP_VIRT_START from vmap.h guards since
MPU systems won't have it defined.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Penny Zheng [Wed, 4 Dec 2024 17:22:43 +0000 (17:22 +0000)]
xen/mmu: enable SMMU subsystem only in MMU
In Xen, SMMU subsystem is supported for MMU system only. The reason being SMMU
driver uses the same page tables as MMU.
Thus, we make it dependent on CONFIG_MMU.
CONFIG_EARLY_UART_SIZE is introduced to let user provide physical size of
early UART. Unlike MMU where we map a page in the virtual address space,
here we need to know the exact physical size to be mapped.
As VA == PA in case of MPU, the memory layout follows exactly the hardware
configuration. As a consequence, we set EARLY_UART_VIRTUAL_ADDRESS as physical
address.
EARLY_UART_BASE_ADDRESS and EARLY_UART_SIZE should be aligned to the minimum
size of MPU region (ie 64 bits) as per the hardware restrictions. Refer ARM
DDI 0600A.d ID120821 A1.3 "A minimum protection region size of 64 bytes.".
UART is mapped as nGnRE region (as specified by ATTR=100 , refer G1.3.13,
MAIR_EL2, "---0100 Device memory nGnRE"). Also, it is mapped as outer shareable,
RW at EL2 only and execution of instructions from the region is not permitted.
The xl command doesn't provide suspend/resume, so add them :
xl suspend <Domain>
xl resume <Domain>
This patch follows a discussion on XenDevel: when you want the
virtualized equivalent of "sleep"-ing a host, it's better to
suspend/resume than to pause/unpause a domain.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Suggested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by: Cyril Rébert (zithro) <slack@rabbit.lu> Signed-off-by: Jason Andryuk <jason.andryuk@amd.com> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Michal Orzel [Tue, 3 Dec 2024 09:22:14 +0000 (10:22 +0100)]
bootfdt: Add missing trailing commas in BOOTINFO_{ACPI,SHMEM}_INIT
Commit a14593e3995a extended BOOTINFO_{ACPI,SHMEM}_INIT initializers
list with a new 'type' member but forgot to add trailing commas (they
were present before). This results in a build failure when building
with CONFIG_ACPI=y and CONFIG_STATIC_SHM=y:
./include/xen/bootfdt.h:155:5: error: request for member 'shmem' in something not a structure or union
155 | .shmem.common.max_banks = NR_SHMEM_BANKS, \
| ^
./include/xen/bootfdt.h:168:5: note: in expansion of macro 'BOOTINFO_SHMEM_INIT'
168 | BOOTINFO_SHMEM_INIT \
| ^~~~~~~~~~~~~~~~~~~
common/device-tree/bootinfo.c:22:39: note: in expansion of macro 'BOOTINFO_INIT'
22 | struct bootinfo __initdata bootinfo = BOOTINFO_INIT;
Fixes: a14593e3995a ("xen/device-tree: Allow region overlapping with /memreserve/ ranges") Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Andrew Cooper [Mon, 2 Dec 2024 17:27:05 +0000 (17:27 +0000)]
libs/guest: Fix migration compatibility with a security-patched Xen 4.13
xc_cpuid_apply_policy() provides compatibility for migration of a pre-4.14 VM
where no CPUID data was provided in the stream.
It guesses the various max-leaf limits, based on what was true at the time of
writing, but this was not correctly adapted when speculative security issues
forced the advertisement of new feature bits. Of note are:
* LFENCE-DISPATCH, in leaf 0x80000021.eax
* BHI-CTRL, in leaf 0x7[2].edx
In both cases, a VM booted on a security-patched Xen 4.13, and then migrated
on to any newer version of Xen on the same or compatible hardware would have
these features stripped back because Xen is still editing the cpu-policy for
sanity behind the back of the toolstack.
For VMs using BHI_DIS_S to mitigate Native-BHI, this resulted in a failure to
restore the guests MSR_SPEC_CTRL setting:
(XEN) HVM d7v0 load MSR 0x48 with value 0x401 failed
(XEN) HVM7 restore: failed to load entry 20/0 rc -6
Fixes: e9b4fe263649 ("x86/cpuid: support LFENCE always serialising CPUID bit") Fixes: f3709b15fc86 ("x86/cpuid: Infrastructure for cpuid word 7:2.edx") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Tue, 3 Dec 2024 08:14:46 +0000 (08:14 +0000)]
CI: Update to FreeBSD 14.2
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- CC: Roger Pau Monné <roger.pau@citrix.com> CC: Anthony PERARD <anthony.perard@vates.tech> CC: Stefano Stabellini <sstabellini@kernel.org>
https://cirrus-ci.com/task/5913096629256192
xen/arm: mpu: Implement a dummy enable_secondary_cpu_mm
Secondary cpus initialization is not yet supported. Thus, we print an
appropriate message and put the secondary cpus in WFE state.
And we introduce to BUILD_BUG_ON to prevent users using from building Xen
on multiprocessor based MPU systems.
In Arm, there is no clean way to disable SMP. As of now, we wish to support
MPU on UNP only. So, we have defined the default range of NR_CPUs to be 1 for
MPU.
After the regions have been created, now we enable the MPU. For this we disable
the background region so that the new memory map created for the regions take
effect. Also, we treat all RW regions as non executable and the data cache is
enabled.
xen/arm: mpu: Create boot-time MPU protection regions
Define enable_boot_cpu_mm() for the Armv8-R AArch64.
Like boot-time page table in MMU system, we need a boot-time MPU protection
region configuration in MPU system so Xen can fetch code and data from normal
memory.
To do this, Xen maps the following sections of the binary as separate regions
(with permissions) :-
1. Text (Read only at EL2, execution is permitted)
2. RO data (Read only at EL2)
3. RO after init data and RW data (Read/Write at EL2)
4. Init Text (Read only at EL2, execution is permitted)
5. Init data and BSS (Read/Write at EL2)
Before creating a region, we check if the count exceeds the number defined in
MPUIR_EL2. If so, then the boot fails.
Also we check if the region is empty or not. IOW, if the start and end address
are same, we skip mapping the region.
To map a region, Xen uses the PRBAR_EL2, PRLAR_EL2 and PRSELR_EL2 registers.
One can refer to ARM DDI 0600B.a ID062922 G1.3 "General System Control
Registers", to get the definitions of these registers. Also, refer to G1.2
"Accessing MPU memory region registers", the following
```
The MPU provides two register interfaces to program the MPU regions:
- Access to any of the MPU regions via PRSELR_ELx, PRBAR<n>_ELx, and
PRLAR<n>_ELx.
```
We use the above mechanism to create the MPU memory regions.
Also, the compiler needs the flag ("-march=armv8-r") in order to build Xen for
Armv8-R AArch64 MPU based systems. There will be no need for us to explicitly
define MPU specific registers.
Julien Grall [Wed, 27 Nov 2024 10:55:12 +0000 (10:55 +0000)]
xen/arm32: Get rid of __memzero()
All the code in arch/arm32/lib/ where copied from Linux 3.16
and never re-synced since then.
A few years ago, Linux got rid of __memzero() because the implementation
is very similar to memset(p,0,n) and the current use of __memzero()
interferes with optimization. See full commit message from Linux below.
So it makes sense to get rid of __memzero in Xen as well.
From ff5fdafc9e9702846480e0cea55ba861f72140a2 Mon Sep 17 00:00:00 2001
From: Nicolas Pitre <nicolas.pitre@linaro.org>
Date: Fri, 19 Jan 2018 18:17:46 +0100
Subject: [PATCH] ARM: 8745/1: get rid of __memzero()
The __memzero assembly code is almost identical to memset's except for
two orr instructions. The runtime performance of __memset(p, n) and
memset(p, 0, n) is accordingly almost identical.
However, the memset() macro used to guard against a zero length and to
call __memzero at compile time when the fill value is a constant zero
interferes with compiler optimizations.
Arnd found tha the test against a zero length brings up some new
warnings with gcc v8:
And successively rremoving the test against a zero length and the call
to __memzero optimization produces the following kernel sizes for
defconfig with gcc 6:
So it is probably not worth keeping __memzero around given that the
compiler can do a better job at inlining trivial memset(p,0,n) on its
own. And the memset code already handles a zero length just fine.
Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Nicolas Pitre <nico@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Origin: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git ff5fdafc9e97 Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Michal Orzel <michal.orzel@amd.com> Signed-off-by: Julien Grall <jgrall@amazon.com>
Roger Pau Monné [Mon, 2 Dec 2024 14:22:05 +0000 (15:22 +0100)]
xen/Kconfig: livepatch-build-tools requires debug information
The tools infrastructure used to build livepatches for Xen
(livepatch-build-tools) consumes some DWARF debug information present in
xen-syms to generate a livepatch (see livepatch-build script usage of readelf
-wi).
The current Kconfig defaults however will enable LIVEPATCH without DEBUG_INFO
on release builds, thus providing a default Kconfig selection that's not
suitable for livepatch-build-tools even when LIVEPATCH support is enabled,
because it's missing the DWARF debug section.
Fix by defaulting DEBUG_INFO to enabled when LIVEPATCH is.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Mon, 2 Dec 2024 08:50:14 +0000 (09:50 +0100)]
x86emul: MOVBE requires a memory operand
The reg-reg forms should cause #UD; they come into existence only with
APX, where MOVBE also extends BSWAP (for the latter not being "eligible"
to a REX2 prefix).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jason Andryuk [Mon, 2 Dec 2024 08:49:38 +0000 (09:49 +0100)]
xl: Keep monitoring suspended domain
When a VM transitioned to LIBXL_SHUTDOWN_REASON_SUSPEND, the xl daemon
was exiting as 0 = DOMAIN_RESTART_NONE "No domain restart".
Later, when the VM actually shutdown, the missing xl daemon meant the
domain wasn't cleaned up properly.
Add a new DOMAIN_RESTART_SUSPENDED to handle the case. The xl daemon
keeps running to react to future shutdown events.
The domain death event needs to be re-enabled to catch subsequent
events. The libxl_evgen_domain_death is moved from death_list to
death_reported, and then it isn't found on subsequent iterations through
death_list. We enable the new event before disabling the old event, to
keep the xenstore watch active. If it is unregistered and
re-registered, it'll fire immediately for our suspended domain which
will end up continuously re-triggering.
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Oleksii Kurochko [Tue, 19 Nov 2024 14:55:32 +0000 (15:55 +0100)]
drivers/char: rename arm-uart.c to uart-init.c
Rename the file containing uart_init() to enable reuse across other
architectures that utilize device trees or SPCR tables to locate UART
information.
After locating UART data, {acpi}_device_init() is called to initialize
the UART.
arm_uart_init() is renamed to uart_init() to be reused by other
architectures.
A new configuration option, CONFIG_GENERIC_UART_INIT, is introduced,
currently available only for Arm. Enabling CONFIG_UART_INIT on additional
architectures will require additional functionality, such as device tree
mapping and unflattening, etc.
arm-uart.c is removed from "ARM (W/ VIRTUALIZATION EXTENSIONS) ARCHITECTURE"
section in the MAINTAINERS file, as it is no longer Arm-specific and can
now be maintained by maintainers of other architectures.
Use GENERIC_UART_INIT for CONFIG_ARM by adding `select GENERIC_UART_INIT`
to CONFIG_ARM.
Luca Fancellu [Thu, 14 Nov 2024 10:28:02 +0000 (10:28 +0000)]
xen/device-tree: Allow region overlapping with /memreserve/ ranges
There are some cases where the device tree exposes a memory range
in both /memreserve/ and reserved-memory node, in this case the
current code will stop Xen to boot since it will find that the
latter range is clashing with the already recorded /memreserve/
ranges.
Furthermore, u-boot lists boot modules ranges, such as ramdisk,
in the /memreserve/ part and even in this case this will prevent
Xen to boot since it will see that the module memory range that
it is going to add in 'add_boot_module' clashes with a /memreserve/
range.
When Xen populate the data structure that tracks the memory ranges,
it also adds a memory type described in 'enum membank_type', so
in order to fix this behavior, allow overlapping with the /memreserve/
ranges in the 'check_reserved_regions_overlap' function when a flag
is set.
In order to implement this solution, there is a distinction between
the 'struct membanks *' handled by meminfo_overlap_check(...) that
needs to be done, because the static shared memory banks doesn't have
a usable bank[].type field and so it can't be accessed, hence now
the 'struct membanks_hdr' have a 'enum region_type type' field in order
to be able to identify static shared memory banks in meminfo_overlap_check(...).
While there, set a type for the memory recorded using meminfo_add_bank()
from efi-boot.h.
Denis Mukhin [Tue, 26 Nov 2024 23:21:52 +0000 (15:21 -0800)]
xsm/flask: missing breaks, MISRA rule 16.4
While working on console forwarding for virtual NS8250 I stepped into
flask_domain_alloc_security()
where break statement was missing in default case which violates MISRA
rule 16.4.
Fixed everywhere in hooks.c.
Signed-off-by: Denis Mukhin <dmukhin@ford.com> Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
projects / people / andrewcoop / xen.git / log