Add XEN_SYSCTL_PHYSCAP_X86_ASSISTED_XAPIC and
XEN_SYSCTL_PHYSCAP_X86_ASSISTED_X2APIC to report accelerated xAPIC and
x2APIC, on x86 hardware. This is so that xAPIC and x2APIC virtualization
can subsequently be enabled on a per-domain basis.
No such features are currently implemented on AMD hardware.
HW assisted xAPIC virtualization will be reported if HW, at the
minimum, supports virtualize_apic_accesses as this feature alone means
that an access to the APIC page will cause an APIC-access VM exit. An
APIC-access VM exit provides a VMM with information about the access
causing the VM exit, unlike a regular EPT fault, thus simplifying some
internal handling.
HW assisted x2APIC virtualization will be reported if HW supports
virtualize_x2apic_mode and, at least, either apic_reg_virt or
virtual_intr_delivery. This also means that
sysctl follows the conditionals in vmx_vlapic_msr_changed().
For that purpose, also add an arch-specific "capabilities" parameter
to struct xen_sysctl_physinfo.
Note that this interface is intended to be compatible with AMD so that
AVIC support can be introduced in a future patch. Unlike Intel that
has multiple controls for APIC Virtualization, AMD has one global
'AVIC Enable' control bit, so fine-graining of APIC virtualization
control cannot be done on a common interface.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jane Malalane <jane.malalane@citrix.com> Reviewed-by: "Roger Pau Monné" <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com> Acked-by: Christian Lindig <christian.lindig@citrix.com>
As it is coming up basically every release cycle of Xen, add a
reference to the discussion why the current release scheme has been
selected in the release management documentation.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Anthony PERARD [Mon, 11 Jul 2022 10:13:24 +0000 (12:13 +0200)]
tools/examples: cleanup Makefile
Don't check if a target exist before installing it. For directory,
install doesn't complain, and for file it would prevent from updating
them. Also remove the existing loop and instead install all files with
a single call to $(INSTALL_DATA).
Remove XEN_CONFIGS-y which isn't used.
Remove "build" target.
Add an empty line after the first comment. The comment isn't about
$(XEN_READMES), it is about the makefile as a whole.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Anthony PERARD [Mon, 11 Jul 2022 10:13:07 +0000 (12:13 +0200)]
tools/console: have one Makefile per program/directory
Sources of both xenconsoled and xenconsole are already separated into
different directory and don't share anything in common. Having two
different Makefile means it's easier to deal with *FLAGS.
Some common changes:
Rename $(BIN) to $(TARGETS), this will be useful later.
Stop removing *.so *.rpm *.a as they aren't created here.
Use $(OBJS-y) to list objects.
Update $(CFLAGS) for the directory rather than a single object.
daemon:
Remove the need for $(LDLIBS_xenconsoled), use $(LDLIBS) instead.
Remove the need for $(CONSOLE_CFLAGS-y) and use $(CFLAGS-y)
instead.
client:
Remove the unused $(LDLIBS_xenconsole)
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
xen/x86: remove cf_check attribute from hypercall handlers
Now that the hypercall handlers are all being called directly instead
through a function vector, the "cf_check" attribute can be removed.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com> # xsm parts Acked-by: Jan Beulich <jbeulich@suse.com> Tested-by: Téo Couprie Diaz <teo.coupriediaz@arm.com> Acked-by: Dario Faggioli <dfaggioli@suse.com>
xen/x86: call hypercall handlers via generated macro
Instead of using a function table use the generated macros for calling
the appropriate hypercall handlers.
This is beneficial to performance and avoids speculation issues.
With calling the handlers using the correct number of parameters now
it is possible to do the parameter register clobbering in the NDEBUG
case after returning from the handler. With the additional generated
data the hard coded hypercall_args_table[] can be replaced by tables
using the generated number of parameters.
Note that this change modifies behavior of clobbering registers in a
minor way: in case a hypercall is returning -ENOSYS (or the unsigned
equivalent thereof) for any reason the parameter registers will no
longer be clobbered. This should be of no real concern, as those cases
ought to be extremely rare and reuse of the registers in those cases
seems rather far fetched.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Instead of repeating similar data multiple times use a single source
file and a generator script for producing prototypes and call sequences
of the hypercalls.
As the script already knows the number of parameters used add generating
a macro for populating an array with the number of parameters per
hypercall.
The priorities for the specific hypercalls are based on two benchamrks
performed in guests (PV and PVH):
- make -j 4 of the Xen hypervisor (resulting in cpu load with lots of
processes created)
- scp of a large file to the guest (network load)
With a small additional debug patch applied the number of the
different hypercalls in the guest and in dom0 (for looking at backend
activity related hypercalls) were counted while the benchmark in domU
was running:
HVM-hypercall PVH-guest build PVH-guest scp
vcpu_op 277684 2324
event_channel_op 350233 57383
(the related dom0 counter values are in the same range as with the test
running in the PV guest)
Today most hypercall handlers have a return type of long, while the
compat ones return an int. There are a few exceptions from that rule,
however.
Get rid of the exceptions by letting compat handlers always return int
and others always return long, with the exception of the Arm specific
physdev_op handler.
For the compat hvm case use eax instead of rax for the stored result as
it should have been from the beginning.
Additionally move some prototypes to include/asm-x86/hypercall.h
as they are x86 specific. Move the compat_platform_op() prototype to
the common header.
Rename paging_domctl_continuation() to do_paging_domctl_cont() and add
a matching define for the associated hypercall.
Make do_callback_op() and compat_callback_op() more similar by adding
the const attribute to compat_callback_op()'s 2nd parameter.
Change the type of the cmd parameter for [do|compat]_kexec_op() to
unsigned int, as this is more appropriate for the compat case.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Christopher Clark <christopher.w.clark@gmail.com> # argo
SUPPORT.md doesn't seem to explicitly say whether static memory is
supported, so this commit updates SUPPORT.md to add feature static
allocation tech preview for now.
The variable __mon_lengths is referenced only in time.c.
Change its linkage from external to internal by adding the storage-class
specifier static to its definitions.
Also, this patch resolves indirectly a MISRA C 2012 Rule 8.4 violation warning.
Jan Beulich [Wed, 6 Jul 2022 11:05:23 +0000 (13:05 +0200)]
Revert "EFI: preserve the System Resource Table for dom0"
This reverts commit 8d410ac2c178e1dd1001cadddbe9ca75a9738c95,
for breaking booting (on at least Arm64), apparently due to
incomplete refactoring from an earlier version.
tools/libxl: report trusted backend status to frontends
Allow administrators to notify a frontend driver that it's backend
counterpart is not to be trusted, so the frontend can deploy whatever
mitigations required in order to secure itself.
Allow such option for disk and network frontends only, as those are
the only hardened ones currently supported.
This is part of XSA-403
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Xen uses "-fshort-wchar" in CFLAGS for EFI common code. Arm32
is using stub.c of EFI common code for EFI stub functions. But
"-fshort-wchar" CFLAG will cause a warning when build stub.c
for Arm32:
"arm-linux-gnueabihf-ld: warning: arch/arm/efi/built_in.o uses
2-byte wchar_t yet the output is to use 4-byte wchar_t; use of
wchar_t values across objects may fail"
This is because the "-fshort-wchar" flag causes GCC to generate
code that is not binary compatible with code generated without
that flag. Why this warning hasn't been triggered in Arm64 is
because Arm64 does not use wchar type directly in any code for
parameters, variables and return values. And in EFI code, wchar
has been replaced by CHAR16 (the UEFI "abstraction" of wchar_t).
CHAR16 has been specified as unsigned short type in typedef, the
"-fshort-wchar" flag will not affect CHAR16. So Arm64 object
files are exactly the same with "-fshort-wchar" and without
"-fshort-wchar".
We are also not using wchar in Arm32 codes, but Arm32 will embed
ABI information in ".ARM.attributes" section. This section stores
some object file attributes, like ABI version, CPU arch and etc.
And wchar size is described in this section by "Tag_ABI_PCS_wchar_t"
too. Tag_ABI_PCS_wchar_t is 2 for object files with "-fshort-wchar",
but for object files without "-fshort-wchar" is 4. Arm32 GCC
ld will check this tag, and throw above warning when it finds
the object files have different Tag_ABI_PCS_wchar_t values.
Xen need to keep "-fshort-wchar" in EFI code to force wchar to use
short integers (2 bytes) instead of integers (4 bytes), but this is
unnecessary for code out of EFI. So in this patch, we add
"-fno-short-wchar" to override "-fshort-wchar" for Arm architectures
without EFI enabled to remove above warning."
Reported-and-Suggested-by: Jan Beulich <jbeulich@suse.com> Tested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Wei Chen <wei.chen@arm.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Julien Grall <jgrall@amazon.com>
Jan Beulich [Tue, 5 Jul 2022 11:11:51 +0000 (13:11 +0200)]
public: constify xsd_errors[]
While in principle this could break existing users, I think such users
deserve to be put in trouble. After all the table should have been const
from the very beginning.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com>
tools/helpers: fix snprintf argument in init-dom0less.c
Fix snprintf argument in init-dom0less.c because two instances of
the function are using libxl_dominfo struct members that are uint64_t
types, so change "%lu" to "%"PRIu64 to handle it properly when
building on arm32 and arm64.
The EFI System Resource Table (ESRT) is necessary for fwupd to identify
firmware updates to install. According to the UEFI specification §23.4,
the ESRT shall be stored in memory of type EfiBootServicesData. However,
memory of type EfiBootServicesData is considered general-purpose memory
by Xen, so the ESRT needs to be moved somewhere where Xen will not
overwrite it. Copy the ESRT to memory of type EfiRuntimeServicesData,
which Xen will not reuse. dom0 can use the ESRT if (and only if) it is
in memory of type EfiRuntimeServicesData.
Earlier versions of this patch reserved the memory in which the ESRT was
located. This created awkward alignment problems, and required either
splitting the E820 table or wasting memory. It also would have required
a new platform op for dom0 to use to indicate if the ESRT is reserved.
By copying the ESRT into EfiRuntimeServicesData memory, the E820 table
does not need to be modified, and dom0 can just check the type of the
memory region containing the ESRT. The copy is only done if the ESRT is
not already in EfiRuntimeServicesData memory, avoiding memory leaks on
repeated kexec.
See https://lore.kernel.org/xen-devel/20200818184018.GN1679@mail-itl/T/
for details.
Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Daniel P. Smith [Mon, 4 Jul 2022 12:47:00 +0000 (14:47 +0200)]
flask: implement xsm_set_system_active
This commit implements full support for starting the idle domain privileged by
introducing a new flask label xenboot_t which the idle domain is labeled with
at creation. It then provides the implementation for the XSM hook
xsm_set_system_active to relabel the idle domain to the existing xen_t flask
label.
In the reference flask policy a new macro, xen_build_domain(target), is
introduced for creating policies for dom0less/hyperlaunch allowing the
hypervisor to create and assign the necessary resources for domain
construction.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Reviewed-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com> Tested-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Rahul Singh <rahul.singh@arm.com> Tested-by: Rahul Singh <rahul.singh@arm.com>
Daniel P. Smith [Mon, 4 Jul 2022 12:46:02 +0000 (14:46 +0200)]
xsm: create idle domain privileged and demote after setup
There are new capabilities, dom0less and hyperlaunch, that introduce internal
hypervisor logic, which needs to make resource allocation calls that are
protected by XSM access checks. The need for these resource allocations are
necessary for dom0less and hyperlaunch when they are constructing the initial
domain(s). This creates an issue as a subset of the hypervisor code is
executed under a system domain, the idle domain, that is represented by a
per-CPU non-privileged struct domain. To enable these new capabilities to
function correctly but in a controlled manner, this commit changes the idle
system domain to be created as a privileged domain under the default policy and
demoted before transitioning to running. A new XSM hook,
xsm_set_system_active(), is introduced to allow each XSM policy type to demote
the idle domain appropriately for that policy type. In the case of SILO, it
inherits the default policy's hook for xsm_set_system_active().
For flask, a stub is added to ensure that flask policy system will function
correctly with this patch until flask is extended with support for starting the
idle domain privileged and properly demoting it on the call to
xsm_set_system_active().
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Reviewed-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com> Acked-by: Julien Grall <jgrall@amazon.com> # arm Reviewed-by: Rahul Singh <rahul.singh@arm.com> Tested-by: Rahul Singh <rahul.singh@arm.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Add instructions on how to build cppcheck, the version currently used
and an example to use the cppcheck integration to run the analysis on
the Xen codebase
cppcheck MISRA addon can be used to check for non compliance to some of
the MISRA standard rules.
Add a CPPCHECK_MISRA variable that can be set to "y" using make command
line to generate a cppcheck report including cppcheck misra checks.
When MISRA checking is enabled, a file with a text description suitable
for cppcheck misra addon is generated out of Xen documentation file
which lists the rules followed by Xen (docs/misra/rules.rst).
By default MISRA checking is turned off.
While adding cppcheck-misra files to gitignore, also fix the missing /
for htmlreport gitignore
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com> Reviewed-by: Michal Orzel <michal.orzel@arm.com> Tested-by: Michal Orzel <michal.orzel@arm.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Dmytro Semenets [Thu, 23 Jun 2022 07:44:28 +0000 (10:44 +0300)]
xen: arm: Don't use stop_cpu() in halt_this_cpu()
When shutting down (or rebooting) the platform, Xen will call stop_cpu()
on all the CPUs but one. The last CPU will then request the system to
shutdown/restart.
On platform using PSCI, stop_cpu() will call PSCI CPU off. Per the spec
(section 5.5.2 DEN0022D.b), the call could return DENIED if the Trusted
OS is resident on the CPU that is about to be turned off.
As Xen doesn't migrate off the trusted OS (which BTW may not be
migratable), it would be possible to hit the panic().
In the ideal situation, Xen should migrate the trusted OS or make sure
the CPU off is not called. However, when shutting down (or rebooting)
the platform, it is pointless to try to turn off all the CPUs (per
section 5.10.2, it is only required to put the core in a known state).
So solve the problem by open-coding stop_cpu() in halt_this_cpu() and
not call PSCI CPU off.
Julien Grall [Thu, 30 Jun 2022 18:37:34 +0000 (19:37 +0100)]
public/io: xs_wire: Allow Xenstore to report EPERM
C Xenstored is using EPERM when the client is not allowed to change
the owner (see GET_PERMS). However, the xenstore protocol doesn't
describe EPERM so EINVAL will be sent to the client.
When writing test, it would be useful to differentiate between EINVAL
(e.g. parsing error) and EPERM (i.e. no permission). So extend
xsd_errors[] to support return EPERM.
Looking at previous time xsd_errors was extended (8b2c441a1b), it was
considered to be safe to add a new error because at least Linux driver
and libxenstore treat an unknown error code as EINVAL.
This statement doesn't cover other possible OSes, however I am not
aware of any breakage.
Roger Pau Monne [Thu, 30 Jun 2022 16:34:49 +0000 (18:34 +0200)]
x86/ept: fix shattering of special pages
The current logic in epte_get_entry_emt() will split any page marked
as special with order greater than zero, without checking whether the
super page is all special.
Fix this by only splitting the page only if it's not all marked as
special, in order to prevent unneeded super page shuttering.
The unconditional special super page shattering has caused a
performance regression on some XenServer GPU pass through workloads.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Andrew Cooper [Wed, 16 Mar 2022 13:07:40 +0000 (13:07 +0000)]
x86/spec-ctrl: Knobs for STIBP and PSFD, and follow hardware STIBP hint
STIBP and PSFD are slightly weird bits, because they're both implied by other
bits in MSR_SPEC_CTRL. Add fine grain controls for them, and take the
implications into account when setting IBRS/SSBD.
Rearrange the IBPB text/variables/logic to keep all the MSR_SPEC_CTRL bits
together, for consistency.
However, AMD have a hardware hint CPUID bit recommending that STIBP be set
unilaterally. This is advertised on Zen3, so follow the recommendation.
Furthermore, in such cases, set STIBP behind the guest's back for now. This
has negligible overhead for the guest, but saves a WRMSR on vmentry. This is
the only default 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>
Andrew Cooper [Mon, 27 Jun 2022 10:54:27 +0000 (11:54 +0100)]
x86/spec-ctrl: Only adjust MSR_SPEC_CTRL for idle with legacy IBRS
Back at the time of the original Spectre-v2 fixes, it was recommended to clear
MSR_SPEC_CTRL when going idle. This is because of the side effects on the
sibling thread caused by the microcode IBRS and STIBP implementations which
were retrofitted to existing CPUs.
However, there are no relevant cross-thread impacts for the hardware
IBRS/STIBP implementations, so this logic should not be used on Intel CPUs
supporting eIBRS, or any AMD CPUs; doing so only adds unnecessary latency to
the idle path.
Furthermore, there's no point playing with MSR_SPEC_CTRL in the idle paths if
SMT is disabled for other reasons.
Fixes: 8d03080d2a33 ("x86/spec-ctrl: Cease using thunk=lfence on AMD") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Xenia Ragiadakou [Tue, 28 Jun 2022 15:08:51 +0000 (18:08 +0300)]
xen/arm: smmu-v3: Fix MISRA C 2012 Rule 1.3 violations
The expression 1 << 31 produces undefined behaviour because the type of integer
constant 1 is (signed) int and the result of shifting 1 by 31 bits is not
representable in the (signed) int type.
Change the type of 1 to unsigned int by adding the U suffix.
Michal Orzel [Tue, 28 Jun 2022 15:25:11 +0000 (17:25 +0200)]
include/public: Use uint32_t instead of unsigned (int)
Public interfaces shall make use of types that indicate size and
signedness. Take the opportunity to also modify places where explicit
unsigned int is used.
Signed-off-by: Michal Orzel <michal.orzel@arm.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Xenia Ragiadakou [Tue, 28 Jun 2022 15:07:38 +0000 (17:07 +0200)]
arm64/traps: fix MISRA C 2012 Rule 8.4 violations
Add a function prototype for do_bad_mode() in <asm/arm64/traps.h> and include
header <asm/traps.h> in traps.c, so that the declarations of the functions
do_bad_mode() and finalize_instr_emulation(), which have external linkage,
are visible before the function definitions.
Xenia Ragiadakou [Tue, 28 Jun 2022 15:07:11 +0000 (17:07 +0200)]
iommu: fix MISRA C 2012 Rule 8.7 violation
The variable iommu_crash_disable is referenced only in one translation unit.
Change its linkage from external to internal by adding the storage-class
specifier static to its definition.
This patch also aims to resolve indirectly a MISRA C 2012 Rule 8.4 violation
warning.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Xenia Ragiadakou [Tue, 28 Jun 2022 15:06:37 +0000 (17:06 +0200)]
page_alloc: fix MISRA C 2012 Rule 8.7 violation
The variables page_offlined_list and page_broken_list are referenced only
in page_alloc.c.
Change their linkage from external to internal by adding the storage-class
specifier static to their definitions.
This patch also aims to resolve indirectly a MISRA C 2012 Rule 8.4 violation
warning.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Juergen Gross [Tue, 28 Jun 2022 15:06:14 +0000 (17:06 +0200)]
tools/xenstore: modify feature bit specification in xenstore-ring.txt
Instead of specifying the feature bits in xenstore-ring.txt as a mask
value use bit numbers. This will make the specification easier to read
when adding more features.
Juergen Gross [Tue, 28 Jun 2022 15:02:42 +0000 (17:02 +0200)]
xen: move do_vcpu_op() to arch specific code
The entry point used for the vcpu_op hypercall on Arm is different
from the one on x86 today, as some of the common sub-ops are not
supported on Arm. The Arm specific handler filters out the not
supported sub-ops and then calls the common handler. This leads to the
weird call hierarchy:
do_arm_vcpu_op()
do_vcpu_op()
arch_do_vcpu_op()
Clean this up by renaming do_vcpu_op() to common_vcpu_op() and
arch_do_vcpu_op() in each architecture to do_vcpu_op(). This way one
of above calls can be avoided without restricting any potential
future use of common sub-ops for Arm.
Jan Beulich [Tue, 28 Jun 2022 15:00:29 +0000 (17:00 +0200)]
x86: correct asm() constraints when dealing with immediate selector values
asm() constraints need to fit both the intended insn(s) which the
respective operands are going to be used with as well as the actual kind
of value specified. "m" (alone) together with a constant, however, leads
to gcc saying
error: memory input <N> is not directly addressable
while clang complains
error: invalid lvalue in asm input for constraint 'm'
And rightly so - in order to access a memory operand, an address needs
to be specified to the insn. In some cases it might be possible for a
compiler to synthesize a memory operand holding the requested constant,
but I think any solution there would have sharp edges.
If "m" alone doesn't work with constants, it is at best pointless (and
perhaps misleading or even risky - the compiler might decide to actually
pick "m" and not try very hard to find a suitable register) to specify
it alongside "r". And indeed clang does, oddly enough despite its
objection to "m" alone. Which means there the change also improves the
generated code.
While there also switch the two operand case to using named operands.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Julien Grall [Sat, 25 Jun 2022 14:52:39 +0000 (15:52 +0100)]
xen/arm: irq: Initialize the per-CPU IRQs while preparing the CPU
Commit 5047cd1d5dea "xen/common: Use enhanced ASSERT_ALLOC_CONTEXT in
xmalloc()" extended the checks in _xmalloc() to catch any use of the
helpers from context with interrupts disabled.
Unfortunately, the rule is not followed when initializing the per-CPU
IRQs:
Xenia Ragiadakou [Wed, 22 Jun 2022 15:15:14 +0000 (18:15 +0300)]
xen/common: gunzip: Fix MISRA C 2012 Rule 8.4 violation
Include header <xen/gunzip.h> so that the declarations of functions gzip_check()
and perform_gunzip(), which have external linkage, are visible before the
function definitions.
Xenia Ragiadakou [Wed, 22 Jun 2022 15:15:13 +0000 (18:15 +0300)]
xen/lib: list-sort: Fix MISRA C 2012 Rule 8.4 violation
Include header <xen/list_sort.h> so that the declaration of the function
list_sort(), which has external linkage, is visible before the function
definition.
Xenia Ragiadakou [Wed, 22 Jun 2022 15:15:12 +0000 (18:15 +0300)]
xen/arm: shutdown: Fix MISRA C 2012 Rule 8.4 violation
Include header <xen/shutdown.h> so that the declarations of the functions
machine_halt() and machine_restart(), which have external linkage, are visible
before the function definitions.
Xenia Ragiadakou [Wed, 22 Jun 2022 15:15:57 +0000 (18:15 +0300)]
xen/common: device_tree: Fix MISRA C 2012 Rule 8.7 violation
The function __dt_n_size_cells() is referenced only in device_tree.c.
Change the linkage of the function from external to internal by adding
the storage-class specifier static to the function definition.
This patch aims to resolve indirectly a MISRA C 2012 Rule 8.4 violation
warning.
Julien Grall [Thu, 23 Jun 2022 12:43:23 +0000 (13:43 +0100)]
tools/xenstored: Harden corrupt()
At the moment, corrupt() is neither checking for allocation failure
nor freeing the allocated memory.
Harden the code by printing ENOMEM if the allocation failed and
free 'str' after the last use.
This is not considered to be a security issue because corrupt() should
only be called when Xenstored thinks the database is corrupted. Note
that the trigger (i.e. a guest reliably provoking the call) would be
a security issue.
Fixes: 06d17943f0cd ("Added a basic integrity checker, and some basic ability to recover from store") Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Juergen Gross <jgross@suse.com>
Anthony PERARD [Thu, 23 Jun 2022 07:40:12 +0000 (09:40 +0200)]
build,include: rework shell script for headers++.chk
The command line generated for headers++.chk by make is quite long,
and in some environment it is too long. This issue have been seen in
Yocto build environment.
Error messages:
make[9]: execvp: /bin/sh: Argument list too long
make[9]: *** [include/Makefile:181: include/headers++.chk] Error 127
Rework so that we do the foreach loop in shell rather that make to
reduce the command line size by a lot. We also need a way to get
headers prerequisite for some public headers so we use a switch "case"
in shell to be able to do some simple pattern matching. Variables
alone in POSIX shell don't allow to work with associative array or
variables with "/".
Also rework headers99.chk as it has a similar implementation, even if
with only two headers to check the command line isn't too long at the
moment.
Fixes: 28e13c7f43 ("build: xen/include: use if_changed") Reported-by: Bertrand Marquis <Bertrand.Marquis@arm.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com> Reviewed-by: Michal Orzel <michal.orzel@arm.com> Tested-by: Michal Orzel <michal.orzel@arm.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Thu, 23 Jun 2022 07:38:58 +0000 (09:38 +0200)]
x86emul/test: improve failure location identification for FMA sub-test
When some FMA set of insns is included in the base instruction set (XOP,
AVX512F, and AVX512-FP16 at present), simd_test() simply invokes
fma_test(), negating its return value. In case of a failure this would
yield a value close to 4G, which doesn't lend itself to easy
identification of the failing test case. Recognize the case in
simd_check_regs() and emit alternative output identifying FMA.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Julien Grall [Wed, 22 Jun 2022 17:51:17 +0000 (18:51 +0100)]
xen/arm: smpboot: Allocate the CPU sibling/core maps while preparing the CPU
Commit 5047cd1d5dea "xen/common: Use enhanced ASSERT_ALLOC_CONTEXT in
xmalloc()" extended the checks in _xmalloc() to catch any use of the
helpers from context with interrupts disabled.
Unfortunately, the rule is not followed when allocating the CPU
sibling/core maps.
Andrew Cooper [Thu, 16 Jun 2022 11:08:02 +0000 (12:08 +0100)]
x86/mm: Add an early PGT_validated exit in _get_page_type()
This is a continuation of the cleanup and commenting in: 9186e96b199e ("x86/pv: Clean up _get_page_type()") 8cc5036bc385 ("x86/pv: Fix ABAC cmpxchg() race in _get_page_type()")
With the re-arranged and newly commented logic, it's now obvious that the
second half of _get_page_type() only has work to do for page validation.
Introduce an early exit for PGT_validated. This makes the fastpath marginally
faster, and simplifies the subsequent logic as it no longer needs to exclude
the fully validated case.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monné [Mon, 20 Jun 2022 12:35:00 +0000 (14:35 +0200)]
tools/include: drop leading underscore from xen_list header
A leading underscore is used to indicate auto generated headers, and
the clean use of 'rm -f _*.h' will remove those. _xen_list.h also
uses a leading underscore, but is checked in the repo and as such
cannot be removed as part of the clean rule.
Fix this by dropping the leading underscore, so that the header is not
removed.
Wei Chen [Fri, 10 Jun 2022 05:53:16 +0000 (13:53 +0800)]
xen/x86: use INFO level for node's without memory log message
In previous code, Xen was using KERN_WARNING for log message
when Xen found a node without memory. Xen will print this
warning message, and said that this may be an BIOS Bug or
mis-configured hardware. But actually, this warning is bogus,
because in an NUMA setting, nodes can only have processors,
and with 0 bytes memory. So it is unreasonable to warn about
BIOS or hardware corruption based on the detection of node
with 0 bytes memory.
So in this patch, we remove the warning messages, but just
keep an info message to info users that there is one or more
nodes with 0 bytes memory in the system.
Signed-off-by: Wei Chen <wei.chen@arm.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Wei Chen [Fri, 10 Jun 2022 05:53:15 +0000 (13:53 +0800)]
xen/x86: add detection of memory interleaves for different nodes
One NUMA node may contain several memory blocks. In current Xen
code, Xen will maintain a node memory range for each node to cover
all its memory blocks. But here comes the problem, in the gap of
one node's two memory blocks, if there are some memory blocks don't
belong to this node (remote memory blocks). This node's memory range
will be expanded to cover these remote memory blocks.
One node's memory range contains other nodes' memory, this is
obviously not very reasonable. This means current NUMA code only
can support node has no interleaved memory blocks. However, on a
physical machine, the addresses of multiple nodes can be interleaved.
So in this patch, we add code to detect memory interleaves of
different nodes. NUMA initialization will be failed and error
messages will be printed when Xen detect such hardware configuration.
As we have checked the node's range before, for a non-empty node,
the "nd->end == end && nd->start == start" check is unnecesary.
So we remove it from conflicting_memblks as well.
Wei Chen [Fri, 10 Jun 2022 05:53:14 +0000 (13:53 +0800)]
xen/x86: use paddr_t for addresses in NUMA node structure
NUMA node structure "struct node" is using u64 as node memory
range. In order to make other architectures can reuse this
NUMA node relative code, we replace the u64 to paddr_t. And
use pfn_to_paddr and paddr_to_pfn to replace explicit shift
operations. The relate PRIx64 in print messages have been
replaced by PRIpaddr at the same time. And some being-phased-out
types like u64 in the lines we have touched also have been
converted to uint64_t or unsigned long.
Wei Chen [Fri, 10 Jun 2022 05:53:13 +0000 (13:53 +0800)]
xen/arm: use !CONFIG_NUMA to keep fake NUMA API
We have introduced CONFIG_NUMA in a previous patch. And this
option is enabled only on x86 at the current stage. In a follow
up patch, we will enable this option for Arm. But we still
want users to be able to disable the CONFIG_NUMA via Kconfig. In
this case, keep the fake NUMA API, will make Arm code still
able to work with NUMA aware memory allocation and scheduler.
Wei Chen [Fri, 10 Jun 2022 05:53:12 +0000 (13:53 +0800)]
xen: decouple NUMA from ACPI in Kconfig
In current Xen code only implements x86 ACPI-based NUMA support.
So in Xen Kconfig system, NUMA equals to ACPI_NUMA. x86 selects
NUMA by default, and CONFIG_ACPI_NUMA is hardcode in config.h.
In a follow-up patch, we will introduce support for NUMA using
the device tree. That means we will have two NUMA implementations,
so in this patch we decouple NUMA from ACPI based NUMA in Kconfig.
Make NUMA as a common feature, that device tree based NUMA also
can select it.
Wei Chen [Fri, 10 Jun 2022 05:53:11 +0000 (13:53 +0800)]
xen: introduce an arch helper for default dma zone status
In current code, when Xen is running in a multiple nodes
NUMA system, it will set dma_bitsize in end_boot_allocator
to reserve some low address memory as DMA zone.
There are some x86 implications in the implementation.
Because on x86, memory starts from 0. On a multiple-nodes
NUMA system, if a single node contains the majority or all
of the DMA memory, x86 prefers to give out memory from
non-local allocations rather than exhausting the DMA memory
ranges. Hence x86 uses dma_bitsize to set aside some largely
arbitrary amount of memory for DMA zone. The allocations
from DMA zone would happen only after exhausting all other
nodes' memory.
But the implications are not shared across all architectures.
For example, Arm cannot guarantee the availability of memory
below a certain boundary for DMA limited-capability devices
either. But currently, Arm doesn't need a reserved DMA zone
in Xen. Because there is no DMA device in Xen. And for guests,
Xen Arm only allows Dom0 to have DMA operations without IOMMU.
Xen will try to allocate memory under 4GB or memory range that
is limited by dma_bitsize for Dom0 in boot time. For DomU, even
Xen can passthrough devices to DomU without IOMMU, but Xen Arm
doesn't guarantee their DMA operations. So, Xen Arm doesn't
need a reserved DMA zone to provide DMA memory for guests.
In this patch, we introduce an arch_want_default_dmazone helper
for different architectures to determine whether they need to
set dma_bitsize for DMA zone reservation or not.
At the same time, when x86 Xen is built with CONFIG_PV=n could
probably leverage this new helper to actually not trigger DMA
zone reservation.
Wei Chen [Fri, 10 Jun 2022 05:53:10 +0000 (13:53 +0800)]
xen/arm: Keep memory nodes in device tree when Xen boots from EFI
In current code, when Xen is booting from EFI, it will delete
all memory nodes in device tree. This would work well in current
stage, because Xen can get memory map from EFI system table.
However, EFI system table cannot completely replace memory nodes
of device tree. EFI system table doesn't contain memory NUMA
information. Xen depends on ACPI SRAT or device tree memory nodes
to parse memory blocks' NUMA mapping. So in EFI + DTB boot, Xen
doesn't have any method to get numa-node-id for memory blocks any
more. This makes device tree based NUMA support become impossible
for Xen in EFI + DTB boot.
So in this patch, we will keep memory nodes in device tree for
NUMA code to parse memory numa-node-id later.
As a side effect, if we still parse boot memory information in
early_scan_node, bootmem.info will calculate memory ranges in
memory nodes twice. So we have to prevent early_scan_node to
parse memory nodes in EFI boot.
Wei Chen [Fri, 10 Jun 2022 05:53:09 +0000 (13:53 +0800)]
xen: reuse x86 EFI stub functions for Arm
x86 is using compiler feature testing to decide EFI build
enable or not. When EFI build is disabled, x86 will use an
efi/stub.c file to replace efi/runtime.c for build objects.
Following this idea, we introduce a stub file for Arm, but
use CONFIG_ARM_EFI to decide EFI build enable or not.
And the most functions in x86 EFI stub.c can be reused for
other architectures, like Arm. So we move them to common
and keep the x86 specific function in x86/efi/stub.c.
To avoid the symbol link conflict error when linking common
stub files to x86/efi. We add a regular file check in efi
stub files' link script. Depends on this check we can bypass
the link behaviors for existed stub files in x86/efi.
As there is no Arm specific EFI stub function for Arm in
current stage, Arm still can use the existed symbol link
method for EFI stub files.
Anthony PERARD [Fri, 25 Feb 2022 15:13:21 +0000 (15:13 +0000)]
tools/ocaml: fix build dependency target
They are two competiting spelling for the variable holding the path to
"tools/ocaml", $(TOPLEVEL) and $(OCAML_TOPLEVEL). The "Makefile.rules"
which is included in all ocaml Makefiles have one rule which make use
of that variable which is then sometime unset. When building
"ocaml/xenstored", make isn't capable of generating ".ocamldep.make"
because $(TOPLEVEL) isn't defined in this case.
This can fail with an error like this when paths.ml have been
regenerated:
Error: Files define.cmx and paths.cmx
make inconsistent assumptions over interface Paths
This patch fix ".ocamldep.make" rule by always spelling the variable
$(OCAML_TOPLEVEL).
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Christian Lindig <christian.lindig@citrix.com>
When we will convert tools/ build system, their will be a need to
replace some use of "vpath". This will done making symbolic links.
Those symlinks are not wanted by stubdom build system when making a
linkfarm for the Xen libraries. To avoid them, we will use `find`
instead of plain shell globbing.
For example, there will be a link to "xen/lib/x86/cpuid.o" in
"tools/libs/guest/".
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Anthony PERARD [Fri, 25 Feb 2022 15:13:16 +0000 (15:13 +0000)]
stubdom: introduce xenlibs.mk
This new makefile will be used to build libraries that provides
"Makefile.common".
At some point, we will be converting Makefile in tools/ to "subdirmk"
and stubdom build will not be able to use those new makefiles, so we
will put the necessary information for stubdom to build the xen
libraries into a new Makefile.common and xenlibs.mk will use it.
We only need to build static libraries and don't need anything else.
The check for the presence of "Makefile.common" will go aways once
there is one for all libraries used by stubdom build.
Also remove DESTDIR= from "clean" targets, we don't do installation in
this recipe so the value of DESTDIR doesn't matter.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Anthony PERARD [Fri, 25 Feb 2022 15:13:14 +0000 (15:13 +0000)]
libs/stat: Fix and rework perl-binding build
For PERL_FLAGS, use make's shell rather than a backquote.
Rather than relying on the VCS to create an empty directory for us,
we can create one before generating the *.c file for the bindings.
Make use of generic variable names to build a shared library from a
source file: CFLAGS, LDFLAGS, and LDLIBS.
To build a shared library, we need to build the source file with
"-fPIC", which was drop by 6d0ec05390 (tools: split libxenstat into
new tools/libs/stat directory).
The source file generated by swig seems to be missing many prototype for
many functions, so we need "-Wno-missing-prototypes" in order to
build it. Also, one of the prototype is deemed malformed, so we also
need "-Wno-strict-prototypes".
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Juergen Gross <jgross@suse.com>
Anthony PERARD [Fri, 25 Feb 2022 15:13:13 +0000 (15:13 +0000)]
libs/stat: Fix and rework python-bindings build
Fix the dependency on the library, $(SHLIB) variable doesn't exist
anymore.
Rework dependency on the include file, we can let `swig` generate the
dependency for us with the use of "-M*" flags.
The xenstat.h file has moved so we need to fix the include location.
Rather than relaying on the VCS to create an empty directory for us,
we can create one before generating the *.c file for the bindings.
Make use of generic variable names to build a shared library from a
source file: CFLAGS, LDFLAGS, and LDLIBS.
Fix python's specific *flags by using python-config, and add them to
generic flags variables: CFLAGS, LDLIBS.
To build a shared library, we need to build the source file with
"-fPIC", which was drop by 6d0ec05390 (tools: split libxenstat into
new tools/libs/stat directory).
The source file generated by swig seems to be missing a prototype for
the "init" function, so we need "-Wno-missing-prototypes" in order to
build it.
Add some targets to .PHONY.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Juergen Gross <jgross@suse.com>
Anthony PERARD [Fri, 25 Feb 2022 15:13:09 +0000 (15:13 +0000)]
libs: Rename $(SRCS-y) to $(OBJS-y)
The only thing done thing done with $(SRCS-y) is to replace ".c" by
".o". It is more useful to collect which object we want to build as
make will figure out how to build it and from which source file.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Juergen Gross <jgross@suse.com>
Anthony PERARD [Fri, 25 Feb 2022 15:13:03 +0000 (15:13 +0000)]
tools/xenstore: Cleanup makefile
Regroup *FLAGS together, use $(LDLIBS).
Remove $(LDLIBS_xenstored) which was the wrong name name as it doesn't
decribe how to link to a potential libxenstored.so, instead add the
value to $(LDLIBS) of xenstored.
Add SYSTEMD_LIBS into $(LDLIBS) instead of $(LDFLAGS).
Remove the "-I." from $(CFLAGS), it shouldn't be needed.
Removed $(CFLAGS-y) and $(LDFLAGS-y). $(CFLAGS-y) is already included
in $(CFLAGS) and both aren't used anyway.
Rename ALL_TARGETS to TARGETS.
Only add programmes we want to build in $(TARGETS), not phony-targets
(replace "clients").
Store all `xenstored` objs into $(XENSTORED_OBJS-y).
Replace one $< by $^ even if there's only one dependency,
(xenstore-control).
clean: "init-xenstore-domain" isn't built here any more, so stop
trying to remove it, remove $(TARGETS). Also regroup all files to be
removed in one command, using $(RM).
Drop $(MAJOR) and $(MINOR), they aren't used anymore.
Drop ".SECONDARY:", it doesn't appear there's intermediate files that
would be deleted anymore.
Drop "tarball:" target.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Juergen Gross <jgross@suse.com>
Fixes: 322ecbe4ac85 ("console: add EHCI debug port based serial console") Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Mon, 13 Jun 2022 18:18:32 +0000 (19:18 +0100)]
x86/spec-ctrl: Add spec-ctrl=unpriv-mmio
Per Xen's support statement, PCI passthrough should be to trusted domains
because the overall system security depends on factors outside of Xen's
control.
As such, Xen, in a supported configuration, is not vulnerable to DRPW/SBDR.
However, users who have risk assessed their configuration may be happy with
the risk of DoS, but unhappy with the risk of cross-domain data leakage. Such
users should enable this option.
On CPUs vulnerable to MDS, the existing mitigations are the best we can do to
mitigate MMIO cross-domain data leakage.
On CPUs fixed to MDS but vulnerable MMIO stale data leakage, this option:
* On CPUs susceptible to FBSDP, mitigates cross-domain fill buffer leakage
using FB_CLEAR.
* On CPUs susceptible to SBDR, mitigates RNG data recovery by engaging the
srb-lock, previously used to mitigate SRBDS.
Both mitigations require microcode from IPU 2022.1, May 2022.
This is part of XSA-404.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Andrew Cooper [Mon, 20 Sep 2021 17:47:49 +0000 (18:47 +0100)]
x86/spec-ctrl: Enumeration for MMIO Stale Data controls
The three *_NO bits indicate non-susceptibility to the SSDP, FBSDP and PSDP
data movement primitives.
FB_CLEAR indicates that the VERW instruction has re-gained it's Fill Buffer
flushing side effect. This is only enumerated on parts where VERW had
previously lost it's flushing side effect due to the MDS/TAA vulnerabilities
being fixed in hardware.
FB_CLEAR_CTRL is available on a subset of FB_CLEAR parts where the Fill Buffer
clearing side effect of VERW can be turned off for performance reasons.
This is part of XSA-404.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Andrew Cooper [Mon, 13 Jun 2022 15:19:01 +0000 (16:19 +0100)]
x86/spec-ctrl: Make VERW flushing runtime conditional
Currently, VERW flushing to mitigate MDS is boot time conditional per domain
type. However, to provide mitigations for DRPW (CVE-2022-21166), we need to
conditionally use VERW based on the trustworthiness of the guest, and the
devices passed through.
Remove the PV/HVM alternatives and instead issue a VERW on the return-to-guest
path depending on the SCF_verw bit in cpuinfo spec_ctrl_flags.
Introduce spec_ctrl_init_domain() and d->arch.verw to calculate the VERW
disposition at domain creation time, and context switch the SCF_verw bit.
For now, VERW flushing is used and controlled exactly as before, but later
patches will add per-domain cases too.
No change in behaviour.
This is part of XSA-404.
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>
Bertrand Marquis [Mon, 13 Jun 2022 12:53:14 +0000 (13:53 +0100)]
arm: Define kconfig symbols used by arm64 cpufeatures
Define kconfig symbols which are used by arm64 cpufeatures to prevent
using undefined symbols and rely on IS_ENABLED returning false.
All the features related to those symbols are unsupported by Xen:
- pointer authentication
- sve
- memory tagging
- branch target identification
Bertrand Marquis [Mon, 13 Jun 2022 12:53:13 +0000 (13:53 +0100)]
arm: add ISAR2, MMFR0 and MMFR1 fields in cpufeature
Complete AA64ISAR2 and AA64MMFR[0-1] with more fields.
While there add a comment for MMFR bitfields as for other registers in
the cpuinfo structure definition.
Bertrand Marquis [Mon, 13 Jun 2022 12:53:12 +0000 (13:53 +0100)]
xen/arm: Add sb instruction support
This patch is adding sb instruction support when it is supported by a
CPU on arm64.
A new cpu feature capability system is introduced to enable alternative
code using sb instruction when it is supported by the processor. This is
decided based on the isa64 system register value and use a new hardware
capability ARM_HAS_SB.
The sb instruction is encoded using its hexadecimal value to avoid
recursive macro and support old compilers not having support for sb
instruction.
Arm32 instruction support is added but it is not enabled at the moment
due to the lack of hardware supporting it.
Bertrand Marquis [Mon, 13 Jun 2022 12:53:11 +0000 (13:53 +0100)]
xen/arm: Sync sysregs and cpuinfo with Linux 5.18-rc3
Sync existing ID registers sanitization with the status of Linux kernel
version 5.18-rc3 and add sanitization of ISAR2 registers.
Sync sysregs.h bit shift defintions with the status of Linux kernel
version 5.18-rc3.
Changes in this patch are splitted in a number of patches in Linux
kernel and, as the previous synchronisation point was not clear, the
changes are done in one patch with a status possible to compare easily
by diffing Xen files to Linux kernel files.
Anthony PERARD [Wed, 15 Jun 2022 08:24:06 +0000 (10:24 +0200)]
build: remove auto.conf prerequisite from compat/xlat.h target
Now that the command line generating "xlat.h" is check on rebuild, the
header will be regenerated whenever the list of xlat headers changes
due to change in ".config". We don't need to force a regeneration for
every changes in ".config".
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Wed, 15 Jun 2022 08:23:16 +0000 (10:23 +0200)]
build: fix exporting for make 3.82
GNU make 3.82 apparently has a quirk where exporting an undefined
variable prevents its value from subsequently being updated. This
situation can arise due to our adding of -rR to MAKEFLAGS, which takes
effect also on make simply re-invoking itself. Once these flags are in
effect, CC (in particular) is empty (undefined), and would be defined
only via Config.mk including StdGNU.mk or alike. With the quirk, CC
remains empty, yet with an empty CC the compiler minimum version check
fails, breaking the build.
Move the exporting of the various tool stack component variables past
where they gain their (final) values.
See also be63d9d47f57 ("build: tweak variable exporting for make 3.82").
Fixes: 15a0578ca4b0 ("build: shuffle main Makefile") Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Jane Malalane [Wed, 15 Jun 2022 08:21:08 +0000 (10:21 +0200)]
x86/hvm: widen condition for is_hvm_pv_evtchn_domain() and report fix in CPUID
Have is_hvm_pv_evtchn_domain() return true for vector callbacks for
evtchn delivery set up on a per-vCPU basis via
HVMOP_set_evtchn_upcall_vector.
Assume that if vCPU0 uses HVMOP_set_evtchn_upcall_vector, all
remaining vCPUs will too and thus remove is_hvm_pv_evtchn_vcpu() and
replace sole caller with is_hvm_pv_evtchn_domain().
is_hvm_pv_evtchn_domain() returning true is a condition for setting up
physical IRQ to event channel mappings. Therefore, also add a CPUID
bit so that guests know whether the check in is_hvm_pv_evtchn_domain()
will fail when using HVMOP_set_evtchn_upcall_vector. This matters for
guests that route PIRQs over event channels since
is_hvm_pv_evtchn_domain() is a condition in physdev_map_pirq().
The naming of the CPUID bit is quite generic about upcall support
being available. That's done so that the define name doesn't become
overly long.
A guest that doesn't care about physical interrupts routed over event
channels can just test for the availability of the hypercall directly
(HVMOP_set_evtchn_upcall_vector) without checking the CPUID bit.
Signed-off-by: Jane Malalane <jane.malalane@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Jan Beulich [Wed, 15 Jun 2022 08:19:32 +0000 (10:19 +0200)]
IOMMU/x86: work around bogus gcc12 warning in hvm_gsi_eoi()
As per [1] the expansion of the pirq_dpci() macro causes a -Waddress
controlled warning (enabled implicitly in our builds, if not by default)
tying the middle part of the involved conditional expression to the
surrounding boolean context. Work around this by introducing a local
inline function in the affected source file.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967
projects / xen.git / log