When Dom0 informs us about MMCFG usability, this may change whether
extended capabilities are available (accessible) for devices. Zap what
might be on record, and re-initialize things.
No synchronization is added for the case where devices may already be in
use. That'll need sorting when (a) DomU support was added and (b) DomU-s
may run already while Dom0 / hwdom still boots (dom0less, Hyperlaunch).
vpci_cleanup_capabilities() also shouldn't have used
pci_find_ext_capability(), as already when the function was introduced
extended config space may not have been (properly) accessible anymore,
no matter whether it was during init. Extended capability cleanup hooks
need to cope with being called when the respective capability doesn't
exist (and hence the corresponding ->init() hook was never called).
Fixes: 70e6dace74 ("vpci: Use cleanup to free capability resource during deassign")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
The label used upon the function failing is wrong. Instead of correcting
the label, move the invocation up a little, to also avoid it altogether
for the idle domain (where ->vmtrace_size would be zero, and hence the
function would bail right away anyway).
Fixes: 217dd79ee2 ("xen/domain: Add vmtrace_size domain creation parameter")
Reported-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Using plain (signed) int variables as array indexes can be unhelpful on at
least x86, where the compiler may see the need to insert sign-extension
insns (strictly speaking it should be able to avoid that when the loop
continuation condition says >= 0, but that's not generally the case even
with gcc15).
Observed effects with gcc15 (will of course vary with compiler version and
level of optimization):
- on x86, one less preserved register in use, yet due to sub-optimal
choice of register variables still a small code size increase (%r12
isn't a good choice when it's used for base-without-index addressing, as
it requires a SIB byte which other registers wouldn't require),
- on Arm64 code size decreases, albeit that's eaten up by padding which is
being inserted ahead of a few labels,
- on Arm32 code size increases for a reason I didn't fully understand (my
ability to read Arm assembly is still somewhat limited).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
A hotplugged PCI device may be added uninitialized. In particular,
memory decoding might be disabled and the BARs might be zeroed. In this
case, the BARs will not be mapped in p2m. However, vpci_make_msix_hole()
unconditionally attempts to punch holes in p2m, leading to init_msix()
failing:
(XEN) d0v0 0000:01:00.0: existing mapping (mfn: 1c1880 type: 0) at 0 clobbers MSIX MMIO area
(XEN) d0 0000:01:00.0: init legacy cap 17 fail rc=-17, mask it
vpci_make_msix_hole() should only attempt to punch holes if the BARs
containing the MSI-X/PBA tables are mapped in p2m. Introduce a helper
for checking if a BAR is enabled, and add a check for the situation
inside vpci_make_msix_hole().
As a result of the newly introduced checks in vpci_make_msix_hole(),
move the call to vpci_make_msix_hole() within modify_decoding() to after
setting ->enabled.
Fixes: ee2eb6849d ("vpci: Refactor REGISTER_VPCI_INIT")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
We cannot assume extended config space to (still) be accessible when
cleaning up. Necessary values need caching instead. In fact, as the caller
also cannot look up extended capabilities, the cleanup function needs to
cope with being called when there's no ReBAR capability at all.
As kind of a side effect nbars being 0 (which init_rebar() doesn't
explicitly reject) no longer results in a bogus call to
vpci_remove_registers().
Fixes: ee459aeac0 ("vpci/rebar: Implement cleanup function for Rebar")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Fixes this `-fsanitize=undefined` error:
```
test_x86_emulator.c:614:12: runtime error: null pointer passed as argument 1, which is declared to never be null
/usr/include/string.h:44:28: note: nonnull attribute specified here
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior test_x86_emulator.c:614:12
```
Although this is more of a grey area: I don't see anything in the
standard that'd forbid calling `memcpy` with NULL and 0, but `glibc`
does specify it as non-null, which allows the compiler to make
optimizations assuming it never is NULL, so this is undefined behaviour
only on glibc.
Best to avoid the potential undefined behaviour though.
Signed-off-by: Edwin Török <edwin.torok@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Fixes this `-fsanitize=undefined` error:
```
test_x86_emulator.c:1103:32: runtime error: left shift of 573785183 by 2 places cannot be represented in type 'int'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior test_x86_emulator.c:1103:32
```
Signed-off-by: Edwin Török <edwin.torok@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
ticks_to_ns() and ns_to_ticks() are not architecture-specific, so provide a
common implementation that is more resilient to overflow than the historical
Arm version. This is not a practical issue for Arm, as the latest ARM ARM
that timer frequency should be fixed at 1 GHz and older platforms used much
lower rates, which is shy of 32-bit overflow. As the helpers are declared
as static inline, they should not affect x86, which does not use them.
On Arm, these helpers were historically implemented as out-of-line functions
because the counter frequency was originally defined as static and unavailable
to headers [1]. Later changes [2] removed this restriction, but the helpers
remained unchanged. Now they can be implemented as static inline without any
issues.
Centralising the helpers avoids duplication and removes subtle differences
between architectures while keeping the implementation simple.
Drop redundant <asm/time.h> includes where <xen/time.h> already pulls it in.
No functional change is intended.
[1] ddee56dc29 arm: driver for the generic timer for ARMv7
[2] 096578b4e4 xen: move XEN_SYSCTL_physinfo, XEN_SYSCTL_numainfo and
XEN_SYSCTL_topologyinfo to common code
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
... both for when the functions are invoked and where they live in source.
Don't invoke them directly in vpci_init_header(), but instead first thing
in vpci_init_capabilities().
Suggested-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Let's keep capability handling together. Start with moving
vpci_init_capabilities() and its helpers, plus splitting out of its
cleanup counterpart.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Before adding more private stuff to xen/vpci.h, split it up. In order to
be able to include the private header first in a CU, the per-arch struct
decls also need to move (to new asm/vpci.h files).
While adjusting the test harness'es Makefile, also switch the pre-existing
header symlink-ing rule to a pattern one.
Apart from in the test harness code, things only move; no functional
change intended.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
With the shadow stack and exception handling adjustements in place, we can now
activate FRED when appropriate. Note that opt_fred is still disabled by
default until more development is complete.
Introduce init_fred() to set up all the MSRs relevant for FRED. FRED uses
MSR_STAR (entries from Ring3 only), and MSR_FRED_SSP_SL0 aliases MSR_PL0_SSP
when CET-SS is active. Otherwise, they're all new MSRs.
Also introduce init_fred_tss(). At this juncture we need a TSS set up, even
if it is mostly unused. Reinsert the BUILD_BUG_ON() checking the size of the
TSS against 0x67, this time with a more precise comment.
With init_fred() existing, load_system_tables() and legacy_syscall_init()
should only be used when setting up IDT delivery. Insert ASSERT()s to this
effect, and adjust the various init functions to make this property true.
The FRED initialisation path still needs to write to all system table
registers at least once, even if only to invalidate them. Per the
documentation, percpu_early_traps_init() is responsible for switching off the
boot GDT, which also needs doing even in FRED mode.
Finally, set CR4.FRED in traps_init()/percpu_early_traps_init().
Xen can now boot in FRED mode and run a PVH dom0. PV guests still need more
work before they can be run under FRED.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Under FRED, there's one entrypoint from Ring 3, and one from Ring 0.
FRED gives us a good stack (even for SYSCALL/SYSENTER), and a unified event
frame on the stack with all flags cleared, meaning that all software needs to
do is spill the GPRs with a line of PUSHes. Introduce PUSH_AND_CLEAR_GPRS for
this purpose, along with the matching POP_GPRS.
Introduce entry_FRED_R0() which to a first approximation is complete for all
event handling within Xen.
entry_FRED_R0() needs deriving from entry_FRED_R3(), so introduce a basic
Ring3 handler. There is more work required to make the return-to-guest path
work under FRED.
Also introduce entry_from_{xen,pv}() to be the C level handlers. By simply
copying regs->fred_ss.vector into regs->entry_vector, we can reuse all the
existing fault handlers.
Extend fatal_trap() to render the event type including name, when FRED is
active. This is slightly complicated, because X86_ET_OTHER must not use
vector_name() or SYSCALL and SYSENTER get rendered as #BP and #DB.
This is sufficient to handle all interrupts and exceptions encountered during
development, including plenty of Double Faults.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
FRED doesn't use Supervisor Shadow Stack tokens. This means that:
1) memguard_guard_stack() should not write Supervisor Shadow Stack Tokens.
2) cpu_has_bug_shstk_fracture is no longer relevant when deciding whether to
enable Shadow Stacks or not.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
We wish to make use of opt_fred earlier on boot, which involves moving
traps_init() earlier, but this comes with several ordering complications.
The feature word containing FRED needs collecting in early_cpu_init(), and
legacy_syscall_init() cannot be moved that early because it relies on the
stubs being allocated, yet must be called ahead of cpu_init() so the SYSCALL
linkage MSRs are set up before being cached.
Delaying legacy_syscall_init() is easy enough based on a system_state check.
Reuse bsp_traps_reinit() to cause a call to legacy_syscall_init() to occur at
the same point as previously.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Lets just say this took an unreasonable amount of time and effort to track
down, when trying to move traps_init() earlier during boot.
When the SYSCALL linkage MSRs are not configured ahead of _svm_cpu_up() on the
BSP, context switch clobbers the later-set-up linkage with the 0's cached
here. Amongst other problems, this causes PV guest to enter at 0 in
supervisor mode on the user stack.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Commit 564d261687 ("x86/ctxt-switch: Document and improve GDT handling") put
the initialisation of {,compat_}gdt_l1e into traps_init() but this wasn't a
great choice. Instead, put it in smp_prepare_cpus() which performs the BSP
preparation of variables normally set up by cpu_smpboot_alloc() for APs.
This removes an implicit dependency that prevents traps_init() moving earlier
than move_xen() in the boot sequence.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
... seeing as I've had to thoroughly reverse engineer it for FRED and make
tweaks in places.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
For INT $N instructions (besides $0x80 for which there is a dedicated fast
path), handling is mostly fault-based because of DPL0 gates in the IDT. This
means that when the guest kernel allows the instruction too, Xen must
increment %rip to the end of the instruction before passing a trap to the
guest kernel.
When an INT $N instruction has a prefix, it's longer than two bytes, and Xen
will deliver the "trap" with %rip pointing into the middle of the instruction.
Introduce a new pv_emulate_sw_interrupt() which uses x86_insn_length() to
determine the instruction length, rather than assuming two.
This is a change in behaviour for PV guests, but the prior behaviour cannot
reasonably be said to be intentional.
This change does not affect the INT $0x80 fastpath. Prefixed INT $N
instructions occur almost exclusively in test code or exploits, and INT $0x80
appears to be the only user-usable interrupt gate in contemporary PV guests.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Multiple downstream distros have tried passing discrete CPIO archives and
tripped over this not working. It turns out to be easy to support, so do so.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Teddy Astie <teddy.astie@vates.tech>
The first parameter passed to align_timer() is the timer expiration, not
the current time. Adjust the calls to align_timer() in the on-demand
governor to pass the expected timer expiration as the first parameter.
Fixes: af74e3a15a ("cpufreq: align dbs timer for better package C state residency")
Fixes: 382b95f627 ("Fix cpufreq HW-ALL coordination handle")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The logic in dbs_check_cpu() resets the sampling window even when the
sampling period is considered too small. This leads to further calls
finding an imbalance between the total window time and the idle time, as
the total window time is possibly shorter than the idle time.
Fix by resetting the sampling window start time in the same block where the
current idle time is stored. While there also prevent a duplicated call to
NOW() and instead re-use the previously fetched value.
Fixes: d6f001cb91 ("x86: Implement cpufreq ondemand policy")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
After e4c3755d4d the function efi_halt_system() is unreachable, remove it
from the file.
No functional change expected, as the function is not called.
Fixes: e4c3755d4d ("x86-64/EFI: don't call EfiResetSystem() from machine_halt()")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Package "bridge-utils" have been removed from the official repos, it
contained `brctl`. That utility is used by network hotplug scripts,
but they already check if it is available and switch to use "iproute2"
(`ip`) when not.
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
If we start a guest with 'cpus="all"' and without 'vcpus' or
'maxvcpus' (or sets them to 0), we execute parse_vcpu_affinity() with
`num_cpus=0`. This malloc "b_info->vcpu_hard_affinity" with a buffer
of size 0, which is implementation defined, and we still initialise
the "first" bitmap of this allocation, which mean we have a buffer
overflow.
On Alpine Linux, this result in a segv when the buffer is being
disposed of.
Since libxl will assume there's at least 1 vcpu, we default to 1 in
xl as well. (libxl sets max_vcpus to 1 if unset, and allocate
avail_vcpus if its size is 0.)
Link: https://gitlab.alpinelinux.org/alpine/aports/-/issues/17809
Fixes: a5dbdcf674 ("libxl/xl: push VCPU affinity pinning down to libxl")
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
As per the standard this is UB, i.e. we're building on an extension in
the compilers we use (for gcc, see "The C Preprocessor" section
"Directives Within Macro Arguments"). Misra C:2012 rule 20.6 disallows
this altogether, though.
Combine the fix with some tidying: Fold the two level-1 checks, adjust in
particular comment style, and move the unlikely() use to a single inner
part of the conditional.
No functional change intended.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
And some AMD related code in emul-priv-op.c.
struct cpuinfo_x86
.x86 => .family
.x86_vendor => .vendor
.x86_model => .model
.x86_mask => .stepping
No functional change.
This work is part of making Xen safe for Intel family 18/19.
Signed-off-by: Kevin Lampis <kevin.lampis@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Archlinux just updated glibc to 2.43+r5+g856c426a7534-1 and that
causes libxl build failure:
libxl_cpuid.c: In function ‘libxl_cpuid_parse_config_xend’:
libxl_cpuid.c:447:16: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
447 | endptr = strchr(str, '=');
| ^
libxl_cpuid.c:452:16: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
452 | endptr = strchr(str, ',');
| ^
libxl_cpuid.c:454:20: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
454 | endptr = strchr(str, 0);
| ^
cc1: all warnings being treated as errors
Add missing consts. Note in libxl_cpuid_parse_config_xend() non-const
endptr still is needed, to be compatible with the second argument to
strtoul(). Add second variable for this reason.
And while at it, move semicolon to its own line
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
sh_destroy_shadow() has a spelling of fallthrough which doesn't match the
permitted pattern. Convert it to a real fallthrough (psedo)keyword.
Elsewhere, insert breaks at the end of the default statements.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
ECLAIR reports an unevaluated side effect in a sizeof() expression (R13.6
violation).
write_atomic() does take care to evaluates each parameter only once, but
expression is complicated to follow. Rewrite it to less resemble an entry
from an obfuscation contest.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
ECLAIR reports that tboot_gen_domain_integrity() is casting away
constness (Rule 11.8 violation).
vmac_set_key() doesn't modify the user_key parameter, so it can become const,
removing the need to cast.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
A range of functions can't see their declarations, requiring the inclusion of
appropriate headers.
For pv/mm.h and pv/traps.h, this requires adjustments to become stand-alone.
In pv/mm.h, swap xen/lib.h for xen/bug.h now that ASSERT_UNREACHABLE() has
moved. For pv/traps.h, pv_trap_callback_registered() needs to see a complete
struct vcpu, and xen/sched.h is not something appropriate to pull in
conditionally.
stack-protector.c can't see the declaration of __stack_chk_guard, and fixing
that reveals that stack-protector.h needs get_cycles() too.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
MISRA Rule 8.2 says that parameters must all have names. Rule 8.3 says that
the names and types must match between declaration and definition.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Use U where necessary (Misra Rule 7.2) and uppercase L (Misra Rule 7.3).
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
All of these are simple cases of using typeof() to avoid multiple parameter
evaluation. Using auto avoids multiple textural expansion also.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
There's no use creating a typed copy of a macro argument, simply to use it to
create a second typed copy. Remove the indirection, halving the number of
local variables created in scope.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Now that the type handling is entirely uniform, it's easier to see that
__declare_arg_3() can use __declare_arg_2() and so on, just like the larger
__declare_arg_$()'s already do.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
This is to aid with MGMT_HYPERCALL work, leaving the functions potentially
unreferenced (which Misra dislikes). By moving them to separate archive
members, the linker simply will not pick them up when not needed.
As the CPUID and MSR ones are always used together, put the "from" and
"to" variants of each together in one file respectively.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
... to a dedicated subdir of x86's private lib/ sub-tree.
For the CPU policy harnesses and libxenguest use $(lib-y) as set by the
new Makefile.common, whereas for the emulator harnesses stick to building
just cpuid.o for the time being.
Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The SMCCC v1.1 inline helper currently forces a1-a4 into
unsigned long and uses in/out constraints for r0-r3. In
contrast, a5-a7 are passed with their original types via
read-only constraints. On arm64 this means a 32-bit signed
value in a1-a4 is converted to a 64-bit unsigned value, while
the same value in a5-a7 keeps its signed 32-bit form. For
example, a negative int in a2 is widened to unsigned long, but
a negative int in a5 is passed as a 32-bit signed value, so the
SMC sees different encodings depending on argument position.
Switch the helper to use typed input registers arg0-arg7
derived from the call arguments (keeping a0 cast to u32) and
separate output registers r0-r3. This preserves argument types
consistently across all positions. Argument evaluation order
is unchanged, so we do not reintroduce the issue fixed in
"e00dc325bd9e" ("xen/arm: smccc-1.1: Handle function result as
parameters").
This also aligns Xen's SMCCC parameter handling with Linux's type-
preserving behavior (same externally visible argument handling,
independent implementation) to avoid surprising differences
between a1-a4 and a5-a7.
Current callers (PSCI, SCMI, platform SMC pass-through, OP-TEE,
and exynos5) pass unsigned values; exynos5 passes an int CPU id
which should always be > 0.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
MEM_SHARE failures in get_shm_pages() are silent, which makes malformed
ranges and page mapping failures hard to diagnose.
Add debug logging for page validation failures:
- descriptor validation failures (unaligned, range short/overflow)
- per-page mapping failures (unmapped GFN, wrong p2m type)
- address overflow detection in range walks
Ratelimit temporary reclaim failures and log permanent reclaim failures
as errors.
No functional changes.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Several FF-A paths log warnings for expected or recoverable conditions,
leading to noisy logs during normal operation.
Reduce log noise by:
- demoting unhandled FID warnings to debug
- ratelimiting notification and VM teardown failures
- printing the bit-15 convention warning once per boot
- adjusting log prefixes for hypervisor-only events
- adding debug diagnostics for RX/TX acquire failures, with busy cases
ratelimited
No functional changes.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Xen only maps a VM RX/TX buffer into the SPMC when firmware supports
FFA_RX_ACQUIRE. Without that mapping, the SPMC cannot access the VM TX
buffer to relay FFA_MSG_SEND2 to a secure partition.
Advertise FFA_MSG_SEND2 to guests only when VM-to-VM is enabled or when
the firmware supports both FFA_MSG_SEND2 and FFA_RX_ACQUIRE, and reject
SEND2 to a secure partition otherwise. Add comments to document the
mapping/ownership dependency.
Functional impact: SEND2 to a secure partition is reported as
NOT_SUPPORTED when FFA_RX_ACQUIRE is absent.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
FFA_FEATURES advertises several ABIs unconditionally, even when firmware
support is missing or when the ABI is physical-instance-only. This can
mislead guests about what Xen can actually provide and violates FF-A
calling conventions. Some SPMCs (Hafnium v2.14 or earlier) also fail to
report FFA_RX_ACQUIRE despite supporting it.
Update FFA_FEATURES validation to match spec and firmware support:
- do no check w2-w7 input registers during FFA_FEATURES as they are
flagged Should Be Zero by the FF-A specification or are not used by
the calls we support.
- reject 64-bit calling conventions from 32-bit guests with NOT_SUPPORTED
- return NOT_SUPPORTED for physical-instance-only ABIs
(FFA_NOTIFICATION_BITMAP_{CREATE,DESTROY}, FFA_RX_ACQUIRE)
- advertise FFA_INTERRUPT as supported
- gate message ABIs on firmware support:
- FFA_MSG_SEND_DIRECT_REQ_{32,64}
- FFA_MSG_SEND_DIRECT_REQ2 (also requires FF-A 1.2 negotiation)
- FFA_MSG_SEND2 (or VM-to-VM enabled)
- report MEM_SHARE_{32,64} only when FFA_MEM_SHARE_64 is supported
- stop advertising FFA_MSG_YIELD (not implemented)
Update firmware probing: drop FFA_MEM_SHARE_32 checks (deprecated) and
add FFA_RX_ACQUIRE to the probed set. If FFA_MSG_SEND2 is reported but
FFA_RX_ACQUIRE is not, assume RX_ACQUIRE support and warn to work
around the Hafnium bug.
Functional impact: guests now see ABI support that reflects firmware
capabilities and Xen implementation status. When SEND2 is present but
RX_ACQUIRE is not reported, Xen assumes RX_ACQUIRE support.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
rxtx_unmap() checks RX ownership without holding the RX/TX locks and
only enforces the ownership rule when FFA_RX_ACQUIRE is supported. This
allows a vCPU to acquire RX between the check and unmap, and it lets
RXTX_UNMAP proceed while RX is owned when buffers are not forwarded to
firmware.
Hold rx_lock/tx_lock across the ownership check and unmap, and deny
RXTX_UNMAP whenever RX is owned, independent of RX_ACQUIRE support. For
teardown, release RX ownership under the same lock window; use
FFA_RX_RELEASE directly because rx_lock is held, and clear the local
flag when the firmware path is unavailable.
Functional impact: RXTX_UNMAP now reliably returns DENIED while RX is
owned, and teardown releases/clears ownership without a race.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Jan Beulich
Stewart Hildebrand
Edwin Török
Oleksii Kurochko
Andrew Cooper
Roger Pau Monne
Anthony PERARD
Kevin Lampis
Marek Marczykowski-Górecki
Bertrand Marquis