blkif: Fix a couple of typos

Those where fixed in OVMF's copy. (And one of them fixed in QEMU's
copy but later discarded by an update.)

Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>

blkif: Fix alignment description for discard request

The discard feature have an other xenstore node to described the size
of the blocks than can be discarded, "discard-granularity", which
default to "sector-size" when absent as noted in the properties and in
note 4. So discard request should be aligned on this value.

Fixes: 221f2748e8da ("blkif: reconcile protocol specification with in-use implementations")
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>

xen/livepatch: remove useless check for duplicated sections

The current check for duplicated sections in a payload is not effective.  Such
check is done inside a loop that iterates over the sections names, it's
logically impossible for the bitmap to be set more than once.

The usage of a bitmap in check_patching_sections() has been replaced with a
boolean, since the function just cares that at least one of the special
sections is present.

No functional change intended, as the check was useless.

Fixes: 29f4ab0b0a4f ('xsplice: Implement support for applying/reverting/replacing patches.')
Fixes: 76b3d4098a92 ('livepatch: Do not enforce ELF_LIVEPATCH_FUNC section presence')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

x86/boot: Initialise BSS sooner

Allows to call C code earlier.
In order to safely call C code we need to setup stack, selectors and BSS.

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

changelog: add note about blkif protocol fixes

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

x86/defns: Fix typo in comment "Porection" -> "Protection"

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

xen: introduce common macros for per-CPU sections defintion

Introduce PERCPU_BSS macro which manages:
 * Alignment of the section start
 * Insertion of per-CPU data sections
 * Alignment and start/end markers for per-CPU data
This change simplifies the linker script maintenance and ensures a unified
approach for per-CPU sections across different architectures.

Refactor the linker scripts for Arm, PPC, and x86 architectures by using
the common macro PERCPU_BSS defined in xen/xen.lds.h to handle per-CPU
data sections.

No functional changes.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

xen/efi: efibind: Fix typo in comment

expresion -> expression

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

xen/ucode: Make Intel's microcode_sanity_check() stricter

The SDM states that data size must be a multiple of 4, but Xen doesn't check
this propery.

This is liable to cause a later failures, but should be checked explicitly.

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

xen/ucode: Improve commentary for parsing AMD containers

Despite writing this code, it's not the easiest logic to follow.

Shorten the UCODE_EQUIV_TYPE name, and provide more of an explanation of
what's going on.

No functional change.

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

x86/APIC: Remove x2APIC pure cluster mode

With the introduction of mixed x2APIC mode (using cluster addressing for
IPIs and physical for external interrupts) the use of pure cluster mode
doesn't have any benefit.

Remove the mode itself, leaving only the code required for logical
addressing when sending IPIs.

Resolves: https://gitlab.com/xen-project/xen/-/issues/189
Signed-off-by: Matthew Barnes <matthew.barnes@cloud.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

x86/vLAPIC: prevent undue recursion of vlapic_error()

With the error vector set to an illegal value, the function invoking
vlapic_set_irq() would bring execution back here, with the non-recursive
lock already held. Avoid the call in this case, merely further updating
ESR (if necessary).

This is XSA-462 / CVE-2024-45817.

Fixes: 5f32d186a8b1 ("x86/vlapic: don't silently accept bad vectors")
Reported-by: Federico Serafini <federico.serafini@bugseng.com>
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

x86/efi: Use generic PE/COFF structures

Adapted x86 efi parser and mkreloc utility to use generic PE header
(efi/pe.h), instead of locally defined structures for each component.

Signed-off-by: Nikola Jelic <nikola.jelic@rt-rk.com>
Signed-off-by: Milan Djokic <milan.djokic@rt-rk.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>

x86/cpufeature: Reposition cpu_has_{lfence_dispatch,nscb}

LFENCE_DISPATCH used to be a synthetic feature, but was given a real CPUID bit
by AMD.  The define wasn't moved when this was changed.

NSCB has always been a real CPUID bit, and was misplaced when introduced in
the synthetic block alongside LFENCE_DISPATCH.

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

tools/libxs: Style consistency improvements

This is mostly Linux style.  Make the file self-consistent.  Drop trailing
whitespace, and use tabs consistently.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>

x86: enable long section names for xen.efi

While for our present .data.read_mostly it may be deemed tolerable that
the name is truncated to .data.re, for the planned .init.trampoline an
abbreviation to .init.tr would end up pretty meaningless. Engage the
long section names extension that GNU ld has had support for already in
2.22 (which we consider the baseline release for xen.efi building).

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

x86/mwait-idle: add dependency on general Intel CPU support

Currently mwait_idle driver in Xen only implements support for Intel CPUs.
Thus in order to reduce dead code in non-Intel build configurations it can
be made explicitly dependant on CONFIG_INTEL option.

Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86/boot: Drop stale comment about zeroing the stack

