automation: wait for the login prompt as test end marker
The login prompt is printed after all the startup (test) scripts, wait
for that instead of "passed" marker. And only then check if test passed.
Before this patch there was a race: "passed" marker could be already
printed, but the final check would fail because login prompt wasn't
there yet.
Also, modify etc/issue in domU rootfs to avoid confusing the one from
domU with the dom0's one. Use the dom0 one as test end marker.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
xen/misra: xen-analysis.py: fix return error on PhaseExceptions
Currently the script return code is 0 even if an exception is
found, because the return code is written only if the exception
object has the errorcode member.
Fix the issue returning the errorcode member in case it exists,
otherwise use a generic value different from 0.
Fixes: 02b26c02c7c4 ("xen/scripts: add cppcheck tool to the xen-analysis.py script") Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Olaf Hering [Wed, 26 Apr 2023 10:52:39 +0000 (10:52 +0000)]
stubdom: fix errors in newlib:makedoc
rpm post-build-checks found a few code bugs in newlib, and marks them as
errors. Add another newlib patch and apply it during stubdom build.
[ 227s] ../../../../newlib-1.16.0/newlib/doc/makedoc.c: In function 'lookup_word':
[ 227s] ../../../../newlib-1.16.0/newlib/doc/makedoc.c:1147:10: warning: implicit declaration of function 'strcmp' [-Wimplicit-function-declaration]
[ 227s] if (strcmp(ptr->word, word) == 0) return ptr;
[ 227s] ^
[ 460s] I: Program is using implicit definitions of special functions.
[ 460s] these functions need to use their correct prototypes to allow
[ 460s] the lightweight buffer overflow checking to work.
[ 460s] - Implicit memory/string functions need #include <string.h>.
[ 460s] - Implicit *printf functions need #include <stdio.h>.
[ 460s] - Implicit *printf functions need #include <stdio.h>.
[ 460s] - Implicit *read* functions need #include <unistd.h>.
[ 460s] - Implicit *recv* functions need #include <sys/socket.h>.
[ 460s] E: xen implicit-fortify-decl ../../../../newlib-1.16.0/newlib/doc/makedoc.c:1147
Signed-off-by: Olaf Hering <olaf@aepfle.de> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Olaf Hering [Wed, 26 Apr 2023 10:51:56 +0000 (10:51 +0000)]
stubdom: fix errors in newlib:cygmon-gmon.c
rpm post-build-checks found a few code bugs in newlib, and marks them as
errors. Add another newlib patch and apply it during stubdom build.
I: A function uses a 'return;' statement, but has actually a value
to return, like an integer ('return 42;') or similar.
W: xen voidreturn ../../../../newlib-1.16.0/libgloss/i386/cygmon-gmon.c:117, 125, 146, 157, 330
I: Program is using implicit definitions of special functions.
these functions need to use their correct prototypes to allow
the lightweight buffer overflow checking to work.
- Implicit memory/string functions need #include <string.h>.
- Implicit *printf functions need #include <stdio.h>.
- Implicit *printf functions need #include <stdio.h>.
- Implicit *read* functions need #include <unistd.h>.
- Implicit *recv* functions need #include <sys/socket.h>.
E: xen implicit-fortify-decl ../../../../newlib-1.16.0/libgloss/i386/cygmon-gmon.c:119
I: Program returns random data in a function
E: xen no-return-in-nonvoid-function ../../../../newlib-1.16.0/libgloss/i386/cygmon-gmon.c:362
Signed-off-by: Olaf Hering <olaf@aepfle.de> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Jason Andryuk [Tue, 25 Apr 2023 19:46:22 +0000 (15:46 -0400)]
libxl: Print device_kind as a string
Printing the integer isn't particularly informative. Switch to a
human-readable string when printing the device_kind in
libxl__get_hotplug_script_info().
Signed-off-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Juergen Gross <jgross@suse.com>
Olaf Hering [Wed, 19 Apr 2023 11:00:26 +0000 (11:00 +0000)]
tools: ipxe: update for fixing build with GCC12
Use a snapshot which includes commit b0ded89e917b48b73097d3b8b88dfa3afb264ed0 ("[build] Disable dangling
pointer checking for GCC"), which fixes build with gcc12.
Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Roger Pau Monne [Mon, 20 Mar 2023 11:08:52 +0000 (12:08 +0100)]
x86/shadow: restore dropped check in sh_unshadow_for_p2m_change()
As a result of 241702e064604dbb3e0d9b731aa8f45be448243b the
mfn_valid() check in sh_unshadow_for_p2m_change() was lost. That
allows sh_remove_shadows() to be called with gfns that have no backing
page, causing an ASSERT to trigger in debug builds or dereferencing an
arbitrary pointer partially under guest control in non-debug builds:
****************************************
Panic on CPU 1:
Assertion 'mfn_valid(gmfn)' failed at arch/x86/mm/shadow/common.c:2203
****************************************
Fix this by restoring the mfn_valid() check in
sh_unshadow_for_p2m_change(), unifying it with the rest of the checks
that are done at the start of the function.
This is XSA-430 / CVE-2022-42335
Fixes: 241702e064 ('x86/shadow: slightly consolidate sh_unshadow_for_p2m_change() (part II)') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Tue, 25 Apr 2023 10:37:25 +0000 (12:37 +0200)]
x86/shadow: "monitor table" is a HVM-only concept
It looks like in the combination of aff8bf94ce65 ('x86/shadow: only
4-level guest code needs building when !HVM') and 0b841314dace
('x86/shadow: sh_{make,destroy}_monitor_table() are "even more" HVM-
only') I didn't go quite far enough: SH_type_monitor_table is also
effectively unused when !HVM.
The assertion early in sh_destroy_shadow() can have the type dropped
altogether: it shouldn't make it here in the first place. Pages of
this type are freed directly from sh_destroy_monitor_table() only.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
x86: add support for crash dump analysis with xen.efi
Today it is not possible to analyse crash dumps of a system in
hypervisor mode when it had been booted via EFI, as the crash utility
doesn't understand the file format of xen.efi.
This can easily be solved by creating an ELF file from xen.efi via
objcopy. Using that file as name list for crash enables the user to
analyse the dump in hypervisor mode. Note that crash isn't happy with
a file containing no text and data, so using --only-keep-debug is not
an option.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Tue, 25 Apr 2023 10:17:26 +0000 (12:17 +0200)]
x86: detect CMOS aliasing on ports other than 0x70/0x71
... in order to also intercept Dom0 accesses through the alias ports.
Also stop intercepting accesses to the CMOS ports if we won't ourselves
use the CMOS RTC, because of there being none. This doesn't go as far as
covering port 0x70, as that also has the NMI disable bit, which we don't
want to permit Dom0 to set.
Note that rtc_init() deliberately uses 16 as the upper loop bound,
despite probe_cmos_alias() using 8: The higher bound is benign now, but
would save us touching the code (or, worse, missing to touch it) in case
the lower one was doubled.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Some firmware/devices are found to not reset MSI-X properly, leaving
MASKALL set. Jason reports on his machine MASKALL persists through a
warm reboot, but is cleared on cold boot. Xen relies on initial state
being MASKALL clear. Especially, pci_reset_msix_state() assumes if
MASKALL is set, it was Xen setting it due to msix->host_maskall or
msix->guest_maskall. Clearing just MASKALL is risky if ENABLE is set,
so clear them both.
Reported-by: Jason Andryuk <jandryuk@gmail.com> Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Tested-by: Jason Andryuk <jandryuk@gmail.com>
xen/arm64: smpboot: Directly switch to the runtime page-tables
Switching TTBR while the MMU is on is not safe. Now that the identity
mapping will not clash with the rest of the memory layout, we can avoid
creating temporary page-tables every time a CPU is brought up.
The arm32 code will use a different approach. So this issue is for now
only resolved on arm64.
Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com> Tested-by: Henry Wang <Henry.Wang@arm.com>
At the moment, switch_ttbr() is switching the TTBR whilst the MMU is
still on.
Switching TTBR is like replacing existing mappings with new ones. So
we need to follow the break-before-make sequence.
In this case, it means the MMU needs to be switched off while the
TTBR is updated. In order to disable the MMU, we need to first
jump to an identity mapping.
Rename switch_ttbr() to switch_ttbr_id() and create an helper on
top to temporary map the identity mapping and call switch_ttbr()
via the identity address.
switch_ttbr_id() is now reworked to temporarily turn off the MMU
before updating the TTBR.
We also need to make sure the helper switch_ttbr() is part of the
identity mapping. So move _end_boot past it.
The arm32 code will use a different approach. So this issue is for now
only resolved on arm64.
Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com> Tested-by: Henry Wang <Henry.Wang@arm.com>
xen/arm64: mm: Introduce helpers to prepare/enable/disable the identity mapping
In follow-up patches we will need to have part of Xen identity mapped in
order to safely switch the TTBR.
On some platform, the identity mapping may have to start at 0. If we always
keep the identity region mapped, NULL pointer dereference would lead to
access to valid mapping.
It would be possible to relocate Xen to avoid clashing with address 0.
However the identity mapping is only meant to be used in very limited
places. Therefore it would be better to keep the identity region invalid
for most of the time.
Two new external helpers are introduced:
- arch_setup_page_tables() will setup the page-tables so it is
easy to create the mapping afterwards.
- update_identity_mapping() will create/remove the identity mapping
Signed-off-by: Julien Grall <jgrall@amazon.com> Tested-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Xen is currently not fully compliant with the Arm Arm because it will
switch the TTBR with the MMU on.
In order to be compliant, we need to disable the MMU before
switching the TTBR. The implication is the page-tables should
contain an identity mapping of the code switching the TTBR.
In most of the case we expect Xen to be loaded in low memory. I am aware
of one platform (i.e AMD Seattle) where the memory start above 512GB.
To give us some slack, consider that Xen may be loaded in the first 2TB
of the physical address space.
The memory layout is reshuffled to keep the first four slots of the zeroeth
level free. All the regions currently in L0 slot 0 will not be part of
slot 4 (2TB). This requires a slight tweak of the boot code because
XEN_VIRT_START (2TB + 2MB) cannot be used as an immediate.
This reshuffle will make trivial to create a 1:1 mapping when Xen is
loaded below 2TB.
Lastly, take the opportunity to check at compile time if any of the
regions may overlap with the reserved area for identity mapping.
Signed-off-by: Julien Grall <jgrall@amazon.com> Tested-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
xen/arm32: head: Widen the use of the temporary mapping
At the moment, the temporary mapping is only used when the virtual
runtime region of Xen is clashing with the physical region.
In follow-up patches, we will rework how secondary CPU bring-up works
and it will be convenient to use the fixmap area for accessing
the root page-table (it is per-cpu).
Rework the code to use temporary mapping when the Xen physical address
is not overlapping with the temporary mapping.
This also has the advantage to simplify the logic to identity map
Xen.
Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Tested-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
On 32 bit systems with 64 bit time_t (hello, Y2038 problem),
the following error occurs otherwise:
| xenstored_control.c: In function 'lu_reject_reason':
| xenstored_control.c:646:70: error: format '%ld' expects argument of type 'long int', but argument 5 has type 'time_t' {aka 'long long int'} [-Werror=format=]
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Reviewed-by: Juergen Gross <jgross@suse.com>
When building the hypervisor with -Og and GCC 11/12, we encounter the
following error:
arch/arm/domain_build.c: In function ‘make_cpus_node’:
arch/arm/domain_build.c:2040:12: error: ‘clock_valid’ may be used uninitialized [-Werror=maybe-uninitialized]
2040 | if ( clock_valid )
| ^
arch/arm/domain_build.c:1947:10: note: ‘clock_valid’ was declared here
1947 | bool clock_valid;
| ^~~~~~~~~~~
cc1: all warnings being treated as errors
Fix it by initializing the variable.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Julien Grall <jgrall@amazon.com>
When building the hypervisor with -Og, we run into a __bad_cmpxchg link error:
aarch64-none-linux-gnu-ld: prelink.o: in function `__int_cmpxchg':
.../xen/./arch/arm/include/asm/arm64/cmpxchg.h:117: undefined reference to `__bad_cmpxchg'
aarch64-none-linux-gnu-ld: .../xen/./arch/arm/include/asm/arm64/cmpxchg.h:117: undefined reference to `__bad_cmpxchg'
aarch64-none-linux-gnu-ld: ./.xen-syms.0: hidden symbol `__bad_cmpxchg' isn't defined
aarch64-none-linux-gnu-ld: final link failed: bad value
This is due to the function __guest_cmpxchg not being inlined in the -Og build
with gcc 12. Fix this by marking __guest_cmpxchg always_inline.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com> Reviewed-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Andrew Cooper [Thu, 13 Apr 2023 19:56:15 +0000 (20:56 +0100)]
xen/livepatch: Fix .altinstructions safety checks
The prior check has && vs || mixups, making it tautologically false and thus
providing no safety at all. There are boundary errors too.
First start with a comment describing how the .altinstructions and
.altinstr_replacement sections interact, and perform suitable cross-checking.
Second, rewrite the alt_instr loop entirely from scratch. Origin sites have
non-zero size, and must be fully contained within the livepatches .text
section(s). Any non-zero sized replacements must be fully contained within
the .altinstr_replacement section.
Fixes: f8a10174e8b1 ("xsplice: Add support for alternatives") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Andrew Cooper [Sun, 16 Apr 2023 00:10:43 +0000 (01:10 +0100)]
arm/alternatives: Rename alt_instr fields which are used in common code
Alternatives auditing for livepatches is currently broken. To fix it, the
livepatch code needs to inspect more fields of alt_instr.
Rename ARM's fields to match x86's, because:
* ARM already exposes alt_offset under the repl name via ALT_REPL_PTR().
* "alt" is ambiguous in a structure entirely about alternatives already.
* "repl", being the same width as orig leads to slightly neater code.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Andrew Cooper [Sun, 16 Apr 2023 00:29:09 +0000 (01:29 +0100)]
xen/ELF: Fix ELF32 PRI formatters
It is rude to hide width formatting inside a PRI* macro, doubly so when it's
only in one bitness of the macro.
However its fully buggy when all the users use %#"PRI because then it expands
to the common trap of %#08x which does not do what the author intends.
Switch the 32bit ELF PRI formatters to use plain integer PRI's, just like on
the 64bit side already. No practical change.
Fixes: 7597fabca76e ("livepatch: Include sizes when an mismatch occurs") Fixes: 380b229634f8 ("xsplice: Implement payload loading") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Note in the changelog that the purpose of
gnttab_max_{maptrack_,}frames command line options has been changed.
Fixes: b2ea81d2b935 ('xen/grants: repurpose command line max options') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Henry Wang <Henry.Wang@arm.com>
Jan Beulich [Wed, 19 Apr 2023 09:02:47 +0000 (11:02 +0200)]
x86: fix build with old gcc after CPU policy changes
Old gcc won't cope with initializers involving unnamed struct/union
fields.
Fixes: 441b1b2a50ea ("x86/emul: Switch x86_emulate_ctxt to cpu_policy") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Wed, 19 Apr 2023 09:01:29 +0000 (11:01 +0200)]
x86: cpu{id,}_policy_updated() can be static
The function merely needs moving earlier in the file to avoid the need
for a forward declaration. While moving it, also rename it following the
recent folding of CPUID and MSR policies.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Jan Beulich [Wed, 19 Apr 2023 09:00:19 +0000 (11:00 +0200)]
tests/cpu-policy: fix "run" goal
An earlier change converted TARGET-y to TARGETS, but failed to replace
all references. Convert run's dependency, but use $< in the command to
avoid the leading blank that += inserts.
Fixes: 6a9f5477637a ("tests/cpu-policy: Rework Makefile") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Andrew Cooper [Thu, 13 Apr 2023 15:52:10 +0000 (16:52 +0100)]
x86/livepatch: Fix livepatch application when CET is active
Right now, trying to apply a livepatch on any system with CET shstk (AMD Zen3
or later, Intel Tiger Lake or Sapphire Rapids and later) fails as follows:
(XEN) livepatch: lp: Verifying enabled expectations for all functions
(XEN) common/livepatch.c:1591: livepatch: lp: timeout is 30000000ns
(XEN) common/livepatch.c:1703: livepatch: lp: CPU28 - IPIing the other 127 CPUs
(XEN) livepatch: lp: Applying 1 functions
(XEN) hi_func: Hi! (called 1 times)
(XEN) Hook executing.
(XEN) Assertion 'local_irq_is_enabled() || cpumask_subset(mask, cpumask_of(cpu))' failed at arch/x86/smp.c:265
(XEN) *** DOUBLE FAULT ***
<many double faults>
The assertion failure is from a global (system wide) TLB flush initiated by
modify_xen_mappings(). I'm not entirely sure when this broke, and I'm not
sure exactly what causes the #DF's, but it doesn't really matter either
because they highlight a latent bug that I'd overlooked with the CET-SS vs
patching work the first place.
While we're careful to arrange for the patching CPU to avoid encountering
non-shstk memory with transient shstk perms, other CPUs can pick these
mappings up too if they need to re-walk for uarch reasons.
Another bug is that for livepatching, we only disable CET if shadow stacks are
in use. Running on Intel CET systems when Xen is only using CET-IBT will
crash in arch_livepatch_quiesce() when trying to clear CR0.WP with CR4.CET
still active.
Also, we never went and cleared the dirty bits on .rodata. This would
matter (for the same reason it matters on .text - it becomes a valid target
for WRSS), but we never actually patch .rodata anyway.
Therefore rework how we do patching for both alternatives and livepatches.
Introduce modify_xen_mappings_lite() with a purpose similar to
modify_xen_mappings(), but stripped down to the bare minimum as it's used in
weird contexts. Leave all complexity to the caller to handle.
Instead of patching by clearing CR0.WP (and having to jump through some
fragile hoops to disable CET in order to do this), just transiently relax the
permissions on .text via l2_identmap[].
Note that neither alternatives nor livepatching edit .rodata, so we don't need
to relax those permissions at this juncture.
The perms are relaxed globally, but this is safe enough. Alternatives run
before we boot APs, and Livepatching runs in a quiesced state where the other
CPUs are not doing anything interesting.
This approach is far more robust.
Fixes: 48cdc15a424f ("x86/alternatives: Clear CR4.CET when clearing CR0.WP") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
In order to support hypervisor analysis of crash dumps, xen-syms needs
to contain debug_info. It should be allowed to configure the hypervisor
to be built with CONFIG_DEBUG_INFO in non-debug builds without having
to enable EXPERT.
Using a rather oldish gcc (7.5) it was verified that code generation
doesn't really differ between CONFIG_DEBUG_INFO on or off without
CONFIG_DEBUG being set (only observed differences were slightly
different symbol addresses, verified via "objdump -d", resulting from
the different config.gz in the binary). The old gcc version selection
was based on the assumption, that newer gcc won't regress in this
regard.
So move CONFIG_DEBUG_INFO out of the section guarded by EXPERT.
It should be mentioned that there have been reports that the linking
of the xen.efi might take considerably longer with CONFIG_DEBUG_INFO
selected when using newer binutils.
xen/riscv: add explicit check that .got{.plt} is empty
The GOT sections usage should be avoided in the hypervisor
so to catch such use cases earlier when GOT things are
produced the patch introduces .got and .got.plt sections
and adds asserts that they're empty.
The sections won't be created until they remain
empty otherwise the asserts would cause early failure.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
The patch is needed to keep all address of cpu0_boot_stack
PC-relative.
Pseudoinstruction 'la' can be transformed to 'auipc/addi' or
'auipc/l{w|d}'. It depends on the .option directive: nopic and pic
or compiler flags.
Right now, 'la' transforms to 'auipc/l{w|d}', which in case of
cpu0_boot_stack[] will lead to the usage of _GLOBAL_OFFSET_TABLE_
where all addresses will be without counting that it might happen
that linker address != load address ( so addresses inside got
sections will be relative to linker time ).
Looking at gcc spec file for the RISC-V architecture:
[user@49295ae49cbe build]$ riscv64-linux-gnu-gcc -dumpspecs | grep -i
pic
--traditional-format %(subtarget_asm_debugging_spec) %{fno-pie|fno-
PIE|fno-pic|fno-PIC:;:-fpic} %{march=*} %{mabi=*} %{mno-relax} %{mbig-
endian} %{mlittle-endian} %(subtarget_asm_spec)%{misa-spec=*}
which means that -fpic is enabled if none of the following options are
present on the command line:
-fno-pie
-fno-PIE
-fno-pic
-fno-PIC
That's the reasons why 'la' is transformed to 'aupic/l{w|d} GOT' and
not be dependent on the toolchain used.
Suggested-by: Jan Beulich <jbeulich@suse.com> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Michal Orzel [Wed, 5 Apr 2023 11:17:50 +0000 (13:17 +0200)]
xen/arm: vpl011: Do not try to handle TX FIFO status when backend in Xen
>From vpl011_rx_char_xen(), we call vpl011_data_avail() that handles both
RX and TX state. Because we are passing 0 as out_fifo_level and
SBSA_UART_FIFO_SIZE as out_size, we end up calling a function
vpl011_update_tx_fifo_status() which performs TXI bit handling
depending on the FIFO trigger level. This does not make sense when backend
is in Xen, as we maintain a single TX state where data can always be
written and as such there is no TX FIFO handling. Furthermore, this
function assumes that the backend is in domain by making use of struct
xencons_interface unconditionally. Fix it by calling this function only
when backend is in domain. Also add an assert for sanity.
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Henry Wang <Henry.Wang@arm.com>
Michal Orzel [Wed, 5 Apr 2023 11:17:49 +0000 (13:17 +0200)]
xen/arm: vpl011: Handle correctly TXFE when backend in Xen
When backend is in Xen, the handling of data written to DR register is a
bit special because we want to tell guest that we are always ready for new
data to be written (i.e. no real FIFO, TXFF/BUSY never set and TXI always
set). This conflicts with the current handling of TXFE bit, which we
always clear and never set on a write path (we happen to set it when we
receive char from serial input due to use of vpl011_data_avail() but this
might never be called). This can lead to issues if a guest driver makes
use of TXFE bit to check for TX transmission completion (such guest could
then wait endlessly). Fix it by keeping TXFE always set to match the
current emulation logic.
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Tested-by: Henry Wang <Henry.Wang@arm.com>
Michal Orzel [Wed, 5 Apr 2023 11:17:48 +0000 (13:17 +0200)]
xen/arm: vpl011: Fix misleading comments
In both vpl011_read_data() and vpl011_read_data_xen(), there is a comment
stating that the guest is expected to read the DR register only if the
TXFE bit of FR register is not set. This is obviously logically wrong and
it should be RXFE (i.e. RX FIFO empty bit set -> nothing to read).
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Jan Beulich [Mon, 17 Apr 2023 16:11:06 +0000 (18:11 +0200)]
x86emul: support AVX-VNNI-INT8
These are close relatives of the AVX-VNNI ISA extension. Since the insns
here and in particular their memory access patterns follow the usual
scheme (and especially the byte variants of AVX-VNNI), I didn't think it
was necessary to add a contrived test specifically for them.
While making the addition also re-wire AVX-VNNI's handling to
simd_0f_ymm: There's no reason to check the AVX feature alongside the
one actually of interest (there are a few features where two checks are
actually necessary, e.g. GFNI+AVX, but this isn't the case here).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Mon, 17 Apr 2023 16:10:14 +0000 (18:10 +0200)]
x86emul: support AVX-IFMA insns
As in a few cases before (in particular: AVX512_IFMA), since the insns
here and in particular their memory access patterns follow the usual
scheme, I didn't think it was necessary to add a contrived test
specifically for them.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Mon, 17 Apr 2023 12:04:34 +0000 (14:04 +0200)]
x86emul: drop regs field from emulator state structure
For an unclear reason 0552a8cfda43 ("x86emul: track only rIP in emulator
state") converted the original struct cpu_user_regs instance to a
pointer, rather than dropping the field altogether: The pointer merely
aliases the one in the context structure.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Mon, 17 Apr 2023 12:03:22 +0000 (14:03 +0200)]
x86emul: support WRMSRNS
This insn differs from WRMSR solely in the lack of serialization. Hence
the code used there can simply be used here as well, plus a feature
check of course. As there's no other infrastructure needed beyond
permitting the insn for PV privileged-op emulation (in particular no
separate new VMEXIT) we can expose the insn to guests right away.
Don't expose the feature to PV guests, as the involved #UD is
serializing anyway.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
When building the hypervisor for arm64 with -Og, we encounter a (false)
uninitialized use warning:
arch/arm/efi/boot.c: In function ‘efi_start’:
arch/arm/efi/boot.c:1468:9: error: ‘argc’ may be used uninitialized [-Werror=maybe-uninitialized]
1468 | efi_arch_handle_cmdline(argc ? *argv : NULL, options, name.s);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/arm/efi/boot.c:1263:21: note: ‘argc’ was declared here
1263 | unsigned int i, argc;
| ^~~~
cc1: all warnings being treated as errors
Fix this by initializing argc. As a precaution, also initialize argv.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Mon, 17 Apr 2023 12:01:02 +0000 (14:01 +0200)]
x86emul: switch split-off files to SPDX
I should have remembered to adjust the splitting patches accordingly,
but I forgot. While making the adjustment also correct fpu.c's first
comment line.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
A use of $(x86_emulate.h) was introduced (mirroring what the testharness
has) without realizing that no such variable exists here. (Re)name the
variable (to) "private.h", which better expresses what is included which
way.
Note that because of automatic dependencies tracking, unlike in the test
harness no $(x86.h) variable is needed here - we solely need explicit
dependencies for files which need symlinks created.
Fixes: 9ace97ab9b87 ("x86emul: split off opcode 0f01 handling") Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Henry Wang [Wed, 1 Feb 2023 02:15:13 +0000 (10:15 +0800)]
xen/arm: Extend the memory overlap check to include EfiACPIReclaimMemory
Similarly as the static regions and boot modules, memory regions with
EfiACPIReclaimMemory type (defined in bootinfo.acpi if CONFIG_ACPI is
enabled) should also not be overlapping with memory regions in
bootinfo.reserved_mem and bootinfo.modules.
Therefore, this commit reuses the `meminfo_overlap_check()` to further
extends the check in function `check_reserved_regions_overlap()` so that
memory regions in bootinfo.acpi are included. If any error occurs in the
extended `check_reserved_regions_overlap()`, the `meminfo_add_bank()`
defined in `efi-boot.h` will return early.
Signed-off-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Henry Wang [Wed, 1 Feb 2023 02:15:12 +0000 (10:15 +0800)]
xen/arm: Extend the memory overlap check to include bootmodules
Similarly as the static regions defined in bootinfo.reserved_mem,
the bootmodule regions defined in bootinfo.modules should also not
be overlapping with memory regions in either bootinfo.reserved_mem
or bootinfo.modules.
Therefore, this commit introduces a helper `bootmodules_overlap_check()`
and uses this helper to extend the check in function
`check_reserved_regions_overlap()` so that memory regions in
bootinfo.modules are included. Use `check_reserved_regions_overlap()`
in `add_boot_module()` to return early if any error occurs.
Signed-off-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Henry Wang [Wed, 1 Feb 2023 02:15:11 +0000 (10:15 +0800)]
xen/arm: Add memory overlap check for bootinfo.reserved_mem
As we are having more and more types of static region, and all of
these static regions are defined in bootinfo.reserved_mem, it is
necessary to add the overlap check of reserved memory regions in Xen,
because such check will help user to identify the misconfiguration in
the device tree at the early stage of boot time.
Currently we have 3 types of static region, namely
(1) static memory
(2) static heap
(3) static shared memory
(1) and (2) are parsed by the function `device_tree_get_meminfo()` and
(3) is parsed using its own logic. All of parsed information of these
types will be stored in `struct meminfo`.
Therefore, to unify the overlap checking logic for all of these types,
this commit firstly introduces a helper `meminfo_overlap_check()` and
a function `check_reserved_regions_overlap()` to check if an input
physical address range is overlapping with the existing memory regions
defined in bootinfo. After that, use `check_reserved_regions_overlap()`
in `device_tree_get_meminfo()` to do the overlap check of (1) and (2)
and replace the original overlap check of (3) with
`check_reserved_regions_overlap()`.
Signed-off-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Henry Wang [Tue, 28 Mar 2023 07:13:34 +0000 (15:13 +0800)]
xen/arm: Clean-up in p2m_init() and p2m_final_teardown()
With the change in previous patch, the initial 16 pages in the P2M
pool is not necessary anymore. Drop them for code simplification.
Also the call to p2m_teardown() from arch_domain_destroy() is not
necessary anymore since the movement of the P2M allocation out of
arch_domain_create(). Drop the code and the above in-code comment
mentioning it. Take the opportunity to fix a typo in the original
in-code comment.
With above clean-up, the second parameter of p2m_teardown() is
also not needed anymore. Drop this parameter and the logic related
to this parameter.
Signed-off-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Henry Wang [Tue, 28 Mar 2023 07:13:33 +0000 (15:13 +0800)]
xen/arm: Defer GICv2 CPU interface mapping until the first access
Currently, the mapping of the GICv2 CPU interface is created in
arch_domain_create(). This causes some troubles in populating and
freeing of the domain P2M pages pool. For example, a default 16
P2M pages are required in p2m_init() to cope with the P2M mapping
of 8KB GICv2 CPU interface area, and these 16 P2M pages would cause
the complexity of P2M destroy in the failure path of
arch_domain_create().
As per discussion in [1], similarly as the MMIO access for ACPI, this
patch defers the GICv2 CPU interface mapping until the first MMIO
access. This is achieved by moving the GICv2 CPU interface mapping
code from vgic_v2_domain_init()/vgic_v2_map_resources() to the
stage-2 data abort trap handling code. The original CPU interface
size and virtual CPU interface base address is now saved in
`struct vgic_dist` instead of the local variable of
vgic_v2_domain_init()/vgic_v2_map_resources().
Take the opportunity to unify the way of data access using the
existing pointer to struct vgic_dist in vgic_v2_map_resources() for
new GICv2.
Since gicv2_map_hwdom_extra_mappings() happens after domain_create(),
so there is no need to map the extra mappings on-demand, and therefore
keep the hwdom extra mappings as untouched.
Henry Wang [Tue, 28 Mar 2023 07:13:32 +0000 (15:13 +0800)]
xen/arm: Rename vgic_cpu_base and vgic_dist_base for new vGIC
In the follow-up patch from this series, the GICv2 CPU interface
mapping will be deferred until the first access in the stage-2
data abort trap handling code. Since the data abort trap handling
code is common for the current and the new vGIC implementation,
it is necessary to unify the variable names in struct vgic_dist
for these two implementations.
Therefore, this commit renames the vgic_cpu_base and vgic_dist_base
for new vGIC to cbase and dbase. So we can use the same code in
the data abort trap handling code for both vGIC implementations.
Signed-off-by: Henry Wang <Henry.Wang@arm.com> Acked-by: Julien Grall <jgrall@amazon.com>
Henry Wang [Tue, 28 Mar 2023 07:13:31 +0000 (15:13 +0800)]
xen/arm: Reduce redundant clear root pages when teardown p2m
Currently, p2m for a domain will be teardown from two paths:
(1) The normal path when a domain is destroyed.
(2) The arch_domain_destroy() in the failure path of domain creation.
When tearing down p2m from (1), the part to clear and clean the root
is only needed to do once rather than for every call of p2m_teardown().
If the p2m teardown is from (2), the clear and clean of the root
is unnecessary because the domain is not scheduled.
Therefore, this patch introduces a helper `p2m_clear_root_pages()` to
do the clear and clean of the root, and move this logic outside of
p2m_teardown(). With this movement, the `page_list_empty(&p2m->pages)`
check can be dropped.
Signed-off-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com> Acked-by: Julien Grall <jgrall@amazon.com>
Andrew Cooper [Thu, 26 Jan 2023 14:57:45 +0000 (14:57 +0000)]
x86/hvm: Disallow disabling paging in 64bit mode
The Long Mode consistency checks exist to "ensure that the processor does not
enter an undefined mode or state that results in unpredictable behavior". APM
Vol2 Table 14-5 "Long-Mode Consistency Checks" lists them, but there is no row
preventing the OS from trying to exit Long mode while in 64bit mode. This
could leave the CPU in Protected Mode with an %rip above the 4G boundary.
Experimentally, AMD CPUs really do permit this state transition. An OS which
tries it hits an instant SHUTDOWN, even in cases where the truncation I expect
to be going on behind the scenes ought to result in sane continued execution.
Furthermore, right from the very outset, the APM Vol2 14.7 "Leaving Long Mode"
section instructs peoples to switch to a compatibility mode segment first
before clearing CR0.PG, which does clear out the upper bits in %rip. This is
further backed up by Vol2 Figure 1-6 "Operating Modes of the AMD64
Architecture".
Either way, this appears to have been a genuine oversight in the AMD64 spec.
Intel, on the other hand, rejects this state transition with #GP.
Between revision 71 (Nov 2019) and 72 (May 2020) of SDM Vol3, a footnote to
4.1.2 "Paging-Mode Enable" was altered from
If CR4.PCIDE= 1, an attempt to clear CR0.PG causes a general-protection
exception (#GP); software should clear CR4.PCIDE before attempting to
disable paging.
to
If the logical processor is in 64-bit mode or if CR4.PCIDE= 1, an attempt to
clear CR0.PG causes a general-protection exception (#GP). Software should
transition to compatibility mode and clear CR4.PCIDE before attempting to
disable paging.
which acknowledges this corner case, but there doesn't appear to be any other
discussion even in the relevant Long Mode sections.
So it appears that Intel spotted and addressed the corner case in IA-32e mode,
but were 15 years late to document it.
Xen was written to the AMD spec, and misses the check. Follow the Intel
behaviour, because it is more sensible and avoids hitting a VMEntry failure.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Julien Grall [Mon, 27 Mar 2023 18:45:20 +0000 (19:45 +0100)]
xen/x86: Replace GPL v2.0+ license boilerplate with an SPDX tag in *.h
It is easier to understand the license of a file when using SPDX.
This is replacing the below pattern with the SPDX tag GPL-2.0-or-later
in xen/arch/x86/*.h:
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; If not, see <http://www.gnu.org/licenses/>.
Julien Grall [Mon, 27 Mar 2023 18:45:19 +0000 (19:45 +0100)]
xen/x86: Replace GPL v2.0+ license boilerplate with an SPDX tag in *.c
It is easier to understand the license of a file when using SPDX.
This is replacing the below pattern with the SPDX tag GPL-2.0-or-later
in xen/arch/x86/*.c:
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; If not, see <http://www.gnu.org/licenses/>.
Julien Grall [Mon, 27 Mar 2023 18:45:18 +0000 (19:45 +0100)]
xen/x86: Replace GPL v2.0 license boilerplate with an SPDX tag in *.h (part 3)
It is easier to understand the license of a file when using SPDX.
This is replacing the below pattern with the SPDX tag GPL-2.0-only
in xen/arch/x86/*.h:
* This program is free software; you can redistribute it and/or
* modify it under the terms and conditions of the GNU General Public
* License, version 2, as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public
* License along with this program; If not, see <http://www.gnu.org/licenses/>.
Julien Grall [Mon, 27 Mar 2023 18:45:17 +0000 (19:45 +0100)]
xen/x86: Replace GPL v2.0 license boilerplate with an SPDX tag in *.h
It is easier to understand the license of a file when using SPDX.
This is replacing the below pattern with the SPDX tag GPL-2.0-only
in xen/arch/x86/*.h:
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
* version 2, as published by the Free Software Foundation.
*
* This program is distributed in the hope it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
* more details.
*
* You should have received a copy of the GNU General Public License along with
* this program; If not, see <http://www.gnu.org/licenses/>.
Julien Grall [Mon, 27 Mar 2023 18:45:16 +0000 (19:45 +0100)]
xen/x86: Replace GPL v2.0 license boilerplate with an SPDX tag in *.c (part 3)
It is easier to understand the license of a file when using SPDX.
This is replacing the below pattern with the SPDX tag GPL-2.0-only
in xen/arch/x86/*.c:
* This program is free software; you can redistribute it and/or
* modify it under the terms and conditions of the GNU General Public
* License, version 2, as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public
* License along with this program; If not, see <http://www.gnu.org/licenses/>.
Julien Grall [Mon, 27 Mar 2023 18:45:15 +0000 (19:45 +0100)]
xen/x86: Replace GPL v2.0 license boilerplate with an SPDX tag in *.c
It is easier to understand the license of a file when using SPDX.
This is replacing the below pattern with the SPDX tag GPL-2.0-only
in xen/arch/x86/*.c:
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
* version 2, as published by the Free Software Foundation.
*
* This program is distributed in the hope it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
* more details.
*
* You should have received a copy of the GNU General Public License along with
* this program; If not, see <http://www.gnu.org/licenses/>.
Andrew Cooper [Fri, 17 Mar 2023 11:10:06 +0000 (11:10 +0000)]
x86/svm: Provide EXITINFO decodes for Exceptions/NPF intercepts
Exceptions and NPF intercepts almost have the same layout, but NPF has bits
above 31 in the error code, and the name for exitinfo2 really does want
distinguishing between cr2 and gpa.
In nsvm_vcpu_vmexit_inject() rearrange VMEXIT_NPF to fall through instead of
repeating the exitinfo1 write. Use the fallthrough pseudo keyword instead of
a comment.
In VMEXIT_NPF, as we're editing the printk() anyway, switch to using the newer
domain_crash() form.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Fri, 17 Feb 2023 23:45:36 +0000 (23:45 +0000)]
x86/treewide: Drop the TRAP_* legacy names
We have two naming schemes for exceptions; X86_EXC_?? which use the
archtiectural abbreviations, and TRAP_* which is a mix of terminology and
nonstandard abbrevations. Switch to X86_EXC_* uniformly.
No funcational change, confirmed by diffing the disassembly. Only 7 binary
changes, and they're all __LINE__ being passed into printk().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Wed, 5 Apr 2023 16:18:42 +0000 (18:18 +0200)]
Revert "x86emul/test: drop bogus .PHONY"
This reverts commit 24c471b6f404ef24db8669d82ae67387067c097f. I
wasn't thinking quite right; the line was added just recently,
when the symlink-ed dir was converted to a real one. Thanks to
Athony Perard for noticing the mistake.
Andrew Cooper [Wed, 5 Apr 2023 12:36:13 +0000 (13:36 +0100)]
tools/libs/guest: Fix build following libx86 changes
I appear to have lost this hunk somewhere...
Fixes: 1b67fccf3b02 ("libx86: Update library API for cpu_policy") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Andrew Cooper [Thu, 30 Mar 2023 17:21:01 +0000 (18:21 +0100)]
x86: Out-of-inline the policy<->featureset convertors
These are already getting over-large for being inline functions, and are only
going to grow further over time. Out of line them, yielding the following net
delta from bloat-o-meter:
Andrew Cooper [Wed, 29 Mar 2023 11:01:33 +0000 (12:01 +0100)]
x86: Drop struct old_cpu_policy
With all the complicated callers of x86_cpu_policies_are_compatible() updated
to use a single cpu_policy object, we can drop the final user of struct
old_cpu_policy.
Update x86_cpu_policies_are_compatible() to take (new) cpu_policy pointers,
reducing the amount of internal pointer chasing, and update all callers to
pass their cpu_policy objects directly.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Wed, 29 Mar 2023 11:37:33 +0000 (12:37 +0100)]
x86: Merge xc_cpu_policy's cpuid and msr objects
Right now, they're the same underlying type, containing disjoint information.
Use a single object instead. Also take the opportunity to rename 'entries' to
'msrs' which is more descriptive, and more in line with nr_msrs being the
count of MSR entries in the API.
test-tsx uses xg_private.h to access the internals of xc_cpu_policy, so needs
updating at the same time. Take the opportunity to improve the code clarity
by passing a cpu_policy rather than an xc_cpu_policy into some functions.
No practical change. This undoes the transient doubling of storage space from
earlier patches.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Wed, 29 Mar 2023 06:39:44 +0000 (07:39 +0100)]
x86: Merge the system {cpuid,msr} policy objects
Right now, they're the same underlying type, containing disjoint information.
Introduce a new cpu-policy.{h,c} to be the new location for all policy
handling logic. Place the combined objects in __ro_after_init, which is new
since the original logic was written.
As we're trying to phase out the use of struct old_cpu_policy entirely, rework
update_domain_cpu_policy() to not pointer-chase through system_policies[].
This in turn allows system_policies[] in sysctl.c to become static and reduced
in scope to XEN_SYSCTL_get_cpu_policy.
No practical change. This undoes the transient doubling of storage space from
earlier patches.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Tue, 28 Mar 2023 20:24:20 +0000 (21:24 +0100)]
x86: Merge struct msr_policy into struct cpu_policy
As with the cpuid side, use a temporary define to make struct msr_policy still
work.
Note, this means that domains now have two separate struct cpu_policy
allocations with disjoint information, and system policies are in a similar
position, as well as xc_cpu_policy objects in libxenguest. All of these
duplications will be addressed in the following patches.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Tue, 28 Mar 2023 17:55:19 +0000 (18:55 +0100)]
x86: Rename struct cpuid_policy to struct cpu_policy
Also merge lib/x86/cpuid.h entirely into lib/x86/cpu-policy.h
Use a temporary define to make struct cpuid_policy still work.
There's one forward declaration of struct cpuid_policy in
tools/tests/x86_emulator/x86-emulate.h that isn't covered by the define, and
it's easier to rename that now than to rearrange the includes.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
These weren't great names to begin with, and using {leaves,msrs} matches up
better with the existing nr_{leaves,msr} parameters anyway.
Furthermore, by renaming these fields we can get away with using some #define
trickery to avoid the struct {cpuid,msr}_policy merge needing to happen in a
single changeset.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Tue, 28 Mar 2023 19:31:33 +0000 (20:31 +0100)]
x86: Rename struct cpu_policy to struct old_cpuid_policy
We want to merge struct cpuid_policy and struct msr_policy together, and the
result wants to be called struct cpu_policy.
The current struct cpu_policy, being a pair of pointers, isn't terribly
useful. Rename the type to struct old_cpu_policy, but it will disappear
entirely once the merge is complete.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Tue, 4 Apr 2023 13:45:18 +0000 (15:45 +0200)]
x86emul: correct AVX512VL+VPCLMUL test descriptions
The stride values (based on 32-bit element size) were wrong for these
two test, yielding misleading output (especially when comparing with the
test variants also involving AVX512-VBMI2).
Also insert a missing blank on a nearby, related line.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Tue, 4 Apr 2023 13:44:11 +0000 (15:44 +0200)]
x86/PV: ignore PAE_MODE ELF note for 64-bit Dom0
Besides a printk() the main effect is slight corruption of the start
info magic: While that's meant to be xen-3.0-x86_64, it wrongly ended
up as xen-3.0-x86_64p. (The extended-CR3 VM-assist thus won't be
enabled anymore either, but that's meaningless to 64-bit PV anyway.)
Note that no known users exist that would have developed a dependency on
the bogus magic string. In particular Linux, NetBSD, and mini-os have
been checked.
Fixes: 460060f83d41 ("libelf: use for x86 dom0 builder") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Tue, 4 Apr 2023 13:43:29 +0000 (15:43 +0200)]
x86emul/fuzzer: re-arrange cleaning
The latter of the two commits referenced below converted x86_emulate
from a symlinked dir to a real one, holding symlinked files. Yet even
before that the split between distclean and clean was suspicious: A
similar split, removing symlinks only in distclean, doesn't exist
anywhere else in the tree afaics.
Fixes: c808475882ef ("tools/fuzz: introduce x86 instruction emulator target") Fixes: 9ace97ab9b87 ("x86emul: split off opcode 0f01 handling") Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Mon, 3 Apr 2023 12:17:35 +0000 (13:17 +0100)]
x86/emul: Fix test harness build with blk.c moved out of x86_emulate.c
Trying to build the test harness fails with:
x86_emulate/blk.c: In function 'x86_emul_blk':
x86_emulate/blk.c:74:15: error: expected ':' or ')' before 'ASM_FLAG_OUT'
74 | ASM_FLAG_OUT(, "; setz %[zf]")
| ^~~~~~~~~~~~
This is because ASM_FLAG_OUT() is still local to x86_emulate.c. Move it into
x86-emulate.h instead so it ends up in all files including private.h. The
main Xen build gets this macro from compiler.h.
Fixes: c80243f94386 ("x86emul: move x86_emul_blk() to separate source file") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
xen/x86: switch to use generic implemetation of bug.h
The following changes were made:
* Make GENERIC_BUG_FRAME mandatory for X86
* Update asm/bug.h using generic implementation in <xen/bug.h>
* Update do_invalid_op using generic do_bug_frame()
* Define BUG_DEBUGGER_TRAP_FATAL to debugger_trap_fatal(X86_EXC_GP,regs)
* type of eip variable was changed to 'const void *'
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
The idea of the patch is to change all <asm/bug.h> to <xen/bug.h> and
keep Xen compilable with adding only minimal amount of changes:
1. It was added "#include <xen/types.h>" to ARM's "<asm/bug.h>" as it
uses uint_{16,32}t in 'struct bug_frame'.
2. It was added '#define BUG_FRAME_STRUCT' which means that ARM hasn't
been switched to generic implementation yet.
3. It was added '#define BUG_FRAME_STRUCT' which means that x86 hasn't
been switched to generic implementation yet.
4. BUGFRAME_* and _start_bug_frame[], _stop_bug_frame_*[] were removed
for ARM & x86 to deal with compilation errors such as:
redundant redeclaration of ...
5. Remove BUG_DISP_WIDTH, BUG_LINE_LO_WIDTH, BUG_LINE_HI_WIDTH from
x86's <asm.bug.h> to not to produce #undef for them and #define again
with the same values as in <xen/bug.h>. These #undef and #define will
be anyway removed in the patch [2]
6. Remove <asm/bug.h> from <x86/acpi/cpufreq/cpufreq.c> and
<drivers/cpufreq/cpufreq.c> as nothing from <xen/bug.h> are used in
<*/cpufreq.c>
In the following two patches x86 and ARM archictectures will be
switched fully:
[1] xen/arm: switch ARM to use generic implementation of bug.h
[2] xen/x86: switch x86 to use generic implemetation of bug.h
Jan Beulich [Mon, 3 Apr 2023 10:48:12 +0000 (12:48 +0200)]
x86emul: move various utility functions to separate source files
Many are needed by the hypervisor only - have one file for this purpose.
Some are also needed by the harness (but not the fuzzer) - have another
file for these.
Code moved gets slightly adjusted in a few places, e.g. replacing
"state" by "s" (like was done for other that has been split off).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Jan Beulich [Mon, 3 Apr 2023 10:47:08 +0000 (12:47 +0200)]
x86emul: move x86_emul_blk() to separate source file
The function is already non-trivial and is expected to further grow.
Code moved gets slightly adjusted in a few places, e.g. replacing EXC_*
by X86_EXC_* (such that EXC_* don't need to move as well; we want these
to be phased out anyway).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
projects / xen.git / log