... rather than opencoding locally. With this, defs.h is empty so delete it.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This is marginally more efficient, but is mostly to get rid of the use of
stdcall in cmdline.c and reloc.c
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
... rather than opencoding locally.
This involve collecting various macros scattered around Xen (min()/max()
macros from kernel.h, and _p() from lib.h) and moving them into macros.h
In reloc.c, replace ALIGN_UP() with ROUNDUP().
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
... rather than opencoding locally. This also covers NULL and *_MAX.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Most of Xen is build using -nostdinc and a fully specified include path.
However, the makefile line:
$(head-bin-objs): XEN_CFLAGS := $(CFLAGS_x86_32) -fpic
discards XEN_CFLAGS and replaces them with CFLAGS_x86_32.
Reinstate -nostdinc, and copy the -include and all -I arguments from
XEN_CFLAGS.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Despite its name, libxl_xen_console_read_line() does not read a line,
it fills the buffer with as many characters as fit. Update the
documentation to reflect the real behaviour of the function. Rename
line_r to avoid confusion since it is a pointer to an array of
characters.
Signed-off-by: Javi Merino <javi.merino@cloud.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
When reading the console, xen overwrites the contents of the buffer,
so there is no need to zero the buffer before passing it to xen.
Instead, add a NULL at the end of the buffer.
While we are at it, change the zalloc() of the buffer back to
malloc() as it was before bdf4131 (libxl: don't leak buf in
libxl_xen_console_read_start error handling, 2013-12-03). The comment
in that commit message says that the intent of the commit was to
change malloc+memset to zalloc(), but only for the
libxl_xen_console_reader struct, not for the buffer.
Signed-off-by: Javi Merino <javi.merino@cloud.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
When built with ASAN, "xl dmesg" crashes in the "printf("%s", line)"
call in main_dmesg(). ASAN reports a heap buffer overflow: an
off-by-one access to cr->buffer.
The readconsole sysctl copies up to count characters into the buffer,
but it does not add a null character at the end. Despite the
documentation of libxl_xen_console_read_line(), line_r is not
nul-terminated if 16384 characters were copied to the buffer.
Fix this by asking xc_readconsolering() to fill the buffer up to size
- 1. As the number of characters in the buffer is only needed in
libxl_xen_console_read_line(), make it a local variable there instead
of part of the libxl__xen_console_reader struct.
Fixes: 4024bae739 ("xl: Add subcommand 'xl dmesg'")
Reported-by: Edwin Török <edwin.torok@cloud.com>
Signed-off-by: Javi Merino <javi.merino@cloud.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Making opt_allow_unsafe read only after init requires changes to the logic in
init_amd(), otherwise the following #PF happens on CPU hotplug:
----[ Xen-4.20.0-1-d x86_64 debug=y Tainted: H ]----
CPU: 1
RIP: e008:[<ffff82d040291081>] arch/x86/cpu/amd.c#init_amd+0x37f/0x993
[...]
Xen call trace:
[<ffff82d040291081>] R arch/x86/cpu/amd.c#init_amd+0x37f/0x993
[<ffff82d040291fbe>] F identify_cpu+0x2d4/0x4db
[<ffff82d04032eeaa>] F start_secondary+0x22e/0x3cf
[<ffff82d040203327>] F __high_start+0x87/0xa0
Pagetable walk from ffff82d0404011ea:
L4[0x105] = 000000006fc2e063 ffffffffffffffff
L3[0x141] = 000000006fc2b063 ffffffffffffffff
L2[0x002] = 000000807c7ca063 ffffffffffffffff
L1[0x001] = 800000006f801121 ffffffffffffffff
****************************************
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: bfcb0abb19 ('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>
Prior work (e.g. cbabbc9f56 ["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>
... 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>
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".
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
"-runas" is deprecated since QEMU 9.1 and will be remove in a future
release.
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
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>
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>
Fixes: 95764a0817 (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>
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>
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>
Provide the user with configuration control over the cpu virtualization support
in Xen by making AMD_SVM and INTEL_VMX options user selectable.
To preserve the current default behavior, both options depend on HVM and
default to value of HVM.
To prevent users from unknowingly disabling virtualization support, make the
controls user selectable only if EXPERT is enabled.
No functional change intended.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
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).
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
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: be07023be1 ("x86/vhpet: add support for level triggered interrupts")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
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>
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>
Update ECLAIR configuration to deviate more cases where an
unintentional fallthrough cannot happen.
Tag Rule 16.3 as clean for arm.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
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: 493ab190e5 ('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>
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>
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: 9429f1a6c4 ("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>
The existing expression is just a very complicated way of expressing a loop
over all bits of target->list. Simplify the expression.
While here, fix the two gprintk()'s. Because of a quotes vs line continuation
issue, there's a line of spaces in the middle of the format string.
$ strings xen-syms-arm32 | grep -e VGIC -e GICD_SGIR
<G><1>%pv VGIC: write r=%08x target->list=%hx, wrong CPUTargetList
<G><1>%pv vGICD:unhandled GICD_SGIR write %08x with wrong mode
not to mention trailing whitespace too.
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>
... which is better optimised for scalar values, rather than using the
arbitrary-sized bitmap helpers.
Additionally, unlike other vgic helpers, this takes both a domain and vcpu
pointer. The domain parameter isn't used, and the callers pass v->domain.
Strip out the domain pointer.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
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: 1695e53851 ("x86/boot: Fix the boot time relocation calculations")
Fixes: d96bb172e8 ("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>
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>
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.
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>
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: 2e6c8f182c ("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>
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>
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>
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>
... which is better optimised for scalar values, rather than using the
arbitrary-sized bitmap helpers.
For ARM32:
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-16 (-16)
Function old new delta
vgic_set_irqs_pending 284 268 -16
including removing calls to _find_{first,next}_bit_le(), and two stack-spilled
words too.
For ARM64:
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-40 (-40)
Function old new delta
vgic_set_irqs_pending 268 228 -40
including removing three calls to find_next_bit().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
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>
... and use it in self-tests.h.
This is intended to replace constructs such as __bitop_bad_size(). It
produces a better diagnostic, and is MISRA-friendly.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
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>
Introduce a --force option to xen-ucode, in order to bypass certain checks
when applying microcode.
Update libxc's xc_microcode_update() to take an extra parameter, and to use
the new XENPF_microcode_update2 hypercall instead.
Signed-off-by: Fouad Hilly <fouad.hilly@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Use getopt_long() to handle command line arguments.
Introduce ext_err for common errors exit.
Signed-off-by: Fouad Hilly <fouad.hilly@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
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
Javi Merino
Roger Pau Monné
Frediano Ziglio
Jan Beulich
Federico Serafini
Anthony PERARD
Victor Lira
Xenia Ragiadakou
Anthony PERARD
Tamas K Lengyel
Jiqian Chen
Nikola Jelic
Fouad Hilly