This used to be true, but was altered by commit 37786b23b027 ("x86/cet: Remove
writeable mapping of the BSPs shadow stack") which moved cpu0_stack into
.init.bss.stack_aligned.

Fixes: 37786b23b027 ("x86/cet: Remove writeable mapping of the BSPs shadow stack")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

xen/riscv: use {read,write}{b,w,l,q}_cpu() to define {read,write}_atomic()

The functions {read,write}{b,w,l,q}_cpu() do not need to be memory-ordered
atomic operations in Xen, based on their definitions for other architectures.

Therefore, {read,write}{b,w,l,q}_cpu() can be used instead of
{read,write}{b,w,l,q}(), allowing the caller to decide if additional
fences should be applied before or after {read,write}_atomic().

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

ubsan: use linux-compat.h

Instead of replacing the s64 (and later also u64) uses, keep the file as
little modified as possible from its Linux origin. (Sadly the two cast
adjustments are needed to avoid compiler warnings.)

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

docs/misra: add R17.2 and R18.2

The Xen community is already informally following both rules. Let's make
it explicit. Both rules have zero violations, only cautions. While we
want to go down to zero cautions in time, adding both rules to rules.rst
enables us to immediately make both rules gating in the ECLAIR job part
of gitlab-ci.

Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>

docs: fusa: Add requirements for emulated uart

Add the requirements for emulated SBSA UART.

Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>

automation/eclair: add deviation for MISRA C 2012 Dir 4.10

Add deviation to address violations of MISRA C:2012 Directive 4.10
("Precautions shall be taken in order to prevent the contents of a
header file being included more than once").

This deviation suppresses the violation arising from autogenerated file
xen/include/generated/autoconf.h

No functional change.

Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>

arm/smmu: Complete SMR masking support

SMR masking support allows deriving a mask either using a 2-cell iommu
specifier (per master) or stream-match-mask SMMU dt property (global
config). Even though the mask is stored in the fwid when adding a
device (in arm_smmu_dt_xlate_generic()), we still set it to 0 when
allocating SMEs (in arm_smmu_master_alloc_smes()). So at the end, we
always ignore the mask when programming SMRn registers. This leads to
SMMU failures. Fix it by completing the support.

A bit of history:
Linux support for SMR allocation was mainly done with:
588888a7399d ("iommu/arm-smmu: Intelligent SMR allocation")
021bb8420d44 ("iommu/arm-smmu: Wire up generic configuration support")

Taking the mask into account in arm_smmu_master_alloc_smes() was added
as part of the second commit, although quite hidden in the thicket of
other changes. We backported only the first patch with: 0435784cc75d
("xen/arm: smmuv1: Intelligent SMR allocation") but the changes to take
the mask into account were missed.

Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Rahul Singh <rahul.singh@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>

xen/arm: Enable workaround for Cortex-A53 erratum #1530924

All versions of Cortex-A53 cores are affected by the speculative
AT instruction erratum, as mentioned in the Cortex-A53 Revision r0
SDEN v21 documentation.

Enabled ARM64_WORKAROUND_AT_SPECULATE for all versions of Cortex-A53
cores, to avoid corrupting the TLB if performing a speculative AT
instruction during a guest context switch.

Signed-off-by: Andrei Cherechesu <andrei.cherechesu@nxp.com>
Acked-by: Julien Grall <jgrall@amazon.com>

arm: Drop deprecated early printk platform options

The predefined configurations for early printk have been deprecated for
a sufficient amount of time. Let's finally remove them.

Note:
In order not to lose these predefined configurations, I wrote a wiki
page: https://wiki.xenproject.org/wiki/Xen_on_ARM_Early_Printk

Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>

xen/ucode: Fix buffer under-run when parsing AMD containers

The AMD container format has no formal spec.  It is, at best, precision
guesswork based on AMD's prior contributions to open source projects.  The
Equivalence Table has both an explicit length, and an expectation of having a
NULL entry at the end.

Xen was sanity checking the NULL entry, but without confirming that an entry
was present, resulting in a read off the front of the buffer.  With some
manual debugging/annotations this manifests as:

  (XEN) *** Buf ffff83204c00b19c, eq ffff83204c00b194
  (XEN) *** eq: 0c 00 00 00 44 4d 41 00 00 00 00 00 00 00 00 00 aa aa aa aa
                            ^-Actual buffer-------------------^
  (XEN) *** installed_cpu: 000c
  (XEN) microcode: Bad equivalent cpu table
  (XEN) Parsing microcode blob error -22

When loaded by hypercall, the 4 bytes interpreted as installed_cpu happen to
be the containing struct ucode_buf's len field, and luckily will be nonzero.

When loaded at boot, it's possible for the access to #PF if the module happens
to have been placed on a 2M boundary by the bootloader.  Under Linux, it will
commonly be the end of the CPIO header.

Drop the probe of the NULL entry; Nothing else cares.  A container without one
is well formed, insofar that we can still parse it correctly.  With this
dropped, the same container results in:

  (XEN) microcode: couldn't find any matching ucode in the provided blob!

Fixes: 4de936a38aa9 ("x86/ucode/amd: Rework parsing logic in cpu_request_microcode()")
Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

xen/keyhandler: Move key_table[] into __ro_after_init

All registration is done at boot.  Almost...

iommu_dump_page_tables() is registered in iommu_hwdom_init(), which is called
twice when LATE_HWDOM is in use.

register_irq_keyhandler() has an ASSERT() guarding againt multiple
registration attempts, and the absence of bug reports hints at how many
configurations use LATE_HWDOM in practice.

Move the registration into iommu_setup() just after printing the overall
status of the IOMMU.  For starters, the hardware domain is specifically
excluded by iommu_dump_page_tables().

ept_dump_p2m_table is registered in setup_ept_dump() which is non-__init, but
whose sole caller, start_vmx(), is __init.  Move setup_ept_dump() to match.

With these two tweeks, all keyhandler reigstration is from __init functions,
so register_{,irq_}keyhandler() can move, and key_table[] can become
__ro_after_init.

No practical change.

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

x86/hvm: Simplify stdvga_mem_accept() further

stdvga_mem_accept() is called on almost all IO emulations, and the
overwhelming likely answer is to reject the ioreq.  Simply rearranging the
expression yields an improvement:

  add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-57 (-57)
  Function                                     old     new   delta
  stdvga_mem_accept                            109      52     -57

which is best explained looking at the disassembly:

  Before:                                                    After:
  f3 0f 1e fa           endbr64                              f3 0f 1e fa           endbr64
  0f b6 4e 1e           movzbl 0x1e(%rsi),%ecx            |  0f b6 46 1e           movzbl 0x1e(%rsi),%eax
  48 8b 16              mov    (%rsi),%rdx                |  31 d2                 xor    %edx,%edx
  f6 c1 40              test   $0x40,%cl                  |  a8 30                 test   $0x30,%al
  75 38                 jne    <stdvga_mem_accept+0x48>   |  75 23                 jne    <stdvga_mem_accept+0x31>
  31 c0                 xor    %eax,%eax                  <
  48 81 fa ff ff 09 00  cmp    $0x9ffff,%rdx              <
  76 26                 jbe    <stdvga_mem_accept+0x41>   <
  8b 46 14              mov    0x14(%rsi),%eax            <
  8b 7e 10              mov    0x10(%rsi),%edi            <
  48 0f af c7           imul   %rdi,%rax                  <
  48 8d 54 02 ff        lea    -0x1(%rdx,%rax,1),%rdx     <
  31 c0                 xor    %eax,%eax                  <
  48 81 fa ff ff 0b 00  cmp    $0xbffff,%rdx              <
  77 0c                 ja     <stdvga_mem_accept+0x41>   <
  83 e1 30              and    $0x30,%ecx                 <
  75 07                 jne    <stdvga_mem_accept+0x41>   <
  83 7e 10 01           cmpl   $0x1,0x10(%rsi)               83 7e 10 01           cmpl   $0x1,0x10(%rsi)
  0f 94 c0              sete   %al                        |  75 1d                 jne    <stdvga_mem_accept+0x31>
  c3                    ret                               |  48 8b 0e              mov    (%rsi),%rcx
  66 0f 1f 44 00 00     nopw   0x0(%rax,%rax,1)           |  48 81 f9 ff ff 09 00  cmp    $0x9ffff,%rcx
  8b 46 10              mov    0x10(%rsi),%eax            |  76 11                 jbe    <stdvga_mem_accept+0x31>
  8b 7e 14              mov    0x14(%rsi),%edi            |  8b 46 14              mov    0x14(%rsi),%eax
  49 89 d0              mov    %rdx,%r8                   |  48 8d 44 01 ff        lea    -0x1(%rcx,%rax,1),%rax
  48 83 e8 01           sub    $0x1,%rax                  |  48 3d ff ff 0b 00     cmp    $0xbffff,%rax
  48 8d 54 3a ff        lea    -0x1(%rdx,%rdi,1),%rdx     |  0f 96 c2              setbe  %dl
  48 0f af c7           imul   %rdi,%rax                  |  89 d0                 mov    %edx,%eax
  49 29 c0              sub    %rax,%r8                   <
  31 c0                 xor    %eax,%eax                  <
  49 81 f8 ff ff 09 00  cmp    $0x9ffff,%r8               <
  77 be                 ja     <stdvga_mem_accept+0x2a>   <
  c3                    ret                                  c3                    ret

By moving the "p->count != 1" check ahead of the
ioreq_mmio_{first,last}_byte() calls, both multiplies disappear along with a
lot of surrounding logic.

No functional change.

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

ARM/cache: Drop legacy __read_mostly/__ro_after_init definitions

These are no longer needed.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <jgrall@amazon.com>

x86/mm: undo type change of partial_flags

Clang dislikes the boolean type combined with the field being set using
PTF_partial_set.

Fixes: 5ffe6d4a02e0 ("types: replace remaining uses of s16")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>

blkif: reconcile protocol specification with in-use implementations

Current blkif implementations (both backends and frontends) have all slight
differences about how they handle the 'sector-size' xenstore node, and how
other fields are derived from this value or hardcoded to be expressed in units
of 512 bytes.

To give some context, this is an excerpt of how different implementations use
the value in 'sector-size' as the base unit for to other fields rather than
just to set the logical sector size of the block device:

                        │ sectors xenbus node │ requests sector_number │ requests {first,last}_sect
────────────────────────┼─────────────────────┼────────────────────────┼───────────────────────────
FreeBSD blk{front,back} │     sector-size     │      sector-size       │           512
────────────────────────┼─────────────────────┼────────────────────────┼───────────────────────────
Linux blk{front,back}   │         512         │          512           │           512
────────────────────────┼─────────────────────┼────────────────────────┼───────────────────────────
QEMU blkback            │     sector-size     │      sector-size       │       sector-size
────────────────────────┼─────────────────────┼────────────────────────┼───────────────────────────
Windows blkfront        │     sector-size     │      sector-size       │       sector-size
────────────────────────┼─────────────────────┼────────────────────────┼───────────────────────────
MiniOS                  │     sector-size     │          512           │           512

An attempt was made by 67e1c050e36b in order to change the base units of the
request fields and the xenstore 'sectors' node.  That however only lead to more
confusion, as the specification now clearly diverged from the reference
implementation in Linux.  Such change was only implemented for QEMU Qdisk
and Windows PV blkfront.

Partially revert to the state before 67e1c050e36b while adjusting the
documentation for 'sectors' to match what it used to be previous to
2fa701e5346d:

 * Declare 'feature-large-sector-size' deprecated.  Frontends should not expose
   the node, backends should not make decisions based on its presence.

 * Clarify that 'sectors' xenstore node and the requests fields are always in
   512-byte units, like it was previous to 2fa701e5346d and 67e1c050e36b.

All base units for the fields used in the protocol are 512-byte based, the
xenbus 'sector-size' field is only used to signal the logic block size.  When
'sector-size' is greater than 512, blkfront implementations must make sure that
the offsets and sizes (despite being expressed in 512-byte units) are aligned
to the logical block size specified in 'sector-size', otherwise the backend
will fail to process the requests.

This will require changes to some of the frontends and backends in order to
properly support 'sector-size' nodes greater than 512.

Fixes: 2fa701e5346d ('blkif.h: Provide more complete documentation of the blkif interface')
Fixes: 67e1c050e36b ('public/io/blkif.h: try to fix the semantics of sector based quantities')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>

types: replace remaining uses of s32

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

While doing so switch a few adjacent types as well, for (a little bit
of) consistency.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

types: replace remaining uses of s16

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

While doing so switch an adjacent x86 struct page_info field to bool.

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

xen/x86/pvh: handle ACPI RSDT table in PVH Dom0 build

Xen always generates an XSDT table even if the firmware only provided an
RSDT table.  Copy the RSDT header from the firmware table, adjusting the
signature, for the XSDT table when not provided by the firmware.

This is necessary to run Xen on QEMU.

Fixes: 1d74282c455f ('x86: setup PVHv2 Dom0 ACPI tables')
Suggested-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

x86/HVM: drop .complete hook for intercept handling

No user of the hook exists anymore.

While touching hvm_mmio_internal() also make direction of the request
explicit - it only so happens that IOREQ_WRITE is zero. Yet it being a
write is imperative for stdvga.c to "accept" the request.

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

x86/HVM: drop stdvga's "lock" struct member

No state is left to protect. It being the last field, drop the struct
itself as well. Similarly for then ending up empty, drop the .complete
handler.

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

x86/HVM: drop stdvga's "vram_page[]" struct member

No uses are left, hence its setup, teardown, and the field itself can
also go away. stdvga_deinit() is then empty and can be dropped as well.

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

x86/HVM: drop stdvga's "{g,s}r_index" struct members

No consumers are left, hence the producer and the fields themselves can
also go away. stdvga_outb() is then useless, rendering stdvga_out()
useless as well. Hence the entire I/O port intercept can go away.

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

x86/HVM: drop stdvga's "sr[]" struct member

No consumers are left, hence the producer and the array itself can also
go away. The static sr_mask[] is then orphaned and hence needs dropping,
too.

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

x86/HVM: drop stdvga's "gr[]" struct member

No consumers are left, hence the producer and the array itself can also
go away. The static gr_mask[] is then orphaned and hence needs dropping,
too.

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

x86/HVM: remove unused MMIO handling code

All read accesses are rejected by the ->accept handler, while writes
bypass the bulk of the function body. Drop the dead code, leaving an
assertion in the read handler.

A number of other static items (and a macro) are then unreferenced and
hence also need (want) dropping. The same applies to the "latch" field
of the state structure.

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

x86/HVM: drop stdvga's "stdvga" struct member

Two of its consumers are dead (in compile-time constant conditionals)
and the only remaining ones are merely controlling debug logging. Hence
the field is now pointless to set, which in particular allows to get rid
of the questionable conditional from which the field's value was
established (afaict 551ceee97513 ["x86, hvm: stdvga cache always on"]
had dropped too much of the earlier extra check that was there, and
quite likely further checks were missing).

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

x86/HVM: properly reject "indirect" VRAM writes

While ->count will only be different from 1 for "indirect" (data in
guest memory) accesses, it being 1 does not exclude the request being an
"indirect" one. Check both to be on the safe side, and bring the ->count
part also in line with what ioreq_send_buffered() actually refuses to
handle.

Fixes: 3bbaaec09b1b ("x86/hvm: unify stdvga mmio intercept with standard mmio intercept")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

x86emul: support CMPccXADD

Unconditionally wire this through the ->rmw() hook. Since x86_emul_rmw()
now wants to construct and invoke a stub, make stub_exn available to it
via a new field in the emulator state structure.

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

automation/eclair_analysis: address violation of Rule 20.7

MISRA Rule 20.7 states:
"Expressions resulting from the expansion of macro parameters
shall be enclosed in parentheses".

The files imported from the gnu-efi package are already deviated, yet
the macro NextMemoryDescriptor is used in non-excluded code, so a further
deviation is needed to exclude also any expansion of the macro.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>

xen/bitmap: remove redundant deviations

Remove comment-based deviations since a project wide deviation that
cover such cases is present.

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

automation/eclair: update configuration of Rule 20.7

MISRA C:2012 Rule 20.7 states that "Expressions resulting from the
expansion of macro parameters shall be enclosed in parentheses".
The rational of the rule is that if a macro argument expands to an
expression, there may be problems related to operator precedence, e.g.,

define M(A, B) A * B

M(1+1, 2+2) will expand to: 1+1 * 2+2

Update ECLAIR configuration to tag as 'safe' the expansions of macro
arguments surrounded tokens '{', '}' and ';', since in their presence
problems related to operator precedence can not occur.

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

automation/eclair_analysis: deviate linker symbols for Rule 18.2

MISRA C Rule 18.2 states: "Subtraction between pointers shall
only be applied to pointers that address elements of the same array".

Subtractions between pointer where at least one symbol is a
symbol defined by the linker are safe and thus deviated, because
the compiler cannot exploit the undefined behaviour that would
arise from violating the rules in this case.

To create an ECLAIR configuration that contains the list of
linker-defined symbols, the script "linker-symbols.sh" is used
after a build of xen (without static analysis) is performed.
The generated file "linker_symbols.ecl" is then used as part of the
static analysis configuration.

Additional changes to the ECLAIR integration are:
- perform a build of xen without static analysis during prepare.sh
- run the scripts to generated ECL configuration during the prepare.sh,
  rather than analysis.sh
- export ECLAIR_PROJECT_ROOT earlier, to allow such generation

Additionally, the macro page_to_mfn performs a subtraction that is safe,
so its uses are deviated.

No functional changes.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>

automation/eclair_analysis: fix MISRA Rule 20.7 regression in self-tests.h

Prior to bd1664db7b7d ("xen/bitops: Introduce a multiple_bits_set() helper")
the definition of {COMPILE,RUNTIME}_CHECK was fully compliant with respect
to MISRA C Rule 20.7:

"Expressions resulting from the expansion of macro parameters shall be
enclosed in parentheses."

However, to allow testing function-like macros, parentheses on the "fn"
parameter were removed and thus new violations of the rule have been
introduced. Given the usefulness of this functionality,
it is deemed ok to deviate these two macros for this rule, because
their scope of (direct) usage is limited to just the file where they
are defined, and the possibility of misuses is unlikely.

No functional change.

Fixes: bd1664db7b7d ("xen/bitops: Introduce a multiple_bits_set() helper")
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

x86/hvm: allow {,un}map_pirq hypercalls unconditionally

The current hypercall interfaces to manage and assign interrupts to
domains is mostly based in using pIRQs as handlers.  Such pIRQ values
are abstract domain-specific references to interrupts.

Classic HVM domains can have access to {,un}map_pirq hypercalls if the
domain is allowed to route physical interrupts over event channels.
That's however a different interface, limited to only mapping
interrupts to itself. PVH domains on the other hand never had access
to the interface, as PVH domains are not allowed to route interrupts
over event channels.

In order to allow setting up PCI passthrough from a PVH domain it
needs access to the {,un}map_pirq hypercalls so interrupts can be
assigned a pIRQ handler that can then be used by further hypercalls to
bind the interrupt to a domain.

Note that the {,un}map_pirq hypercalls end up calling helpers that are
already used against a PVH domain in order to setup interrupts for the
hardware domain when running in PVH mode.  physdev_map_pirq() will
call allocate_and_map_{gsi,msi}_pirq() which is already used by the
vIO-APIC or the vPCI code respectively.  So the exposed code paths are
not new when targeting a PVH domain, but rather previous callers are
not hypercall but emulation based.

Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86/HVM: drop stdvga's "cache" struct member

Since 68e1183411be ("libxc: introduce a xc_dom_arch for hvm-3.0-x86_32
guests"), HVM guests are built using XEN_DOMCTL_sethvmcontext, which
ends up disabling stdvga caching because of arch_hvm_load() being
involved in the processing of the request. With that the field is
useless, and can be dropped. Drop the helper functions manipulating /
checking as well right away, but leave the use sites of
stdvga_cache_is_enabled() with the hard-coded result the function would
have produced, to aid validation of subsequent dropping of further code.

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

x86/mmcfg: address violation of MISRA C Rule 16.3

Address a violation of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".

No functional change.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86/mm: address violations of MISRA C Rule 16.3

Address violations of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".

No functional change.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86/monitor: address violation of MISRA C Rule 16.3

Address a violation of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".

No functional change.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>

x86/hypercall: address violations of MISRA C Rule 16.3

Address violations of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".

No functional change.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86/vm_event: address violation of MISRA C Rule 16.3

Address a violation of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".

No functional change.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>

x86/time: address violations of MISRA C Rule 16.3

Address violations of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".

No functional change.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86/psr: address violation of MISRA C Rule 16.3

Address a violation of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".

No functional change.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86/APIC: address violation of MISRA C Rule 21.2

The rule disallows the usage of an identifier reserved by the C standard.
All identfiers starting with '__' are reserved for any use, so the label
can be renamed in order to avoid the violation.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86/cpufreq: address MISRA Rule 7.3 violation

Rule 7.3 states:
"The lowercase character l shall not be used in a literal suffix",
but the INTEL_MSR_RANGE macro uses the "ull" suffix.
The "u" is transformed in uppercase for consistency.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

x86/time: introduce probing logic for the wallclock

Adding such probing allows to clearly separate init vs runtime code, and to
place the probing logic into the init section for the CMOS case.  Note both
the Xen shared_info page wallclock, and the EFI wallclock don't really have any
probing-specific logic.  The shared_info wallclock will always be there if
booted as a Xen guest, while the EFI_GET_TIME method probing relies on checking
if it returns a value different than 0.

The panic message printed when Xen is unable to find a viable wallclock source
has been adjusted slightly, I believe the printed guidance still provides the
same amount of information to the user.

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

x86/time: pull cmos_rtc_probe outside of function and rename

Rename cmos_rtc_probe to opt_cmos_rtc_probe in order to better describe it
being a command line option, and rename cmos_probe() function to
cmos_rtc_probe().

Also move opt_cmos_rtc_probe to being a static global variable in preparation
for further changes that will require the variable being global to the file.

No functional change intended.

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

x86/mm address violations of MISRA C:2012 Rule 5.3

This addresses violations of MISRA C:2012 Rule 5.3 which states as
following: An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope.

In /x86/mm.c the object struct e820entry *e820 hides an identifier
with the same name declared in x86/include/asm/e820.h.

No functional change.

Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

arm/gicv3: Fix ICH_VTR_EL2.ListRegs mask

According to GIC spec IHI 0069H.b (12.4.9), the ListRegs field of
ICH_VTR_EL2 can have value between 0b00000..0b01111, as there can
be maximum 16 LRs (field value + 1). Fix the mask used to extract this
value which wrongly assumes there can be 64 (case for GICv2).

Fixes: bc183a0235e0 ("xen/arm: Add support for GIC v3")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>

automation: fix xilinx test console settings

The test showed unreliable behavior due to unsupported console settings.
Update the baud rate used to connect to the UART.

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

cirrus-ci: update to FreeBSD 14.1 image

14.0 is going EOL by the end of the month.

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

x86/ucode: Utilize ucode_force and remove opt_ucode_allow_same

Pass xen-ucode flags to do low level checks on microcode version and utilize
it to allow for microcode downgrade or reapply the same version of the
microcode.  ucode_force is required to be passed to a low level Intel and AMD
for version checks to be done.

While adding ucode_force, opt_ucode_allow_same was removed.  Remove
opt_ucode_allow_same from documentation.

Update CHANGELOG.md for opt_ucode_allow_same removal.

Signed-off-by: Fouad Hilly <fouad.hilly@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

x86/cache: Drop legacy __read_mostly/__ro_after_init definitions

Lots of files were picking these up transitively, including lib.h

However, lib.h needs __read_mostly for printk_once() and this has the side
effect of kicking the transitive can down the road.

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

x86/build: Swap cache.h includes for xen/sections.h

These include {xen/asm}/cache.h but only want xen/sections.h.

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

xen/build: Drop unused includes of xen/cache.h

None of these are used, not even transitively.

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

x86/build: Rework includes in genapic/probe.c

probe.c includes a large number of headers which are unused, and not from
churn so far as I can see in history.  Strip back to a reasonable set.

One complication is that genapic.h has to include xen/cpumask.h because
there's no way to forward declare a cpumask_t.

Also strip trailing whitespace while adjusting the file.

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

x86/boot: Add missing __XEN__ definition for 32 bit code

We are compiling Xen source code so we should define __XEN__ macro.
We don't want to import all definitions from XEN_CFLAGS (as done for
other options) because most of them are processor dependent and
do not apply to 32 bit.

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

x86/boot: Optimise 32 bit C source code

The various filters are removing all optimisations.
No need to have all optimisations turned off.

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

tools/oxenstored: Switch to using the plugin for Xenctrl.domain_getinfo

Also run 'make format' on the file to reformat an adjacent block of code
correctly.

Signed-off-by: Andrii Sultanov <andrii.sultanov@cloud.com>
Acked-by: Christian Lindig <christian.lindig@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

tools/oxenstored: Load the plugin for Xenctrl.domain_getinfo

Oxenstored dynamically loads the plugin provided in ocaml/libs/xsd_glue.
The plugin is verified to be providing the specified plugin_interface
during its loading.

If a V2 of the plugin is produced, V1 will still be present, and a new
version should only be loaded if it's verified to exist
(New oxenstored can run in an environment with only V1 of the plugin).

The plugin is not switched to as of yet, the old Xenctrl stubs are still
used.

Signed-off-by: Andrii Sultanov <andrii.sultanov@cloud.com>
Acked-by: Christian Lindig <christian.lindig@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

ocaml/libs: Implement a dynamically-loaded plugin for Xenctrl.domain_getinfo

This plugin intends to hide the unstable Xenctrl interface under a
stable one. In case of the change in the interface, a V2 of this plugin
would need to be produced, but V1 with the old interface would
need to be kept (with potential change in the implementation) in the
meantime.

To reduce the need for such changes in the future, this plugin only
provides the absolute minimum functionality that Oxenstored uses - only
three fields of the domaininfo struct are used and presented here.

Oxenstored currently uses the single-domain domain_getinfo function,
whereas domain_getinfolist is a potentially more efficient option. Both
of these are provided in the plugin to allow a transition from one to
the other without modifying the interface in the future. Both return
identical structures and rely on the same fields in xenctrl, thus if one
of them breaks, both will break, and a new version of the interface
would need to be issued.

Signed-off-by: Andrii Sultanov <andrii.sultanov@cloud.com>
Acked-by: Christian Lindig <christian.lindig@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

tools/ocaml: Rationalise .gitignore

The root .gitignore is quite stale from recent (and less recent) removals, but
also fails to work for the forthcoming dynamic plugin work.

Strip all Ocaml content out of the root .gitignore, and provide a more local
.gitignore's with up-to-date patterns.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Christian Lindig <christian.lindig@cloud.com>

x86/bitops: Use the POPCNT instruction when available

It has existed in x86 CPUs since 2008, so we're only 16 years late adding
support.  With all the other scafolding in place, implement arch_hweightl()
for x86.

The only complication is that the call to arch_generic_hweightl() is behind
the compilers back.  Address this by writing it in ASM and ensure that it
preserves all registers.

Copy the code generation from generic_hweightl().  It's not a complicated
algorithm, and is easy to regenerate if needs be, but cover it with the same
unit tests as test_generic_hweightl() just for piece of mind.

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

xen/bitops: Implement hweight64() in terms of hweight{l,32}()

... and drop generic_hweight{32,64}().

This is identical on all architectures except ARM32.  Add one extra SELF_TEST
to check that hweight64() works when the input is split in half.

No functional change.

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

xen/bitops: Implement hweight32() in terms of hweightl()

... and drop generic_hweight32().

As noted previously, the only two users of hweight32() are in __init paths.

The int-optimised form of generic_hweight() is only two instructions shorter
than the long-optimised form, and even then only on architectures which lack
fast multiplication, so there's no point providing an int-optimised form.

No functional change.

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

xen/bitops: Drop the remnants of hweight{8,16}()

They are no more.  No functional change.

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

xen/bitops: Reinstate the please tidy message

Recent additions have undone prior tidying at the top of the file.

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

xen/riscv: fix type mismatch in read_atomic_size()

Correct a typo in read_atomic_size() where a 64-bit result
was incorrectly cast to a `uint32_t` instead of `uint64_t`
in the case of 8-byte reads.

Fixes: 3cd46d4ec8b9 ("xen/riscv: introduce atomic.h")
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

x86/boot: Avoid usage of global in reloc.c

All code and data from this file will go into a text section
which we want to not be writeable.

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

x86/time: split CMOS read and probe logic into function

The current logic to probe for the CMOS RTC is open-coded in get_cmos_time(),
move it to a separate function that both serves the purpose of testing for the
CMOS RTC existence and returning its value.

The goal is to be able to split the probing and the reading logic into separate
helpers, and putting the current logic in a separate function helps simplifying
further changes.

A transient *rtc_p variable is introduced as a parameter to the function, that
will be removed by further changes.  Also note that due to the code movement,
now cmos_rtc_probe will only get cleared on a second call to get_cmos_time(),
as the newly introduced cmos_probe() function doesn't modify the variable
anymore.

No functional change intended.

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

x86/time: move CMOS edge detection into read helper

Move the logic that ensures the CMOS RTC data is read just after it's been
updated into the __get_cmos_time() function that does the register reads.  This
requires returning a boolean from __get_cmos_time() to signal whether the read
has been successfully performed after an update.

Note that while __get_cmos_time() can be used without waiting for the update
edge, so far the only caller does wait for it, hence move the code inside of
the function.

The goal, albeit not accomplished by this patch, is to be able to split the
probing and the reading of the CMOS RTC data into two separate functions.

No functional change intended.

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

x86/time: introduce helper to fetch Xen wallclock when running as a guest

Move the current code in get_wallclock_time() to fetch the Xen wallclock
information from the shared page when running as a guest into a separate
helper.

No functional change intended.

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

x86/HVM: reduce recursion in linear_{read,write}()

Let's make explicit what the compiler may or may not do on our behalf:
The 2nd of the recursive invocations each can fall through rather than
re-invoking the function. This will save us from adding yet another
parameter (or more) to the function, just for the recursive invocations.

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

xen/pci: Add hypercall to support reset of pcidev

When a device has been reset on dom0 side, the Xen hypervisor
doesn't get notification, so the cached state in vpci is all
out of date compare with the real device state.

To solve that problem, add a new hypercall to support the reset
of pcidev and clear the vpci state of device. So that once the
state of device is reset on dom0 side, dom0 can call this
hypercall to notify hypervisor.

The behavior of different reset types may be different in the
future, so divide them now so that they can be easily modified
in the future without affecting the hypercall interface.

Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

x86/trampoline: Move the trampoline declarations out of <asm/config.h>

asm/config.h is included in every translation unit (via xen/config.h), while
only a handful of functions actually interact with the trampoline.

Move the infrastructure into its own header, and take the opportunity to
document everything.

Change trampoline_realmode_entry() and wakeup_start() to be nocall functions,
rather than char arrays.  Also switch to fixed width integers which are less
likely to diverge from the asm declaration.

No functional change.

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

x86/acpi: Drop acpi_video_flags and use bootsym(video_flags) directly

This removes a level of indirection, as well as removing a somewhat misleading
name; the variable is really "S3 video quirks".

More importantly however it makes it very clear that, right now, parsing the
cmdline and quirks depends on having already placed the trampoline; a
dependency which is going to be gnarly to untangle.

That said, fixing the quirk is easy.  The Toshiba Satellite 4030CDT has an
Intel Celeron 300Mhz CPU (Pentium 2 era) from 1998 when MMX was the headline
feature, sporting 64M of RAM.  Being a 32-bit processor, it hasn't been able
to run Xen for about a decade now, so drop the quirk entirely.

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

tools/ocaml: Build infrastructure for OCaml dynamic libraries

Dynamic libraries in OCaml require an additional compilation step on top
of the already specified steps for static libraries. Add an appropriate
template to Makefile.rules.

Signed-off-by: Andrii Sultanov <andrii.sultanov@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Christian Lindig <christian.lindig@cloud.com>

xen/ppc: Adjust ppc64_defconfig

All of CONFIG_SCHED_*, and CONFIG_HYPFS build fine.

Add a stub for share_xen_page_with_guest(), which is all that is necessary to
make CONFIG_TRACEBUFFER build.

No functional change.

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

x86/cpufeatures: Add new cpuid features in SPR to featureset

Upon running `xen-cpuid -v` on a host machine with Sapphire Rapids
within Dom0, there exist unrecognised features.

This patch adds these features as macros to the CPU featureset,
disabled by default.

Signed-off-by: Matthew Barnes <matthew.barnes@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

x86emul/test: use MSR constants

msr-index.h has been in use for a while, so use the identifiers it
provides in place of raw numbers plus comments.

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

x86emul: mark new "cp" local var maybe-unused

Just for the sake of the 32-bit build of the test harness. This wants
reverting once unconditional uses of the variable appear (AMX, AVX10).

Fixes: b20e3fbc3ec9 ("x86emul: introduce a struct cpu_policy * local in x86_emulate()")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

x86emul/test: fix build with gas 2.43

Drop explicit {evex} pseudo-prefixes. New gas (validly) complains when
they're used on things other than instructions. Our use was potentially
ahead of macro invocations - see simd.h's "override" macro.

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

x86/xstate: enable AMX components

These being controlled by XCR0, enabling support is relatively
straightforward. Note however that there won't be any use of them until
their dependent ISA extension CPUID flags are exposed, not the least due
to recalculate_xstate() handling the dependencies in kind of a reverse
manner.

Note that xstate_check_sizes() already covers the two new states.

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

x86: fix UP build with gcc14

The complaint is:

In file included from ././include/xen/config.h:17,
                 from <command-line>:
arch/x86/smpboot.c: In function ‘link_thread_siblings.constprop’:
./include/asm-generic/percpu.h:16:51: error: array subscript [0, 0] is outside array bounds of ‘long unsigned int[1]’ [-Werror=array-bounds=]
   16 |     (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
./include/xen/compiler.h:140:29: note: in definition of macro ‘RELOC_HIDE’
  140 |     (typeof(ptr)) (__ptr + (off)); })
      |                             ^~~
arch/x86/smpboot.c:238:27: note: in expansion of macro ‘per_cpu’
  238 |     cpumask_set_cpu(cpu2, per_cpu(cpu_sibling_mask, cpu1));
      |                           ^~~~~~~
In file included from ./arch/x86/include/generated/asm/percpu.h:1,
                 from ./include/xen/percpu.h:30,
                 from ./arch/x86/include/asm/cpuid.h:9,
                 from ./arch/x86/include/asm/cpufeature.h:11,
                 from ./arch/x86/include/asm/system.h:6,
                 from ./include/xen/list.h:11,
                 from ./include/xen/mm.h:68,
                 from arch/x86/smpboot.c:12:
./include/asm-generic/percpu.h:12:22: note: while referencing ‘__per_cpu_offset’
   12 | extern unsigned long __per_cpu_offset[NR_CPUS];
      |                      ^~~~~~~~~~~~~~~~

Which I consider bogus in the first place ("array subscript [0, 0]" vs a
1-element array). Yet taking the experience from 99f942f3d410 ("Arm64:
adjust __irq_to_desc() to fix build with gcc14") I guessed that
switching function parameters to unsigned int (which they should have
been anyway) might help. And voilà ...

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