Javi Merino [Fri, 18 Oct 2024 09:17:43 +0000 (10:17 +0100)]
CI: Refresh the Debian 12 x86_32 container
Rework the container to be non-root, use heredocs for readability, and
use apt-get --no-install-recommends to keep the size down. Rename the
job to x86_32, to be consistent with XEN_TARGET_ARCH and the
naming scheme of all the other CI jobs:
${VERSION}-${ARCH}-${BUILD_NAME}
Remove build dependencies for building QEMU. The absence of ninja/meson means
that the container hasn't been able to build QEMU in years.
Remove build dependencies for the documentation as we don't have to
build it for every single arch.
This reduces the size of the container from 2.22GB to 1.32Gb.
Signed-off-by: Javi Merino <javi.merino@cloud.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Javi Merino [Mon, 14 Oct 2024 16:53:31 +0000 (17:53 +0100)]
CI: Refresh the Debian 12 x86_64 container
Rework the container to use heredocs for readability, and use
apt-get --no-install-recommends to keep the size down.
This reduces the size of the (uncompressed) container from 3.44GB to
1.97GB.
The container is left running the builds and tests as root. A
subsequent patch will make the necessary changes to the test scripts
to allow test execution as a non-root user.
Signed-off-by: Javi Merino <javi.merino@cloud.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Javi Merino [Mon, 4 Nov 2024 15:58:14 +0000 (15:58 +0000)]
CI: Don't use -y with apt-get update
apt-get update refreshes the package lists. -y doesn't do anything
here. It is needed for "apt-get install" or "apt-get upgrade" but not
for apt-get update. Drop it.
Signed-off-by: Javi Merino <javi.merino@cloud.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Daniel P. Smith [Sat, 2 Nov 2024 17:25:42 +0000 (13:25 -0400)]
x86/boot: introduce boot module flags
The existing startup code employs various ad-hoc state tracking about certain
boot module types by each area of the code. A boot module flags bitfield is
added to enable tracking these different states. The first state to be
transition by this commit is module relocation.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Daniel P. Smith [Sat, 2 Nov 2024 17:25:41 +0000 (13:25 -0400)]
x86/boot: eliminate module_map
With all boot modules now labeled by type, it is no longer necessary to
track whether a boot module was identified via the module_map bitmap.
Introduce a set of helpers to search the list of boot modules based on type and
the reference type, pointer or array index, desired. Then drop all uses of
setting a bit in module_map and replace its use for looping with the helpers.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Daniel P. Smith [Sat, 2 Nov 2024 17:25:40 +0000 (13:25 -0400)]
x86/boot: introduce boot module types
This commit introduces module types for the types of boot modules that may be
passed to Xen. These include xen, kernel, ramdisk, microcode, and xsm policy.
This reduces the need for hard coded order assumptions and global variables to
be used by consumers of boot modules, such as domain construction.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Fri, 25 Oct 2024 19:35:47 +0000 (20:35 +0100)]
x86/ucode: Fold early_update_cache() into its single caller
The data pointer is known good, so the -ENOMEM path is unnecessary. However,
if we find no patch, something's wrong seeing as early_microcode_init()
indicated it was happy.
We are the entity initialising the cache, so we don't need the complexity of
using microcode_update_cache(). Just assert the cache is empty, and populate
it.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Andrew Cooper [Fri, 25 Oct 2024 18:49:11 +0000 (19:49 +0100)]
x86/ucode: Drop ucode_mod and ucode_blob
Both are used to pass information from early_microcode_load() to
microcode_init_cache(), and both constitute use-after-free's in certain cases.
Later still in microcode_init() is a failed attempt to "free" this
information, long after the damage has been done.
* ucode_mod is a copy of the module_t identified by `ucode=$n`. It is a copy
of the physical pointer from prior to Xen relocating the modules.
microcode_init_cache() might happen to find the data still intact in it's
old location, but it might be an arbitrary part of some other module.
* ucode_blob is a stashed virtual pointer to a bootstrap_map() which becomes
invalid the moment control returns to __start_xen(), where other logic is
free to to make temporary mappings. This was even noticed and
microcode_init_cache() adjusted to "fix" the stashed pointers.
The information which should be passed between these two functions is which
module to look in. Introduce early_mod_idx for this purpose. opt_scan can be
reused to distinguish between CPIO archives and raw containers.
Notably this means microcode_init_cache() doesn't need to scan all modules any
more; we know exactly which one to look in. However, we do re-parse the CPIO
header for simplicity.
Furthermore, microcode_init_cache(), being a presmp_initcall does not need to
use bootstrap_map() to access modules; it can use mfn_to_virt() directly,
which avoids needing to funnel exit paths through bootstrap_unmap().
Fold microcode_scan_module() into what is now it's single caller. It operates
on the function-wide idx/data/size state which allows for a unified "found"
path irrespective of module selection method.
Delete microcode_init() entirely. It was never legitimate logic.
This resolves all issues to do with holding pointers (physical or virtual)
across returning to __start_xen().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Andrew Cooper [Fri, 25 Oct 2024 19:02:10 +0000 (20:02 +0100)]
x86/ucode: Use bootstrap_unmap() in early_microcode_load()
If bootstrap_map() has provided a mapping, we must free it when done. Failing
to do so may cause a spurious failure for unrelated logic later.
Inserting a bootstrap_unmap() here does not break the use of ucode_{blob,mod}
any more than they already are.
Add a printk noting when we didn't find a microcode patch. It's at debug
level, because this is the expected case on AMD Client systems, and SDPs, but
for people trying to figure out why microcode loading isn't work, it might be
helpful.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Andrew Cooper [Fri, 25 Oct 2024 17:08:34 +0000 (18:08 +0100)]
x86/ucode: Enforce invariant about module selection
The work to add the `ucode=nmi` cmdline option left a subtle corner case.
Both scan and an explicit index could be chosen, and we could really find both
a CPIO archive and a microcode file.
Worse, because the if/else chains for processing ucode_{blob,mod} are opposite
ways around in early_microcode_load() and microcode_init_cache(), we can
genuinely perform early microcode loading from the CPIO archive, then cache
from the explicit file.
Therefore, enforce that only one selection method can be active.
Rename ucode_{scan,mod_idx} to have an opt_ prefix. This is both for
consistency with the rest of Xen, and to guarantee that we've got all
instances of the variables covered in this change. Explain how they're use.
During cmdline/config parsing, always update both variables in pairs.
In early_microcode_load(), ASSERT() the invariant just in case. Use a local
variable for idx rather than operating on the static; we're the only consume
of the value.
Expand the index selection logic with comments and warnings to the user when
something went wrong.
Fixes: 5ed12565aa32 ("microcode: rendezvous CPUs in NMI handler and load ucode") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Frediano Ziglio [Tue, 5 Nov 2024 14:13:43 +0000 (14:13 +0000)]
x86/boot: Explicitly list .{sym,shstr,str}tab in build32.lds.S
Currently, building with LLVM's LLD fails:
ld -melf_i386_fbsd --orphan-handling=error -N -T ...
ld: error: <internal>:(.symtab) is being placed in '.symtab'
ld: error: <internal>:(.shstrtab) is being placed in '.shstrtab'
ld: error: <internal>:(.strtab) is being placed in '.strtab'
gmake[11]: *** [arch/x86/boot/Makefile:69: arch/x86/boot/built-in-32.base.bin] Error 1
This is a consequence of --orphan-handling, and it appears that Binutils
doesn't diagnose some orphaned sections even explicitly asked to do so.
List the sections explicitly.
Fixes: aa9045e77130 ('x86/boot: Rework how 32bit C is linked/included for early boot') Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Frediano Ziglio [Wed, 6 Nov 2024 10:22:47 +0000 (10:22 +0000)]
x86/boot: Uses nm command instead of map file to get symbols
combine_two_binaries.py only understands GNU LD's format, and does
not work with LLVM's LLD.
Use nm command instead to get list of symbols; specifically
BSD format as it does not truncate symbols names like sysv one.
Fixes: aa9045e77130 ('x86/boot: Rework how 32bit C is linked/included for early boot') Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Frediano Ziglio [Wed, 6 Nov 2024 10:07:48 +0000 (10:07 +0000)]
x86/boot: Fix intermediate file names to generate 32 bit code
The "base" and "offset" definition were inverted, "base" file should be the
files without offsets applied while "offset" should have the offsets applied.
Also update an old usage of "final" to "apply offset" to make more clear and
consistent (in former commit messages the "final" term was used instead of
"offset").
Fixes: aa9045e77130 ('x86/boot: Rework how 32bit C is linked/included for early boot') Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Update the apt package index before installing, which fixes things.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Andrew Cooper [Fri, 25 Oct 2024 18:20:41 +0000 (19:20 +0100)]
x86/ucode: Move the CPIO path string into microcode_ops
We've got a perfectly good vendor abstraction already for microcode. No need
for a second ad-hoc one in microcode_scan_module().
This is in preparation to use ucode_ops.cpio_path in multiple places.
These paths are only used during __init, so take the opportunity to move them
into __initconst.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Andrew Cooper [Fri, 25 Oct 2024 16:50:37 +0000 (17:50 +0100)]
x86/ucode: Fold microcode_grab_module() into its single caller
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Andrew Cooper [Fri, 25 Oct 2024 16:24:35 +0000 (17:24 +0100)]
x86/ucode: Fold early_microcode_update_cpu() into its single caller
Diff-wise, as early_microcode_update_cpu() is the larger function, this more
closely resembles "merge early_microcode_load() into it's single callee", but
the end result is the same.
At the same time, rename the len variable to size. This is for better
consistency with existing logic, and to reduce churn later.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Andrew Cooper [Fri, 25 Oct 2024 16:39:06 +0000 (17:39 +0100)]
x86/ucode: Break early_microcode_load() out of early_microcode_init()
microcode_grab_module() and early_microcode_update_cpu() are logically one
task that passes state via static variables.
We intend to delete said static variables; start by breaking these functions
out of early_microcode_init().
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Andrew Cooper [Sat, 26 Oct 2024 17:05:39 +0000 (18:05 +0100)]
x86/ucode: Turn microcode_init_cache() into a presmp_initcall
There's no need for microcode_init_cache() to be called exactly where it is in
__start_xen(). All that matters is it must be after xmalloc() is available
and before APs start up.
As a consequence, microcode_init_cache() runs a little later on boot now.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Roger Pau Monne [Mon, 28 Oct 2024 11:48:31 +0000 (12:48 +0100)]
tools/libxl: remove usage of VLA arrays
Clang 19 complains with the following error when building libxl:
libxl_utils.c:48:15: error: variable length array folded to constant array as an extension [-Werror,-Wgnu-folding-constant]
48 | char path[strlen("/local/domain") + 12];
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Replace the usage of strlen() with sizeof, which allows the literal
string length to be known at build time. Note sizeof accounts for the
NUL terminator while strlen() didn't, hence subtract 1 from the total
size calculation.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Anthony PERARD <anthony.perard@vates.tech>
Roger Pau Monne [Thu, 31 Oct 2024 08:57:13 +0000 (09:57 +0100)]
x86/io-apic: fix directed EOI when using AMD-Vi interrupt remapping
When using AMD-Vi interrupt remapping the vector field in the IO-APIC RTE is
repurposed to contain part of the offset into the remapping table. Previous to 2ca9fbd739b8 Xen had logic so that the offset into the interrupt remapping
table would match the vector. Such logic was mandatory for end of interrupt to
work, since the vector field (even when not containing a vector) is used by the
IO-APIC to find for which pin the EOI must be performed.
A simple solution wold be to read the IO-APIC RTE each time an EOI is to be
performed, so the raw value of the vector field can be obtained. However
that's likely to perform poorly. Instead introduce a cache to store the
EOI handles when using interrupt remapping, so that the IO-APIC driver can
translate pins into EOI handles without having to read the IO-APIC RTE entry.
Note that to simplify the logic such cache is used unconditionally when
interrupt remapping is enabled, even if strictly it would only be required
for AMD-Vi.
Reported-by: Willi Junga <xenproject@ymy.be> Suggested-by: David Woodhouse <dwmw@amazon.co.uk> Fixes: 2ca9fbd739b8 ('AMD IOMMU: allocate IRTE entries instead of using a static mapping') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Wei Chen [Mon, 28 Oct 2024 12:45:44 +0000 (12:45 +0000)]
xen/arm: mpu: Define Xen start address for MPU systems
On Armv8-A, Xen has a fixed virtual start address (link address too) for all
Armv8-A platforms. In an MMU based system, Xen can map its loaded address to
this virtual start address. So, on Armv8-A platforms, the Xen start address does
not need to be configurable. But on Armv8-R platforms, there is no MMU to map
loaded address to a fixed virtual address and different platforms will have very
different address space layout. So Xen cannot use a fixed physical address on
MPU based system and need to have it configurable.
So, we introduce a Kconfig option for users to set the start address. The start
address needs to be aligned to 4KB. We have a check for this alignment.
MPU allows us to define regions which are 64 bits aligned. This restriction
comes from the bitfields of PRBAR, PRLAR (the lower 6 bits are 0 extended to
provide the base and limit address of a region). This means that the start
address of Xen needs to be at least 64 bits aligned (as it will correspond to
the start address of memory protection region).
As for now Xen on MPU tries to use the same memory alignment restrictions as it
has been for MMU. We have added a build assertion to ensure that the page size
is 4KB. Unlike MMU where the starting virtual address is 2MB, Xen on MPU needs
the start address to be 4KB (ie page size) aligned.
In case if the user forgets to set the start address, then 0xffffffff is used
as default. This is to trigger the error (on alignment check) and thereby prompt
user to set the start address.
Also updated config.h so that it includes mpu/layout.h when CONFIG_MPU is
defined.
xen/arm: mpu: Introduce choice between MMU and MPU
There are features in the forthcoming patches which are dependent on
MPU. For eg fixed start address.
Also, some of the Xen features (eg STATIC_MEMORY) will be selected
by the MPU configuration.
Thus, this patch introduces a choice between MMU and MPU for the type
of memory management system. By default, MMU is selected.
MPU is now gated by UNSUPPORTED.
Update SUPPORT.md to state that the support for MPU is experimental.
Also updated CHANGELOG.md as well.
xen/arm: Skip initializing the BSS section when it is empty
If the BSS section is empty, then the function should return.
If one does not check whether the BSS section is empty or not, then there is a
risk of writing 0s outside of BSS section (which may contain critical data).
Recent patches to xen-devel indicate active interest in Argo within the Xen
community, and as the feature has been documented and in use by
OpenXT for multiple years, update the Xen SUPPORT.md statement of status.
This has also been discussed at several XenSummits, with general agreement to
the status upgrade.
Signed-off-by: Christopher Clark <christopher.w.clark@gmail.com> Acked-by: Julien Grall <jgrall@amazon.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Roger Pau Monné [Thu, 31 Oct 2024 11:43:10 +0000 (12:43 +0100)]
x86/mm: ensure L2 is always freed if empty
The current logic in modify_xen_mappings() allows for fully empty L2 tables to
not be freed and unhooked from the parent L3 if the last L2 slot is not
populated.
Ensure that even when an L2 slot is empty the logic to check whether the whole
L2 can be removed is not skipped.
Fixes: 4376c05c3113 ('x86-64: use 1GB pages in 1:1 mapping if available') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Dom0 normally informs Xen of PCI device removal via
PHYSDEVOP_pci_device_remove, e.g. in response to SR-IOV disable or
hot-unplug. We might find ourselves with stale pdevs if a buggy dom0
fails to report removal via PHYSDEVOP_pci_device_remove. In this case,
attempts to access the config space of the stale pdevs would be invalid
and return all 1s.
Some possible conditions leading to this are:
1. Dom0 disables SR-IOV without reporting VF removal to Xen.
The Linux SR-IOV subsystem normally reports VF removal when a PF driver
disables SR-IOV. In case of a buggy dom0 SR-IOV subsystem, SR-IOV could
become disabled with stale dangling VF pdevs in both dom0 Linux and Xen.
2. Dom0 reporting PF removal without reporting VF removal.
During SR-IOV PF removal (hot-unplug), a buggy PF driver may fail to
disable SR-IOV, thus failing to remove the VFs, leaving stale dangling
VFs behind in both Xen and Linux. At least Linux warns in this case:
[ 100.000000] 0000:01:00.0: driver left SR-IOV enabled after remove
In either case, Xen is left with stale VF pdevs, risking invalid PCI
config space accesses.
When Xen is built with CONFIG_DEBUG=y, the following Xen crashes were
observed when dom0 attempted to access the config space of a stale VF:
(XEN) Assertion 'pos' failed at arch/x86/msi.c:1274
(XEN) ----[ Xen-4.20-unstable x86_64 debug=y Tainted: C ]----
...
(XEN) Xen call trace:
(XEN) [<ffff82d040346834>] R pci_msi_conf_write_intercept+0xa2/0x1de
(XEN) [<ffff82d04035d6b4>] F pci_conf_write_intercept+0x68/0x78
(XEN) [<ffff82d0403264e5>] F arch/x86/pv/emul-priv-op.c#pci_cfg_ok+0xa0/0x114
(XEN) [<ffff82d04032660e>] F arch/x86/pv/emul-priv-op.c#guest_io_write+0xb5/0x1c8
(XEN) [<ffff82d0403267bb>] F arch/x86/pv/emul-priv-op.c#write_io+0x9a/0xe0
(XEN) [<ffff82d04037c77a>] F x86_emulate+0x100e5/0x25f1e
(XEN) [<ffff82d0403941a8>] F x86_emulate_wrapper+0x29/0x64
(XEN) [<ffff82d04032802b>] F pv_emulate_privileged_op+0x12e/0x217
(XEN) [<ffff82d040369f12>] F do_general_protection+0xc2/0x1b8
(XEN) [<ffff82d040201aa7>] F x86_64/entry.S#handle_exception_saved+0x2b/0x8c
(XEN) Assertion 'pos' failed at arch/x86/msi.c:1246
(XEN) ----[ Xen-4.20-unstable x86_64 debug=y Tainted: C ]----
...
(XEN) Xen call trace:
(XEN) [<ffff82d040346b0a>] R pci_reset_msix_state+0x47/0x50
(XEN) [<ffff82d040287eec>] F pdev_msix_assign+0x19/0x35
(XEN) [<ffff82d040286184>] F drivers/passthrough/pci.c#assign_device+0x181/0x471
(XEN) [<ffff82d040287c36>] F iommu_do_pci_domctl+0x248/0x2ec
(XEN) [<ffff82d040284e1f>] F iommu_do_domctl+0x26/0x44
(XEN) [<ffff82d0402483b8>] F do_domctl+0x8c1/0x1660
(XEN) [<ffff82d04032977e>] F pv_hypercall+0x5ce/0x6af
(XEN) [<ffff82d0402012d3>] F lstar_enter+0x143/0x150
These ASSERTs triggered because the MSI-X capability position can't be
found for a stale pdev.
Latch the capability positions of MSI and MSI-X during device init, and
replace instances of pci_find_cap_offset(..., PCI_CAP_ID_MSI{,X}) with
the stored value. Introduce one additional ASSERT, while the two
existing ASSERTs in question continue to work as intended, even with a
stale pdev.
Fixes: 484d7c852e4f ("x86/MSI-X: track host and guest mask-all requests separately") Fixes: 575e18d54d19 ("pci: clear {host/guest}_maskall field on assign") Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Jan Beulich [Thu, 31 Oct 2024 11:41:18 +0000 (12:41 +0100)]
byteorder: replace __u64
In {big,little}_endian.h the changes are entirely mechanical, except for
dealing with casting away of const from pointers-to-const on lines
touched anyway.
In swab.h the casting of constants is done away with as well - I simply
don't see what the respective comment is concerned about in our
environment (sizeof(int) >= 4, sizeof(long) >= {4,8} depending on
architecture, sizeof(long long) >= 8). The comment is certainly relevant
in more general cases. Excess parentheses are dropped as well,
___swab64()'s local variable is renamed, and __arch__swab64()'s is
dropped as being redundant with ___swab64()'s.
Excessive casts compared to ___{,constant_}swab{16,32}() are also
dropped. Much like excessive ones in __fswab64().
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Jan Beulich [Thu, 31 Oct 2024 11:39:33 +0000 (12:39 +0100)]
byteorder: replace __u32
In {big,little}_endian.h the changes are entirely mechanical, except for
dealing with casting away of const from pointers-to-const on lines
touched anyway.
In swab.h the casting of constants is done away with as well - I simply
don't see what the respective comment is concerned about in our
environment (sizeof(int) >= 4, sizeof(long) >= {4,8} depending on
architecture, sizeof(long long) >= 8). The comment is certainly relevant
in more general cases. Excess parentheses are dropped as well,
___swab32()'s local variable is renamed, and __arch__swab32()'s is
dropped as being redundant with ___swab32()'s.
The masking operation is also dropped from __fswab64().
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Jan Beulich [Thu, 31 Oct 2024 11:39:23 +0000 (12:39 +0100)]
byteorder: replace __u16
In {big,little}_endian.h the changes are entirely mechanical, except for
dealing with casting away of const from pointers-to-const on lines
touched anyway.
In swab.h the casting of constants is done away with as well - I simply
don't see what the respective comment is concerned about in our
environment (sizeof(int) >= 4, sizeof(long) >= {4,8} depending on
architecture, sizeof(long long) >= 8). The comment is certainly relevant
in more general cases. Excess parentheses are dropped as well,
___swab16()'s local variable is renamed, and __arch__swab16()'s is
dropped as being redundant with ___swab16()'s.
With that no uses of the type remain, so it moves to linux-compat.h.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Andrew Cooper [Wed, 30 Oct 2024 19:03:42 +0000 (19:03 +0000)]
scripts: Fix git-checkout.sh to work with branches other than master
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 stating which branch/tag is wanted.
$TAG is really a committish, and git-clone's -b/--branch takes a committish
too.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Andrew Cooper [Tue, 29 Oct 2024 17:21:08 +0000 (17:21 +0000)]
x86/cpu-policy: Extend the guest max policy max leaf/subleaves
We already have one migration case opencoded (feat.max_subleaf). A more
recent discovery is that we advertise x2APIC to guests without ensuring that
we provide max_leaf >= 0xb.
In general, any leaf known to Xen can be safely configured by the toolstack if
it doesn't violate other constraints.
Therefore, introduce guest_common_{max,default}_leaves() to generalise the
special case we currently have for feat.max_subleaf, in preparation to be able
to provide x2APIC topology in leaf 0xb even on older hardware.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Alejandro Vallejo <alejandro.vallejo@cloud.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Victor Lira [Mon, 28 Oct 2024 23:55:35 +0000 (16:55 -0700)]
automation: add x86_64 test (linux argo)
Add x86_64 hardware test that creates a Xen Argo communication
connection between two PVH domains. In the test, dom0 creates a domU and
listens for messages sent by the domU through Argo.
To accomplish this, build Xen with CONFIG_ARGO=y and create a CI test job.
Update the xilinx x86_64 test script to support the new test, and add
"sync_console" to command line to avoid an issue with console messages
being lost.
Frediano Ziglio [Tue, 29 Oct 2024 10:29:39 +0000 (10:29 +0000)]
x86/boot: Reuse code to relocate trampoline
Move code from efi-boot.h to a separate, new, reloc-trampoline.c file.
Reuse this new code, compiling it for 32bit as well, to replace assembly
code in head.S doing the same thing.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Frediano Ziglio [Tue, 29 Oct 2024 10:29:38 +0000 (10:29 +0000)]
x86/boot: Rework how 32bit C is linked/included for early boot
Right now, the two functions which were really too complicated to write
in asm are compiled as 32bit PIC, linked to a blob and included
directly, using global asm() to arrange for them to have function semantics.
This is limiting and fragile; the use of data relocations will compile
fine but malfunction when used, creating hard-to-debug bugs.
Furthermore, we would like to increase the amount of C, to
deduplicate/unify Xen's boot logic, as well as making it easier to
follow. Therefore, rework how the 32bit objects are included.
Link all 32bit objects together first. This allows for sharing of logic
between translation units. Use differential linking and explicit
imports/exports to confirm that we only have the expected relocations,
and write the object back out as an assembly file so it can be linked
again as if it were 64bit, to integrate with the rest of Xen.
This allows for the use of external references (e.g. access to global
variables) with reasonable assurance of doing so safely.
No functional change.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Daniel P. Smith [Mon, 21 Oct 2024 00:45:39 +0000 (01:45 +0100)]
x86/boot: Convert mod[] to bi->mods[] in __start_xen()
The former is about to disappear.
In some cases, introduce a local struct boot_module pointer. Judgement on
where to do this, and on constness, is based on what creates least churn
overall.
No functional change.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Daniel P. Smith [Wed, 23 Oct 2024 16:11:43 +0000 (17:11 +0100)]
x86/boot: Introduce bootstrap_map_bm() to map boot_module's
Convert converting the call to bzimage_headroom(), as well as using
bi->mod[0]. It will be used externally by later changes.
No functional change.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Andrew Cooper [Wed, 23 Oct 2024 15:55:55 +0000 (16:55 +0100)]
x86/boot: Introduce bootstrap_unmap()
We're about to introduce alternative mapping functions, and passing NULL was
always a slightly weird way to express unmap. Make an explicit unmap
function, to avoid having two different valid ways of unmapping.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Daniel P. Smith [Mon, 21 Oct 2024 18:02:42 +0000 (19:02 +0100)]
x86/boot: Drop initial_images pointer
Now that the module list is encapsulated inside boot_info, we can do away with
the initial_images pointer.
No functional change.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Andrew Cooper [Mon, 27 Mar 2023 18:33:46 +0000 (19:33 +0100)]
xen/earlycpio: Drop nextoff parameter
This is imported from Linux, but the parameter being signed is dubious in the
first place and we're not plausibly going to gain a use for the functionality.
Linux has subsequently made it an optional parameter to avoid forcing callers
to pass a stack variable they don't care about using.
In the unlikely case that we gain a usecase, we can reintroduce it, but in the
meantime simplify the single caller.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Wed, 23 Oct 2024 13:52:49 +0000 (14:52 +0100)]
x86/boot: Remove the mbi_p parameter from __start_xen()
The use of physical addresses in __start_xen() has proved to be fertile soure
of bugs.
The MB1/2 path stashes the MBI pointer in multiboot_ptr (a setup.c variable
even), then re-loads it immediately before calling __start_xen(). For this,
we can just drop the function parameter and read multiboot_ptr in the one
place where it's used.
The EFI path also passes this parameter into __start_xen(). Have the EFI path
set up multiboot_ptr too, and move the explanation of phyiscal-mode pointers.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Daniel P. Smith [Wed, 23 Oct 2024 01:03:15 +0000 (02:03 +0100)]
x86/boot: Fix XSM module handling during PVH boot
As detailed in commit 0fe607b2a144 ("x86/boot: Fix PVH boot during boot_info
transition period"), the use of __va(mbi->mods_addr) constitutes a
use-after-free on the PVH boot path.
This pattern has been in use since before PVH support was added. This has
most likely gone unnoticed because no-one's tried using a detached Flask
policy in a PVH VM before.
Plumb the boot_info pointer down, replacing module_map and mbi. Importantly,
bi->mods[].mod is a safe way to access the module list during PVH boot.
As this is the final non-bi use of mbi in __start_xen(), make the pointer
unusable once bi has been established, to prevent new uses creeping back in.
This is a stopgap until mbi can be fully removed.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Daniel P. Smith [Wed, 23 Oct 2024 01:02:42 +0000 (02:02 +0100)]
x86/boot: Fix microcode module handling during PVH boot
As detailed in commit 0fe607b2a144 ("x86/boot: Fix PVH boot during boot_info
transition period"), the use of __va(mbi->mods_addr) constitutes a
use-after-free on the PVH boot path.
This pattern has been in use since before PVH support was added. Inside a PVH
VM, it will go unnoticed as long as the microcode container parser doesn't
choke on the random data it finds.
The use within early_microcode_init() happens to be safe because it's prior to
move_xen(). microcode_init_cache() is after move_xen(), and therefore unsafe.
Plumb the boot_info pointer down, replacing module_map and mbi. Importantly,
bi->mods[].mod is a safe way to access the module list during PVH boot.
Note: microcode_scan_module() is still bogusly stashing a bootstrap_map()'d
pointer in ucode_blob.data, which constitutes a different
use-after-free, and only works in general because of a second bug. This
is unrelated to PVH, and needs untangling differently.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Daniel P. Smith [Mon, 21 Oct 2024 00:45:37 +0000 (20:45 -0400)]
x86/boot: convert consider_modules to struct boot_module
To start transitioning consider_modules() over to struct boot_module, begin
with taking the array of struct boot_modules but use the temporary struct
element mod.
No functional change intended.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Tue, 22 Oct 2024 17:48:30 +0000 (18:48 +0100)]
x86/boot: Simplify size calculations in move_memory()
While both src and dst are similar, src is mapped only accounting for src's
size, while dst is mapped based on the minimum of both. This means that in
some cases, an overly large mapping is requested for src.
Rework the sz calcuation to be symmetric, and leave an explanation of how
logic works.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Andrew Cooper [Tue, 22 Oct 2024 20:08:53 +0000 (21:08 +0100)]
x86/boot: Simplify address calculations in move_memory()
Given that soffs is the offset into the 2M superpage,
start = (src - soffs) >> PAGE_SIFT
is a complicated expression for the frame address of the containing superpage.
Except, start is converted straight back to a byte address to use, so the
shifting is unnecessary too.
The only thing done with the mapped pointer is to have soffs added back on for
the memmove() call. bootstrap_map_addr() passes through the offset, so we can
pass src directly in and simplify the memmove() call too. For the end mapping
address, this simplifies to just src + sz too.
The same reasoning holds for dst and doffs.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Andrew Cooper [Tue, 22 Oct 2024 17:33:57 +0000 (18:33 +0100)]
x86/boot: Convert move_memory() to use bootstrap_map_addr()
move_memory() is very complicated, and buggy. In order to fix the latter, we
have to address the former.
Given prior cleanup, bootstrap_map() is now implemented in terms of
bootstrap_map_addr(), meaning that it is counterproductive to plumb the
mapping through module_t.
Delete mod, and introduce two same-sized/named fields. At this point in boot,
neither fields have their named purpose, so indicate the purpose in comments.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Andrew Cooper [Tue, 22 Oct 2024 10:15:26 +0000 (11:15 +0100)]
x86/boot: Fix PVH boot during boot_info transition period
multiboot_fill_boot_info() taking the physical address of the multiboot_info
structure leads to a subtle use-after-free on the PVH path, with rather less
subtle fallout.
The pointers used by __start_xen(), mbi and mod, are either:
- MB: Directmap pointers into the trampoline, or
- PVH: Xen pointers into .initdata, or
- EFI: Directmap pointers into Xen.
Critically, these either remain valid across move_xen() (MB, PVH), or rely on
move_xen() being inhibited (EFI).
The conversion to multiboot_fill_boot_info(), taking only mbi_p, makes the PVH
path use directmap pointers into Xen, as well as move_xen() which invalidates
said pointers.
Switch multiboot_fill_boot_info() to consume the same virtual addresses that
__start_xen() currently uses. This keeps all the pointers valid for the
duration of __start_xen(), for all boot protocols.
It can be safely untangled once multiboot_fill_boot_info() takes a full copy
the multiboot info data, and __start_xen() has been moved over to using the
new boot_info consistently.
Right now, bi->{loader,cmdline,mods} are problematic. Nothing uses
bi->mods[], and nothing uses bi->cmdline after move_xen().
bi->loader is used after move_xen(), although only for cmdline_cook() of
dom0's cmdline, where it happens to be benign because PVH boot skips the
inspection of the bootloader name.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Andrew Cooper [Mon, 21 Oct 2024 14:07:54 +0000 (15:07 +0100)]
CI: Rework domU_config generation in qubes-x86-64.sh
Right now, various blocks rewrite domU_config= as a whole, even though it is
largely the same.
* dom0pvh-hvm does nothing but change the domain type to hvm
* *-pci sets the domain type, clears vif=[], appends earlyprintk=xen to the
cmdline, and adds some PCI config.
Refactor this to be domU_type (defaults to pvh), domU_vif (defaults to
xenbr0), and domU_extra_config (defaults to empty) and use these variables to
build domU_config= once.
Of note, the default domU_config= now sets cmdline=, and extra= is intended
for inclusion via domU_extra_config as necessary.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Andrew Cooper [Mon, 21 Oct 2024 13:06:24 +0000 (14:06 +0100)]
CI: Minor cleanup to qubes-x86-64.sh
* List all the test_variants and summerise what's going on
* Use case rather than an if/else chain for $test_variant
* Adjust indentation inside the case block
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
x86/fpu: Rework fpu_setup_fpu() uses to split it in two
It was trying to do too many things at once and there was no clear way of
defining what it was meant to do. This commit splits the function in two.
1. A function to return the FPU to power-on reset values.
2. A x87/SSE state loader (equivalent to the old function when it took
a data pointer).
The old function also had a concept of "default" values that the FPU
would be configured for in some cases but not others. This patch removes
that 3rd vague initial state and replaces it with power-on reset.
While doing this make sure the abridged control tag is consistent with the
manuals and starts as 0xFF
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
x86/fpu: Combine fpu_ctxt and xsave_area in arch_vcpu
fpu_ctxt is either a pointer to the legacy x87/SSE save area (used by FXSAVE) or
a pointer aliased with xsave_area that points to its fpu_sse subfield. Such
subfield is at the base and is identical in size and layout to the legacy
buffer.
This patch merges the 2 pointers in the arch_vcpu into a single XSAVE area. In
the very rare case in which the host doesn't support XSAVE all we're doing is
wasting a tiny amount of memory and trading those for a lot more simplicity in
the code.
While at it, dedup the setup logic in vcpu_init_fpu() and integrate it
into xstate_alloc_save_area().
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Daniel P. Smith [Mon, 21 Oct 2024 00:45:36 +0000 (20:45 -0400)]
x86/boot: introduce struct boot_module
This will introduce a new struct boot_module to provide a rich state
representation around modules provided by the boot loader. Support is for 64
boot modules, one held in reserve for Xen, and up to 63 can be provided by the
boot loader. The array of struct boot_modules will be accessible via a
reference held in struct boot_info.
A temporary `mod` parameter is included in struct boot_module to ease the
transition from using Multiboot v1 structures over to struct boot_module. Once
the transition is complete, the parameter will be dropped from the structure.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Sat, 19 Oct 2024 18:15:04 +0000 (19:15 +0100)]
x86/boot: Fix PVH boot following the start of the MBI->BI conversion
pvh_init() sets up the mbi pointer, but leaves mbi_p at 0. This isn't
compatbile with multiboot_fill_boot_info() starting from the physical address,
in order to remove the use of the mbi pointer.
Fixes: 038826b61e85 ("x86/boot: move x86 boot module counting into a new boot_info struct") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
xen/arm: Add NXP LINFlexD UART early printk support
This adds support for early printk debug via the NXP LINFlexD
UART controller.
Signed-off-by: Andrei Cherechesu <andrei.cherechesu@nxp.com> Signed-off-by: Peter van der Perk <peter.vander.perk@nxp.com> Acked-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Andrei Cherechesu <andrei.cherechesu@nxp.com> Signed-off-by: Peter van der Perk <peter.vander.perk@nxp.com> Acked-by: Julien Grall <jgrall@amazon.com>
Javi Merino [Thu, 17 Oct 2024 16:20:20 +0000 (17:20 +0100)]
ocaml/libs: Fill build failure due to unused variable in ocaml macro
On Fedora 40, the build fails with:
In file included from domain_getinfo_stubs_v1.c:10:
domain_getinfo_stubs_v1.c: In function 'xsd_glue_failwith':
/usr/lib64/ocaml/caml/memory.h:275:29: error: unused variable 'caml__frame' [-Werror=unused-variable]
275 | struct caml__roots_block *caml__frame = *caml_local_roots_ptr
| ^~~~~~~~~~~
domain_getinfo_stubs_v1.c:48:9: note: in expansion of macro 'CAMLparam0'
48 | CAMLparam0();
| ^~~~~~~~~~
cc1: all warnings being treated as errors
The CAMLparam0 macro is defined in /usr/lib64/ocaml/caml/memory.h:255 as:
Andrew Cooper [Thu, 17 Oct 2024 17:02:56 +0000 (13:02 -0400)]
x86/boot: split bootstrap_map_addr() out of bootstrap_map()
Using an interface based on addresses directly, not modules.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Daniel P. Smith [Thu, 17 Oct 2024 17:02:44 +0000 (13:02 -0400)]
x86/boot: move mmap info to boot info
Transition the memory map info to be held in struct boot_info.
No functional change intended.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Daniel P. Smith [Thu, 17 Oct 2024 17:02:42 +0000 (13:02 -0400)]
x86/boot: move boot loader name to boot info
Transition the incoming boot loader name to be held in struct boot_info.
No functional change intended.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
x86/boot: move x86 boot module counting into a new boot_info struct
An initial step towards a non-multiboot internal representation of boot
modules for common code, starting with x86 setup and converting the fields
that are accessed for the startup calculations.
Introduce a new header, <asm/bootinfo.h>, and populate it with a new boot_info
structure initially containing a count of the number of boot modules.
No functional change intended.
Signed-off-by: Christopher Clark <christopher.w.clark@gmail.com> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
If a partial DT has a /gic node, but no references to it, dtc may omit
the phandle property. With the phandle property missing,
fdt_get_phandle() returns 0, leading Xen to generate a malformed domU
dtb due to invalid interrupt-parent phandle references. 0 is an invalid
phandle value. Add a zero check, and fall back to GUEST_PHANDLE_GIC.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Michal Orzel [Thu, 10 Oct 2024 10:57:46 +0000 (12:57 +0200)]
device-tree: Move dt-overlay.c to common/device-tree/
The code is DT specific and as such should be placed under common
directory for DT related files. Update MAINTAINERS file accordingly
and drop the line with a path from a top-level comment in dt-overlay.c.
It serves no purpose and requires being updated on every code movement.
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Frediano Ziglio [Tue, 15 Oct 2024 08:25:12 +0000 (09:25 +0100)]
x86/boot: Align mbi2.c stack to 16 bytes
Most of Xen is built with a stack alignment of 8 bytes, but the UEFI spec
mandates 16 and UEFI services will fault if the stack is misaligned.
While the caller of efi_multiboot2_prelude() takes care to align the stack,
mbi2.c accidentally got the Xen-wide default of 8, and has a 50% chance of
crashing depending on how many variables the compiler decided to spill to the
stack.
Compile mbi2.c with the appropriate alignment for UEFI functionality.
Also take the opportunity to make it a fully .init object.
Fixes: eb21ce14d709 ('x86/boot: Rewrite EFI/MBI2 code partly in C') Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
[rewrite the commit message] Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Frediano Ziglio [Tue, 15 Oct 2024 12:24:25 +0000 (14:24 +0200)]
x86/boot: Prep work for 32bit object changes
Broken out of the subsequent patch for clarity.
* Rename head-bin-objs to obj32
* Use a .32.o suffix to distinguish these objects
* Factor out $(LD32)
No functional change.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monné [Tue, 15 Oct 2024 12:23:59 +0000 (14:23 +0200)]
iommu/amd-vi: do not error if device referenced in IVMD is not behind any IOMMU
IVMD table contains restrictions about memory which must be mandatory assigned
to devices (and which permissions it should use), or memory that should be
never accessible to devices.
Some hardware however contains ranges in IVMD that reference devices outside of
the IVHD tables (in other words, devices not behind any IOMMU). Such mismatch
will cause Xen to fail in register_range_for_device(), ultimately leading to
the IOMMU being disabled, and Xen crashing as x2APIC support might be already
enabled and relying on the IOMMU functionality.
Relax IVMD parsing: allow IVMD blocks to reference devices not assigned to any
IOMMU. It's impossible for Xen to fulfill the requirement in the IVMD block if
the device is not behind any IOMMU, but it's no worse than booting without
IOMMU support, and thus not parsing ACPI IVRS in the first place.
Reported-by: Willi Junga <xenproject@ymy.be> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Oleksii Kurochko [Tue, 15 Oct 2024 12:23:41 +0000 (14:23 +0200)]
xen/riscv: parse and handle fdt command line
Receive Xen's command line passed by DTB using boot_fdt_cmdline()
and passed it to cmdline_parse() for further procesinng and setup
of Xen-specific parameters.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Oleksii Kurochko [Tue, 15 Oct 2024 12:23:19 +0000 (14:23 +0200)]
xen/riscv: initialize bootinfo from dtb
Parse DTB during startup, allowing memory banks and reserved
memory regions to be set up, along with early device tree node
(chosen, "xen,domain", "reserved-memory", etc) handling.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Acked-by: Jan Beulich <jbeulich@suse.com>
projects / xen.git / log