The arch_init_idle_domain() initializes struct arch_csw idle_csw as:
static const struct arch_csw idle_csw = {
.from = paravirt_ctxt_switch_from,
.to = paravirt_ctxt_switch_to,
.tail = idle_loop,
};
but only place where d->arch.ctxt_switch->{to,from}() are used is
__context_switch() where they are both guarded by !is_idle_domain(pd)
which makes the callbacks in idle_csw unreachable.
Introduce a new poison value to be used in unreachable function hooks, and
set the from/to fields of idle_csw to it. Use a different value from the
currently defined ones for easy differentiation.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
There is a corner case in the error path of evtchn_bind_virq() (handling
EVTCHNOP_bind_virq hypercall) which allows unprivileged domains to
interfere with privileged ones: If an unprivileged domain allocates all
available ports to reach "no more ports available" and then issues an
EVTCHNOP_bind_virq hypercall to bind any allowed VIRQ (e.g. VIRQ_DEBUG),
domain_deinit_states() will be called despite not having called
domain_init_states().
To fix the issue move domain_deinit_states(d) under the same condition as
used for the domain_init_states() call.
This is CVE-2026-42492 / XSA-496.
Fixes: f94360a7fe ("xen: add bitmap to indicate per-domain state changes")
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
The VMTRACE feature is depends on Platform/Arch HW and code support and now
can be used only on x86 HVM with Intel VT-x (INTEL_VMX) enabled.
This makes VMTRACE support optional by introducing HVM Kconfig option:
- CONFIG_VMTRACE to enable/disable the feature.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
The d->arch.physaddr_bitsize field is used only by PV32 code, so move
d->arch.physaddr_bitsize field under PV32 ifdef into struct pv_domain.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The d->arch.physaddr_bitsize field is used only by PV32 code so as the
domain_clamp_alloc_bitsize() function.
Hence move domain_clamp_alloc_bitsize() function into PV32 code and convert
it to macro.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Now Xen, for HVM/PVH, supports only two paging modes: HAP and SHADOW, so
!paging_mode_hap() is actually means paging_mode_shadow().
For an abstract, future case of there being a 3rd paging mode it is also
better to explicitly mention checked paging mode (SHADOW) instead of using
negative check of another paging mode (HAP).
Hence, s/!paging_mode_hap()/paging_mode_shadow() which also allows DCE drop
unused code when SHADOW_PAGING=n.
The !paging_mode_hap() in hap.c not changed as HAP is checking for itself
to be enabled.
Inspired by [1].
[1] https://patchwork.kernel.org/project/xen-devel/patch/20251111200958.3576341-3-grygorii_strashko@epam.com/
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The Cache Disable mode data is used only by VMX code, so move it from
common HVM structures into VMX specific structures:
- move "uc_lock", "is_in_uc_mode" fields from struct hvm_domain to struct
vmx_domain;
- move "cache_mode" field from struct hvm_vcpu to struct vmx_vcpu.
Hence, the "in_uc_mode" field is used directly in mm/shadow/multi.c
_sh_propagate(), introduce the hvm_is_in_uc_mode() macro to avoid direct
access to this field and account for INTEL_VMX configuration.
While here:
- rename "is_in_uc_mode" to "in_uc_mode"
- s/NORMAL_CACHE_MODE/CACHE_MODE_NORMAL
- s/NO_FILL_CACHE_MODE/CACHE_MODE_NO_FILL
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The shadow_handle_cd() can be used only with SHADOW_PAGING=y, so guard
shadow_handle_cd() call with paging_mode_shadow() which accounts for
SHADOW_PAGING state.
bloat-o-meter
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-290 (-290)
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Functions:
hvm_shadow_handle_cd()
hvm_set_uc_mode()
domain_exit_uc_mode()
are used only by Intel VMX code, so move them to VMX code.
While here:
- drop hvm_ prefixes
- minor format change and constification in domain_exit_uc_mode()
- s/(0/1)/(false/true) for bool types
- use "struct domain *" as parameter in set_uc_mode()
- use "struct domain *d" as local var in shadow_handle_cd()
No functional changes.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Since commit b992273472 ("x86: Fix AMD_SVM and INTEL_VMX dependency") the
HVM Intel VT-x support can be disabled, but it still keeps VMX
code partially built-in. Particularly in HVM code there are two places:
1) hvm/dom0_build.c
dom0_construct_pvh()->pvh_populate_p2m()
...
if ( cpu_has_vmx && paging_mode_hap(d) && !vmx_unrestricted_guest(v) )
{
...
[unreachable for !cpu_has_vmx case]
rc = pvh_setup_vmx_realmode_helpers(d);
pvh_setup_vmx_realmode_helpers() allocates memory and configures
HVM_PARAM_VM86_TSS_SIZED
HVM_PARAM_IDENT_PT
2) hvm/hvm.c
hvm_set_param()
...
case HVM_PARAM_IDENT_PT:
if ( !paging_mode_hap(d) || !cpu_has_vmx )
{
d->arch.hvm.params[index] = value;
break;
}
[unreachable for !cpu_has_vmx case]
...
Hence HVM_PARAM_IDENT_PT/HVM_PARAM_VM86_TSS_SIZED are used only by VMX code
above code become unreachable in !cpu_has_vmx case and can be optimazed
when !CONFIG_INTEL_VMX.
Replace "cpu_has_vmx" with using_vmx() to account !CONFIG_INTEL_VMX and allow
compiler DCE to optimize code.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
According to the commit b66e28226d ("x86/mem_sharing: gate enabling on
cpu_has_vmx") the Xen memory sharing support is only possible on platforms
with "Intel VT-x" (INTEL_VMX=y) enabled.
The same commit is also added runtime check for "cpu_has_vmx" in
mem_sharing_control() which blocks access to XENMEM_sharing_ops if
!cpu_has_vmx.
Hence add dependency from INTEL_VMX for MEM_SHARING Kconfig option.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Use define X86_MODE_64BIT instead of constant in hvm_hypercall() for "mode"
conditional check to improve code readability.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.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>
Call stack for dom0less hwdom case (1:1) memory:
create_domUs
|-construct_domU
|-construct_hwdom()
|-allocate_memory_11()
And allocate_memory_11() uses "dom0_mem" as:
min_low_order =
get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
In case of dom0less boot the "dom0_mem" is not used and defaulted to 0,
which causes min_low_order to get high value > order and so no allocations
happens from low memory.
Fix it, by using kinfo->unassigned_mem instead of "dom0_mem" which has
correct memory size in both cases: regular dom0 boot and dom0less boot.
Fixes: 52cb53f181 ("xen/arm: dom0less hwdom construction")
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Since commit 341f271cf8 ("xen/evtchn: fully restrict concept of pIRQ for
arches with pIRQ support only"), the corresponding PPC arch pIRQ callbacks
become unreachable, so drop them.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Since commit 341f271cf8 ("xen/evtchn: fully restrict concept of pIRQ for
arches with pIRQ support only"), the corresponding Arm arch pIRQ callbacks
become unreachable, so drop them.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Julien Grall <jgrall@amazon.com>
On platforms without PIRQ support evtchn_move_pirqs()/send_guest_pirq()
functions are unreachable (Misra rule 2.1).
Move these function under CONFIG_HAS_PIRQ ifdefs to fix Misra rule 2.1
violation and resolve call of evtchn_move_pirqs() from common /sched/core.c
vcpu_move_irqs() code by moving evtchn_move_pirqs() into x86
arch_move_irqs() callback (which is converted to define).
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Juergen Gross <jgross@suse.com> # xen/sched
Grygorii Strashko