Move Xen version printout from 'h' keyhandler to the new dedicated
handler '?'.
Suggested-by: Roger Pau Monné <roger@xenproject.org>
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Currently there's no way to print Xen command line on the emergency
console for debugging purposes when 'xl' is unavailable.
Add new print_cmdline() function to print both built-in and run-time
command lines on the console.
To allow built-in command printout, drop __initconst in
'opt_builtin_cmdline' declaration.
Add new keyhander '?' to show command line printout.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This name is misleading.
It's not possible to configure NMI or not from the event select register; that
comes from the APIC configuration for performance events.
This name is "the thing we want to count for the NMI watchdog", but that's
clearer to follow when it simply names the event. Drop the indirection.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
With Oprofile support dropped, there are no more users of these. Drop them.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
It used to be the case that cpu_data[] inherited the BSP's cpuid_level until
the AP had calculated it itself. Following the rework, cpuid_level has a
placeholder 1 until it is calculated properly.
setup_apic_nmi_watchdog() happens to be called on the BSP after SMP bring-up,
meaning that the first call is on CPU1. It is also positioned in the window
where cpu_data[] is wrong.
As a result, setup_p6_watchdog()'s one-time calculation of the performance
counter width falls back into Pentium compatibility mode assuming 32bit
counters. This causes a watchdog NMI which is delayed a little (e.g. from an
SMI), to appear as if it hadn't overflowed, and therefore be considered as not
a watchdog NMI. On systems where unknown NMIs are treated as fatal, this
results in a spurious crash.
Switch setup_p6_watchdog() to use boot_cpu_data.cpuid_level, which is how this
is checked almost everywhere else.
core2_vpmu_init() used the same pattern to look at leaf 0xa. Despite being
init code and only running on the BSP, {boot,current}_cpu_data are different
objects, so switch it over to checking boot_cpu_data.cpuid_level too.
Fixes: 7126b7f806 ("x86/CPU: re-work populating of cpu_data[]")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The GICv3 secondary_init() callback can fail while discovering or
waking a Redistributor, enabling LPIs, or setting up an ITS collection.
gic_init_secondary_cpu() currently discards that status. start_secondary()
then marks the CPU online even though its per-CPU GIC interface may be
unusable.
Return the callback status through the common GIC layer. Have
start_secondary() report the failure and stop the affected CPU before it
updates system features or is added to cpu_online_map.
Fixes: bc183a0235 ("xen/arm: Add support for GIC v3")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
For whatever reason they didn't have an xsm_default_t first argument (to
cope with XSM=n mode), making it impossible to (easily) cover them in
xsm/hooks.h.
flask_do_xsm_op() is also changed to return int, as all the function ever
returns is an int. This way no new machinery needs adding to xsm/hooks.h.
Instead one piece of compat machinery can then be dropped from
xsm/flask/flask_op.c.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
This can be easily done in hypercall-defs.c, thus avoiding the need to
dive into xsm/ when building Xen, just to add code which does what is done
for an absent hypercall handler anyway (returning -ENOSYS).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolution.com>
Use of cf_check together with always_inline is pretty pointless, and with
XSM=n none of the dummy handlers are supposed to have their address taken.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
The comments on the PMINTENSET/PMINTENCLR cases claim that an EL0 access
may be trapped to EL2 when MDCR_EL2.TPM is set, and that such a case is
handled. Both are inaccurate. PMINTENSET_EL1/PMINTENCLR_EL1 are accessible
at EL1 and above only, with no enable making them accessible at EL0.
Arm ARM (DDI 0487M.b) D1.4.5.6 "Prioritization of Synchronous
exceptions" orders the two exceptions. An access that is never
accessible at the current Exception level regardless of any enables or
traps is priority 18, whereas an exception taken to EL2 as the result of
a configuration control in MDCR_EL2 is priority 24. An EL0 access is
therefore UNDEFINED and taken to EL1.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
do_sysreg() and do_cp15_32() inject an undefined exception when the
trapped access to ACTLR_EL1 (resp. ACTLR) originates from EL0. That
branch cannot be taken. ACTLR_EL1 can be accessed by EL1 and above, and no
enable makes them accessible at EL0. The only trap covering them,
HCR_EL2.TACR (HCR.TAC on AArch32), applies to accesses from EL1 only.
Refer Arm ARM (DDI 0487M.b) D1.4.5.6 "Prioritization of Synchronous
exceptions": "attempting to execute an instruction that is defined to
never be accessible at the current Exception level and Security state,
regardless of any enables or traps" is priority 18, whereas an exception
taken to EL2 as the result of a configuration control in HCR_EL2 is
priority 24. The former wins, so an access from EL0 is UNDEFINED and the
TACR trap is not taken.
An EL0 access therefore never reaches EL2: it is taken to EL1, as Xen
never sets HCR_EL2.TGE for guests, and it is reported with EC=0x00
(Unknown reason) rather than EC=0x18/0x03.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Split out struct x86_event to an entirely separate header, and move a few
other items describing the architecture to a new x86-types.h. With a few
forward decls of structures and with a fair number of new #include-s in
.c files, the inclusion of x86_emulate.h (and hence
x86_emulate/x86_emulate.h) can be dropped from all header files except
hvm/emulate.h; it needs additionally adding to hvm/ioreq.h though.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
There are several stubdoms mentioned in docs/misc/stubdom.txt which
no longer exist. Remove them.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
grub-pv was the last user of the stubdom variants of libxenguest and
libxenctrl.
Remove both libraries from the stubdom build system.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
With the removal of grub-pv there is no 32-bit stubdom left.
Remove 32-bit support from the stubdom build system.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
The Mini-OS based grub-pv is not being built by default since Xen 4.16.
Additionally it can be replaced in most cases by the more modern pvgrub
(part of grub upstream), while grub-pv is based on legacy grub 0.97.
In case someone is really depending on grub-pv, an old build from a
previous Xen version can be used without any problem, as only stable
hypercall interfaces are used by it.
Remove grub-pv from the build system.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
struct scheduler currently serves two purposes: it is the static
vtable a scheduler backend defines (name, opt_name, sched_id, and
all its function pointers), and it is also the per-cpupool runtime
object scheduler_alloc() allocates. Being the same type forces
scheduler_alloc() to memcpy() the whole vtable into a fresh
allocation per cpupool, duplicating identical function pointers
across every cpupool using the same scheduler.
Split the vtable out into its own type, struct sched_ops, so it
can be shared by every cpupool using a given scheduler instead of
copied per cpupool. struct scheduler is left holding only what is
actually per-instance: a pointer to the shared sched_ops, plus
sched_data and cpupool. scheduler_alloc() now stores a pointer to
the matching sched_ops instance instead of copying its fields and
uses xzalloc() to zero-initialize the struct. Every accessor in
private.h is updated from s->field to s->ops->field to match.
Every in-tree scheduler backend (credit, credit2, rtds, arinc653,
null) is converted from struct scheduler to struct sched_ops.
Also drop the generic comment in arinc653.c.
A handful of call sites elsewhere read a scheduler's name,
opt_name or sched_id directly and are updated to go through
->ops as well.
Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
domctl_psr_get_val() copies unitialized stack space back if psr_get_val
fails. Fix by zero-initializing v_.
Fixes: 03f30dc193 ("x86: refactor psr: L3 CAT: implement get value flow.")
Signed-off-by: Johann Höpfner <hoepf@cit.tum.de>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Xen does not provide much details for system reset debugging in case
system reset happens via ACPI subsystem.
Log reset I/O address and reset value.
While here, add the missing default case, add breaks between case
statements and drop full stops in the loglines.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Switch 'txbuf' allocation to xvmalloc_array() since there is no
hard requirement to have buffer physically contiguous.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
read_console_ring() and conring_flush() still use 'uint32_t' to access
indices.
Switch to 'unsigned int' to as required by CODING_STYLE.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Replace XENCONS_RING_IDX with unsigned int for the console ring indices,
as the console ring is not a Xen console (XENCONS) ring.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Add a convenience target generating the compilation database from a
built object tree, alongside the other developer conveniences (tags,
cscope, cloc -- the last of which already walks the same .cmd files):
make -C xen compile_commands.json
The output lands in the object tree root. For an in-tree build,
clangd and other consumers discover it there automatically when
opening files; for an out-of-tree build, symlink it into the source
tree root (consumers search the ancestors of the file being edited).
Note the database records the compiler invocations actually used.
With a clang build it is consumable by clangd as-is; for a gcc build,
clang-based tools may need a small .clangd configuration
(CompileFlags: Remove/Add) dropping gcc-only flags.
Also add the generated file to .gitignore.
Assisted-by: LLM
Signed-off-by: George Dunlap <gwd@xenproject.org>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Two changes from the Linux original:
- Linux's compiler invocations end with the source file
("... -c -o foo.o foo.c"), and the script's line pattern relies
on that; Xen's cmd_cc_o_c places "-c $<" before "-o" and "-MQ",
so on a Xen object tree the unmodified script matches nothing and
produces an empty database. Adjust _LINE_PATTERN to capture the
command up to and including "-c" plus the source file, dropping
the remainder, which database consumers do not need.
- Reword the docstring and help text to refer to Xen.
The support for reading object lists from archives and modules.order
is unused in Xen but retained to minimise divergence from the
original.
Assisted-by: LLM
Signed-off-by: George Dunlap <gwd@xenproject.org>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Xen's Kbuild-derived build system records the exact command line used
to compile each object in .<target>.o.cmd files. That is everything
needed to produce a compile_commands.json compilation database, the
format clangd and other tooling consume to provide accurate
cross-referencing (go to definition, find references, call hierarchy)
in LSP-capable editors.
Import scripts/clang-tools/gen_compile_commands.py from the Linux
kernel, unmodified, so that the provenance of the code is easy to
verify (commit 90efe2b9119f, Linux v6.16).
As-is the script produces an empty database on a Xen tree, since
Xen's compile command lines differ slightly from Linux's; the
following patch adapts it.
Assisted-by: LLM
Signed-off-by: George Dunlap <gwd@xenproject.org>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
Preparation for a followup patch "libs/guest: allocate various migration
arrays just once".
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
During migration there are a lot of mmap/munmap calls,
because xc_get_pfn_type_batch() exceeds the default hypercall bounce
buffer cache size, and needs to allocate every time it is called.
munmap() is slow, especially in a PV Dom0 (takes an emulation fault),
so is best avoided.
Eventually it'd be good if the memory pool from xmalloc_tlsf.c
was reused here, but for now make it handle the commonly encountered
sizes (so far up to 4 pages).
Signed-off-by: Edwin Török <edwin.torok@citrix.com>
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
There's some logic to avoid CC committers (THE REST section) when a
file is fully maintained by a list of maintainers. There's also some
logic to add maintainers if a patch or file contains some keywords.
We do add maintainers based on keyword to the list of $email_to before
checking if we can remove emails from THE REST. And at the time when
checking if we can drop THE REST, we've lost the information which
tell if the maintainers was added because of a keyword of because they
maintain the file.
Reorder the logic, add maintainers based on keywords only after
checking if we can drop THE REST.
For example, if we have a file covered by a sections with only
reviewers, but this file also contains the keyword "XSM", then:
scripts/get_maintainer.pl -f $file
would suppress THE REST without this patch.
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Jan Beulich <jbeulich@suse.com>
This will prevent eclair jobs from been started automatically
everywhere but in the main push repo, but still have the option to
start a jobs manually.
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
process_domain_node() parses "xen,static-mem" regardless of
CONFIG_STATIC_MEMORY. With the feature off, init_staticmem_pages() is a
no-op stub, so boot carries on until construct_domU() reaches the
ASSERT_UNREACHABLE() stubs of allocate_static_memory() /
assign_static_memory_11(): a debug build trips the assertion, a production
build gives the domain no memory at all.
Bail out at parse time instead, like process_shm_node() already does for
CONFIG_STATIC_SHM.
Fixes: 41c031ff43 ("xen/arm: introduce domain on Static Allocation")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
Radix trees are in principle usable as soon as memory allocation works.
(Radix trees with only index 0 populated are usable even earlier.) If only
there wasn't height_to_maxindex[], which is filled only by a pre-SMP
initcall. The benefit of this array is rather limited - the calculations
done by __maxindex() can as well be done by radix_tree_maxindex(); the
overhead isn't all this high.
This was found by UBSAN on a multi-segment system:
(XEN) UBSAN: Undefined behaviour in common/radix-tree.c:83:27
(XEN) index 12 is out of range for type 'long unsigned int [12]'
...
(XEN) Xen call trace:
(XEN) [<ffff82d040323f9c>] R common/ubsan/ubsan.c#ubsan_epilogue+0xa/0xd5
(XEN) [<ffff82d040324d91>] F __ubsan_handle_out_of_bounds+0x9d/0xd4
(XEN) [<ffff82d04029265a>] F radix_tree_insert+0x24d/0x570
(XEN) [<ffff82d04037ac3e>] F drivers/passthrough/pci.c#alloc_pseg+0xc4/0x165
(XEN) [<ffff82d040a3b526>] F pci_add_segment+0xc/0x1b
(XEN) [<ffff82d040a5ad1b>] F acpi_parse_mcfg+0x29b/0x344
(XEN) [<ffff82d040a3f612>] F acpi_table_parse+0x5d/0x92
(XEN) [<ffff82d040a5bf55>] F acpi_mmcfg_init+0x3a2/0x71d
(XEN) [<ffff82d040a71ba6>] F pci_setup+0x17/0x29
(XEN) [<ffff82d040a784d0>] F __start_xen+0x394c/0x4ed8
(XEN) [<ffff82d040423057>] F __high_start+0xb7/0xb8
Fixes: 21844b0e32 ("PCI multi-seg: introduce notion of PCI segments")
Fixes: 8dc6738dbb ("Update radix-tree.[ch] from upstream Linux to gain RCU awareness")
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
When a fault occurs on an IOMMU, print the IOMMU the fault is coming from.
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Acked-by: Jan Beulich <jbeulich@suse.com>
... and use it for ideal_nops and toolchain_nops_are_ideal; both of which are
invariant after arch_init_ideal_nops() has run.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The {k8,p6}_nops[] arrays are both 80-byte structures indexing 45-byte
structures. Furthermore, perhaps unusually for C, the source layout is an
obvious hint about the triangular nature of the structure.
Therefore, we can replace the pointer chase with some simple arithmetic.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
xen/livepatch.h is a fairly heavyweight header pulling in public/sysctl.h, and
a reasonable number of users care only for the init_or_livepatch_* tags.
They're arguably more init than livepatch anyway, and by moving them to
init.h, we can remove a number of includes.
The include in vsprintf was leftover from early versions of the work. In the
version committed, d5ccf4482e ("x86, xsplice: Print payload's symbol name
and payload name in backtraces"), symbol_lookup() had been adjusted to handle
the livepatch symbol names properly.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
xen/livepatch.h includes public/sysctl.h twice, which can be deduplicated.
xen/livepatch.h also includes asm/livepatch.h meaning that each livepatch.c
does not need to include both.
Comment the #else and #endif cases to aid legibility.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
They're unreachable / dead otherwise. Really resource_{,un}plug_pci() is
further limited to PCI pass-through.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Juergen Gross