xen/x86: drop passing include path to the assembler
The current logic to pass the non-arch include path to the assembler is no
longer required, since the .include asm macros all use full paths, the more it
was missing the arch specific include path after the move from include/ into
arch/.
This should have been part of:
762c3890c89f x86: fold indirect_thunk_asm.h into asm-defns.h
As the above change dropped the usage of .include with a header relative path.
Signed-off-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:
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:
* 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 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 (even when 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: 67e1c050e36b ('public/io/blkif.h: try to fix the semantics of sector based quantities') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Probing for the CMOS RTC registers consist in reading IO ports, and we expect
those reads to have no side effects even when the CMOS RTC is not present. Xen
already does a similar probing (reading of IO ports) by default when searching
for possible CMOS aliased locations.
Switch the default to probe for the CMOS RTC by default when ACPI FADT contains
the ACPI_FADT_NO_CMOS_RTC flag. At the same time introduce a new option that
can be used to turn off the probing: `wallclock=no-cmos-probe`. Deprecate the
previous `cmos-rtc-probe` option.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v2:
- New in this version.
x86/time: introduce command line option to select wallclock
Allow setting the used wallclock from the command line. When the option is set
to a value different than `auto` the probing is bypassed and the selected
implementation is used (as long as it's available).
The `xen` and `efi` options require being booted as a Xen guest (with Xen guest
supported built-in) or from UEFI firmware.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
****************************************
Panic on CPU 0:
FATAL PAGE FAULT
[error_code=0011]
Faulting linear address: 0000000062ccfa70
****************************************
Swap the preference to default to CMOS first, and EFI later, in an attempt to
use EFI_GET_TIME as a last resort option only. Note that Linux for example
doesn't allow calling the get_time method, and instead provides a dummy handler
that unconditionally returns EFI_UNSUPPORTED on x86-64.
Such change in the preferences requires some re-arranging of the function
logic, so that panic messages with workaround suggestions are suitably printed.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v2:
- Updated to match previous changes.
Roger Pau Monne [Tue, 27 Aug 2024 14:33:16 +0000 (16:33 +0200)]
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>
---
Changes since v2:
- New in this version.
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.
No functional change intended.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v2:
- New in this version.
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.
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>
---
Changes since v2:
- New in this version.
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>
---
Changes since v2:
- New in this version.
****************************************
Panic on CPU 1:
FATAL PAGE FAULT
[error_code=0003]
Faulting linear address: ffff82d0404011ea
****************************************
For the time being revert opt_allow_unsafe to be __read_mostly.
Fixes: bfcb0abb191f ('types: replace remaining uses of s8') Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Mon, 2 Sep 2024 09:58:21 +0000 (11:58 +0200)]
x86: drop map-low-16Mb leftovers
Prior work (e.g. cbabbc9f5659 ["x86/boot: Size the boot/directmap
mappings dynamically"]) has fully eliminated that hardcoded boundary.
Drop both the linker script assertion (the upper bound is now the stubs
area) and the artificial extending of xen.efi's image size.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Mon, 2 Sep 2024 09:57:22 +0000 (11:57 +0200)]
types: replace remaining uses of s8
... and move the type itself to linux-compat.h.
While doing so,
- convert __read_mostly to __ro_after_init for respective variables
having their type changed (for acpi_numa add the attribute anew),
- in cpuid_hypervisor_leaves() drop a cast altogether,
- switch an adjacent struct arch_irq_desc field to bool.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Mon, 2 Sep 2024 09:56:24 +0000 (11:56 +0200)]
x86: drop s<N>/u<N> overrides from mkelf32
Use uint<N>_t instead (s<N> were unused altogether). While adjusting
swap<N>() drop excessive casts and rename the arguments to avoid leading
underscores.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Add defensive return statement at the end of an unreachable
default case. Other than improve safety, this meets the requirements
to deviate a violation of MISRA C Rule 16.3: "An unconditional `break'
statement shall terminate every switch-clause".
Anthony PERARD [Fri, 30 Aug 2024 09:49:40 +0000 (09:49 +0000)]
libxl: Probe QEMU for -run-with chroot=dir and use it
QEMU 9.0 have removed "-chroot" command line option, which have been
deprecated since QEMU 8.1 in favor of "-run-with chroot=dir".
Look into the result of the QMP command "query-command-line-options"
to find out if "-run-with chroot=dir" is available. Then use it in
place of "-chroot".
Resolves: xen-project/xen#187 Signed-off-by: Anthony PERARD <anthony.perard@vates.tech> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Andrew Cooper [Wed, 28 Aug 2024 19:20:34 +0000 (20:20 +0100)]
x86/pv: Make cr4_pv32_mask be PV32-only
The user of cr4_pv32_mask (the cr4_pv32_restore() function) only exists in a
CONFIG_PV32 build, but right now the variable is unconditionally set up.
To start with, move the setup into set_in_cr4() and remove it from it's
somewhat ad-hoc position in __start_xen(). This means the variable will be
set up in two steps for a CONFIG_PV32=y build, but it's cleaner and more
robust logic overall.
With that, there's no good reason for the variable to stay in setup.c. Move
it to x86/pv/domain.c (beside opt_pv32, for want of any better place to live),
and move the declaration to beside set_in_cr4() and mmu_cr4_features which is
a better position than setup.h.
Guard the reference with CONFIG_PV32, and fix up a recent typo in an adjacent
comment while at it.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Victor Lira [Thu, 29 Aug 2024 22:34:23 +0000 (15:34 -0700)]
automation: use expect utility in xilinx tests
Fixes: 95764a0817a5 (automation: update xilinx test scripts (tty))
This patch introduced a CI failure due to a timeout in xilinx-x86_64 test.
Change xilinx-x86_64 and xilinx-arm64 scripts to use "expect" utility
to determine test result and allow early exit from tests.
Add "expect" to xilinx container environment (dockerfile).
Rename references to "QEMU" in "qemu-key.exp" expect script to "TEST" to be
used by both QEMU and hardware tests.
Signed-off-by: Victor Lira <victorm.lira@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Victor Lira [Thu, 29 Aug 2024 22:34:22 +0000 (15:34 -0700)]
automation: fix false success in qemu tests
Fix flaw in qemu-*.sh tests that producess a false success. The following
lines produces success despite the "expect" script producing nonzero exit
status:
set +e
...
./automation/scripts/qemu-key.exp | sed 's/\r\+$//'
(end of file)
The default exit status for a pipeline using "|" operator is that of the
rightmost command. Fix this by setting the "pipefail" option in the shell,
and removing "set +e" allowing the expect script to determine the result.
Signed-off-by: Victor Lira <victorm.lira@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Jan Beulich [Thu, 29 Aug 2024 08:03:53 +0000 (10:03 +0200)]
Arm64: adjust __irq_to_desc() to fix build with gcc14
With the original code I observe
In function ‘__irq_to_desc’,
inlined from ‘route_irq_to_guest’ at arch/arm/irq.c:465:12:
arch/arm/irq.c:54:16: error: array subscript -2 is below array bounds of ‘irq_desc_t[32]’ {aka ‘struct irq_desc[32]’} [-Werror=array-bounds=]
54 | return &this_cpu(local_irq_desc)[irq];
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
which looks pretty bogus: How in the world does the compiler arrive at
-2 when compiling route_irq_to_guest()? Yet independent of that the
function's parameter wants to be of unsigned type anyway, as shown by
a vast majority of callers (others use plain int when they really mean
non-negative quantities). With that adjustment the code compiles fine
again.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Michal Orzel <michal.orzel@amd.com>
Xenia Ragiadakou [Thu, 29 Aug 2024 08:02:46 +0000 (10:02 +0200)]
ioreq: do not build arch_vcpu_ioreq_completion() for non-VMX configurations
VIO_realmode_completion is specific to vmx realmode and thus the function
arch_vcpu_ioreq_completion() has actual handling work only in VMX-enabled build,
as for the rest x86 and ARM build configurations it is basically a stub.
Here a separate configuration option ARCH_VCPU_IOREQ_COMPLETION introduced that
tells whether the platform we're building for requires any specific ioreq
completion handling. As of now only VMX has such requirement, so the option is
selected by INTEL_VMX, for other configurations a generic default stub is
provided (it is ARM's version of arch_vcpu_ioreq_completion() moved to common
header).
For partial writes the non-written parts of registers are folded into
the full 64-bit value from what they're presently set to. That's wrong
to do though when the behavior is write-1-to-clear: Writes not
including to low 3 bits would unconditionally clear all ISR bits which
are presently set. Re-calculate the value to use.
Fixes: be07023be115 ("x86/vhpet: add support for level triggered interrupts") Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Thu, 29 Aug 2024 08:01:19 +0000 (10:01 +0200)]
x86emul: drop further Xeon Phi decode leftovers
Special casing in x86emul_decode() can be dropped, while overrides done
in decode_0f38() can move into ext0f38_table[]. That table's S/G
prefetch entries aren't needed anymore either.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Anthony PERARD [Thu, 29 Aug 2024 08:00:46 +0000 (10:00 +0200)]
libxl: Implement QEMU command line probe
Starting with QEMU 9.0, the option "-chroot", that we use for the
"dmrestrict" feature, is removed. We need to find out which to use
between "-chroot" and "-run-with chroot=dir".
This patch implement the machinery to spawn QEMU, and to run the QMP
command "query-command-line-options" but doesn't yet look at the
actual result. Whether or not to use "-run-with chroot=dir" will be
implemented in a follow up patch.
The command line used to spawn the qemu we want to probe is mostly
similar to the one we already use for the device model, "-machine
none" comes from libvirt.
This patch implement the probing on qemu-xen, even if we probably not
going to use the result. We could check the feature wanted for the
domain being created, but this could get complicated fairly quickly.
We already need to check the options "b_info->dm_restrict" for
"-chroot" and "state->dm_runas" for "-runas" (which is deprecated).
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Roger Pau Monne [Wed, 28 Aug 2024 11:30:44 +0000 (13:30 +0200)]
x86/dom0: disable SMAP for PV domain building only
Move the logic that disables SMAP so it's only performed when building a PV
dom0, PVH dom0 builder doesn't require disabling SMAP.
The fixes tag is to account for the wrong usage of cpu_has_smap in
create_dom0(), it should instead have used
boot_cpu_has(X86_FEATURE_XEN_SMAP). Fix while moving the logic to apply to PV
only.
While there also make cr4_pv32_mask __ro_after_init.
Fixes: 493ab190e5b1 ('xen/sm{e, a}p: allow disabling sm{e, a}p for Xen itself') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tamas K Lengyel [Wed, 28 Aug 2024 13:38:23 +0000 (09:38 -0400)]
oss-fuzz: Fix coverage runtime error
The oss-fuzz infrastructure collects runtime coverage information for debugging
and fuzzing evaluation. Currently it appears broken due to missing C files.
This is because the fuzzer's Makefile only symlinks the C files from various
locations in the Xen source tree into the build folder. These symlinks however
are gone as oss-fuzz uses separate docker containers for the build and for the
run.
Update the oss-fuzz build script to copy the required C files into the
build folder to fix this oss-fuzz specific issue.
Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Tue, 27 Aug 2024 23:33:19 +0000 (00:33 +0100)]
ARM/vgic: Fix variable shadowing in vgic_to_sgi()
for_each_set_bit() allocates its own variable intentionally as loop-scope
only. Unfortunately, this causes the inner 'i' to shadow the outer 'i', and
violates MISRA Rule 5.3.
Drop the outermost 'i' and 'vcpuid' variables, moving them into a more narrow
scope and correcting them to be unsigned which they should have been all
along. Update the printk() formatting of vcpuid to match.
Fixes: 9429f1a6c475 ("ARM/vgic: Use for_each_set_bit() in vgic_to_sgi()") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Rewrite them to be more concise and useful. Use 0x prefixes for hex, rather
than being ambiguous, and identify the problem target vCPU / mode, rather than
simply saying something was wrong.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Frediano Ziglio [Thu, 22 Aug 2024 14:00:43 +0000 (15:00 +0100)]
x86/boot: Preserve the value clobbered by the load-base calculation
Right now, Xen clobbers the value at 0xffc when performing it's load-base
calculation. We've got plenty of free registers at this point, so the value
can be preserved easily.
This fixes a real bug booting under Coreboot+SeaBIOS, where 0xffc happens to
be the cbmem pointer (e.g. Coreboot's dmesg ring, among other things).
However, there's also a better choice of memory location to use than 0xffc, as
all our supported boot protocols have a pointer to an info structure in %ebx.
Update the documentation to match.
Fixes: 1695e53851e5 ("x86/boot: Fix the boot time relocation calculations") Fixes: d96bb172e8c9 ("x86/entry: Early PVH boot code") Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Mon, 26 Aug 2024 08:33:09 +0000 (10:33 +0200)]
x86emul: drop and avoid use of BUG()
Generally it is not a good idea to use BUG() in emulator code. Even for
internal flaws we're better off returning errors to callers, rather than
crashing the system. Replace the sole remaining use and remove the
test / fuzzing harness surrogate. Put in place a declaration pleasing
the compiler when finding uses in Xen headers, while at the same time
breaking the build (at linking time) in case an active reference would
newly appear.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jiqian Chen [Mon, 26 Aug 2024 08:32:05 +0000 (10:32 +0200)]
x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0
The gsi of a passthrough device must be configured for it to be
able to be mapped into a hvm domU.
But When dom0 is PVH, the gsis may not get registered(see below
clarification), it causes the info of apic, pin and irq not be
added into irq_2_pin list, and the handler of irq_desc is not set,
then when passthrough a device, setting ioapic affinity and vector
will fail.
To fix above problem, on Linux kernel side, a new code will
need to call PHYSDEVOP_setup_gsi for passthrough devices to
register gsi when dom0 is PVH.
So, add PHYSDEVOP_setup_gsi into hvm_physdev_op for above
purpose.
Clarify two questions:
First, why the gsi of devices belong to PVH dom0 can work?
Because when probe a driver to a normal device, it uses the normal
probe function of pci device, in its callstack, it requests irq
and unmask corresponding ioapic of gsi, then trap into xen and
register gsi finally.
Callstack is(on linux kernel side) pci_device_probe->
request_threaded_irq-> irq_startup-> __unmask_ioapic->
io_apic_write, then trap into xen hvmemul_do_io->
hvm_io_intercept-> hvm_process_io_intercept->
vioapic_write_indirect-> vioapic_hwdom_map_gsi-> mp_register_gsi.
So that the gsi can be registered.
Second, why the gsi of passthrough device can't work when dom0
is PVH?
Because when assign a device to passthrough, it uses the specific
probe function of pciback, in its callstack, it doesn't install a
fake irq handler due to the ISR is not running. So that
mp_register_gsi on Xen side is never called, then the gsi is not
registered.
Callstack is(on linux kernel side) pcistub_probe->pcistub_seize->
pcistub_init_device-> xen_pcibk_reset_device->
xen_pcibk_control_isr->isr_on==0.
Jan Beulich [Mon, 26 Aug 2024 08:30:40 +0000 (10:30 +0200)]
x86/x2APIC: correct cluster tracking upon CPUs going down for S3
Downing CPUs for S3 is somewhat special: Since we can expect the system
to come back up in exactly the same hardware configuration, per-CPU data
for the secondary CPUs isn't de-allocated (and then cleared upon re-
allocation when the CPUs are being brought back up). Therefore the
cluster_cpus per-CPU pointer will retain its value for all CPUs other
than the final one in a cluster (i.e. in particular for all CPUs in the
same cluster as CPU0). That, however, is in conflict with the assertion
early in init_apic_ldr_x2apic_cluster().
Note that the issue is avoided on Intel hardware, where we park CPUs
instead of bringing them down.
Extend the bypassing of the freeing to the suspend case, thus making
suspend/resume also a tiny bit faster.
Fixes: 2e6c8f182c9c ("x86: distinguish CPU offlining from CPU removal") Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Nikola Jelic [Mon, 26 Aug 2024 08:27:53 +0000 (10:27 +0200)]
xen: PE/COFF image header
Added PE/COFF generic image header which shall be used for EFI
application format for x86/risc-v. x86 and risc-v source shall be adjusted
to use this header in following commits. pe.h header is taken over from
linux kernel with minor changes in terms of formatting and structure member comments.
Also, COFF relocation and win cert structures are ommited, since these are not relevant for Xen.
Origin: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 36e4fc57fc16 Signed-off-by: Nikola Jelic <nikola.jelic@rt-rk.com> Signed-off-by: Milan Djokic <milan.djokic@rt-rk.com> Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Victor Lira [Fri, 23 Aug 2024 22:29:04 +0000 (15:29 -0700)]
automation: update xilinx test scripts (tty)
Update serial device names from ttyUSB* to test board specific names.
Update xilinx-smoke-dom0-x86_64 with new Xen command line console options,
which are now set as Gitlab CI/CD variables. Abstract the directory where
binaries are stored. Increase the timeout to match new setup.
Signed-off-by: Victor Lira <victorm.lira@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Andrew Cooper [Wed, 19 Jun 2024 19:39:54 +0000 (20:39 +0100)]
x86/xstate: Switch back to for_each_set_bit()
In all 3 examples, we're iterating over a scaler. They have an upper bound of
63 which is to exclude the top bit; the COMPRESSED bit.
recalculate_xstate() calculates xstates directly and doesn't set the
COMPRESSED bit. Both xstate_{un,}compressed_size() take architectural
register values, neither of which permit the COMPRESSED bit either.
xstate_uncompressed_size() has an ASSERT() covering this properly; add a
equivelent ASSERT() to xstate_compressed_size() too.
This alone produces:
add/remove: 0/0 grow/shrink: 0/4 up/down: 0/-161 (-161)
Function old new delta
compress_xsave_states 66 58 -8
xstate_uncompressed_size 119 71 -48
xstate_compressed_size 124 76 -48
recalculate_xstate 347 290 -57
where xstate_{un,}compressed_size() have practically halved in size despite
being small before.
The change in compress_xsave_states() is unexpected. The function is almost
entirely dead code, and within what remains there's a smaller stack frame. I
suspect it's leftovers that the optimiser couldn't fully discard.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Wed, 19 Jun 2024 14:46:47 +0000 (15:46 +0100)]
xen/bitops: Introduce for_each_set_bit()
The prior version (renamed to bitmap_for_each()) was inefficeint when used
over a scalar, but this is the more common usage even before accounting for
the many opencoded forms.
Introduce a new version which operates on scalars only and does so without
spilling them to memory. This in turn requires the addition of a type-generic
form of ffs().
Add testing for the new construct alongside the ffs/fls testing.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Tue, 18 Jun 2024 22:23:11 +0000 (23:23 +0100)]
xen/bitops: Rename for_each_set_bit() to bitmap_for_each()
The current implementation wants to take an in-memory bitmap. However, all
ARM callers and all-but-1 x86 callers spill a scalar to the stack in order to
use the "generic arbitrary bitmap" helpers under the hood.
This works, but is far from ideal.
Rename the construct and move it into bitmap.h, because having an iterator for
an arbitrary bitmap is a useful thing.
This will allow us to re-implement for_each_set_bit() to be more appropriate
for scalar values.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Michal Orzel <michal.orzel@amd.com>
Andrew Cooper [Fri, 23 Aug 2024 10:37:35 +0000 (11:37 +0100)]
tools/ocaml: Fix the version embedded in META files
Xen 4.1 is more than a decade stale now. Use the same mechanism as elsewhere
in the tree to get the current version number.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Christian Lindig <christian.lindig@cloud.com> Reviewed-by: Edwin Török <edwin.torok@cloud.com>
Andrew Cooper [Fri, 23 Aug 2024 10:18:25 +0000 (11:18 +0100)]
tools/ocaml: Drop the o= variable
This hides a shell redirection which is quite rude. It also opencodes
$(move-if-changed) without the benefit of short-circuiting dependent logic
when the content hasn't changed.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Christian Lindig <christian.lindig@cloud.com> Reviewed-by: Edwin Török <edwin.torok@cloud.com>
Andrew Cooper [Fri, 23 Aug 2024 09:52:41 +0000 (10:52 +0100)]
tools/ocaml: Drop the OCAMLOPTFLAG_G invocation
These days, `ocamlopt -h` asks you whether you meant --help instead, meaning
that the $(shell ) invocation here isn't going end up containing '-g'.
Make it unconditional, like it is in OCAMLCFLAGS already.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Christian Lindig <christian.lindig@cloud.com> Reviewed-by: Edwin Török <edwin.torok@cloud.com>
Andrii Sultanov [Thu, 22 Aug 2024 09:06:05 +0000 (10:06 +0100)]
tools/ocaml: Fix OCaml libs rules
This has been sat in the XenServer patchqueue for more than a decade.
Signed-off-by: Andrii Sultanov <andrii.sultanov@cloud.com> Acked-by: Christian Lindig <christian.lindig@cloud.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrii Sultanov [Thu, 22 Aug 2024 09:06:02 +0000 (10:06 +0100)]
tools/ocaml: Remove '-cc $(CC)' from OCAMLOPTFLAGS
This option does not work as one might expect, and needs to be the full
compiler invocation including linking arguments to operate correctly.
See https://github.com/ocaml/ocaml/issues/12284 for more details.
Signed-off-by: Andrii Sultanov <andrii.sultanov@cloud.com> Acked-by: Christian Lindig <christian.lindig@cloud.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Fri, 23 Aug 2024 07:13:07 +0000 (09:13 +0200)]
x86emul: convert op_bytes/opc checks in SIMD emulation
Raising #UD for an internal shortcoming of the emulator isn't quite
right. Similarly BUG() is bigger a hammer than needed.
Switch to using EXPECT() instead. This way even for insns not covered by
the test harness fuzzers will have a chance of noticing issues, should
any still exist or new ones be introduced.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Fri, 23 Aug 2024 07:12:24 +0000 (09:12 +0200)]
x86emul: set (fake) operand size for AVX512CD broadcast insns
Back at the time I failed to pay attention to op_bytes still being zero
when reaching the respective case block: With the ext0f38_table[]
entries having simd_packed_int, the defaulting at the bottom of
x86emul_decode() won't set the field to non-zero for F3-prefixed insns.
Fixes: 37ccca740c26 ("x86emul: support AVX512CD insns") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Fri, 23 Aug 2024 07:11:15 +0000 (09:11 +0200)]
x86emul: always set operand size for AVX-VNNI-INT8 insns
Unlike for AVX-VNNI-INT16 I failed to notice that op_bytes may still be
zero when reaching the respective case block: With the ext0f38_table[]
entries having simd_packed_int, the defaulting at the bottom of
x86emul_decode() won't set the field to non-zero for F3- or F2-prefixed
insns.
Fixes: 842acaa743a5 ("x86emul: support AVX-VNNI-INT8") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
After commit c36efb7fcea6 ("automation: use expect to run QEMU") we lost
the \r filtering introduced by b576497e3b7d ("automation: remove CR
characters from serial output"). This patch reintroduced it.
Fixes: c36efb7fcea6 ("automation: use expect to run QEMU") Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Michal Orzel [Wed, 14 Aug 2024 09:43:03 +0000 (11:43 +0200)]
xen/arm: head: Do not pass physical offset to start_xen
Given no further use in C world of boot_phys_offset, drop it from the
argument list of start_xen() and do the necessary changes in the startup
code head.S (most notably modifying launch not to expect 2 arguments to
pass to C entry point).
Both on arm64 and arm32, phys offset (stored in x20 or r10 respectively)
is still needed, so that it can be used in e.g. create_table_entry,
therefore keep it on the list of common register usage.
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Acked-by: Julien Grall <jgrall@amazon.com>
Michal Orzel [Wed, 14 Aug 2024 09:43:02 +0000 (11:43 +0200)]
xen/arm: Drop {boot_}phys_offset usage
boot_phys_offset stores the physical offset (PA-VA), is calculated in
the startup head.S code and passed to start_xen() as a first argument.
There is no point in using it given that we can ask MMU to translate
a VA for us using e.g. virt_to_{mfn,maddr}. Drop usage of these
variables from the C world.
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Acked-by: Julien Grall <jgrall@amazon.com>
Julien Grall [Wed, 14 Aug 2024 21:00:54 +0000 (22:00 +0100)]
xen/arm64: Hide FEAT_SME
Newer hardware may support FEAT_SME. Xen doesn't have any knowledge but
it will still expose the feature to the VM. If the OS is trying to use
SME, then it will crash.
update_boot_mapping() invokes update_identity_mapping() for the MMU specific
code.
Later when the MPU code is added, update_boot_mapping() will invoke the
equivalent.
The common code now invokes update_boot_mapping() instead of
update_identity_mapping(). So, that there is clear abstraction between the
common and MMU/MPU specific logic.
This is in continuation to commit f661a20aa880: "Extract MMU-specific MM code".
update_identity_mapping() is now marked as static as it is called from
xen/arch/arm/arm64/mmu/mm.c only. Also, amend the prototype to
update_boot_mapping() which is now invoked from other files.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Amneesh Singh [Tue, 20 Aug 2024 08:22:03 +0000 (13:52 +0530)]
drivers: char: omap-uart: provide a default clock frequency
Quite a few TI K3 devices do not have clock-frequency specified in their
respective UART nodes. However hard-coding the frequency is not a
solution as the function clock input can differ between SoCs. So, use a
default frequency of 48MHz, which is the same as the linux default (see
8250_omap.c), if the device tree does not specify it.
Signed-off-by: Amneesh Singh <a-singh21@ti.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Andrew Cooper [Thu, 15 Aug 2024 12:18:08 +0000 (13:18 +0100)]
x86/pv: Address Coverity complaint in check_guest_io_breakpoint()
Commit 08aacc392d86 ("x86/emul: Fix misaligned IO breakpoint behaviour in PV
guests") caused a Coverity INTEGER_OVERFLOW complaint based on the reasoning
that width could be 0.
It can't, but digging into the code generation, GCC 8 and later (bisected on
godbolt) choose to emit a CSWITCH lookup table, and because the range (bottom
2 bits clear), it's a 16-entry lookup table.
So Coverity is understandable, given that GCC did emit a (dead) logic path
where width stayed 0.
Rewrite the logic. Introduce x86_bp_width() which compiles to a single basic
block, which replaces the switch() statement. Take the opportunity to also
make start and width be loop-scope variables.
No practical change, but it should compile better and placate Coverity.
Fixes: 08aacc392d86 ("x86/emul: Fix misaligned IO breakpoint behaviour in PV guests")
Coverity-ID: 1616152 Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Thu, 24 May 2018 11:39:00 +0000 (12:39 +0100)]
x86/pv: Fix merging of new status bits into %dr6
All #DB exceptions result in an update of %dr6, but this isn't captured in
Xen's handling, and is buggy just about everywhere.
To begin resolving this issue, add a new pending_dbg field to x86_event
(unioned with cr2 to avoid taking any extra space, adjusting users to avoid
old-GCC bugs with anonymous unions), and introduce pv_inject_DB() to replace
the current callers using pv_inject_hw_exception().
Push the adjustment of v->arch.dr6 into pv_inject_event(), and use the new
x86_merge_dr6() rather than the current incorrect logic.
A key property is that pending_dbg is taken with positive polarity to deal
with RTM/BLD sensibly. Most callers pass in a constant, but callers passing
in a hardware %dr6 value need to XOR the value with X86_DR6_DEFAULT to flip to
positive polarity.
This fixes the behaviour of the breakpoint status bits; that any left pending
are generally discarded when a new #DB is raised. In principle it would fix
RTM/BLD too, except PV guests can't turn these capabilities on to start with.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Mon, 28 May 2018 14:20:18 +0000 (15:20 +0100)]
x86/pv: Introduce x86_merge_dr6() and fix do_debug()
Pretty much everywhere in Xen the logic to update %dr6 when injecting #DB is
buggy. Introduce a new x86_merge_dr6() helper, and start fixing the mess by
adjusting the dr6 merge in do_debug(). Also correct the comment.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Mon, 19 Aug 2024 13:32:31 +0000 (15:32 +0200)]
x86emul: correct #UD check for AVX512-FP16 complex multiplications
avx512_vlen_check()'s argument was inverted, while the surrounding
conditional wrongly forced the EVEX.L'L check for the scalar forms when
embedded rounding was in effect.
Fixes: d14c52cba0f5 ("x86emul: handle AVX512-FP16 complex multiplication insns") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Wed, 14 Aug 2024 13:40:30 +0000 (15:40 +0200)]
xvmalloc: please Misra C:2012 Rule 8.2
The cloning from xmalloc.h happened long before Misra work started in
earnest, leading to the missing parameter name having been overlooked
later on.
Fixes: 9102fcd9579f ("mm: introduce xvmalloc() et al and use for grant table allocations") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Michal Orzel <michal.orzel@amd.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Wed, 14 Aug 2024 13:40:06 +0000 (15:40 +0200)]
x86emul: don't call ->read_segment() with x86_seg_none
LAR, LSL, VERR, and VERW emulation involve calling protmode_load_seg()
with x86_seg_none. The fuzzer's read_segment() hook function has an
assertion which triggers in this case. Calling the hook function,
however, makes little sense for those insns, as there's no data to
retrieve. Instead zero-filling the output structure is what properly
corresponds to those insns being invoked with a NUL selector.
While there also add a related comment at the VERR/VERW call site.
Fixes: 06a3b8cd7ad2 ("x86emul: support LAR/LSL/VERR/VERW") Link: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=70918 Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Stefano Stabellini <stefano.stabellini@amd.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Roger Pau Monné [Wed, 14 Aug 2024 13:39:26 +0000 (15:39 +0200)]
x86/spec-ctrl: initialize per-domain XPTI in spec_ctrl_init_domain()
XPTI being a speculation mitigation feels better to be initialized in
spec_ctrl_init_domain().
No functional change intended, although the call to spec_ctrl_init_domain() in
arch_domain_create() needs to be moved ahead of pv_domain_initialise() for
d->->arch.pv.xpti to be correctly set.
Move it ahead of most of the initialization functions, since
spec_ctrl_init_domain() doesn't depend on any member in the struct domain being
set.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Wed, 14 Aug 2024 06:50:14 +0000 (08:50 +0200)]
libxl/disk: avoid aliasing of abs()
Tool chains with -Wshadow enabled by default won't like the function
parameter name "abs", for aliasing stdlib.h's abs(). Rename the
parameter to what other similar functions use.
Fixes: a18b50614d97 ("libxl: Enable stubdom cdrom changing") Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com> Acked-by: Anthony PERARD <anthony.perard@vates.tech>
Jan Beulich [Wed, 14 Aug 2024 06:47:58 +0000 (08:47 +0200)]
mm: introduce xvmalloc() et al and use for grant table allocations
All of the array allocations in grant_table_init() can exceed a page's
worth of memory, which xmalloc()-based interfaces aren't really suitable
for after boot. We also don't need any of these allocations to be
physically contiguous. Introduce interfaces dynamically switching
between xmalloc() et al and vmalloc() et al, based on requested size,
and use them instead.
All the wrappers in the new header are cloned mostly verbatim from
xmalloc.h, with the sole adjustment to switch unsigned long to size_t
for sizes and to unsigned int for alignments, and with the cloning of
x[mz]alloc_bytes() avoided. The exception is xvmemdup(), where the
const related comment on xmemdup() is actually addressed and hence
dropped.
While adjusting grant_table_destroy() also move ahead the clearing of
the struct domain field.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Julien Grall <jgrall@amazon.com>
Use expect to invoke QEMU so that we can terminate the test as soon as
we get the right string in the output instead of waiting until the
final timeout.
For timeout, instead of an hardcoding the value, use a Gitlab CI
variable "QEMU_TIMEOUT" that can be changed depending on the latest
status of the Gitlab CI runners.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Julien Grall [Tue, 6 Aug 2024 12:48:15 +0000 (13:48 +0100)]
xen/arm64: entry: Actually skip do_trap_*() when an SError is triggered
For SErrors, we support two configurations:
* Every SErrors will result to a panic in Xen
* We will forward SErrors triggered by a VM back to itself
For the latter case, we want to skip the call to do_trap_*() because the PC
was already adjusted.
However, the alternative used to decide between the two configurations
is inverted. This would result to the VM corrupting itself if:
* x19 is non-zero in the panic case
* advance PC too much in the second case
Solve the issue by switch from alternative_if to alternative_if_not.
Fixes: a458d3bd0d25 ("xen/arm: entry: Ensure the guest state is synced when receiving a vSError") Signed-off-by: Julien Grall <jgrall@amazon.com>
Jan Beulich [Tue, 13 Aug 2024 11:49:39 +0000 (13:49 +0200)]
Arm: correct FIXADDR_TOP
While reviewing a RISC-V patch cloning the Arm code, I noticed an
off-by-1 here: FIX_PMAP_{BEGIN,END} being an inclusive range and
FIX_LAST being the same as FIX_PMAP_END, FIXADDR_TOP cannot derive from
FIX_LAST alone, or else the BUG_ON() in virt_to_fix() would trigger if
FIX_PMAP_END ended up being used.
While touching this area also add a check for fixmap and boot FDT area
to not only not overlap, but to have at least one (unmapped) page in
between.
Fixes: 4f17357b52f6 ("xen/arm: add Persistent Map (PMAP) infrastructure") Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Jan Beulich [Tue, 13 Aug 2024 14:41:25 +0000 (16:41 +0200)]
x86emul: fix UB multiplications in S/G handling
The conversion of the shifts to multiplications by the commits tagged
below still wasn't quite right: The multiplications (of signed values)
can overflow, too. As of 298556c7b5f8 ("x86emul: correct 32-bit address
handling for AVX2 gathers") signed multiplication wasn't necessary
anymore, though: The necessary sign-extension (if any) will happen as
well when using intermediate variables of unsigned long types, and
excess address bits are chopped off by truncate_ea().
Fixes: b6a907f8c83d ("x86emul: replace UB shifts") Fixes: 21de9680eb59 ("x86emul: replace further UB shifts")
Oss-fuzz: 71138 Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Oleksii Kurochko [Tue, 13 Aug 2024 14:39:43 +0000 (16:39 +0200)]
xen/riscv: enable CONFIG_HAS_DEVICE_TREE
Enable build of generic functionality for working with device
tree for RISC-V.
Also, a collection of functions for parsing memory map and other
boot information from a device tree are available now.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Acked-by: Jan Beulich <jbeulich@suse.com>
hvmloader's cpuid() implementation deviates from Xen's in that the value
passed on ecx is unspecified. This means that when used on leaves that
implement subleaves it's unspecified which one you get; though it's more
than likely an invalid one.
Import Xen's implementation so there are no surprises.
Fixes: 318ac791f9f9 ("Add utilities needed for SMBIOS generation to hvmloader") Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Sergiy Kibrik [Tue, 13 Aug 2024 14:38:40 +0000 (16:38 +0200)]
x86/vmx: guard access to cpu_has_vmx_* in common code
There're several places in common code, outside of arch/x86/hvm/vmx,
where cpu_has_vmx_* get accessed without checking whether VMX supported first.
These macros rely on global variables defined in vmx code, so when VMX support
is disabled accesses to these variables turn into build failures.
To overcome these failures, build-time check is done before accessing global
variables, so that DCE would remove these variables.
Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> Acked-by: Paul Durrant <paul@xen.org> Acked-by: Jan Beulich <jbeulich@suse.com>
Oleksii Kurochko [Tue, 13 Aug 2024 14:38:15 +0000 (16:38 +0200)]
xen/riscv: enable GENERIC_BUG_FRAME
Enable GENERIC_BUG_FRAME to support BUG(), WARN(), ASSERT,
and run_in_exception_handler().
"UNIMP" is used for BUG_INSTR, which, when macros from <xen/bug.h>
are used, triggers an exception with the ILLEGAL_INSTRUCTION cause.
This instruction is encoded as a 2-byte instruction when
CONFIG_RISCV_ISA_C is enabled: ffffffffc0046ba0: 0000 unimp
and is encoded as a 4-byte instruction when CONFIG_RISCV_ISA_C
ins't enabled: ffffffffc005a460: c0001073 unimp
Using 'ebreak' as BUG_INSTR does not guarantee proper handling of macros
from <xen/bug.h>. If a debugger inserts a breakpoint (using the 'ebreak'
instruction) at a location where Xen already uses 'ebreak', it
creates ambiguity. Xen cannot distinguish whether the 'ebreak'
instruction is inserted by the debugger or is part of Xen's own code.
Remove BUG_INSN_32 and BUG_INSN_16 macros as they encode the ebreak
instruction, which is no longer used for BUG_INSN.
Update the comment above the definition of INS_LENGTH_MASK as instead of
'ebreak' instruction 'unimp' instruction is used.
<xen/lib.h> is included for the reason that panic() and printk() are
used in common/bug.c and RISC-V fails if it is not included.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Tue, 13 Aug 2024 14:37:25 +0000 (16:37 +0200)]
x86/pass-through: documents as security-unsupported when sharing resources
When multiple devices share resources and one of them is to be passed
through to a guest, security of the entire system and of respective
guests individually cannot really be guaranteed without knowing
internals of any of the involved guests. Therefore such a configuration
cannot really be security-supported, yet making that explicit was so far
missing.
This is XSA-461 / CVE-2024-31146.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com>
Teddy Astie [Tue, 13 Aug 2024 14:36:40 +0000 (16:36 +0200)]
x86/IOMMU: move tracking in iommu_identity_mapping()
If for some reason xmalloc() fails after having mapped the reserved
regions, an error is reported, but the regions remain mapped in the P2M.
Similarly if an error occurs during set_identity_p2m_entry() (except on
the first call), the partial mappings of the region would be retained
without being tracked anywhere, and hence without there being a way to
remove them again from the domain's P2M.
Move the setting up of the list entry ahead of trying to map the region.
In cases other than the first mapping failing, keep record of the full
region, such that a subsequent unmapping request can be properly torn
down.
To compensate for the potentially excess unmapping requests, don't log a
warning from p2m_remove_identity_entry() when there really was nothing
mapped at a given GFN.
This is XSA-460 / CVE-2024-31145.
Fixes: 2201b67b9128 ("VT-d: improve RMRR region handling") Fixes: c0e19d7c6c42 ("IOMMU: generalize VT-d's tracking of mapped RMRR regions") Signed-off-by: Teddy Astie <teddy.astie@vates.tech> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
The Yocto jobs take a long time to run. We are changing Gitlab ARM64
runners and the new runners might not be able to finish the Yocto jobs
in a reasonable time.
For now, disable the Yocto jobs by turning them into "manual" trigger
(they need to be manually executed.)
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
docs: Introduce Fusa Requirement and define maintainers
The FUSA folder is expected to contain requirements and other documents
to enable safety certification of Xen hypervisor.
Added a intro to explain how the requirements are categorized, written
and their supported status.
Also, added index.rst for inclusion in build docs.
Jan Beulich [Thu, 8 Aug 2024 11:27:25 +0000 (13:27 +0200)]
x86emul: adjust 2nd param of idiv_dbl()
-LONG_MIN cannot be represented in a long and hence is UB, for being one
larger than LONG_MAX.
The caller passing an unsigned long and the 1st param also being (array
of) unsigned long, change the 2nd param accordingly while adding the
sole necessary cast. This was the original form of the function anyway.
Jan Beulich [Thu, 8 Aug 2024 11:26:38 +0000 (13:26 +0200)]
x86emul: avoid UB shift in AVX512 VPMOV* handling
For widening and narrowing moves, operand (vector) size is calculated
from a table. This calculation, for the AVX512 cases, lives ahead of
validation of EVEX.L'L (which cannot be 3 without raising #UD). Account
for the later checking by adjusting the constants in the expression such
that even EVEX.L'L == 3 will yield a non-UB shift (read: shift count
reliably >= 0).
Fixes: 3988beb08 ("x86emul: support AVX512{F,BW} zero- and sign-extending moves")
Oss-fuzz: 70914 Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
automation: fix eclair gitlab jobs for merge requests
The "eclair" script calls action_push.sh even for merge request, while
instead action_pull_request.sh should be called, resulting in a job
failure with this error:
Unexpected event pull_request
Fix the script to call action_pull_request.sh appropriately.
Non-PCI platform devices may use the ITS. Dom0 Linux drivers for such
devices are failing to register IRQs due to a missing #msi-cells
property. Add the missing #msi-cells property.
projects / people / royger / xen.git / log