panic_PAR() is only called from va_to_par(), which translates using
__va_to_par(), i.e. "at s1e2r" on arm64 and ATS1HR on arm32. Both
perform an EL2 stage 1 only translation, so PAR.S (PAR_STAGE2) and
PAR.PTW (PAR_STAGE21) can never be set.
This has been the case since commit a14447dbcf ("xen: arm: do not
panic when failing to translate a guest address"), which made
gva_to_par() and gva_to_ipa() return -EFAULT instead of calling
panic_PAR() for guest translations.
Print stage 1 unconditionally and keep an ASSERT() to document the
invariant. PAR_STAGE21 has no user left, so drop it. While at it, fix
the spacing in the decode_fsc() call.
No functional change intended.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
decode_fsc() derives the fault level from the low two bits of the FSC, so
level 0 is a valid output: FSC_FLT_TRANS is 0x04, i.e. "translation fault,
level 0 or translation table base register".
This is reachable on arm64 because xen_pgtable is the zeroeth-level root,
but fsc_level_str() has no case for it and prints " (level invalid)"
instead. At the time the function was created Xen used only three levels.
Add the missing case. On arm32 the zeroeth level does not exist but FSC
0 denotes address size fault at translation table base register.
While at it, make decode_fsc() decode also address size faults.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
On ARMv8.4-A and newer platforms, booting Dom0 Linux with ACPI enabled
causes the domain to probe advanced PMU feature based on system ID
register ID_AA64DFR0_EL1. During this probe, Linux accesses PMMIR_EL1,
which causes unhandled register traps and crashes the domain.
To address this issue, implement the following:
- Add emulation for ID_AA64DFR{0,1}_EL1, ID_DFR{0,1}_EL1 and
ID_DFR{0,1} register accesses for guest domains.
- Hide PMU registers from a guest domain when its vPMU feature is
disabled.
- Proactively make SPE, TRBE, BRBE, Trace Extensions, SPMU, ITE and
EBEP inaccessible to arm64 guest domains and hide TraceFilt,
MMapTrc and CopTrc to arm32 guest domains, as they could
potentially cause similar issues.
Fixes: dbb948110a ("xen: Expose the PMU to the guests")
Fixes: 07b9acea11 ("xen/arm: Add handler for ID registers on arm64")
Fixes: 3669a1cb95 ("xen/arm: create a cpuinfo structure for guest")
Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Just having called the function and stored the result, there's no point in
calling it again right away with the same argument; the stored result can
be used instead. And the stored result also doesn't need overwriting again
with the same value.
No functional change intended.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
FEP is now the only reason for the #UD handler to run.
While the #UD handler is unreachable when CONFIG_HVM_FEP is disabled, it's
helpful to keep the function around. Reinject #UD in the non-FEP case so
DCE can remove the rest.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Hypervisor leaf 5 is PV-specific, but is gated with !is_hvm_domain(),
which stays a runtime test in a build without PV support. Test for a
PV domain directly so the compiler can discard the leaf when
CONFIG_PV is disabled.
Suggested-by: Roger Pau Monné <roger@xenproject.org>
Signed-off-by: Jiaqing Zhao <Zhao.Jiaqing@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
While the CPU policy is obtained from hardware, the CRn values to start
with are taken from fuzzed input. Since most CR4 bits can only be set when
the respective feature is indicated as available by CPUID, the emulator
often only checks the CR4 bit. Without sanitization, assertions like the
one in emul_test_read_xcr() (checking XSAVE support) could therefore
trigger.
Omit most paging-only bits from sanitization, as the core emulator doesn't
itself walk page tables. LA57 wants checking for the bit being used by
CANONICALIZE_MAYBE().
Reported-by: Andrew Mbugua <andrewprecious388@gmail.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
It's possible for domains to generate unaligned PCI config space accesses
when using ECAM, and hence vPCI should support those at least for the
hardware domain. Such unaligned accesses to the PCI config space have been
reported to come from ACPI logic.
Relax the checking in vpci_access_allowed() to allow such accesses for the
hardware domain, and fix the handling in pci_conf_{read,write}{16,32}() to
fulfill them using MMCFG.
MMCFG regions are identity exposed to the hardware domain, and hence such
unaligned accesses can only come as a result of the host having MMCFG in the
first place, as otherwise MMCFG won't be exposed to the hardware domain
either.
Note that vpci_ecam_{read,write}() already refuse accesses that cross a
device boundary unconditionally.
Reported-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
I wrote the i.MX8M platform and UART support and can help review
patches touching these areas.
Signed-off-by: Wig Cheng <onlywig@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Add platform glue for the NXP i.MX8M family (i.MX8MP/MQ/MM/MN).
When Linux is used as dom0 a number of drivers make SiP SMC calls into
TF-A to manage hardware: GPC power domains, SRC (M-core remoteproc),
SoC info and NoC QoS. There is no public specification for these
calls; the function IDs and their subfunctions are taken from the
vendor kernel call sites.
Forward only the specific subfunctions the hardware domain issues,
following the whitelist model of the i.MX8QM platform. Each service
with a fixed set of subfunctions (GPC, SRC, NoC) filters them with an
explicit switch on the subfunction id, and the SoC info call is a
read-only query. CPU and DRAM frequency scaling are denied because
the hardware domain cannot make an informed decision about resources
shared with the other domains, and any unknown function ID is
rejected.
Signed-off-by: Wig Cheng <onlywig@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Research into compiler-invented loads has flagged FFA_MSG_SEND2 as a
possible vulnerability.
ffa_handle_msg_send2() copies the message header from the guest-writable
TX buffer before validating and using its fields. A plain structure copy
does not prevent the compiler from re-deriving later field accesses from
the live TX mapping.
For VM-to-VM messages, msg_offset and msg_size are validated against the
source and destination buffers, then used to copy the payload. If a
sibling vCPU changes the header and the compiler reloads either field,
the checked and used values can differ. This can cause an out-of-bounds
read from the sender's TX buffer or an out-of-bounds write into the
receiver's RX buffer.
The cross-VM path is gated by CONFIG_FFA_VM_TO_VM, which is disabled by
default. The audit ranks the likelihood of such a reload as low, but the
C semantics do not guarantee that later accesses use the stack copy.
Add a compiler barrier immediately after copying the header so that
validation and use consume the same snapshot.
Link: https://github.com/xoreaxeaxeax/schrodingers-toctou/blob/main/observer-effect/audits/audit-xen-tee-mediator-RELEASE-4.21.1.md#tm-2--ff-a-txrx-buffers-ffa_shmc-ffa_msgc
Fixes: 98af565b1e ("xen/arm: ffa: Add indirect message between VM")
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
I wrote the i.MX8M platform and UART support and can help review
patches touching these areas.
Signed-off-by: Wig Cheng <onlywig@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Add platform glue for the NXP i.MX8M family (i.MX8MP/MQ/MM/MN).
When Linux is used as dom0 a number of drivers make SiP SMC calls into
TF-A to manage hardware: GPC power domains, SRC (M-core remoteproc),
SoC info and NoC QoS. There is no public specification for these
calls; the function IDs and their subfunctions are taken from the
vendor kernel call sites.
Forward only the specific subfunctions the hardware domain issues,
following the whitelist model of the i.MX8QM platform. Each service
with a fixed set of subfunctions (GPC, SRC, NoC) filters them with an
explicit switch on the subfunction id, and the SoC info call is a
read-only query. CPU and DRAM frequency scaling are denied because
the hardware domain cannot make an informed decision about resources
shared with the other domains, and any unknown function ID is
rejected.
Signed-off-by: Wig Cheng <onlywig@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Add an early printk implementation for the classic i.MX UART IP,
selectable via EARLY_UART_CHOICE_IMX_UART. The UART is expected to be
fully initialized by the bootloader.
Signed-off-by: Wig Cheng <onlywig@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Add a console driver for the classic i.MX UART IP ("fsl,imx6q-uart"
compatible), used as the console UART on the i.MX8M family. Baudrate
and pin configuration are inherited from the bootloader; the driver
only enables the transmitter/receiver and wires up the RX/TX
interrupts, mirroring the existing imx-lpuart driver.
The i.MX8M family's UART IP differs from the LPUART used on
i.MX8QM/8QXP, so a separate driver is needed.
Signed-off-by: Wig Cheng <onlywig@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
The Xen nested virtualization code does not validate that the physical address
range assigned by the L1 guest, for IOPM, resides within the valid guest
physical memory. Add a sanity check to properly validate the IOPM is in the
valid L1 guest address range. This check also makes the behaviour compliant
with the hardware handling of the assigned address. The hardware is expected to
trigger VMEXIT_INVALID if the address of the last byte in the IOPM is greater
than or equal to the maximum supported physical address, see the APM
volume #2 (40332—Rev. 4.40—July 2026).
While at it, clean up the code. Remove the unused bool viopm and the
svm_vcpu::ns_oiomap_pa. Change nsvm_vmrun_permissionmap return error from
literal 1 to NSVM_ERROR_VVMCB.
Signed-off-by: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
..., for that logic to become reusable. While doing so undo the open-
coding of DIV_ROUND_UP(). Also switch to the new struct cpuinfo_x86 field
names.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger@xenproject.org>
printk_start_of_line() checks for a value of 0 right now. In order to be
able to have NOW() return at least monotonically increasing values, that
needs replacing by an explicit indicator.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Roger Pau Monné <roger@xenproject.org>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
In both setup_{k7,p6}_watchdog(), EvtSel0 is first zeroed, then written with
everything but the enable bit, then written with the enable bit.
setup_p4_watchdog() is slightly more complicated, owing to what
appears to be a bug introduced by commit 2a2bd8de16 ("Clean up NMI
watchdog handler."), which causes a second bit to be temporarily
different too.
The middle of the three writes is useless in all cases. Drop it.
While doing this, rename the 'counter' parameter for
setup_p6_watchdog(). It is the event which is passed in; the counter
is always counter 0.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Right now it's only checked in setup_p4_watchdog(), and not in
setup_p6_watchdog().
Perform the check in the common Intel path in setup_apic_nmi_watchdog(), and
pass misc_enable as a parameter into setup_p4_watchdog() to avoid reading it
twice.
Fixes: 0dfba864fb ("NMI watchdog support in Xen.")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
* Drop trailing whitespace
* Sort includes, dropping asm/mc146818rtc.h and asm/div64.h as unused
* Brace position, and types
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Model 3 was the first 64bit-capable P4. Xen won't be booting on anything
older, so remove the condition.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
FRED has formalised the event_data field. It already has more uses than
given (e.g. the NMI Source Bitmap), and further uses are expected in the
future.
Collapse the union into a single field called 'data' as the struct has event
in it's name, as well as 'event' being the common name for the variable.
Refer to the FRED spec rather than keeping an out-of-date list of uses.
Adjust all users of the old names.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
These refer to the segments themsevles, not to the registers, even if there is
a tight coupling between the two.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
x86_segment enumerates segments, not segment registers. Adjust the comment to
make this clearer.
Fix a stray tab with the closing #endif.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
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>
Michal Orzel