Currently, many common functions perform the same operations to calculate
GIC register addresses. This patch consolidates the similar code into
a separate helper function to improve maintainability and reduce duplication.
This refactoring also simplifies the implementation of eSPI support in future
changes.
Signed-off-by: Leonid Komarianskyi <leonid_komarianskyi@epam.com>
Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Acked-by: Julien Grall <jgrall@amazon.com>
In order to safely acquire a reference for a foreign page mapping, the
P2M lock needs to be held until we have the reference in hand (or
getting one failed). Otherwise the page can change P2M type and
ownership in between.
This is CVE-2025-58145 / part of XSA-473.
Fixes: 9486a8d07b ("xen/arm: Handle remove foreign mapping")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
I can't see what would make the 1st of the assertions safe: For example,
the P2M lock not being held, the foreign page may disappear before we
get to call page_get_owner_and_reference(), which hence may return NULL.
Even the 2nd, which appears to be safe safe, is lacking proper release
build fallbacks.
Drop the former in favor of an if(), and convert the latter to the
equivalent of what x86 uses: ASSERT_UNREACHABLE() plus putting of the
obtained page.
This is CVE-2025-58144 / part of XSA-473.
Fixes: 9486a8d07b ("xen/arm: Handle remove foreign mapping")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
The reference TSC page is shared between all vCPUs, and the data stored in
the domain struct. However the handlers to set and clear it are not safe
against concurrent accesses. It's possible for two (or more) vCPUs to call
HV_X64_MSR_REFERENCE_TSC at the same time and cause the in-use reference
TSC page to be freed, while still being on the p2m. This creates a use-
after-free bug, where the page can end up mapped in another domain or used
by Xen while still being part of the original domain's p2m.
It's also possible to underflow the reference counter, as multiple
concurrent writes to HV_X64_MSR_REFERENCE_TSC can create an imbalance on
the number of put_page_and_type() calls.
Introduce a lock to protect the reference TSC domain field, thus
serializing concurrent vCPU accesses.
This is CVE-2025-58143 / part of XSA-472.
Fixes: 386b336522 ('viridian: use viridian_map/unmap_guest_page() for reference tsc page')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The function is called unconditionally, regardless of whether the SIM page
is mapped. Avoid a NULL pointer dereference in
viridian_synic_deliver_timer_msg() by checking whether the SIM page is
mapped.
This is CVE-2025-58142 / part of XSA-472.
Fixes: 26fba3c855 ('viridian: add implementation of synthetic timers')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The function is only called when the MSR has the enabled bit set, but even
then the page might not be mapped because the guest provided gfn is not
suitable.
Prevent a NULL pointer dereference in update_reference_tsc() by checking
whether the page is mapped.
This is CVE-2025-27466 / part of XSA-472.
Fixes: 386b336522 ('viridian: use viridian_map/unmap_guest_page() for reference tsc page')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
In mca_cap_init function,the mcabanks_alloc allocates and
initializes an mca_banks structure for managing MCA banks,
setting up a bank map and storing the specified or default number
of banks.
After this we will call mcabanks_set(i, mca_allbanks);
The mcabanks_set function sets a specific bit in the bank_map of
an mca_banks structure, provided the structure, its bank_map, and
the bit index are valid.
At the end, we will call
mcabanks_free(xchg(&mca_allbanks, all));
This function is thread safe and does below:
1. Atomically exchanges the value of "mca_allbanks" with "all"
2. Returns the old value that was previously in "mca_allbanks"
So, when we will call mcabanks_free , that will free the memory.
The problem is that mcabanks_set(i, mca_allbanks) function is updating
mca_allbanks which will be freed via mcabanks_free later. This means
new mca_allbanks instance("all") will never get chance to update
it's bank_map.
Due to this when we will collect log from mcheck_mca_logout function ,
the condition "if ( !mcabanks_test(i, bankmask) )" will always fails
and MCA logs will not be collected for any bank.
The fix is to solve this problem.
Fixes: 560cf418c8 ("x86/mcheck: allow varying bank counts per CPU")
Signed-off-by: Soham Dandapat <soham.dandapat@amd.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Callers observing errors elsewhere may be confused by the ENOSYS that
the Flask operation would yield on a Flask-disabled hypervisor.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
Dom0 is never started in PoD mode, and hence it can at "best" do harm if
we try to set a PoD target for it.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
A new "no (more) symbol" path there was lacking a necessary unlock.
Fixes: d3b637fba3 ("symbols: arrange to know where functions end")
Coverity ID: 1665212
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Mykola Kvach <mykola_kvach@epam.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The existing Verify functionality of the Shim lock protocol is
deprecated and will be removed, the alternative it to use the LoadImage
interface to perform the verification.
When the loading is successful we won't be using the newly loaded image
(as of yet) so we must then immediately unload the image to clean up.
If the LoadImage protocol isn't available then fall back to the Shim
Lock (Verify) interface.
Log when the kernel is not verified and fail if this occurs
when secure boot mode is enabled.
Signed-off-by: Gerald Elder-Vass <gerald.elder-vass@cloud.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Introduce some basic infrastructure for doing domain ID allocation unit tests,
and add a few tests that ensure correctness of the domain ID allocator.
Use <xen-tools/bitops.h> and xen/lib/find-next-bit.c in test hardness code.
Adjust find-next-bit.c to be compiled with __XEN_TOOLS__.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Currently, there are two different domain ID allocation implementations:
1) Sequential IDs allocation in dom0less Arm code based on max_init_domid;
2) Sequential IDs allocation in XEN_DOMCTL_createdomain; does not use
max_init_domid (both Arm and x86).
The domain ID allocation covers dom0 or late hwdom, predefined domains,
post-boot domains, excluding Xen system domains (domid >=
DOMID_FIRST_RESERVED).
It makes sense to have a common helper code for such task across architectures
(Arm and x86) and between dom0less / toolstack domU allocation.
Note, fixing dependency on max_init_domid is out of scope of this patch.
Wrap the domain ID allocation as an arch-independent function domid_alloc() in
new common/domid.c based on the bitmap.
Allocation algorithm:
- If an explicit domain ID is provided, verify its availability and use it if
ID is not used;
- If DOMID_INVALID is provided, search the range [1..DOMID_FIRST_RESERVED-1],
starting from the last used ID.
Implementation guarantees that two consecutive calls will never return the
same ID. ID#0 is reserved for the first boot domain (currently, dom0) and
excluded from the allocation range.
Remove is_free_domid() helper as it is not needed now.
No functional change intended.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
The commit 3e322bef8b ("xen/arm: firmware: Add SCMI over SMC calls
handling layer") introduces simple driver which forwards SCMI over SMC
calls from hwdom/dom0 to EL3 firmware (TF-A) with a single SCMI OSPM agent
support. While it is working gracefully for hwdom/dom0 use case it doesn't
cover "thin Dom0 with guest domain, which serves as Driver domain"
use-case. In this case HW need to be enable in Driver domain and dom0 is
performing only control functions.
The EL3 SCMI firmware (TF-A) with a single SCMI OSPM agent support is
pretty generic case for the default vendors SDK and new platforms.
This patch enables passthrough of SCMI SMC single agent interface to the
one guest domain serving as Driver domain.
Configure Dom0 to enable SCMI passthrough:
- dom0: add scmi-smc-passthrough to the Xen Command Line
Enabled SCMI passthrough for guest using toolstack in the following way:
- domD: xl.cfg add "arm_sci" option as below
arm_sci = "type=scmi_smc"
- domD: xl.cfg enable access to the "arm,scmi-shmem"
iomem = [
"47ff0,1@22001",
]
- domD: add SCMI nodes to the Driver domain partial device tree as in the
below example:
passthrough {
scmi_shm_0: sram@22001000 {
compatible = "arm,scmi-shmem";
reg = <0x0 0x22001000 0x0 0x1000>;
};
firmware {
compatible = "simple-bus";
scmi: scmi {
compatible = "arm,scmi-smc";
shmem = <&scmi_shm_0>;
...
}
}
}
dom0less case configuration:
- add "xen,sci_type" property for required DomU ("xen,domain") node
xen,sci_type="scmi_smc"
- add scmi nodes to the Driver domain partial device tree the same way
as above and enable access to the "arm,scmi-shmem" according to
dom0less documentation. For example:
scmi_shm_0: sram@22001000 {
compatible = "arm,scmi-shmem";
reg = <0x00 0x22001000 0x00 0x1000>;
-> xen,reg = <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>;
-> xen,force-assign-without-iommu;
};
The SCMI SMC single agent interface can be enabled for one and only one
domain. In general, the configuration is similar to any other HW
passthrough, except explicitly enabling SCMI with "arm_sci" xl.cfg option.
Note that "arm,scmi-smc" and "arm,scmi-shmem" nodes will be removed from
dom0/hwdom DT when "scmi-smc-passthrough" cmdline parameter was provided.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech> # tools
The introduced SCI (System Control Interface) subsystem provides unified
interface to integrate in Xen SCI drivers which adds support for ARM
firmware (EL3, SCP) based software interfaces (like SCMI) that are used in
system management. The SCI subsystem allows to add drivers for different FW
interfaces or have different drivers for the same FW interface (for example,
SCMI with different transports).
This patch updates SCMI over SMC calls handling layer, introduced by
commit 3e322bef8b ("xen/arm: firmware: Add SCMI over SMC calls handling
layer"), to be SCI driver:
- convert to DT device;
- convert to SCI Xen interface.
There are no functional changes in general, the driver is just adopted
to the SCI interface.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
This patch adds the basic framework for ARM SCI mediator. SCI is System
Control Interface, which is designed to redirect requests from the Domains
to ARM specific Firmware (for example SCMI). This will allow the devices,
passed-through to the different Domains, to access to the System resources
(such as clocks/resets etc) by sending requests to the firmware.
ARM SCI subsystem allows to implement different SCI drivers to handle
specific ARM firmware interfaces (like ARM SCMI) and mediate requests
-between the Domains and the Firmware. Also it allows SCI drivers to perform
proper action during Domain creation/destruction which is vital for
handling use cases like Domain reboot.
This patch introduces new DEVICE_FIRMWARE device subclass for probing SCI
drivers basing on device tree, SCI drivers register itself with
DT_DEVICE_START/END macro. On init - the SCI drivers should register its
SCI ops with sci_register(). Only one SCI driver can be supported.
At run-time, the following SCI API calls are introduced:
- sci_domain_sanitise_config() called from arch_sanitise_domain_config()
- sci_domain_init() called from arch_domain_create()
- sci_relinquish_resources() called from domain_relinquish_resources()
- sci_domain_destroy() called from arch_domain_destroy()
- sci_handle_call() called from vsmccc_handle_call()
- sci_dt_handle_node()
- sci_dt_finalize() called from handle_node() (Dom0 DT)
Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
On rare occasions Fixes: isn't quite appropriate to use, yet another
commit still wants making a connection to in a formalized way. Such could
e.g. happen if a pretty obvious optimization was left out (which isn't a
bug, but still a shortcoming). Formalize Amends: as a tage to use in such
a situation.
Requested-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Michal Orzel <michal.orzel@amd.com>
Introduce a new '-p/--pcpus' flag to display physical CPU utilization metrics
using xc_interface. This provides hypervisor-level CPU usage insights alongside
existing domain statistics. This helps correlate VM resource usage with host CPU
load patterns.
Changes:
- Add pcpu.c/pcpu.h for PCPU stat collection logic
- Link against libxenctrl for xc_handle access
- Extend CLI with '-p' flag and output formatting
- Forward declare xenstat_handle to access xc_handle
- Include cleanup for PCPU resources in exit handler
Example usage:
xentop -p # Shows physical CPU stats
xentop -bp # Batch mode
xentop -d 1 -p # With different delays
Example output with '-p':
NAME STATE CPU(%) MEM(%) VCPUS ...
Domain-0 -----r 17.0 6.3 8
DomD -----r 767.0 38.1 8
Physical CPU Usage:
┌───────┬────────┐
│ Core │ Usage │
├───────┼────────┤
│ 0 │ 98.1% │
│ ... │ ... │
│ 7 │ 97.3% │
└───────┴────────┘
Signed-off-by: Jahan Murudi <jahan.murudi.zg@renesas.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
According to the Arm SMMUv3 spec (ARM IHI 0070), a system may have
SMMU(s) that is/are non-coherent to the PE (processing element). In such
cases, memory accesses from the PE should be either non-cached or be
augmented with manual cache maintenance. SMMU cache coherency is reported
by bit 4 (COHACC) of the SMMU_IDR0 register and is already present in the
Xen driver. However, the current implementation is not aware of cache
maintenance for memory that is shared between the PE and non-coherent
SMMUs. It contains dmam_alloc_coherent() function, that is added during
Linux driver porting. But it is actually a wrapper for _xzalloc(), that
returns normal writeback memory (which is OK for coherent SMMUs).
During Xen bring-up on a system with non-coherent SMMUs, the driver did
not work properly - the SMMU was not functional and halted initialization
at the very beginning due to a timeout while waiting for CMD_SYNC
completion:
(XEN) SMMUv3: /soc/iommu@fa000000: CMD_SYNC timeout
(XEN) SMMUv3: /soc/iommu@fa000000: CMD_SYNC timeout
To properly handle such scenarios, add the non_coherent flag to the
arm_smmu_queue struct. It is initialized using features reported by the
SMMU HW and will be used for triggering cache clean/invalidate operations.
This flag is not queue-specific (it is applicable to the whole SMMU), but
adding it to arm_smmu_queue allows us to not change function signatures
and simplify the patch (smmu->features, which contains the required flag,
are not available in code parts that require cache maintenance).
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Tested-by: Mykola Kvach <mykola_kvach@epam.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
Fix an issue in the 'fail:' cleanup path of the 'assign_shared_memory()'
function where the use of an unsigned long 'i' with the condition
'--i >= 0' caused an infinite loop. Update the loop to use 'i--',
ensuring correct loop termination.
This change adheres to MISRA C Rule 14.3: "Controlling expressions shall
not be invariant."
Fixes: 041957bad3 ("xen/arm: Add additional reference to owner domain when the owner is allocated")
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Michal Orzel <michal.orzel@amd.com>
The Renesas R-Car Gen4 platform requires the GICv3 driver,
including support for the Interrupt Translation Service (ITS).
Without explicitly selecting GICV3, it was possible to create a
configuration with RCAR4=y and GICV3=n, leading to a build failure
due to unmet dependencies.
GICv3 driver (GICV3) [Y/n/?] (NEW) n
WARNING: unmet direct dependencies detected for HAS_ITS
Depends on [n]: GICV3 [=n] && !NEW_VGIC [=n] && !ARM_32 [=n]
Selected by [y]:
- RCAR4 [=y] && <choice> && ARM_64 [=y]
...
arch/arm/gic-v3-its.c: In function 'gicv3_its_map_guest_device':
arch/arm/gic-v3-its.c:729:41: error: 'struct vgic_dist' has no member named 'its_devices'
729 | struct rb_node **new = &d->arch.vgic.its_devices.rb_node, *parent = NULL;
| ^
arch/arm/gic-v3-its.c:755:28: error: 'struct vgic_dist' has no member named 'its_devices_lock'
755 | spin_lock(&d->arch.vgic.its_devices_lock);
| ^
arch/arm/gic-v3-its.c:768:54: error: 'struct vgic_dist' has no member named 'its_devices'
768 | rb_erase(&temp->rbnode, &d->arch.vgic.its_devices);
| ^
In file included from ./include/xen/sched.h:6,
from ./include/xen/iocap.h:10,
from arch/arm/gic-v3-its.c:13:
...
Fix this by adding "select GICV3" to the RCAR4 Kconfig entry.
Fixes: 336fc7a19b ("xen/arm: platform: Add support for R-Car Gen4")
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Implement the MPU variant of `setup_frametable_mappings`. This function
will be called by `setup_mm` when an implementation for MPU systems is
added in a follow up commit.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Signed-off-by: Hari Limaye <hari.limaye@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
The errors can happen in the middle of a console line which causes the message
to appear at the end of the current line.
Prepend a newline to clearly separate the error line.
Signed-off-by: Victor Lira <victorm.lira@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
In the console expect script, "send_error" will send a message to standard
error. Current use of this script redirects only standard output into a
pipeline. This causes the error messages to sometimes appear hidden in the
middle of the test logs.
Redirect also standard error to clearly show when a test has timed out or hit
EOF.
Signed-off-by: Victor Lira <victorm.lira@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
... instead of having them split across multiple.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Drop unused or stale lines.
* While it's necessary to have .git and .hg in each others ignore files if
using multiple SCMs (as we did for a while), they should not be in their
own. The mercurial files were dropped in commit ba5bae659d ("Drop
remains of prior SCMs") (2023).
* The ignore for LibVNCServer* was added by commit a090ca495e ("VNC pasword
authentication support for the paravirt framebuffer server.") (2006) but
without justification or any obvious reason.
* The ignore for tools/misc/lowmemd was added in commit c812282081 ("Low
mem virq incremental adjustments") (2012), but xen-lowmemd (from the same
author) already existed and was ignored properly.
* tools/libs/guest/xc_* were added in commit af6c78d9dc ("tools: move
libxenctrl below tools/libs") for bisectibility, but should have been
dropped in the following change, commit e3dd624e48 ("tools/libxc: move
libxenguest to tools/libs/guest").
* tools/debugger/xenitp/ was dropped in commit e567964a54 ("tools: drop
ia64 support") (2012).
* tools/debugger/gdb/ was dropped in commit
baa1aae9cf ("tools/debugger/gdb: Remove gdb") (2010).
* tools/misc/cpuperf/ was dropped in commit ae95fdf65a ("[TOOLS] Remove the
'cpuperf' misc tool.") (2006).
* tools/misc/xc_shadow was dropped in commit 7133144e3a ("Remove xc_shadow
tool") (2007).
* tools/misc/xen_cpuperf was dropped in commit 60eba9b0d2 ("Delete some
unused tools") (2004).
* tools/misc/xen-tmem-list-parse was dropped in commit c588c002cc ("tools:
remove tmem code and commands") (2018).
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
One aspect of the old ffs() infrastructure was the use of TZCNT without a
CPUID check. Given no obvious justification, I dropped it during the cleanup.
It turns out there is a good reason, on all but the most recent AMD CPUs.
Reinstate the use of "blind" TZCNT when safe to do so. This happens to be
preferentially in loops where a repeated saving of 5-6 uops becomes far more
relevant than a one-off scenario. Leave an explanation of why.
It is not safe to perform this transformation for BSR and LZCNT, because they
count from opposite ends of the input operand. Furthermore, this incorrect
transform was not caught by the selftests.
Extend the selftests with test_for_each_set_bit_reverse() as that exercises
the "x known non-zero" optimsiation path in x86's helpers. Adjust the
existing test_for_each_set_bit() to intentionally use an asymmetric input bit
pattern, otherwise "counting from the wrong end" bugs continue to slip by.
No functional change.
Fixes: 989e5f08d3 ("x86/bitops: Improve arch_ffs() in the general case")
Fixes: 5ed26fc076 ("xen/bitops: Implement ffsl() in common logic")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
It is not obvious at first glance, but this is dead logic.
On Intel, xAPIC (which is what modern_apic() is really checking for) predates
64bit support, while the Family 0xf check on AMD is the K8 processor.
Simply drop the logic, rather than trying to adjust vendor/family logic.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This is a port of Linux commit 517234446c1a ("x86/apic: Get rid of
get_physical_broadcast()") to Xen. Thomas Gleixner notes:
There is no point for this function. The only case where this is used is
when there is no XAPIC available, which means the broadcast address is 0xF.
In Linux, users of get_physical_broadcast() have already been hidden behind
CONFIG_X86_32 suggesting we can drop all of this, but that's a task for some
other time.
In Xen as with Linux, setup_ioapic_ids_from_mpc() and io_apic_get_unique_id()
only apply to pre-xAPIC cases, so can use a broadcast ID of 0xf. The only
other user is __print_IO_APIC() for diagnostics, which can simply drop the
check.
No functional change.
Link: https://lore.kernel.org/r/20240212154639.057209154@linutronix.de
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Jan reports the following exception when using the cycle debugging:
Feature IBRSB, seen [IBRSB, STIBP, INTEL_PSFD, EIBRS, IPRED_CTRL, RRSBA_CTRL, RRSBA, BHI_CTRL], to_process [SSBD]
Traceback (most recent call last):
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 594, in <module>
sys.exit(main())
^^^^^^
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 588, in main
crunch_numbers(state)
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 366, in crunch_numbers
(state.names[feat], repl(seen), repl(to_process)))
^^^^^^^^^^^^^^^^
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 364, in repl
return "[" + ", ".join((state.names[x] for x in l)) + "]"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 364, in <genexpr>
return "[" + ", ".join((state.names[x] for x in l)) + "]"
~~~~~~~~~~~^^^
KeyError: 534
make[2]: *** [/local/xen.git/xen/include/xen/lib/x86/Makefile:9: cpuid-autogen.h] Error 1
This is caused by commit ce8c930851 ("x86/cpu-policy: MSR_ARCH_CAPS feature
names") being rather lazy and marking dependenices on unknown features.
Introduce a helper to pick the known features in a range, and use it for
ARCH_CAPS.
Additionally, remove trailing whitespace and an unnecessary line continuation
from the debug print.
Reported-by: Jan Beulich <jbeulich@suse.com>
Fixes: ce8c930851 ("x86/cpu-policy: MSR_ARCH_CAPS feature names")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
FRED and IDT differ by a Supervisor Token on the base of the shstk. This
means that the value they load into MSR_PL0_SSP differs by 8.
s3_resume() in particular has logic which is otherwise invariant of FRED mode,
and must not clobber a FRED MSR_PL0_SSP with an IDT one.
This also simplifies the AP path too.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
With the processing done linearly (rather than recursively), checking
whether any of the features was previously seen is wrong: That would
e.g. trigger for this simple set of dependencies
X: [A, B]
A: [C]
B: [C]
(observed in reality when making AMX-AVX512 dependent upon both
AMX-TILE and AVX512F, causing XSAVE to see AMX-AVX512 twice in its list
of dependents). But checking the whole accumulated set also isn't
necessary - just checking the feature we're processing dependents of is
sufficient. We may detect a cycle later that way, but we still will
detect it. What we need to avoid is adding a feature again when we've
already seen it.
As a result, seeding "seen[]" with "feat" isn't necessary anymore.
Fixes: fe4408d180 ("xen/x86: Generate deep dependencies of features")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Move xc_bitops.h to common tools location to be shared between
the toolstack and unit test code.
Adjust the guard in xen-tools/bitops.h
Correct the #include directives and comments referring to the old
xc_bitops.h in the toolstack code.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
EFI code path split options from EFI LoadOptions fields in 2
pieces, first EFI options, second Xen options.
"get_argv" function is called first to get the number of arguments
in the LoadOptions, second, after allocating enough space, to
fill some "argc"/"argv" variable. However the first parsing could
be different from second as second is able to detect "--" argument
separator. So it was possible that "argc" was bigger than the
initialized portion of "argv" array, leading to potential
uninitialized pointer dereference, in particular a string like
"-- a b c" would lead to crashes.
Using EFI shell is possible to pass any kind of string in
LoadOptions.
Fixes: bf6501a62e ("x86-64: EFI boot code")
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
The present copy_page_sse2() is useful in case the destination page isn't
going to get touched again soon, or if we want to limit churn on the
caches. Just rename it, to fit the corresponding {clear,scrub}_page_*()
naming scheme.
For cases where latency is the most important aspect, or when it is
expected that sufficiently large parts of a destination page will get
accessed again soon after the copying, introduce a "hot" alternative.
Again use alternatives patching to select between a "legacy" and an ERMS
variant.
Don't switch any callers just yet - this will be the subject of subsequent
changes.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
vpci_remove_register() only supports removing a register in a time,
but the follow-on changes need to remove all registers within a range.
So, refactor it to support removing all registers in a given region.
And it is no issue to remove a non exist register, so remove the
__must_check prefix.
Note: two test cases don't math the new logic of
vpci_remove_registers(), then modify them.
Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
As cleanup hook of all supported capabilities will be implemented in
follow-on changes, so to pre-call hook in vpci_deassign_device(), and
the capability specific clean open-code in there will be removed by
follow-on corresponding capability changes.
Since vpci_deassign_device() and vpci_init_capabilities() require
different cleanup actions, add a boolean parameter to cleanup hook
to distinguish them.
Requested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
... and thus typically also a size. Using global vs local is undesirable
in certain situations, e.g. when a "real" symbol is local and at the
same address as a section start/end one (which are all global).
Note that for xen.efi the checking for "Function" is only forward-
looking at this point: The function-ness of symbols (much like their
size) is lost when linking PE/COFF binaries from ELF objects with GNU ld
up to at least 2.44.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
For one there's no need for each architecture to have the same logic.
Move to the root Makefile, also to calculate just once.
And then re-arrange to permit FAST_SYMBOL_LOOKUP to be independent of
LIVEPATCH, which may be useful in (at least) debugging.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
When determining the symbol for a given address (e.g. for the %pS
logging format specifier), so far the size of a symbol (function) was
assumed to be everything until the next symbol. There may be gaps
though, which would better be recognizable in output (often suggesting
something odd is going on).
Insert "fake" end symbols in the address table, accompanied by zero-
length type/name entries (to keep lookup reasonably close to how it
was).
Note however that this, with GNU binutils prior to 2.45, won't work for
xen.efi: The linker loses function sizes (they're not part of a normal
symbol table entry), and hence nm has no way of reporting them.
The address table growth is quite significant on x86 release builds (due
to functions being aligned to 16-byte boundaries), though: Its size
almost doubles.
Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
In preparation for inserting address entries into symbols_addresses[] /
symbols_offsets[] without enlarging symbols_sorted_offsets[], split
symbols_num_syms into symbols_num_addrs (counting entries in the former
plus symbols_names[] as well as, less directly, symbols_markers[]) and
symbols_num_names (counting entries in the latter).
While doing the adjustment move declarations to a new private symbols.h,
to be used by both symbols.c and symbols-dummy.c. Replace u8/u16 while
doing so.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
There's no need for PDX compression given the memory map provided by Xen
to guests is contiguous, turn off the feature by default in the PV shim
defconfig.
Reported-by: Jan Beulich <jbeulich@suse.com>
Fixes: c5c45bcbd6 ("pdx: introduce a new compression algorithm based on region offsets")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Under FRED, SETSSBSY is disallowed, and we want to be setting up FRED prior to
setting up shadow stacks. Luckily, RSTORSSP will also work in this case.
This involves a new type of shadow stack token, the Restore Token, which is
distinguished from the Supervisor Token by pointing to the adjacent slot on
the shadow stack rather than pointing at itself.
In the short term, this logic still needs to load MSR_PL0_SSP.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Leonid Komarianskyi