mm: adjust _xvrealloc() declaration

... to match its definition parameter-name-wise, to please Misra C:2012
Rule 8.3.

Fixes: 9102fcd9579f ("mm: introduce xvmalloc() et al and use for grant table allocations")
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

libxl: Use zero-ed memory for PVH acpi tables

xl/libxl memory is leaking into a PVH guest through uninitialized
portions of the ACPI tables.

Use libxl_zalloc() to obtain zero-ed memory to avoid this issue.

This is XSA-464 / CVE-2024-45819.

Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Fixes: 14c0d328da2b ("libxl/acpi: Build ACPI tables for HVMlite guests")
Reviewed-by: Jan Beulich <jbeulich@suse.com>

x86/boot: Setup correctly fs segment for bogus_real_magic

bogus_real_magic code uses fs segment so it should be initialised.

Fixes: d8c8fef09054 ("Provide basic Xen PM infrastructure")
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

x86/trampoline: Change type of trampoline_phys to uint32_t

As now documented, this variable holds a page aligned value less than 1M.

However, head.S fills it using 4-byte stores, and reloc_trampoline() is
compiled for both 32bit and 64bit, where unsigned long is a different size.

This happens to work because of the range of the value, but switch to uint32_t
to make it explicit.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86/wakeup: Fix code generation for bogus_saved_magic

bogus_saved_magic() is assembled in a .code64 section but invoked in 32bit
mode.  Moving it causes a real encoding difference.

Before:
  66 c7 04 25 14 80 0b 00 53 0e    movw   $0xe53,0xb8014(,%eiz,1)

After:
  66 c7 05 14 80 0b 00 53 0e       movw   $0xe53,0xb8014

The difference happens to be benign, but move the logic back into a .code32
for sanity sake.  Annotate it with ELF metadata while doing so.

Fixes: d8c8fef09054 ("Provide basic Xen PM infrastructure")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

x86: Drop mach_mpspec.h

This header is included in exactly one location.  Fold it into mpspec.h

With this done, mach-default/ is empty, so remove the include path.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86: Drop mach-default/bios_ebda.h

It has a single function, and a single user.  This is unlikely to change
moving forwards so fold it into mpparse.c.

Update it to use an explicit uint16_t cast, rather than assuming the width of
short.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86: Move mach-default/io_ports.h to asm/io-ports.h

intercept.c and msi.c don't even need this header.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86: Move mach-default/irq_vectors.h to asm/irq-vectors.h

irq_vectors.h is included by with multiple paths.  Move it to be a regular
header instead.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86: Delete mach_apic.h

All useful content has been moved elsewhere.

enable_apic_mode() and multi_timer_check() are empty stubs.  Remove their sole
callers and drop them.

apicid_to_node() and bios_cpu_apicid[] are entirely unused.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

x86/mach-apic: Move the genapic wrappers to genapic.h

This a better place for them to live.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86/mach-apic: Drop set_apicid()

It's an unnecessary wrapper, and longer than the operation it wraps.

It's also the only reason that mpparse.c includes mach_apic.h, other than for
transitive dependencies.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86/mach-apic: Drop check_apicid_present()

It's an unnecessary wrapper.

It's also the only reason that smpboot.c includes mach_apic.h, other than for
transitive dependencies.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86/mach-apic: Drop check_apicid_used()

It's an unnecessary wrapper, and is longer than the operation it wraps.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86/mach-apic: Drop ioapic_phys_id_map()

It's an unnecessary wrapper.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86/mach-apic: Drop apic_id_registered()

It's an unnecessary wrapper.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86/mach-apic: Move generic_*_probe() declarations into genapic.h

... as the implementations are in genapic/probe.c

This covers the only functions that both setup.c and boot.c were including
mach_apic.h for, although setup.c was depending on io_apic.h transitively too.

The happens to address two MISRA Rule 8.4 violations, as probe.c couldn't
previously see the declarations.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86: Drop includes of mach_apic.h

A number of files don't need mach_apic.h at all, or only need transitive
dependences.  Drop the includes.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

VT-d: Drop includes of mach_apic.h

Neither iommu.c nor quirks.c use any functionality.  iommu.c only uses it to
transitively include apic.h and io_apic.h, while quirks.c is only depending on
the ACLINUX wrapping of strtoul() which we spell simple_strtoul() everywhere
else in Xen.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

