PV console doesn't require Xen to be running as a shim and only
requires CONFIG_XEN_GUEST and running as a Xen guest. Update the
documentation accordingly.
Fixes: 4f6609d6a6 ("x86/guest: use PV console for Xen/Dom0 I/O")
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
get-core-temp allows querying the per-core CPU temperature and
per-package one on processors that supports Digital Temperature Sensors
(most Intel processors; as usual Dom0 drivers cannot work due to
misalignment between Dom0 vCPU and pCPUs).
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Remove these checks now that we don't use these 2 ops anymore.
Amends: 4bedbe47ee ("x86/emul: Remove fallback path from SWAPGS")
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
errno is not unified accross platforms, which makes error codes actually
platform specific. C standard defines EXIT_SUCCESS and EXIT_FAILURE
(respectively 0 and 1) as standard errors codes, even though it only reports
whether it failed or not.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
xc_report_op doesn't update errno when called with 0 operations
(even though it returns -1).
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Most (if not all) Intel CPUs starting from Sandy Bridge have up to 8
event selectors per core, which could be halved per hyperthread.
However, current PV emulation logic doesn't support up to 8 event selector,
leading to errors when trying to access them, hence, preventing Linux from
driving the vPMU correctly.
Make sure up to MSR_P6_EVNTSEL(7) is usable, which is the same upper bound as
used in VMX code.
The check if the event selector actually exist for the hardware is done in
core2_vpmu_do_{rdmsr,wrmsr}, hence we're not allowing to access non-existent
MSRs.
Fixes: 27c5541986 ("x86/VPMU: add support for PMU register handling on PV guests")
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Many machines fails to boot if this option is disabled.
It's off by default as it was deemed too risky for being enabled
by default late in the Xen 4.13 cycle, but found out to be safe.
As there are no known drawback by having this option on, enable
it by default.
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Temperature sensors MSR were previously assumed to be available when "DTS"
CPUID bit is set. This is not really the case :
* MSR_IA32_THERM_STATUS is gated behind ACPI CPUID bit, only DTS-related bits
of this MSR are gated behind the DTS CPUID
* MSR_PACKAGE_THERM_STATUS is gated behind "PTM" CPUID
Also adjust the MSR_TEMPERATURE_TARGET which is not architectural, but stable
in practice, and required to be exposed for reliably querying CPU temperature.
Fixes: 615c9f3f82 ("x86/platform: Expose DTS sensors MSR")
Reported-by: Tu Dinh <ngoc-tu.dinh@vates.tech>
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Intel provide CPU sensors through "DTS" MSRs. As these MSR are core-specific
(or package-specific), we can't reliably fetch them from Dom0 directly.
Expose these MSR (if supported) through XENPF_resource_op so that it is
accessible through hypercall.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
xenpm doesn't provide any interesting usable features outside of x86,
skip building it if we are not x86.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
This function can only be reached from EPT-related code which is inherently
HAP. Thus it is not useful to check for shadow_paging (or lack of HAP) there.
Moreover, it is an error to call this function in the non-EPT cases.
Not a functional change.
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
There are many places where we use interesting ways of reading 32-bits
components of the RTE. Introduce and use low and high components directly
to the rte structure instead.
Also take the opportunity to simplify "x & 1 ? 1 : 0".
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Acked-by: Jan Beulich <jbeulich@suse.com>
This macro was introduced to abstract between IO-APIC and IO-SAPIC (ia64),
now that ia64 isn't supported anymore, this macro now only refers to IO-APIC.
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
This macro was there when ia64 was a thing, nowaday, this macro isn't meaningful
anymore and is actually a slightly disguised nr_ioapic_entries array access.
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Callers can pass in a vpmask which exceeds d->max_vcpus. Prevent out-of-bound
reads of d->vcpu[].
This is XSA-475 / CVE-2025-58148.
Fixes: 728acba1ba ("viridian: use hypercall_vpmask in hvcall_ipi()")
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Callers can pass vp/mask values which exceed the size of vpmask->mask. Ensure
we only set bits which are within bounds.
This is XSA-475 / CVE-2025-58147.
Fixes: b4124682db ("viridian: add ExProcessorMasks variants of the flush hypercalls")
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
do_sched_op(SCHEDOP_yield) just calls vcpu_yield(). Remove the indirection
through the hypercall handler and use the function directly.
Export vcpu_block_enable_events() to perform the same for SCHEDOP_block.
Not a functional change.
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Xen currently uses an ASID scheme where:
- ASIDs are cycled where a "TLB flush" is performed
- When ASIDs wrap around, perform a full TLB flush
- In exceptional cases, stop using ASIDs
However, the TLB control mode used only flushes the current active ASID of
the logical processor. Which mean that will supply "stale" ASIDs (not flushed),
because it hasn't been actually flushed (TLB_CTRL_FLUSH_ASID only performs a
TLB flush of the ASID set in VMCB).
This affects CPUs where flush-by-asid is available (Fam15h (2011) and later).
To fix this, always flush all ASIDs even when flush-by-asid is available.
Fixes: 64b1da5a2f ("x86/svm: Use flush-by-asid when available")
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
binutils 2.25 has support for assembling vmresume/vmlaunch
instructions, so we don't need to open-code the byte sequences
for these opcodes anymore.
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
As CX16 support is now mandatory for IOMMU usage, the checks for CX16 in
the DMA remapping code are stale. Remove them together with the associated
code introduced in case CX16 was not available.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
As CX16 support is now mandatory for IOMMU usage, the checks for CX16 in
the interrupt remapping code are stale. Remove them together with the
associated code introduced in case CX16 was not available.
Note that AMD-Vi support for atomically updating a 128bit IRTE entry is
still not implemented, it will be done by further changes.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
All hardware with VT-d/AMD-Vi has CMPXCHG16B support. Check this at
initialisation time, and otherwise refuse to use the IOMMU.
If the local APICs support x2APIC mode the IOMMU support for interrupt
remapping will be checked earlier using a specific helper. If no support
for CX16 is detected by that earlier hook disable the IOMMU at that point
and prevent further poking for CX16 later in the boot process, which would
also fail.
There's a possible corner case when running virtualized, and the underlying
hypervisor exposing an IOMMU but no CMPXCHG16B support. In which case
ignoring the IOMMU is fine, albeit the most natural would be for the
underlying hypervisor to also expose CMPXCHG16B support if an IOMMU is
available to the VM.
Note this change only introduces the checks, but doesn't remove the now
stale checks for CX16 support sprinkled in the IOMMU code. Further changes
will take care of that.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In many places of x86 HVM code, constants integer are used to indicate in what mode is
running the CPU (real, vm86, 16-bits, 32-bits, 64-bits). However, these constants are
are written directly as integer which hides the actual meaning of these modes.
This patch introduces X86_MODE_* macros and replace those occurences with it.
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
If for some reason xmalloc() fails after having mapped the reserved
regions, an error is reported, but the regions remain mapped in the P2M.
Similarly if an error occurs during set_identity_p2m_entry() (except on
the first call), the partial mappings of the region would be retained
without being tracked anywhere, and hence without there being a way to
remove them again from the domain's P2M.
Move the setting up of the list entry ahead of trying to map the region.
In cases other than the first mapping failing, keep record of the full
region, such that a subsequent unmapping request can be properly torn
down.
To compensate for the potentially excess unmapping requests, don't log a
warning from p2m_remove_identity_entry() when there really was nothing
mapped at a given GFN.
This is XSA-460 / CVE-2024-31145.
Fixes: 2201b67b91 ("VT-d: improve RMRR region handling")
Fixes: c0e19d7c6c ("IOMMU: generalize VT-d's tracking of mapped RMRR regions")
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Teddy Astie