Juergen Gross [Thu, 6 Mar 2025 12:52:38 +0000 (13:52 +0100)]
xen: add new domctl get_domain_state
Add a new domctl sub-function to get data of a domain having changed
state (this is needed by Xenstore).
The returned state just contains the domid, the domain unique id,
and some flags (existing, shutdown, dying).
In order to enable Xenstore stubdom being built for multiple Xen
versions, make this domctl stable. For stable domctls the
interface_version is always 0.
Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Juergen Gross [Thu, 6 Mar 2025 12:52:14 +0000 (13:52 +0100)]
xen: add bitmap to indicate per-domain state changes
Add a bitmap with one bit per possible domid indicating the respective
domain has changed its state (created, deleted, dying, crashed,
shutdown).
Registering the VIRQ_DOM_EXC event will result in setting the bits for
all existing domains and resetting all other bits.
As the usage of this bitmap is tightly coupled with the VIRQ_DOM_EXC
event, it is meant to be used only by a single consumer in the system,
just like the VIRQ_DOM_EXC event.
Resetting a bit will be done in a future patch.
This information is needed for Xenstore to keep track of all domains.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Juergen Gross [Thu, 6 Mar 2025 12:51:55 +0000 (13:51 +0100)]
xen/events: allow setting of global virq handler only for unbound virqs
XEN_DOMCTL_set_virq_handler will happily steal a global virq from the
current domain having bound it and assign it to another domain. The
former domain will just never receive any further events for that
virq without knowing what happened.
Change the behavior to allow XEN_DOMCTL_set_virq_handler only if the
virq in question is not bound by the current domain allowed to use it.
Currently the only user of XEN_DOMCTL_set_virq_handler in the Xen code
base is init-xenstore-domain, so changing the behavior like above will
not cause any problems.
Juergen Gross [Thu, 6 Mar 2025 12:51:35 +0000 (13:51 +0100)]
xen/events: don't allow binding a global virq from any domain
Today Xen will happily allow binding a global virq by a domain which
isn't configured to receive it. This won't result in any bad actions,
but the bind will appear to have succeeded with no event ever being
received by that event channel.
Instead of allowing the bind, error out if the domain isn't set to
handle that virq. Note that this check is inside the write_lock() on
purpose, as a future patch will put a related check into
set_global_virq_handler() with the addition of using the same lock.
Frediano Ziglio [Thu, 6 Mar 2025 12:51:01 +0000 (13:51 +0100)]
EFI: Avoid crash calling PrintErrMesg() from efi_multiboot2()
Although code is compiled with -fpic option data is not position
independent. This causes data pointer to become invalid if
code is not relocated properly which is what happens for
efi_multiboot2 which is called by multiboot entry code.
Code tested adding
PrintErrMesg(L"Test message", EFI_BUFFER_TOO_SMALL);
in efi_multiboot2 before calling efi_arch_edd (this function
can potentially call PrintErrMesg).
After the patch:
Booting `XenServer (Serial)'Booting `XenServer (Serial)'
Test message: Buffer too small
BdsDxe: loading Boot0000 "UiApp" from Fv(7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1)/FvFile(462CAA21-7614-4503-836E-8AB6F4662331)
BdsDxe: starting Boot0000 "UiApp" from Fv(7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1)/FvFile(462CAA21-7614-4503-836E-8AB6F4662331)
Similar to commit (d736b6eb451b, "xen/arm: mpu: Define Xen start address for
MPU systems"), one needs to add a build assertion to ensure that the page size
is 4KB on arm32 based systems as well.
The existing build assertion is moved under "xen/arch/arm/mpu" as it applies
for both arm64 and arm32 based systems.
xen/arm: mpu: Move some of the definitions to common file
For AArch32, refer to ARM DDI 0568A.c ID110520.
MPU_REGION_SHIFT is same between AArch32 and AArch64 (HPRBAR).
Also, NUM_MPU_REGIONS_SHIFT is same between AArch32 and AArch64
(HMPUIR).
Andrew Cooper [Fri, 13 Dec 2024 14:34:00 +0000 (14:34 +0000)]
x86/ucode: Perform extra SHA2 checks on AMD Fam17h/19h microcode
Collisions have been found in the microcode signing algorithm used by AMD
Fam17h/19h CPUs, and now anyone can sign their own.
For more details, see:
https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html
As a stopgap mitigation, check the digest of patches against a table of blobs
with known provenance. These are all Fam17h and Fam19h blobs included in
linux-firwmare at the time of writing, specifically:
Andrew Cooper [Fri, 13 Dec 2024 14:34:00 +0000 (14:34 +0000)]
xen/lib: Introduce SHA2-256
A future change will need to calculate SHA2-256 digests. Introduce an
implementation in lib/, derived from Trenchboot which itself is derived from
Linux.
In order to be useful to other architectures, it is careful with endianness
and misaligned accesses as well as being more MISRA friendly, but is only
wired up for x86 in the short term.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Juergen Gross [Wed, 5 Mar 2025 15:37:37 +0000 (16:37 +0100)]
tools/xl: fix channel configuration setting
Channels work differently than other device types: their devid should
be -1 initially in order to distinguish them from the primary console
which has the devid of 0.
So when parsing the channel configuration, use
ARRAY_EXTEND_INIT_NODEVID() in order to avoid overwriting the devid
set by libxl_device_channel_init().
Fixes: 3a6679634766 ("libxl: set channel devid when not provided by application") Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
x86/xstate: Create map/unmap primitives for xsave areas
Add infrastructure to simplify ASI handling. With ASI in the picture
we'll have several different means of accessing the XSAVE area of a
given vCPU, depending on whether a domain is covered by ASI or not and
whether the vCPU is question is scheduled on the current pCPU or not.
Having these complexities exposed at the call sites becomes unwieldy
very fast. These wrappers are intended to be used in a similar way to
map_domain_page() and unmap_domain_page(); The map operation will
dispatch the appropriate pointer for each case in a future patch, while
unmap will remain a no-op where no unmap is required (e.g: when there's
no ASI) and remove the transient maping if one was required.
Follow-up patches replace all uses of raw v->arch.xsave_area by this
mechanism in preparation to add the beforementioned dispatch logic to be
added at a later time.
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Penny Zheng [Wed, 5 Mar 2025 14:45:10 +0000 (15:45 +0100)]
xen/cpufreq: abstract Energy Performance Preference value
Intel's hwp Energy Performance Preference value is compatible with
CPPC's Energy Performance Preference value, so this commit abstracts
the value and re-place it in common header file cpufreq.h, to be
used not only for hwp in the future.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Extensions 'f' and 'd' aren't really needed for Xen, and allowing floating
point registers to be used can lead to crashes.
Extensions 'i', 'm', 'a', 'zicsr', and 'zifencei' are necessary for the
operation of Xen, which is why they are used explicitly (unconditionally)
in -march.
Drop "Base ISA" choice from riscv/Kconfig as it is always empty.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
xen/README: add compiler and binutils versions for RISCV-64
Considering that the Zbb extension is supported since GCC version 12 [1]
and that older GCC versions do not support Z extensions in -march (I haven't
faced this issue for GCC >=11.2), leading to compilation failures,
the baseline version for GCC is set to 12.2 and for GNU binutils to 2.39.
The GCC version is set to 12.2 instead of 12.1 because Xen's GitLab CI uses
Debian 12, which includes GCC 12.2 and GNU binutils 2.39.
Denis Mukhin [Wed, 5 Mar 2025 14:42:49 +0000 (15:42 +0100)]
xen/console: introduce console_{get,put}_domain()
console_input_domain() takes an RCU lock to protect domain structure.
That implies call to rcu_unlock_domain() after use.
Introduce a pair of console_get_domain() / console_put_domain() to highlight
the correct use of the call within the code interacting with Xen console
driver.
The new calls used in __serial_rx(), which also fixed console forwarding to
late hardware domains which run with domain IDs different from 0.
While moving the guest_printk() invocation also drop the redundant _G infix.
Jan Beulich [Wed, 5 Mar 2025 14:42:12 +0000 (15:42 +0100)]
x86/HVM: drop redundant access splitting
With all paths into hvmemul_linear_mmio_access() coming through
linear_{read,write}(), there's no need anymore to split accesses at
page boundaries there. Leave an assertion, though.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Jan Beulich [Wed, 5 Mar 2025 14:41:14 +0000 (15:41 +0100)]
x86/HVM: slightly improve CMPXCHG16B emulation
Using hvmemul_linear_mmio_write() directly (as fallback when mapping the
memory operand isn't possible) won't work properly when the access
crosses a RAM/MMIO boundary. Use linear_write() instead, which splits at
such boundaries as necessary.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Roger Pau Monne [Wed, 12 Feb 2025 10:37:50 +0000 (11:37 +0100)]
x86/dom0: be less restrictive with the Interrupt Address Range
Xen currently prevents dom0 from creating CPU or IOMMU page-table mappings
into the interrupt address range [0xfee00000, 0xfeefffff]. This range has
two different purposes. For accesses from the CPU is contains the default
position of local APIC page at 0xfee00000. For accesses from devices
it's the MSI address range, so the address field in the MSI entries
(usually) point to an address on that range to trigger an interrupt.
There are reports of Lenovo Thinkpad devices placing what seems to be the
UCSI shared mailbox at address 0xfeec2000 in the interrupt address range.
Attempting to use that device with a Linux PV dom0 leads to an error when
Linux kernel maps 0xfeec2000:
Remove the restrictions to create mappings in the interrupt address range
for dom0. Note that the restriction to map the local APIC page is enforced
separately, and that continues to be present. Additionally make sure the
emulated local APIC page is also not mapped, in case dom0 is using it.
Note that even if the interrupt address range entries are populated in the
IOMMU page-tables no device access will reach those pages. Device accesses
to the Interrupt Address Range will always be converted into Interrupt
Messages and are not subject to DMA remapping.
There's also the following restriction noted in Intel VT-d:
> Software must not program paging-structure entries to remap any address to
> the interrupt address range. Untranslated requests and translation requests
> that result in an address in the interrupt range will be blocked with
> condition code LGN.4 or SGN.8. Translated requests with an address in the
> interrupt address range are treated as Unsupported Request (UR).
Similarly for AMD-Vi:
> Accesses to the interrupt address range (Table 3) are defined to go through
> the interrupt remapping portion of the IOMMU and not through address
> translation processing. Therefore, when a transaction is being processed as
> an interrupt remapping operation, the transaction attribute of
> pretranslated or untranslated is ignored.
>
> Software Note: The IOMMU should
> not be configured such that an address translation results in a special
> address such as the interrupt address range.
However those restrictions don't apply to the identity mappings possibly
created for dom0, since the interrupt address range is never subject to DMA
remapping, and hence there's no output address after translation that
belongs to the interrupt address range.
Roger Pau Monne [Fri, 14 Feb 2025 09:39:29 +0000 (10:39 +0100)]
x86/iommu: account for IOMEM caps when populating dom0 IOMMU page-tables
The current code in arch_iommu_hwdom_init() kind of open-codes the same
MMIO permission ranges that are added to the hardware domain ->iomem_caps.
Avoid this duplication and use ->iomem_caps in arch_iommu_hwdom_init() to
filter which memory regions should be added to the dom0 IOMMU page-tables.
Note the IO-APIC and MCFG page(s) must be set as not accessible for a PVH
dom0, otherwise the internal Xen emulation for those ranges won't work.
This requires adjustments in dom0_setup_permissions().
The call to pvh_setup_mmcfg() in dom0_construct_pvh() must now strictly be
done ahead of setting up dom0 permissions, so take the opportunity to also
put it inside the existing is_hardware_domain() region.
Also the special casing of E820_UNUSABLE regions no longer needs to be done
in arch_iommu_hwdom_init(), as those regions are already blocked in
->iomem_caps and thus would be removed from the rangeset as part of
->iomem_caps processing in arch_iommu_hwdom_init(). The E820_UNUSABLE
regions below 1Mb are not removed from ->iomem_caps, that's a slight
difference for the IOMMU created page-tables, but the aim is to allow
access to the same memory either from the CPU or the IOMMU page-tables.
Since ->iomem_caps already takes into account the domain max paddr, there's
no need to remove any regions past the last address addressable by the
domain, as applying ->iomem_caps would have already taken care of that.
Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monne [Tue, 18 Feb 2025 16:57:49 +0000 (17:57 +0100)]
x86/dom0: correctly set the maximum ->iomem_caps bound for PVH
The logic in dom0_setup_permissions() sets the maximum bound in
->iomem_caps unconditionally using paddr_bits, which is not correct for HVM
based domains. Instead use domain_max_paddr_bits() to get the correct
maximum paddr bits for each possible domain type.
Switch to using PFN_DOWN() instead of PAGE_SHIFT, as that's shorter.
Fixes: 53de839fb409 ('x86: constrain MFN range Dom0 may access') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monne [Thu, 13 Feb 2025 09:58:45 +0000 (10:58 +0100)]
x86/dom0: attempt to fixup p2m page-faults for PVH dom0
When building a PVH dom0 Xen attempts to map all (relevant) MMIO regions
into the p2m for dom0 access. However the information Xen has about the
host memory map is limited. Xen doesn't have access to any resources
described in ACPI dynamic tables, and hence the p2m mappings provided might
not be complete.
PV doesn't suffer from this issue because a PV dom0 is capable of mapping
into it's page-tables any address not explicitly banned in d->iomem_caps.
Introduce a new command line options that allows Xen to attempt to fixup
the p2m page-faults, by creating p2m identity maps in response to p2m
page-faults.
This is aimed as a workaround to small ACPI regions Xen doesn't know about.
Note that missing large MMIO regions mapped in this way will lead to
slowness due to the VM exit processing, plus the mappings will always use
small pages.
The ultimate aim is to attempt to bring better parity with a classic PV
dom0.
Note such fixup rely on the CPU doing the access to the unpopulated
address. If the access is attempted from a device instead there's no
possible way to fixup, as IOMMU page-fault are asynchronous.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Only slightly tested on my local PVH dom0 deployment.
---
Changes since v1:
- Make the fixup function static.
- Print message in case mapping already exists.
Roger Pau Monne [Thu, 13 Feb 2025 08:08:01 +0000 (09:08 +0100)]
x86/emul: dump unhandled memory accesses for PVH dom0
A PV dom0 can map any host memory as long as it's allowed by the IO
capability range in d->iomem_caps. On the other hand, a PVH dom0 has no
way to populate MMIO region onto it's p2m, so it's limited to what Xen
initially populates on the p2m based on the host memory map and the enabled
device BARs.
Introduce a new debug build only printk that reports attempts by dom0 to
access addresses not populated on the p2m, and not handled by any emulator.
This is for information purposes only, but might allow getting an idea of
what MMIO ranges might be missing on the p2m.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Wed, 1 Jan 2025 15:43:20 +0000 (15:43 +0000)]
x86/IDT: Collect IDT related content idt.h
Logic concerning the IDT is somewhat different to the other system tables, and
in particular ought not to be in asm/processor.h. Collect it together a new
header.
While doing so, make a few minor adjustments:
* Make set_ist() use volatile rather than ACCESS_ONCE(), as
_write_gate_lower() already does, removing the need for xen/lib.h.
* Move the BUILD_BUG_ON() from subarch_percpu_traps_init() into mm.c's
build_assertions(), rather than including idt.h into x86_64/traps.c.
* Drop UL from IST constants.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Mon, 30 Dec 2024 06:41:46 +0000 (06:41 +0000)]
xen: Don't cast away const-ness in vcpu_show_registers()
The final hunk is `(struct vcpu *)v` in disguise, expressed using a runtime
pointer chase through memory and a technicality of the C type system to work
around the fact that get_hvm_registers() strictly requires a mutable pointer.
For anyone interested, this is one reason why C cannot optimise any reads
across sequence points, even for a function purporting to take a const object.
Anyway, have the function correctly state that it needs a mutable vcpu. All
callers have a mutable vCPU to hand, and it removes the runtime pointer chase
in x86.
Make one style adjustment in ARM while adjusting the parameter type.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Nicola Vetrini [Tue, 4 Mar 2025 17:49:36 +0000 (18:49 +0100)]
automation/eclair: Reduce verbosity of ECLAIR logs.
While activating verbose logging simplifies debugging, this causes
GitLab logs to be truncated, preventing the links to the ECLAIR
analysis database to be shown.
Andrew Cooper [Mon, 3 Mar 2025 14:06:55 +0000 (14:06 +0000)]
CHANGELOG.md: Set release date for 4.20
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
common: remove -fno-stack-protector from EMBEDDED_EXTRA_CFLAGS
This patch is preparation for making stack protector
configurable. First step is to remove -fno-stack-protector flag from
EMBEDDED_EXTRA_CFLAGS so separate components (Hypervisor in this case)
can enable/disable this feature by themselves.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Fix platforms/Kconfig and Kconfig.debug help indent to respect the
standard (tab + 2 spaces).
While there also move some default in Kconfig.debug before the help
message.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Michal Orzel [Mon, 3 Mar 2025 08:56:50 +0000 (09:56 +0100)]
xen/arm: Don't blindly print hwdom in generic panic messages
These functions are generic and used not only for hardware domain. This
creates confusion when printing any of these panic messages (e.g.
failure when loading domU kernel would result in informing a user about
a failure in loading hwdom kernel).
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Michal Orzel [Mon, 3 Mar 2025 08:56:49 +0000 (09:56 +0100)]
xen/arm: static-shmem: Drop unused size_cells
Value stored in size_cells is never read because we're only interested
in retrieving gbase address of shmem region for which we only need
address cells.
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Michal Orzel [Mon, 3 Mar 2025 08:56:48 +0000 (09:56 +0100)]
xen/arm: Check return code from fdt_finish_reservemap()
fdt_finish_reservemap() may fail (with -FDT_ERR_NOSPACE) in which case
further DTB creation (in prepare_dtb_hwdom()) makes no sense. Fix it.
Fixes: 13bb63b754e4 ("device tree,arm: supply a flat device tree to dom0") Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Michal Orzel [Mon, 3 Mar 2025 08:56:47 +0000 (09:56 +0100)]
xen/arm: dm: Bail out if padding != 0 for XEN_DMOP_set_irq_level
XEN_DMOP_set_irq_level operation requires elements of pad array (being
member of xen_dm_op_set_irq_level structure) to be 0. While handling the
hypercall we validate this. If one of the elements is not zero, we set
rc to -EINVAL. At this point we should stop further DM handling and bail
out propagating the error to the caller. However, instead of goto the
code uses break which has basically no meaningful effect. The rc value
is never read and the code continues with the hypercall processing ending
up (possibly) with the interrupt injection. Fix it.
Luca Fancellu [Wed, 26 Feb 2025 21:52:56 +0000 (21:52 +0000)]
xen/arm: Don't use copy_from_paddr for DTB relocation
Currently the early stage of the Arm boot maps the DTB using
early_fdt_map() using PAGE_HYPERVISOR_RO which is cacheable
read-only memory, later during DTB relocation the function
copy_from_paddr() is used to map pages in the same range on
the fixmap but using PAGE_HYPERVISOR_WC which is non-cacheable
read-write memory.
The Arm specifications, ARM DDI0487L.a, section B2.11 "Mismatched
memory attributes" discourage using mismatched attributes for
aliases of the same location.
Given that there is nothing preventing the relocation since the region
is already mapped, fix that by open-coding copy_from_paddr inside
relocate_fdt, without mapping on the fixmap.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
automation: allow selecting individual jobs via CI variables
Debugging sometimes involves running specific jobs on different
versions. It's useful to easily avoid running all of the not interesting
ones (for given case) to save both time and CI resources. Doing so used
to require changing the yaml files, usually in several places.
Ease this step by adding SELECTED_JOBS_ONLY variable that takes a regex.
Note that one needs to satisfy job dependencies on their own (for
example if a test job needs a build job, that specific build job
needs to be included too).
The variable can be specified via Gitlab web UI when scheduling a
pipeline, but it can be also set when doing git push directly:
More details at https://docs.gitlab.co.jp/ee/user/project/push_options.html
The variable needs to include regex for selecting jobs, including
enclosing slashes.
A coma/space separated list of jobs to select would be friendlier UX,
but unfortunately that is not supported:
https://gitlab.com/gitlab-org/gitlab/-/issues/209904 (note the proposed
workaround doesn't work for job-level CI_JOB_NAME).
On the other hand, the regex is more flexible (one can select for
example all arm32 jobs).
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
automation: add jobs running tests from tools/tests/*
There are a bunch of tests in tools/tests/, let them run in CI.
For each subdirectory expect "make run" will run the test, and observe
its exit code. This way, adding new tests is easy, and they will be
automatically picked up.
For better visibility, log test output to junit xml format, and let
gitlab ingest it. Set SUT_ADDR variable with name/address of the system
under test, so a network can be used to extract the file. The actual
address is set using DHCP. And for the test internal network, still add
the 192.168.0.1 IP (but don't replace the DHCP-provided one).
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Stefano Stabellini <stefano.stabellini@amd.com>
Nicola Vetrini [Fri, 14 Feb 2025 20:45:23 +0000 (21:45 +0100)]
automation: Update ECLAIR analysis configuration
The Xen configurations for the ARM64 and X86_64 ECLAIR analyses
is currently held in fixed files under
'automation/eclair_analysis/xen_{arm,x86}_config'. The values
of the configuration options there are susceptible to going stale
due to configuration option changes.
To enhance maintainability, the configuration under analysis is
derived from the respective architecture's defconfig, with suitable
changes added via EXTRA_XEN_CONFIG.
ARM: ITS: implement quirks and add support for Renesas Gen4 ITS
There are number of ITS implementations exist which are different from
the base one which have number of functionalities defined as is
"IMPLEMENTATION DEFINED", e.g. there may exist differences in cacheability,
shareability and memory requirements and others. This requires
appropriate handling of such HW requirements which are implemented as
ITS quirks: GITS_IIDR (ITS Implementer Identification Register) is used to
differentiate the ITS implementations and select appropriate set of
quirks if any.
As an example of such ITSes add quirk implementation for Renesas Gen4 ITS:
- add possibility to override default cacheability and shareability
settings used for ITS memory allocations;
- change relevant memory allocations to alloc_xenheap_pages which allows
to specify memory access flags, free_xenheap_pages is used to free;
- add quirks validation to ensure that all ITSes share the same quirks
in case of multiple ITSes are present in the system;
The Gen4 ITS memory requirements are not covered in any errata as of yet,
but observed behavior suggests that they are indeed required.
The idea of the quirk implementation is inspired by the Linux kernel ITS
quirk implementation [1].
Changelog:
v2 -> v3:
- added missing memset;
v1 -> v2:
- switched to using alloc_xenheap_pages/free_xenheap_pages for ITS memory
allocations;
- updated declaration of its_quirk_flags;
- added quirks validation to ensure that all ITSes share the same quirks;
- removed unnecessary vITS changes;
Michal Orzel [Wed, 19 Feb 2025 17:29:46 +0000 (18:29 +0100)]
xen/arm: Create GIC node using the node name from host dt
At the moment the GIC node we create for hwdom has a name
"interrupt-controller". Change it so that we use the same name as the
GIC node from host device tree. This is done for at least 2 purposes:
1) The convention in DT spec is that a node name with "reg" property
is formed "node-name@unit-address".
2) With DT overlay feature, many overlays refer to the GIC node using
the symbol under __symbols__ that we copy to hwdom 1:1. With the name
changed, the symbol is no longer valid and requires error prone manual
change by the user.
The unit-address part of the node name always refers to the first
address in the "reg" property which in case of GIC, always refers to
GICD and hwdom uses host memory layout.
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
arch: arm64: always set IL=1 when injecting an abort exception
ARM Architecture Reference Manual states that IL field of ESR_EL1
register should be 1 in some cases, and all these cases are covered by
inject_abt64_exception()
Section D24.2.40, page D24-7337 of ARM DDI 0487L:
IL, bit [25]
Instruction Length for synchronous exceptions. Possible values of this bit are:
[...]
0b1 - 32-bit instruction trapped.
This value is also used when the exception is one of the following:
[...]
- An Instruction Abort exception.
- A Data Abort exception for which the value of the ISV bit is 0.
[...]
inject_abt64_exception() function injects either Instruction Abort or
Data Abort exception. In both cases, ISS is 0, which means that ISV
bit is 0 as well. Thus, IL must be set to 1 unconditionally.
To align code with the specification, set .len field to 1 in
inject_abt64_exception() and remove unneeded third parameter.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
arch: arm64: always set IL=1 when injecting undefined exception
ARM Architecture Reference Manual states that IL field of ESR_EL1
register should be 1 when EC is 0b000000 aka HSR_EC_UNKNOWN.
Section D24.2.40, page D24-7337 of ARM DDI 0487L:
IL, bit [25]
Instruction Length for synchronous exceptions. Possible values of this bit are:
[...]
0b1 - 32-bit instruction trapped.
This value is also used when the exception is one of the following:
[...]
- An exception reported using EC value 0b000000.
To align code with the specification, set .len field to 1 in
inject_undef64_exception() and remove unneeded second parameter.
Michal Orzel [Wed, 12 Feb 2025 15:43:58 +0000 (17:43 +0200)]
device-tree: optimize size of struct dt_device_node
The current placement of fields in struct dt_device_node is not optimal and
introduces holes due to fields alignment.
Checked with "'pahole xen-syms -C dt_device_node"
ARM64 size 144B, 16B holes:
/* size: 144, cachelines: 3, members: 15 */
/* sum members: 128, holes: 3, sum holes: 16 */
/* last cacheline: 16 bytes */
ARM32 size 72B, 4B holes
/* size: 72, cachelines: 2, members: 15 */
/* sum members: 68, holes: 2, sum holes: 4 */
/* last cacheline: 8 bytes */
This patch optimizes size of struct dt_device_node by rearranging its
field, which eliminates holes and reduces structure size by 16B(ARM64) and
4B(ARM32).
After ARM64 size 128B, no holes (-16B):
/* size: 128, cachelines: 2, members: 15 */
After ARM32 size 68B, no holes (-4B)
/* size: 68, cachelines: 2, members: 15 */
/* last cacheline: 4 bytes */
Note that the property hard-affinity is optional. It is possible to add
other properties in the future not only to specify soft affinity, but
also to provide more precise methods for configuring affinity. For
instance, on ARM the MPIDR could be use to specify the pCPU. For now, it
is left to the future.
xen/arm: introduce legacy dom0less option for xenstore allocation
The new xenstore page allocation scheme might break older unpatched
Linux kernels that do not check for the Xenstore connection status
before proceeding with Xenstore initialization.
Introduce a dom0less configuration option to retain the older behavior.
The older behavior triggered by this option is to allocate the xenstore
page in init-dom0less. That does not work with static-mem guests.
However, it will make it possible to run as regular guests older Linux
kernel versions that are left unpatched.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
init-dom0less: allocate xenstore page if not already allocated
We check if the xenstore page is already allocated. If yes, there is
nothing to do. If no, we proceed allocating it to support old unpatched
Linux kernels.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Henry Wang [Fri, 24 May 2024 22:55:22 +0000 (15:55 -0700)]
docs/features/dom0less: Update the late XenStore init protocol
With the new allocation strategy of Dom0less DomUs XenStore page,
update the doc of the late XenStore init protocol accordingly.
Signed-off-by: Henry Wang <xin.wang2@amd.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Henry Wang [Fri, 24 May 2024 22:55:20 +0000 (15:55 -0700)]
xen/arm: Alloc XenStore page for Dom0less DomUs from hypervisor
There are use cases (for example using the PV driver) in Dom0less
setup that require Dom0less DomUs start immediately with Dom0, but
initialize XenStore later after Dom0's successful boot and call to
the init-dom0less application.
An error message can seen from the init-dom0less application on
1:1 direct-mapped domains:
```
Allocating magic pages
memory.c:238:d0v0 mfn 0x39000 doesn't belong to d1
Error on alloc magic pages
```
The "magic page" is a terminology used in the toolstack as reserved
pages for the VM to have access to virtual platform capabilities.
Currently the magic pages for Dom0less DomUs are populated by the
init-dom0less app through populate_physmap(), and populate_physmap()
automatically assumes gfn == mfn for 1:1 direct mapped domains. This
cannot be true for the magic pages that are allocated later from the
init-dom0less application executed in Dom0. For domain using statically
allocated memory but not 1:1 direct-mapped, similar error "failed to
retrieve a reserved page" can be seen as the reserved memory list is
empty at that time.
Since for init-dom0less, the magic page region is only for XenStore.
To solve above issue, this commit allocates the XenStore page for
Dom0less DomUs at the domain construction time. The PFN will be
noted and communicated to the init-dom0less application executed
from Dom0. To keep the XenStore late init protocol, set the connection
status to XENSTORE_RECONNECT.
Since the guest magic region allocation from init-dom0less is for
XenStore, and the XenStore page is now allocated from the hypervisor,
instead of hardcoding the guest magic pages region, use
xc_hvm_param_get() to get the XenStore page PFN. Rename alloc_xs_page()
to get_xs_page() to reflect the changes.
With this change, some existing code is not needed anymore, including:
(1) The definition of the XenStore page offset.
(2) Call to xc_domain_setmaxmem() and xc_clear_domain_page() as we
don't need to set the max mem and clear the page anymore.
(3) Foreign mapping of the XenStore page, setting of XenStore interface
status and HVM_PARAM_STORE_PFN from init-dom0less, as they are set
by the hypervisor.
Take the opportunity to do some coding style improvements when possible.
Reported-by: Alec Kwapis <alec.kwapis@medtronic.com> Signed-off-by: Henry Wang <xin.wang2@amd.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com> Tested-by: Michal Orzel <michal.orzel@amd.com>
Andrew Cooper [Fri, 28 Feb 2025 09:58:51 +0000 (09:58 +0000)]
MISRA: Update path for bsearch devation
This ought to have been part of the original patch, so as to avoid breaking
CI.
Fixes: 31c0d6fdf421 ("xen/bsearch: Split out of lib.h into it's own header") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Jan Beulich [Thu, 27 Feb 2025 12:58:32 +0000 (12:58 +0000)]
IOMMU/x86: the bus-to-bridge lock needs to be acquired IRQ-safe
The function's use from set_msi_source_id() is guaranteed to be in an
IRQs-off region. While the invocation of that function could be moved
ahead in msi_msg_to_remap_entry() (doesn't need to be in the IOMMU-
intremap-locked region), the call tree from map_domain_pirq() holds an
IRQ descriptor lock. Hence all use sites of the lock need become IRQ-
safe ones.
In find_upstream_bridge() do a tiny bit of tidying in adjacent code:
Change a variable's type to unsigned and merge a redundant assignment
into another variable's initializer.
This is XSA-467 / CVE-2025-1713.
Fixes: 476bbccc811c ("VT-d: fix MSI source-id of interrupt remapping") Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Andrew Cooper [Wed, 26 Feb 2025 03:27:33 +0000 (21:27 -0600)]
PPC: Activate UBSAN in testing
Also enable -fno-sanitize=alignment like x86 since support for unaligned
accesses is guaranteed by the ISA and the existing OPAL setup code
relies on it.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Thu, 24 Oct 2024 12:47:20 +0000 (13:47 +0100)]
x86/ucode: Drop the match_reg[] field from AMD's microcode_patch
This was true in the K10 days, but even back then the match registers were
really payload data rather than header data.
But, it's really model specific data, and these days typically part of the
signature, so is random data for all intents and purposes.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Fri, 23 Aug 2024 18:38:59 +0000 (19:38 +0100)]
x86/ucode: Rename hypercall-context functions
microcode_update{,_helper}() are overly generic names in a file that has
multiple update routines and helper functions contexts.
Rename microcode_update() to ucode_update_hcall() so it explicitly identifies
itself as hypercall context, and rename microcode_update_helper() to
ucode_update_hcall_cont() to make it clear it is in continuation context.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Jan Beulich [Wed, 26 Feb 2025 11:26:23 +0000 (12:26 +0100)]
x86/DM: slightly simplify set_mem_type()
There's no need to access the static array twice per iteration, even
more so when that's effectively open-coding array_access_nospec().
Along with renaming the "new type" variable, rename the "old type" one
as well, to clarify which one is which.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Oleksii Kurochko [Wed, 26 Feb 2025 11:24:26 +0000 (12:24 +0100)]
xen/riscv: update mfn calculation in pt_mapping_level()
When pt_update() is called with arguments (..., INVALID_MFN, ..., 0 or 1),
it indicates that a mapping is being destroyed/modifyed.
In the case when modifying or destroying a mapping, it is necessary to
search until a leaf node is found, instead of searching for a page table
entry based on the precalculated `level` and `order`(look at pt_update()).
This is because when `mfn` == INVALID_MFN, the `mask` (in pt_mapping_level())
will take into account only `vfn`, which could accidentally return an
incorrect level, leading to the discovery of an incorrect page table entry.
For example, if `vfn` is page table level 1 aligned, but it was mapped as
page table level 0, then pt_mapping_level() will return `level` = 1, since
only `vfn` (which is page table level 1 aligned) is taken into account when
`mfn` == INVALID_MFN (look at pt_mapping_level()).
Have unmap_table() check for NULL, such that individual callers don't need
to.
Jan Beulich [Wed, 26 Feb 2025 11:23:49 +0000 (12:23 +0100)]
x86/MCE-telem: drop unnecessary per-CPU field
struct mc_telem_cpu_ctl's processing field is used solely in
mctelem_process_deferred(), where the local variable can as well be used
directly when retrieving the head of the list to process. This then also
eliminates the field holding a dangling pointer once the processing of
the list finished, in particular when the entry is handed to
mctelem_dismiss().
No functional change intended.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Wed, 26 Feb 2025 11:23:19 +0000 (12:23 +0100)]
x86/MCE: fail init more gracefully when CPU vendor isn't supported
When mcheck_init() doesn't recognize the CPU vendor, it will undo the
all-banks allocation, and it will in particular not install the CPU
notifier. This way APs will pointlessly try to re-establish an
all-banks allocation, while then falling over NULL pointers due to the
notifier not having run and hence not having allocated anything for
them.
Prevent both from happening, and additionally delay writing MCG_CTL
until no errors can occur anymore in mca_cap_init().
Fixes: 741367e77d6c ("mce: Clean-up mcheck_init handler") Fixes: a5e1b534ac6f ("x86: mce cleanup for both Intel and AMD mce logic") Fixes: 560cf418c845 ("x86/mcheck: allow varying bank counts per CPU") Reported-by: Teddy Astie <teddy.astie@vates.tech> Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Andrew Cooper [Mon, 24 Feb 2025 15:36:11 +0000 (15:36 +0000)]
CirrusCI: Use shallow clone
This reduces the Clone step from ~50s to ~3s.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Andrew Cooper [Thu, 31 Oct 2024 13:35:40 +0000 (13:35 +0000)]
scripts: Fix git-checkout.sh to work with non-master branches (take 2)
First, rename $TAG to $COMMITTISH. We already pass tags, branches (well, only
master) and full SHAs into this script.
Xen uses master for QEMU_UPSTREAM_REVISION, and has done for other trees too
in the path. Apparently we've never specified a different branch, because the
git-clone rune only pulls in the master branch; it does not pull in diverging
branches.
Fix this by performing an explicit fetch of the $COMMITTISH, then checking out
the dummy branch from the FETCH_HEAD.
Suggested-by: Jason Andryuk <jason.andryuk@amd.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Andrii Sultanov [Fri, 14 Feb 2025 15:24:27 +0000 (15:24 +0000)]
tools/ocaml: Fix oxenstored build warning
OCaml, in preparation for a renaming of the error string associated with
conversion failure in 'int_of_string' functions, started to issue this
warning:
File "process.ml", line 440, characters 13-28:
440 | | (Failure "int_of_string") -> reply_error "EINVAL"
^^^^^^^^^^^^^^^
Warning 52 [fragile-literal-pattern]: Code should not depend on the actual values of
this constructor's arguments. They are only for information
and may change in future versions. (See manual section 11.5)
Deal with this at the source, and instead create our own stable
ConversionFailure exception that's raised on the None case in
'int_of_string_opt'.
'c_int_of_string' is safe and does not raise such exceptions.
Signed-off-by: Andrii Sultanov <andrii.sultanov@cloud.com> Acked-by: Christian Lindig <christian.lindig@cloud.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Mon, 17 Feb 2025 19:13:01 +0000 (19:13 +0000)]
xen/ACPI: Drop local acpi_os_{v,}printf() and use plain {v,}printk()
Now that Xen has a real vprintk(), there's no need to opencode it locally with
vsnprintf(). Redirect the debug routines to the real {v,}printk() and drop
the local acpi_os_{v,}printf() implementations.
Amongst other things, this removes one arbitrary limit on message size, as
well as removing a 512 byte static buffer that ought to have been in
__initdata given that is private to an __init function.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Thu, 23 Jan 2025 03:27:07 +0000 (03:27 +0000)]
xen/console: Optimise the parameter order of vprintk_common()
For ABIs which pass parameters by register (all cases that we compile Xen
for), inserting new arguments on the left hand side involves shuffling all
other parameters along by one register whereas appending a new argument
doesn't involve shuffling of existing registers.
Reorder vprintk_common()'s prefix parameter to being last. This is a marginal
improvement on all architectures:
Function old new delta
vprintk 18 12 -6 x86
vprintk 32 24 -8 arm32
vprintk 52 48 -4 arm64
vprintk 52 48 -4 riscv64
vprintk 80 72 -8 ppc64
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Ross Lagerwall [Mon, 17 Feb 2025 17:50:11 +0000 (17:50 +0000)]
x86/ucode: Add option to scan microcode by default
A lot of systems automatically add microcode to the initramfs so it can
be useful as a vendor policy to always scan for microcode. Add a Kconfig
option to allow setting the default behaviour.
The default behaviour is unchanged since the new option defaults to
"no".
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Oleksii Kurochko [Tue, 25 Feb 2025 07:47:12 +0000 (08:47 +0100)]
xen/riscv: update defintion of vmap_to_mfn()
vmap_to_mfn() uses virt_to_maddr(), which is designed to work with VA from
either the direct map region or Xen's linkage region (XEN_VIRT_START).
An assertion will occur if it is used with other regions, in particular for
the VMAP region.
Since RISC-V lacks a hardware feature to request the MMU to translate a VA to
a PA (as Arm does, for example), software page table walking (pt_walk()) is
used for the VMAP region to obtain the mfn from pte_t.
To avoid introduce a circular dependency between asm/mm.h and asm/page.h by
including each other, the static inline function _vmap_to_mfn() is introduced
in asm/page.h, as it uses struct pte_t and pte_is_mapping() from asm/page.h.
_vmap_to_mfn() is then reused in the definition of vmap_to_mfn() macro in
asm/mm.h.
Fixes: 7db8d2bd9b ("xen/riscv: add minimal stuff to mm.h to build full Xen") Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Oleksii Kurochko [Tue, 25 Feb 2025 07:46:32 +0000 (08:46 +0100)]
xen/riscv: implement software page table walking
RISC-V doesn't have hardware feature to ask MMU to translate
virtual address to physical address ( like Arm has, for example ),
so software page table walking is implemented.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Tue, 25 Feb 2025 07:45:14 +0000 (08:45 +0100)]
radix-tree: don't left-shift negative values
Any (signed) integer is okay to pass into radix_tree_int_to_ptr(), yet
left shifting negative values is UB. Use an unsigned intermediate type,
reducing the impact to implementation defined behavior (for the
unsigned->signed conversion).
Also please Misra C:2012 rule 7.3 by dropping the lower case numeric 'l'
tag.
No difference in generated code, at least on x86.
Fixes: b004883e29bb ("Simplify and build-fix (for some gcc versions) radix_tree_int_to_ptr()") Reported-by: Teddy Astie <teddy.astie@vates.tech> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
projects / people / royger / xen.git / log