xen/x86: prevent addition of .note.gnu.property if livepatch is enabled

GNU assembly that supports such feature will unconditionally add a
.note.gnu.property section to object files.  The content of that section can
change depending on the generated instructions.  The current logic in
livepatch-build-tools doesn't know how to deal with such section changing
as a result of applying a patch and rebuilding.

Since .note.gnu.property is not consumed by the Xen build, suppress its
addition when livepatch support is enabled.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

CHANGELOG: Add note about xAPIC destination mode change

Fixes: dcbf8210f3f3 ('x86/APIC: Switch flat driver to use phys dst for ext ints')
Signed-off-by: Matthew Barnes <matthew.barnes@cloud.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

iommu/ipmmu-vmsa: Add Renesas R8A779G0 (R-Car V4H) support

Add Renesas R8A779G0 (R-Car V4H) IPMMU support.

Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>

x86/boot: Fix bootinfo.h to be standalone

Work to rebase the Trenchboot patch series has encountered:

  In file included from ./arch/x86/include/asm/tpm.h:4,
                   from arch/x86/boot/../tpm.c:23:
  ./arch/x86/include/asm/bootinfo.h:88:35: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'next_boot_module_index'
     88 | static inline unsigned int __init next_boot_module_index(
        |

Fix this by including the necessary header.

Fixes: 74af2d98276d ("x86/boot: eliminate module_map")
Reported-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>

x86/trampoline: Collect other scattered trampoline symbols

... and document them too.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>

x86/boot: add cmdline_pa to struct boot_module

Add an address field, cmdline_pa, to struct boot_module to hold the address of
the string field from struct mod.

Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

x86/boot: move kextra into boot info

... so it can be removed as a distinct parameter to create_dom0().

Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

x86/boot: move headroom to boot modules

The purpose of struct boot_module is to encapsulate the state of boot module as
it is processed by Xen. Locating boot module state struct boot_module reduces
the number of global variables as well as the number of state variables that
must be passed around. It also lays the groundwork for hyperlaunch mult-domain
construction, where multiple instances of state variables like headroom will be
needed.

Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

NUMA: Introduce NODE_DATA->node_present_pages (RAM)

Xen tracks the total span of physical memory space of each NUMA node,
but the PFN span includes large MMIO holes in e.g. the first NUMA node.
Thus, the span is not the same as the amount of usable RAM of a node.

Xen does not need it, but NUMA node memory amount can be helpful for
management tools and HW information tools like hwloc/lstopo with its
Xen backend for Dom0: https://github.com/xenserver-next/hwloc/

Introduce node_present_pages to node_data[]:
On boot, set the count of usable PFNs and update it on memory_add().

Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

x86/xstate: Remove stale assertions in fpu_x{rstor,save}()

After edb48e76458b("x86/fpu: Combine fpu_ctxt and xsave_area in arch_vcpu"),
v->arch.xsave_area is always present and we can just remove these asserts.

Fixes: edb48e76458b("x86/fpu: Combine fpu_ctxt and xsave_area in arch_vcpu")
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86emul/test: drop an undue conditional

Gating the main part of what do_test() does is wrong: As it stands, the
"memory" forms of BNDC{L,N,U} weren't tested because of this mistake.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

CI: Fix package installation for Coverity run

Something has changed recently in the Github Actions environment and the
golang metapacakge resolves to something that no longer exists:

  https://github.com/xen-project/xen/actions/runs/11539340171/job/32120834909

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>

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>

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>

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>

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>

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>

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>

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>

CI: Drop alpine-3.18-rootfs-export and use test-artefacts

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

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.

Signed-off-by: Wei Chen <wei.chen@arm.com>
Signed-off-by: Jiamei.Xie <jiamei.xie@arm.com>
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>

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.

Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

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).

Fixes: dac84b66cc9a ("xen: arm64: initial build + config changes, start of day code")
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>

SUPPORT.md: Argo: Upgrade status to Tech Preview

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>

CI: Fix cppcheck parallel build more

A recent cppcheck run was found to fail:

  https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/8237167472

with:

  "type mismatch! call is<type>() before get<type>()" && is<std::string>()
  make[3]: *** [arch/x86/boot/Makefile:28: arch/x86/boot/reloc-trampoline.32.o] Error 1

