When a physical memory bank spans multiple guest RAM banks, the variable
psize is modified inside the allocation loop, but the modified value
(instead of the original bank size) is added to tot_size. This causes an
incorrect total size calculation leading to false panic. Move the
tot_size calculation right after acquire_static_memory_bank().
Fixes: 487975df53 ("xen/arm: introduce allocate_static_memory")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Remove the part about platform defined address which is not true. The
help text is correct i.e. 0xFFFFFFFF is used as default value to indicate
that user has not customized this address.
Amends: d736b6eb45 ("xen/arm: mpu: Define Xen start address for MPU systems")
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
Physmap population has the need to use pages as big as possible to reduce
p2m shattering. However that triggers issues when big enough pages are not
yet scrubbed, and so scrubbing must be done at allocation time. On some
scenarios with added contention the watchdog can trigger:
Watchdog timer detects that CPU55 is stuck!
----[ Xen-4.17.5-21 x86_64 debug=n Not tainted ]----
CPU: 55
RIP: e008:[<ffff82d040204c4a>] clear_page_sse2+0x1a/0x30
RFLAGS: 0000000000000202 CONTEXT: hypervisor (d0v12)
[...]
Xen call trace:
[<ffff82d040204c4a>] R clear_page_sse2+0x1a/0x30
[<ffff82d04022a121>] S clear_domain_page+0x11/0x20
[<ffff82d04022c170>] S common/page_alloc.c#alloc_heap_pages+0x400/0x5a0
[<ffff82d04022d4a7>] S alloc_domheap_pages+0x67/0x180
[<ffff82d040226f9f>] S common/memory.c#populate_physmap+0x22f/0x3b0
[<ffff82d040228ec8>] S do_memory_op+0x728/0x1970
Introduce a mechanism to preempt page scrubbing in populate_physmap(). It
relies on stashing the dirty page in the domain struct temporarily to
preempt to guest context, so the scrubbing can resume when the domain
re-enters the hypercall. The added deferral mechanism will only be used for
domain construction, and is designed to be used with a single threaded
domain builder. If the toolstack makes concurrent calls to
XENMEM_populate_physmap for the same target domain it will trash stashed
pages, resulting in slow domain physmap population.
Note a similar issue is present in increase reservation. However that
hypercall is likely to only be used once the domain is already running and
the known implementations use 4K pages. It will be deal with in a separate
patch using a different approach, that will also take care of the
allocation in populate_physmap() once the domain is running.
Fixes: 74d2e11ccf ("mm: Scrub pages in alloc_heap_pages() if needed")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Future changes will care about the state of the PGC_need_scrub flag even
when pages have the PGC_allocated set, and hence it's no longer possible to
alias both values. Also introduce PGC_need_scrub to the set of preserved
flags, so it's not dropped by assign_pages().
No functional change intended, albeit the page counter on x86 looses a bit.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Use the new .config manipulation tool to toggle CONFIG_DEBUG in the
Xen automation build script.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Add alias -y ("yes") to --enable and -n ("no") to --disable a Kconfig
option for better scripting experience.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Drop the --module (-m) and --module-after (-M) options, as Xen
does not support loadable modules, so options are not applicable.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Manipulating Kconfig settings is often required when preparing a custom
Xen build using an external build system (e.g., a Yocto-based workflow).
Import the Kconfig manipulation tool from the Linux kernel
(commit 0f61b1860cc3, Linux v6.19-rc5) to support this use case.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
It is handy to have 2 CPUs and more RAM for smoke testing a hypervisor
change via XTF.
Align x86 QEMU configuration with Arm for XTF tests: 2 CPU and 2G of RAM.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
As was recently noticed with PCI_X_STATUS_533MHZ, leaving presently unused
#define-s in non-Misra-compliant shape (7.2 is "A `u' or `U' suffix shall
be applied to all integer constants that are represented in an unsigned
type") is putting new code actually using any of the constants at risk of
then causing Misra scan failures in CI. Adjust those few constants which
strictly require a suffix.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Rather than spelling out their amounts (requiring updates when multiples
of 32 are crossed), introduce a sentinel each and calculate the two
numbers from those.
No difference in generated code, albeit debug info size grows quite a bit.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
cpumask_var_t can resolve to a pointer or to an array. While the pointer
typically is allocated once for a CPU and then only read (i.e. wants to be
marked read-mostly), the same isn't necessarily true for the array case.
There things depend on how the variable is actually used. cpu_core_mask
and cpu_sibling_mask (which all architectures have inherited from x86,
which in turn is possibly wrong) are altered only as CPUs are brought up
or down, so may remain uniformly read-mostly. Other (x86-only) instances
want to change, to avoid disturbing adjacent read-mostly data.
While doing the x86 adjustment, also do one in the opposite direction,
i.e. where there was no read-mostly annotation when it is applicable in
the "pointer" case.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
The types are local to the shadow and HAP subsystems respectively, and
HAP has no need for the shadow-specific fields (i.e. it can get away with
smaller allocations). In struct hvm_domain it therefore suffices to have
a union of two (generally opaque) pointers.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
It's really FIRST_IRQ_VECTOR vector which is meant here, i.e. effectively
there is a form of open-coding in use right now.
No change in practice, due to the present aliasing.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Expose the RX/TX MAP capacity field only once a guest has
negotiated FF-A v1.2.
While there, drop the stale <asm/tee/ffa.h> include.
To comply with the wider v1.2 register ABI, zero registers x8–x17 when
responding to a v1.2 VM. The dispatcher also rejects SMCCC64 calls from
AArch32 guests.
Finally, bump Xen's FF-A version to 1.2.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Extend the direct-request path so FF-A v1.2 guests can issue
FFA_MSG_SEND_DIRECT_REQ2 and receive the matching RESP2.
The handler now marshals registers x8–x17, and
ffa_finish_direct_req_run() copies back the 17-register response used by
FFA_MSG_SEND_DIRECT_RESP2. The new opcode is exposed via FFA_FEATURES
and gated on guests that negotiated v1.2.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Teach the SEND2 path about the distinct FF-A v1.1 and v1.2 RX/TX header
layouts so we can propagate the 128-bit UUIDs introduced in v1.2.
VM-to-VM SEND2 calls now build the larger v1.2 header, zeroing the UUID
fields for v1.1 senders, and the dispatcher validates messages using
the v1.1 header layout to keep legacy guests working.
While there, make the code more robust by checking that the send is not
trying to send a message to himself.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Add FFA_RUN support and remove mention that YIELD and INTERRUPT are not
supported in the comment as we will now return them.
Make FFA_FEATURE answer supported for RUN, YIELD and INTERRUPT.
Share the SMCCC plumbing used by SEND_DIRECT and RUN via a common
ffa_finish_direct_req_run() helper so canonical success and error cases
are handled in one place.
The dispatcher now routes FFA_RUN through ffa_handle_run(), and direct
requests bail out early if a guest targets itself or a non-secure
endpoint. This simplifies the direct path while adding support for
INTERRUPT or YIELD answers from secure world.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Introduce struct ffa_uuid together with nil/equality/set helpers, and
use it end-to-end in the partition-info plumbing.
The SP and VM enumeration paths now build UUIDs from the guest
registers, call a new ffa_copy_info() helper and ensure non-nil UUID
queries only return matching SP entries, relying on firmware UUID
filtering. VM entries are skipped because we do not track per-VM UUIDs.
Count requests and subscriber initialisation are updated accordingly so
firmware is always called with an explicit UUID. This keeps count and
listing requests aligned with the FF-A v1.1 rules while preserving the
Linux compatibility workaround for v1.2 requesters.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
The FF-A spec defines return status values as signed 32-bit integers.
Align the Xen mediator with this requirement by:
- switching the FF-A helpers (ffa_handle_mem_reclaim(), partition info
init, notification ops, dispatcher glue, etc.) to int32_t return types
so callers cannot silently truncate negative values
- masking SMCCC responses/exits in ffa_get_version(),
ffa_get_ret_code() and ffa_set_regs_error() to 32 bits before storing
them in guest registers
- updating notifier, shared-memory reclaim, partition-info and
dispatcher call sites to use the new prototypes so the entire FF-A
path propagates spec-compliant 32-bit signed error codes
While there, tidy up the FF-A notification helpers by using GENMASK(15, 0)
for endpoint extraction and fix the secure-endpoint check in
ffa_handle_notification_set() to apply the mask to the endpoint ID before
calling FFA_ID_IS_SECURE(), instead of testing the wrong halfword of
src_dst.
Fixes: 911b305e7b ("xen/arm: ffa: Enable VM to VM without firmware")
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Rework access to VM RX/TX buffer to use acquire/release functions
equivalent to the ones used for the SPMC RX/TX buffers and remove all
direct access to ctx->tx or ctx->rx by giving back the buffer pointer
and size back in acquire.
This design ensures that rx or page_count is not accessed without the
lock held and limit direct usage of the context rx/tx buffer info to
ffa_rxtx.c
Modify msg, partinfo and shm code to use the new RX/TX buffer
acquire/release functions and remove all direct accesses to rx/tx and
page_count so that any access is done only with the lock taken.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Rework how Xen accesses the RX/TX buffers shared with the SPMC so that
ownership and locking are handled centrally.
Move the SPMC RX/TX buffer bases into ffa_rxtx.c as ffa_spmc_rx/ffa_spmc_tx,
protect them with dedicated ffa_spmc_{rx,tx}_lock spinlocks and expose
ffa_rxtx_spmc_{rx,tx}_{acquire,release}() helpers instead of the global
ffa_rx/ffa_tx pointers and ffa_{rx,tx}_buffer_lock.
The RX helpers now always issue FFA_RX_RELEASE when we are done
consuming data from the SPMC, so partition-info enumeration and shared
memory paths release the RX buffer on all exit paths. The RX/TX mapping
code is updated to use the descriptor offsets (rx_region_offs and
tx_region_offs) rather than hard-coded structure layout, and to use the
TX acquire/release helpers instead of touching the TX buffer directly.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Harden the RX/TX mapping paths and keep signed FF-A return codes
end-to-end.
Reject zero-length mappings and insist on page-aligned RX/TX buffer
addresses before touching the P2M. The unmap plumbing is switched to
use the same signed helpers so dispatcher error handling is consistent
across map and unmap operations.
This avoids partially mapped or silently truncated buffers and makes the
mediator behaviour match the FF-A error model more closely.
Prevent concurrent usage of rx or tx buffer during map or unmap by
holding the rx_lock and tx_lock.
While there also introduce a domain_rxtx_init to properly initialize the
rxtx buffers spinlocks.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
is_64bit_domain(d) is not set during domain_init as the domain field is
only set when loading the domain image which is done after executing
domain_init.
Fix the implementation to set is_64bit when version gets negotiated.
is_64bit is only used during partition_info_get once a domain is added
in the list of domains having ffa support. It must only be accessed when
the rwlock is taken (which is the case).
is_64bit must not be used without the rwlock taken and other places in
the code needing to test 64bit support of the current domain will have
to use calls to is_64bit_domain instead of the field from now on.
Fixes: 09a201605f ("xen/arm: ffa: Introduce VM to VM support")
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Track FF-A version negotiation per VM and enforce that no FF-A ABI
(other than FFA_VERSION) is processed before a guest has selected a
version.
Each ffa_ctx gains a dedicated guest_vers_lock, a negotiated version
(guest_vers) and a guest_vers_tmp:
- guest_vers is the version negotiated or 0 if no version has been
negotiated. This must be used with ACCESS_ONCE when reading it without
the spinlock taken.
- guest_vers_tmp stores the version currently requested by a VM.
The version requested is the one actually negotiated once a call
different from FFA_VERSION is done to allow several attempts and as
requested by FF-A specification.
We always return our implementation version FFA_MY_VERSION, even if the
version requested was different, as requested by FF-A specification.
Any call other than FFA_VERSION is rejected until a version has been
requested.
Update all places in the code where guest_vers is used to use
ACCESS_ONCE.
This prevents partially initialised contexts from using the mediator
and complies with the FF-A 1.2 FFA_VERSION semantics.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Bring the FF-A headers up to the v1.2 baseline and fix the function-number
range used for ABI discovery:
- update FFA_FNUM_MAX_VALUE so the FF-A function-number window covers the
full v1.2 range, and derive the ABI bitmap bounds from
FFA_FNUM_MIN_VALUE/FFA_FNUM_MAX_VALUE instead of hard-coding
FFA_ERROR/FFA_MSG_SEND2
- define the new v1.2 function IDs; CONSOLE_LOG_32/64 and
PARTITION_INFO_GET_REGS are added for ABI discovery even though they are
not implemented yet
- extend the firmware ABI table to probe RUN and
MSG_SEND_DIRECT_REQ2/RESP2
- while there, fix an off-by-one in ffa_fw_supports_fid(): the computed bit
index must be strictly smaller than FFA_ABI_BITMAP_SIZE, so use >= in the
bounds check
- Also fix comment as call IDs reserved for FF-A are from 0x60 to 0xEF
Keep FFA_MY_VERSION at 1.1 for now; we only advertise v1.2 once the
implementation is fully compliant.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
When MSI-X initialization fails, vPCI hides the capability, but
removing handlers and datas won't be performed until the device is
deassigned. So, implement MSI-X cleanup hook that will be called
to cleanup MSI-X related handlers and free it's associated data when
initialization fails.
Since cleanup function of MSI-X is implemented, delete the open-code
in vpci_deassign_device().
Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
When MSI initialization fails, vPCI hides the capability, but
removing handlers and datas won't be performed until the device is
deassigned. So, implement MSI cleanup hook that will be called to
cleanup MSI related handlers and free it's associated data when
initialization fails.
Since cleanup function of MSI is implemented, delete the open-code
in vpci_deassign_device().
Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
When Rebar initialization fails, vPCI hides the capability, but
removing handlers and datas won't be performed until the device is
deassigned. So, implement Rebar cleanup hook that will be called to
cleanup Rebar related handlers and free it's associated data when
initialization fails.
Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Currently, an interrupt cause which is not explicitly handled is silently
ignored, and execution resumes without reporting the fault. This is
incorrect and do_unexpected_trap() should be called in the case of
unhandled interrupt.
Fixes: a8b85fabf6 ("xen/riscv: add external interrupt handling for hypervisor mode")
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
For DomU-s, whether to emulate accesses to the first 32 bits of extended
config space as read-as-zero or read-as-all-ones depends on whether a
device actually has extended config space. If it doesn't, read-as-zero
isn't correct; not getting this right may confuse functions like Linux
6.19-rc's pci_ext_cfg_is_aliased().
For Dom0 this then simply allows dropping a later conditional.
Fixes: a845b50c12 ("vpci/header: Emulate extended capability list for dom0")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Avoid interpreting as extended capabilities what may be about anything. In
doing so, vPCI then also won't mis-interpret data from beyond base config
space anymore.
Fixes: 3b35911d70 ("Enable pci mmcfg and ATS for x86_64")
Fixes: a845b50c12 ("vpci/header: Emulate extended capability list for dom0")
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>
Legacy PCI devices don't have any extended config space. Reading any part
thereof may return all ones or other arbitrary data, e.g. in some cases
base config space contents repeatedly.
Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our
determination of device type; in particular some comments are taken
verbatim from there. Like with Linux'es CONFIG_PCI_QUIRKS, only the alias
detection logic is covered by the new "pci=no-quirks". The singular access
at PCI_CFG_SPACE_SIZE is left unconditional.
For Misra's sake the PCI_X_STATUS_533HMZ definition also needs amending.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Don't know how I managed to overlook the freeing side when adding the case
to alloc_pdev().
Fixes: cd2b9f0b19 ("PCI: handle PCI->PCIe bridges as well in alloc_pdev()")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Only explicit writes are subject to e.g. the checking of the MSR intercept
bitmap, which extends to VM-event's hvm_monitor_msr(). Indicate, by way of
a new boolean parameter, to the hook functions which variant it is.
Fixes: 6eb43fcf8a ("x86emul: support SWAPGS")
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
RISC-V SMP support is not yet implemented, but smp_send_event_check_mask()
is required by common code and vcpu_kick(), which is introduced later.
Provide a temporary stub implementation that asserts the mask only targets
CPU0.
cpumask_subset() is used instead of cpumask_equal() because some callers
(e.g. cpumask_raise_softirq() or cpu_raise_softirq_batch_finish()) may
legitimately pass an empty mask, which would otherwise cause false
failures.
The BUG_ON() ensures that attempts to use this function with multiple CPUs
are caught early once SMP support is introduced.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
While sizes (and possibly positions) of the symbol table related symbols
(and as a result other ones) are expected to change from linking pass 1
to pass 2, no such change should happen anymore from pass 2 to pass 3, or
else the internally recorded symbol table wouldn't represent the ELF or
PE/COFF ones.
For comparing to be actually useful, i.e. most notably also covering the
last of the arrays emitted, symbol sizes need establishing. Make use of
the xen/linkage.h machinery to achieve that.
Suggested-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>
See the extensive code comment. This isn't really nice, but unless I'm
overlooking something there doesn't look to be a way to have the linker
strip individual symbols while doing its work.
Fixes: bf6501a62e ("x86-64: EFI boot code")
Reported-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Provide additional context when an unexpected exception occurs by dumping
the relevant Supervisor, Virtual Supervisor (VS), and Hypervisor CSRs,
along with the general-purpose registers associated with the trap.
Dumping VS-mode CSRs in addition to host CSRs is beneficial when analysing
VS-mode traps. VSCAUSE, VSEPC, VSTVAL, and related VS state are required to
properly diagnose unexpected guest traps and potential hypervisor
misconfiguration.
For example, on an illegal-instruction exception the hardware may record
the faulting instruction in VSTVAL. If VSTVAL is zero, VSEPC should always
be inspected, and can be used together with objdump to identify the
faulting instruction. Dumping VSCAUSE is also useful when the guest does
not report it, or when the hypervisor redirects a trap to the guest using
VSCAUSE, VSTATUS, and VSTVEC, allowing verification that a subsequent trap
is not caused by incorrect VS state.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The hook is never invoked in that case, and hence needlessly offers an
extra valid indirect call target. With the hook suppressed, no consumer
of the three local per-CPU variables exists either, so they're
suppressed as well.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The microcode suffix is redundant, and "microcode loading" is the more common
term.
Introduce the ucode_load() wrapper to encapsulate the alternative_call().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
cpu_request_microcode() was never a good name, and the microcode suffix is
redundant. Rename it to simply parse().
Introduce ucode_parse() and ucode_parse_dup() wrappers around the parse()
hook, also abstracting away the make_copy parameter and associated
const-correctness.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
This frees up the name to be reused a little differently.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Between RevD and RevE silicon, the feature MSRs moved location. This property
is highlighted by the suggested workaround for Erratum #110 which gives the
two different MSRs for the extended feature leaf.
The other feature MSRs are not given and while they're easy enough to figure
out I don't have any K8's to test the result with.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
As amd_init_de_cfg() states, it's only safe for there to be one location
writing to DE_CFG. This happens to be a latent bug rather than a real one
because Fam12h CPUs aren't SMT-capable. Nevertheless, group it together with
the other DE_CFG modifications.
This removes a printk() which is not noteworthy, and skips the adjustment
entirely under virt, where the attempted write wouldn't have stuck anyway.
Fixes: d0c75dc4c0 ("x86/amd: Fix race editing DE_CFG")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
parse_ucode() is abnormal compared to similar parsing elsewhere in Xen.
Invert the ucode_mod_forced check with respect to the "scan" and integer
handling, so we can warn the user when we've elected to ignore the parameters,
and yield -EINVAL for any unrecognised list element.
Rewrite the ucode= command line docs for clarity.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The previous logic attempted to skip an IBPB in the case of vCPU returning to
a CPU on which it was the previous vCPU to run. While safe for Xen's
isolation between vCPUs, this prevents the guest kernel correctly isolation
between tasks. Consider:
1) vCPU runs on CPU A, running task 1.
2) vCPU moves to CPU B, idle gets scheduled on A. Xen skips IBPB.
3) On CPU B, guest kernel switches from task 1 to 2, issuing IBPB.
4) vCPU moves back to CPU A. Xen skips IBPB again.
Now, task 2 is running on CPU A with task 1's training still in the BTB.
Do the flush unconditionally when switching to a vCPU different than the
idle one. Note there's no need to explicitly gate the IBPB to next domain
!= idle, as the context where the IBPB is issued is subject to that
condition already unless the pCPU is going offline, at which point we don't
really care to issue an extra IBPB.
Also add a comment with the reasoning why the IBPB needs to be in
context_switch() rather than __context_switch().
This is XSA-479 / CVE-2026-23553.
Fixes: a2ed643ed7 ("x86/ctxt: Issue a speculation barrier between vcpu contexts")
Reported-by: David Kaplan <david.kaplan@amd.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Guests can do wider-than-PTE-size writes on page tables. The tracing
helper variable, however, only offers space for a single PTE (and it is
being switched to the more correct type right here). Therefore bound
incoming write sizes to the amount of space available.
To not leave dead code (which is a Misra concern), drop the now unused
guest_pa_t as well.
Also move and adjust GUEST_PTE_SIZE: Derive it rather than using hard-
coded numbers, and put it in the sole source file where it's actually
needed. This then also addresses a Misra rule 20.9 ("All identifiers
used in the controlling expression of #if or #elif preprocessing
directives shall be #define'd before evaluation") violation:
GUEST_PAGING_LEVELS is #define'd only in multi.c.
This is XSA-477 / CVE-2025-58150.
Fixes: 9a86ac1aa3 ("xentrace 5/7: Additional tracing for the shadow code")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
No reason for it to be a separate per-CPU item; it's connected to a
struct cpufreq_policy instance just like other driver data.
This also eliminates the concern over amd_cppc_cpufreq_cpu_init() being
called for all CPUs, or a CPU going offline that's recorded in policy->cpu
(which would result in accesses of per-CPU data of offline CPUs).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Penny Zheng <penny.zheng@amd.com>
No reason for it to be a separate per-CPU item; it's connected to a
struct cpufreq_policy instance just like other driver data.
This further reduces the concern over amd_cppc_cpufreq_cpu_init() being
called for all CPUs, or a CPU going offline that's recorded in policy->cpu
(which would result in accesses of per-CPU data of offline CPUs).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Penny Zheng <penny.zheng@amd.com>
Michal Orzel