Base image "archlinux/base" isn't available anymore,
https://lists.archlinux.org/pipermail/arch-dev-public/2020-November/030181.html
But instead of switching to archlinux/archlinux, we will use the
official image from Docker. Main difference is that the first one is
updated daily while the second is updated weekly.
Also, as we will install the packages from "base-devel" anyway, switch
to the "base-devel" tag.
"dev86" package is now available from the main repo, no need for
multilib repo anymore.
It is recommended to initialise local signing key used by pacman, so
let's do that.
Replace "markdown" by "discount" as the former isn't available anymore
and has been replaced by the later.
Also, clean pacman's cache.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Ask docker to check if there's an update of the base image to avoid
using an old container cached locally.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
PMU virtualization is not dependent on the hardware virtualization support.
Rename {svm,vmx}_vpmu_initialise to {amd,core2}_vpmu_initialise because
the {svm,vmx} prefix is misleading.
Take the opportunity to remove the also misleading comment stating that
vpmu is specific to hvm guests, and correct the filename.
No functional change intended.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
This reverts the build system relevant half of commit
a4557f515f, as gitlab CI can't fully cope
with the change just yet.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Currently late ucode loading is performed only on the first core of CPU
siblings. But according to the latest recommendation from AMD, late
ucode loading should happen on every logical thread/core on AMD CPUs.
To achieve that, introduce is_cpu_primary() helper which will consider
every logical cpu as "primary" when running on AMD CPUs. Also include
Hygon in the check for future-proofing.
Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Add a debian container with cppcheck installation routine inside,
capable of performing cppcheck analysis on Xen-only build including
cross-builds for arm32 and x86_64.
Populate build jobs making use of that container to run cppcheck
analysis to produce a text report (xen-cppcheck.txt) containing the list
of all the findings.
This patch does not aim at performing any sort of bisection. Cppcheck is
imperfect and for now, our goal is to at least be aware of its reports,
so that we can compare them with the ones produced by better tools and
to be able to see how these reports change as a result of further
infrastructure improvements (e.g. exception list, rules exclusion).
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
As part of the arm32 dom0 test, also create a simple domU using xl. To
do that, we need the toolstack installed in the dom0 rootfs. We switch
to using the kernel and rootfs built by the Yocto arm32 job.
Remove the PCI node from the host device tree: it is unused but causes a
Linux hang at boot.
Use xen-watchdog to trigger the domU creation for convience
(/etc/local.d is not handled by rootfs.)
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Copy the build output of Yocto builds to binaries/ for the arm32 target,
and export binaries/ among the jobs artifacts so that they can be reused
by other jobs.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
We are going to use artifacts produced by the Yocto builds in test jobs.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reduce the scope of nvmx_enqueue_n2_exceptions() to static because it is used
only in this file.
Take the opportunity to remove a trailing space.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Move vmx_update_debug_state() in vmcs.c because it is used only in this
file and limit its scope to this file by declaring it static and removing
its declaration from vmx.h.
No functional change intended.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
From `man 2 realloc`:
If realloc() fails, the original block is left untouched; it is not freed or moved.
Found using GCC -fanalyzer:
| 184 | backup->entries = realloc(backup->entries,
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | | | |
| | | | (91) when ‘realloc’ fails
| | | (92) ‘old_ptes.entries’ leaks here; was allocated at (44)
| | (90) ...to here
Signed-off-by: Edwin Török <edwin.torok@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Edwin, with the help of GCC's -fanalyzer, identified that p2m_frame_list_list
gets leaked. What fanalyzer can't see is that the live_p2m_frame_list_list
and live_p2m_frame_list foreign mappings are leaked too.
Rework the logic so the out path is executed unconditionally, which cleans up
all the intermediate allocations/mappings appropriately.
Fixes: bd7a29c3d0 ("tools/libs/ctrl: fix xc_core_arch_map_p2m() to support linear p2m table")
Reported-by: Edwin Török <edwin.torok@cloud.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Use a single fairly generic string as the "all done" message to look for,
which avoids the need to patch qemu-smoke-riscv64.sh each time a new feature
is added.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
struct nestedvm uses mostly plain integer types, except for virt_ext_t which
is a union wrapping two bitfield names.
However, it turns out that this is a write-only variable. Delete it, allowing
us to drop the include of vmcb.h
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
There are no references anymore as of c9a4a1c419 ("x86/layout: Correct
Xen's idea of its own memory layout"). For what's left, switch to
"unsigned char" as here we're not dealing with strings of any kind.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The shadow_mode_refcounts() check immediately ahead of the "emulate"
label renders redundant two subsequent is_hvm_domain() checks (the
latter of which was already redundant with the former).
Also guest_mode() checks are pointless when we already know we're
dealing with a HVM domain.
Finally style-adjust a comment which otherwise would be fully visible as
patch context anyway.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The types p2m_is_readonly() checks for aren't applicable to PV;
specifically get_gfn() won't ever return any such type for PV domains.
Extend the HVM-conditional block of code, also past the subsequent HVM-
only if(). This way the "emulate_readonly" also becomes unreachable when
!HVM, so move the conditional there upwards as well. Noticing the
earlier shadow_mode_refcounts() check, move it up even further, right
after that check. With that, the "done" label also needs marking as
potentially unused.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Do away with the partly mis-named "mmio" label there, which really is
only about emulated MMIO. Move the code to the place where the sole
"goto" was. Re-order steps slightly: Assertion first, perfc increment
outside of the locked region, and "gpa" calculation closer to the first
use of the variable. Also make the HVM conditional cover the entire
if(), as p2m_mmio_dm isn't applicable to PV; specifically get_gfn()
won't ever return this type for PV domains.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Create a new private header in arch/x86/hvm/svm called nestedsvm.h and move
there all definitions and declarations that are used only by svm code and
don't need to reside in an external header.
No functional change intended.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
These days, this is just two length helpers. Move into the private svm.h
No functional change intended.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Fold svm_asid_g_invlpg() into its single caller, deleting the #if 0 which has
been present for the entire 16 years this helper has existed: c/s 322a078ab1
"[HVM][SVM] Reintroduce ASIDs."
Move the two remaining prototypes into the private svm.h, forward declaring
cpuinfo_x86 in preference to including asm/processor.h
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Delete asm/hvm/svm/intr.h because it contains only the declaration of
svm_intr_assist() which is referenced only by assembly.
No functional change intended.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Create a new private header in arch/x86/hvm/svm called svm.h and move there
all definitions and declarations that are used solely by svm code.
Take the opportunity to remove the forward declaration of struct vcpu, that is
a leftover since the removal of svm_update_guest_cr()'s declaration.
Take the opportunity to re-arrange the header as follows, all structures first,
then all variable decalarations, all function delarations, and finally all
inline functions.
No functional change intended.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
In the interest of having less jobs, we remove the x86_32 build jobs
that do release build. Debug build is very likely to be enough to find
32bit build issues.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
While the Let's Encrypt root certificate ISRG_Root_X1.crt is already
present, openssl seems to still check for the root certificate
DST_Root_CA_X3.crt which has expired. This prevent https connections.
Removing DST_Root_CA_X3 fix the issue.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jessie as rearch EOL in 2020.
Even if we update the containers, we would still not be able to reach
HTTPS webside with Let's Encrypt certificates and thus would need more
change to the container.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
As Jessie is EOL, the official tag isn't supported anymore. Also, the
GPG key for the packages on the repository on the official image are
expired and it isn't possible to update or install packages.
But we can use the image from "debian/eol" tag which use repositories
from archive.debian.org and have workaround to ignore the validity
date of the keys.
There isn't a dedicated i386 tag for jessie, but we can ask docker to
pull the i386 image of the "debial/eol:jessie" tag.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
This is generally good practice, and necessary for livepatch binary diffing to
work.
With this, livepatching of the SVM entry path works. The only complication is
with svm_stgi_label which is only used by oprofile to guestimate (not
completely correctly) when an NMI hit guest context.
Livepatching of VMX is still an open question, because the logic doesn't form
anything remotely resembling functions. Both code fragments jump into each
other so need to be updated in tandem. Also, both code fragment entries need
trampolines in the case that patching actually occurs. For now, just treat it
as a single function.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Taking struct cpu_user_regs as a full object is bogus, and while what was
probably meant was to take a struct cpu_user_regs pointer, that's still wrong.
This isn't a function; its an address stored in the VMCS that the CPU resumes
from on VMExit, meaning that it doesn't conform to a normal C API/ABI.
Annotate it with `nocall`, and move the declaration into vmcs.c next to its
sole user.
Fixes: 9c3118a825 ("bitkeeper revision 1.1159.1.483 (41c0c417XYObowWqbfqU0cdLx30C9w)")
`-> "Initial Intel VMX support"
Reported-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Replace PKG_CONFIG variable name with PKG_CONFIG_FILE for the name of
the pkg-config file.
This is preventing a conflict in some build systems where PKG_CONFIG
actually contains the path to the pkg-config executable to use, as the
default assignment in libs.mk is using a weak assignment (?=).
This problem has been found when trying to build the latest version of
Xen tools using buildroot.
Fixes: d400dc5729 ("tools: tweak tools/libs/libs.mk for being able to support libxenctrl")
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
While trying to work around a different Clang-IAS bug (parent changeset), I
stumbled onto:
In file included from arch/x86/asm-macros.c:3:
./arch/x86/include/asm/spec_ctrl_asm.h:144:19: error: \u used with
no following hex digits; treating as '\' followed by identifier [-Werror,-Wunicode]
.L\@_fill_rsb_loop\uniq:
^
It turns out that Clang -E is sensitive to the file extension of the source
file it is processing. Furthermore, C explicitly permits the use of \u
escapes in identifier names, so the diagnostic would be reasonable in
principle if we trying to compile the result.
asm-macros should really have been .S from the outset, as it is ultimately
generating assembly, not C. Rename it, which causes Clang not to complain.
We need to introduce rules for generating a .i file from .S, and substituting
c_flags for a_flags lets us drop the now-redundant -D__ASSEMBLY__.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
https://github.com/llvm/llvm-project/issues/60792
It turns out that Clang-IAS does not expand \@ uniquely in a translaition
unit, and the XSA-426 change tickles this bug:
<instantiation>:4:1: error: invalid symbol redefinition
.L1_fill_rsb_loop:
^
make[3]: *** [Rules.mk:247: arch/x86/acpi/cpu_idle.o] Error 1
Extend DO_OVERWRITE_RSB with an optional parameter so C callers can mix %= in
too, which Clang does seem to expand properly.
Fixes: 63305e5392 ("x86/spec-ctrl: Mitigate Cross-Thread Return Address Predictions")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Also print the compiler version before starting. It's not easy to find
otherwise, and does change from time to time.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Delete the macros SVM_PAUSE{FILTER,THRESH}_INIT from svm.h and opencode
their values, since they are used in a single place and using macros is
just unnecessary obfuscation.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
An assert failure has been observed in p2m_teardown when performing vm
forking and then destroying the forked VM (p2m-basic.c:173). The assert
checks whether the domain's shared pages counter is 0. According to the
patch that originally added the assert (7bedbbb5c3) the p2m_teardown
should only happen after mem_sharing already relinquished all shared pages.
In this patch we flip the order in which relinquish ops are called to avoid
tripping the assert. Conceptually sharing being torn down makes sense to
happen before paging is torn down.
Fixes: e7aa55c0aa ("x86/p2m: free the paging memory pool preemptively")
Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
First, apt complain that it isn't the right way to add keys anymore,
but hopefully that's just a warning.
Second, we can't install clang-8:
The following packages have unmet dependencies:
clang-8 : Depends: libstdc++-8-dev but it is not installable
Depends: libgcc-8-dev but it is not installable
Depends: libobjc-8-dev but it is not installable
Recommends: llvm-8-dev but it is not going to be installed
Recommends: libomp-8-dev but it is not going to be installed
libllvm8 : Depends: libffi7 (>= 3.3~20180313) but it is not installable
E: Unable to correct problems, you have held broken packages.
clang on Debian unstable is now version 14.0.6.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
We already have a container which track the latest CentOS 7, no need
for this one as well.
Also, 7.2 have outdated root certificate which prevent connection to
website which use Let's Encrypt.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The attribute has no purpose here and, in the worst case, could lead to
the compiler generating worse code. In practice, however: No change to
generated code (surprisingly not even to generated debug info), at least
with gcc12 and the .config-s I've tried.
Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
In COVERAGE=y but DEBUG=n builds (observed by randconfig testing) gcc12
takes issue with the subtraction of 1 from __stop___pre_ex_table[],
considering this an out of bounds access. Not being able to know that
the symbol actually marks the end of an array, the compiler is kind of
right with this diagnosis. Move the subtraction into the function.
Reported-by: Anthony Perard <anthony.perard@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Both values are unconditionally overridden (to 0) in the "hvm" (i.e.
PVH) case. There's therefore no reason to punish a PVH kernel for
setting the former but not the latter.
Fixes: 632cbaf124 ("libelf: improve PVH elfnote parsing")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
This is the only file left with a use of an __s<N> type coming from
Linux. Since the file has been using an apparently random mix of all
three classes of fixed-width types (__{s,u}<N>, {s,u}<N>, and
{,u}int<N>_t), consolidate this to use exclusively standard types.
No functional change intended.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
It is easier just to make the functions void and let the compiler do the (not
very) hard work.
Passing regs is a bit weird for HVM guests anyway, because the resulting
pointer is invariant (this isn't native exception handling where the regs
pointers *are* important), and all functions calculate current themselves
which is another invariant.
Finally, the compiler can merge the get_cpu_info() calculation which is common
to both current and guest_cpu_user_regs(), meaning the delta in C really is
just one LEA, and not any more expensive than MOV's in ASM anyway.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Consolidate this to use exclusively standard types, and change
indentation style to Xen's there at the same time (the file already had
a mix of styles).
While there
- switch boolean fields to use bool,
- drop the notion of big-endian bitfields being a thing on x86,
- drop the names for reserved fields,
- adjust the comment on "dest32".
No functional change intended.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The original issue has been reported on AMD Bulldozer-based CPUs where
ucode loading loses the LWP feature bit in order to gain the IBPB bit.
LWP disabling is per-SMT/CMT core modification and needs to happen on
each sibling thread despite the shared microcode engine. Otherwise,
logical CPUs will end up with different cpuid capabilities.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216211
Guests running under Xen happen to be not affected because of levelling
logic for the feature masking/override MSRs which causes the LWP bit to
fall out and hides the issue. The latest recommendation from AMD, after
discussing this bug, is to load ucode on every logical CPU.
In Linux kernel this issue has been addressed by e7ad18d1169c
("x86/microcode/AMD: Apply the patch early on every logical thread").
Follow the same approach in Xen.
Introduce SAME_UCODE match result and use it for early AMD ucode
loading. Take this opportunity and move opt_ucode_allow_same out of
compare_revisions() to the relevant callers and also modify the warning
message based on it. Intel's side of things is modified for consistency
but provides no functional change.
Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Anthony PERARD