This turns out to be a parallel build issue, combined with a recent change to
x86.  Notably, we now have a case where we build both:

  CC      arch/x86/boot/reloc-trampoline.32.o
  CC      arch/x86/boot/reloc-trampoline.o

from the same original C file, and cppcheck uses the source C file as the key
for generating it's intermediate files.

Switch cppcheck to use the object file as the unique key instead.

Fixes: 45bfff651173 ("xen/misra: xen-analysis.py: fix parallel analysis Cppcheck errors")
Fixes: db8acf31f96b ("x86/boot: Reuse code to relocate trampoline")
Suggested-by: Luca Fancellu <luca.fancellu@arm.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>

Revert "x86/mm: ensure L2 is always freed if empty"

CI says no:

  https://gitlab.com/xen-project/hardware/xen/-/jobs/8240163332

This reverts commit a6dba2761e2ecaa7ffc3d3bb3c85685d232bbe68.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Revert "scripts: Fix git-checkout.sh to work with branches other than master"

While it does work with branches, it breaks working with full SHAs.

This reverts commit c554ec124b12f9c0d8bfb2b564ca239bd676037c.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

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>

x86/msi: harden stale pdev handling

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>

types: replace remaining use of __u64

... and move the type itself to linux-compat.h.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>

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>

types: replace remaining uses of __u32

... and move the type itself to linux-compat.h.

While doing so drop casts (instead of modiyfing them) from x86'es
wrmsrl().

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>

x86: modernize swab64()

For quite a while we didn't need to be concerned of 32-bit code
generation anymore: Simply use the 64-bit form of BSWAP here.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>

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>

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>

MAINTAINERS: minor file line update

"xen/arch/arm/include/asm/tee" is a directory and should be terminated
by a slash ("/").

Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Acked-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>

Config: Update MiniOS revision

Commit 6d5159e8410b ("Add missing symbol exports for grub-pv")

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

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>

x86/mm: Use standard C types for sized integers

The header is already using these types.

Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86/setup: Make setup.h header self contained

The header uses rangeset structure pointer.
Forward declare the structure.

Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

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>

automation/eclair: monitor Rules 11.2 and 18.1 and update configuration

Add Rule 11.2 and Rule 18.1 to the monitored set.

Tag Rule 7.3 as clean.
Tag Rule 11.2 and Rule 20.7 as clean only for arm.

Rule 2.2, Rule 9.5 and Directive 4.12 are not accepted: do not enable
them and do not tag them as clean. Same for D4.3.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

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.

Requested-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Victor Lira <victorm.lira@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

x86/boot: Use trampoline_phys variable directly from C code

No more need to pass from assembly code.

Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

x86/boot: Use boot_vid_info variable directly from C code

No more need to pass from assembly code.

Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

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>

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>

x86/boot: Explain how discard_initial_images() works

discard_initial_images() only works because init_domheap_pages() with ps==pe
is a no-op.

In dom0_construct(), explaining the significance of setting the initrd length
to 0, and put an explicit check in discard_initial_images().

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>

x86/boot: Drop the mbi and mod pointers in __start_xen()

We can't drop them fully yet, but we can limit their scope to almost nothing,
which serves the same purpose.

This removes the ability to accidentally reintroduce buggy uses of
__va(mbi->mods_addr).

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>

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>

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>

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>

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>

x86/ucode: Explain what microcode_set_module() does

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>

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>

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>

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>

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>

x86/boot: Add a temporary module_map pointer to boot_image

... in order to untangle parameter handling independently from other logic
changes.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>

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>

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>

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>

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>

x86/emul: address violations of MISRA C Rule 16.3

Add missing break statements to address violations of MISRA C:2012
Rule 16.3 (An unconditional `break' statement shall terminate
every switch-clause).

Make explicit unreachability of a program point with
ASSERT_UNREACHABLE() and add defensive code.

No functional change.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

x86/pv: remove unlikely() from BUG_ON() condition in pv_map_ldt_shadow_page()

BUG_ON() itself already contains an unlikely() wrapping the bug condition.

No functional change.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

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>

CI: Add {adl,zen3p}-pvshim-* tests

GitlabCI has no testing of Xen's PVH entrypoint.  Fix this.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

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>