In preparation of exposing vITS to domUs, generalize arm_iommu_map_page
and arm_iommu_unmap_page to allow ITS doorbell mappings with dfn != mfn.
The mfn does not need to be passed to guest_physmap_remove_page since
there is no mfn checking on the p2m_iommu_map_{rw,ro} p2m types during
unmap. Pass INVALID_MFN to guest_physmap_remove_page.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Tested-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Up until f9f6b22abf "xen/arm: Map ITS doorbell register to IOMMU page
tables" the only caller of iommu_map on ARM was grant_table.c which has
a specific usage model and restrictions as described by the in-code
comment in arm_iommu_map_page.
f9f6b22abf introduced a second caller to iommu_map on ARM:
vgic_v3_its_init_virtual. This specific statement in the
f9f6b22abf commit message is partially wrong:
"Note that the 1:1 check in arm_iommu_map_page remains for now, as
virtual ITSes are currently only created for hwdom where the doorbell
mapping is always 1:1."
Leading to crashes any time the hardware domain is not direct-mapped
(e.g. cache coloring and non-Dom0 hardware domain):
(XEN) Xen BUG at drivers/passthrough/arm/iommu_helpers.c:47
[...]
(XEN) Xen call trace:
(XEN) [<00000a000024c758>] arm_iommu_map_page+0x80/0x90 (PC)
(XEN) [<00000a000024c750>] arm_iommu_map_page+0x78/0x90 (LR)
(XEN) [<00000a0000250884>] iommu_map+0xcc/0x29c
(XEN) [<00000a0000288024>] vgic_v3_its_init_domain+0x18c/0x1e8
(XEN) [<00000a0000285228>] vgic-v3.c#vgic_v3_domain_init+0x168/0x21c
(XEN) [<00000a0000281dcc>] domain_vgic_init+0x14c/0x210
(XEN) [<00000a00002705a4>] arch_domain_create+0x150/0x1f0
(XEN) [<00000a00002055e8>] domain_create+0x47c/0x6c0
(XEN) [<00000a00002cf090>] create_domUs+0x7f8/0x8cc
(XEN) [<00000a00002eb588>] start_xen+0x8f4/0x998
(XEN) [<00000a000020018c>] head.o#primary_switched+0x4/0x10
Specifically, non-1:1 hardware domain exists with cache coloring
enabled. For that, is_domain_direct_mapped(d) is false but
domain_use_host_layout(d) is true.
Change the is_domain_direct_mapped(d) checks in arm_iommu_map_page and
arm_iommu_unmap_page into domain_use_host_layout(d) checks.
Drop stale in-code comment specific to grant table mappings.
Fixes: f9f6b22abf ("xen/arm: Map ITS doorbell register to IOMMU page tables")
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Tested-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Call stack for dom0less hwdom case (1:1) memory:
create_domUs
|-construct_domU
|-construct_hwdom()
|-allocate_memory_11()
And allocate_memory_11() uses "dom0_mem" as:
min_low_order =
get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
In case of dom0less boot the "dom0_mem" is not used and defaulted to 0,
which causes min_low_order to get high value > order and so no allocations
happens from low memory.
Fix it, by using kinfo->unassigned_mem instead of "dom0_mem" which has
correct memory size in both cases: regular dom0 boot and dom0less boot.
Fixes: 52cb53f181 ("xen/arm: dom0less hwdom construction")
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
If init_one_irq_desc() fails, init_local_irq_data() returns without
releasing local_irqs_type_lock, leading to a possible deadlock.
Release the lock before returning to ensure proper cleanup.
Fixes: 2bb32b8092 ("xen/irq: Propagate the error from init_one_desc_irq() in init_*_irq_data()")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Julien Grall <jgrall@amazon.com>
When VM to VM support is activated and there is no suitable FF-A support
in the firmware, enable FF-A support for VMs to allow using it for VM to
VM communications.
If there is OP-TEE running in the secure world and using the non FF-A
communication system, having CONFIG_FFA_VM_TO_VM could be non functional
(if optee is probed first) or OP-TEE could be non functional (if FF-A is
probed first) so it is not recommended to activate the configuration
option for such systems.
To make buffer full notification work between VMs when there is no
firmware, rework the notification handling and modify the global flag to
only be used as check for firmware notification support instead.
Also split probe function into one for firmware and one for vm to vm to
make the implementation clearer.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Julien Grall <jgrall@amazon.com>
Add support to raise a Rx buffer full notification to a VM.
This function will be used for indirect message support between VM and
is only activated if CONFIG_FFA_VM_TO_VM is selected.
Even if there are 32 framework notifications possible, right now only
one is defined so the implementation is simplified to only handle the
buffer full notification using a boolean. If other framework
notifications have to be supported one day, the design will have to be
modified to handle it properly.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Julien Grall <jgrall@amazon.com>
Create a CONFIG_FFA_VM_TO_VM parameter to activate FFA communication
between VMs.
When activated list VMs in the system with FF-A support in part_info_get.
When VM to VM is activated, Xen will be tainted as Insecure and a
message is displayed to the user during the boot as there is no
filtering of VMs in FF-A so any VM can communicate or see any other VM
in the system.
WARNING: There is no filtering for now and all VMs are listed !!
This patch is reorganizing the ffa_ctx structure to make clear which
lock is protecting what parts.
This patch is introducing a chain list of the ffa_ctx with a FFA Version
negotiated allowing to create the partinfo results for VMs in parallel
by using rwlock which only ensure addition/removal of entries are
protected.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Julien Grall <jgrall@amazon.com>
This patch is in preparation for VM to VM support in order to do the
changes on the SP handling part of partinfo_get before adding support
for the VM part.
This patches is doing the following changes:
- split partinfo_get into 3 functions to have the locking handling and
proper exit on error handled more clearly
- add some potential overflow checks to validate the offset and sizes
passed by the VM on partinfo call.
- Introduce a maximum number of SPs (for now set to 64) to prevent
holding the CPU for too long in case there would be a lot of
partitions in the secure world. The limit currently set is thought to
be realistic for most use cases as 64 secure partitions is a very high
number compared to current seen usage (more 3 or 4).
- fix include ordering in ffa_private.h to be in alphabetic order
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Julien Grall <jgrall@amazon.com>
Add a new command line parameter "tee=" to be used to explicitly select
what tee mediator is to be used by Xen and fail if it does not exist
or the probe function for it failed.
Without specifying which tee is to be used, Xen will use the first one
for which the probe function succeeds which depends on the order of the
mediator list which depends on the compiler.
Using the command line argument, it is now possible to explicit request
a specific TEE mediator and panic on boot if it is not available.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Julien Grall <jgrall@amazon.com>
The enforced toolchain baseline for clang is version 11,
therefore this logic is effectively dead code.
No functional change.
Signed-off-by: Nicola Vetrini <nicola.vetrini@gmail.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
If the config file is builtin, cfg.addr will be zero but Xen
unconditionally calls FreePages() on the address.
Xen may also call FreePages() with a zero address if blexit() is called
after this point since cfg.need_to_free is not set to false.
The UEFI specification does not say whether calling FreePages() with a
zero address is allowed so let's be cautious and use cfg.need_to_free
properly.
Fixes: 8a71d50ed4 ("efi: Enable booting unified hypervisor/kernel/initrd images")
Fixes: 04be2c3a06 ("efi/boot.c: add file.need_to_free")
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by Daniel P. Smith <dpsmith@apertussolutions.com>
While it is correct that in shim-exclusive mode log-dirty handling is
all unreachable code, the present conditional still isn't correct: In a
HVM=n and SHADOW_PAGING=n configuration log-dirty code also is all
unreachable (and hence violating Misra rule 2.1).
As we're aiming at moving away from special casing PV_SHIM_EXCLUSIVE=y,
don't retain that part of the conditional.
Because of hypercall-defs.c we need to carry out the dependency by
introducing a new auxiliary PAGING control.
Since compiling out mm/paging.c altogether would entail further changes,
merely conditionalize the one function in there (paging_enable()) which
would otherwise remain unreachable (Misra rule 2.1 again) when PAGING=n.
Fixes: 23d4e0d17b ("x86/shim: fix build with PV_SHIM_EXCLUSIVE and SHADOW_PAGING")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Move fill_mask(), pdx_region_mask() and pdx_init_mask() to the
!CONFIG_PDX_NONE section in preparation of them also being used by a newly
added PDX compression.
No functional change intended.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Introduce a set of unit tests for PDX compression. The unit tests contains
both real and crafted memory maps that are then compressed using the
selected PDX algorithm. Note the build system for the unit tests has been
done in a way to support adding new compression algorithms easily. That
requires generating a new test-pdx-<compress> executable that's build with
the selected PDX compression enabled.
Currently the only generated executable is test-pdx-mask that tests PDX
mask compression.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
There are four performance critical PDX conversion helpers that do the PFN
to/from PDX and the physical addresses to/from directmap offsets
translations.
In the absence of an active PDX compression, those functions would still do
the calculations needed, just to return the same input value as no
translation is in place and hence PFN and PDX spaces are identity mapped.
To reduce the overhead of having to do the pointless calculations allow
architectures to implement the translation helpers in a per-arch header.
Rename the existing conversion functions to add a trailing _xlate suffix,
so that the per-arch headers can define the non suffixed versions.
Currently only x86 implements meaningful custom handlers to short circuit
the translation when not active, using asm goto. Other architectures use
generic macros that map the non-xlate to the xlate variants to keep the
previous behavior.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Introduce a command line option to allow disabling PDX compression. The
disabling is done by turning pfn_pdx_add_region() into a no-op, so when
attempting to initialize the selected compression algorithm the array of
ranges to compress is empty.
Signed-off-by: Roger Pau Monné <roger.pau@cloud.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The current setup (pdx_init_mask() and pdx_region_mask()) and init
(pfn_pdx_hole_setup()) PDX compression functions are tailored to the
existing PDX compression algorithm.
In preparation for introducing a new compression algorithm convert the
setup and init functions to more generic interfaces that aren't tied to the
compression in-use. To accomplish this introduce a function that registers
all the PFN RAM ranges, plus an init function.
This has the downside of requiring a static array to store such ranges
ahead of being processed by the setup function, however it's the only way
to pass all the possible information to the different compression setup
functions without using per-compression specific setup functions.
Per-arch compression setup also need to be adjusted to use the new
interface. There's a slight ordering adjustment, in that after PDX
compression setup the caller will check whether all the RAM regions are
properly covered by the newly setup compression, otherwise compression is
disabled by resetting to the initial values.
No functional change intended in the resulting PDX compression values.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com> # ARM
Rename the current CONFIG_PDX_COMPRESSION to CONFIG_PDX_MASK_COMPRESSION,
and make it part of the PDX compression choice block, in preparation for
adding further PDX compression algorithms.
The PDX compression defaults should still be the same for all
architectures, however the choice block cannot be protected under EXPERT
and still have a default choice being unconditionally selected. As a
result, the new "PDX (Page inDeX) compression" item will be unconditionally
visible in Kconfig, even on architectures like x86 that previously had no
way to enable PDX compression.
As part of this preparation work to introduce new PDX compressions, adjust
some of the comments on pdx.h to note they apply to a specific PDX
compression. Also shuffle function prototypes and dummy implementations
around to make it easier to introduce a new PDX compression. Note all
PDX compression implementations are expected to provide a
pdx_is_region_compressible() that takes the same set of arguments.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
The data segment registers are part of the on-stack IRET frame when
interrupting Virtual 8086 mode, but this ceased being relevant for Xen in
commit 5d1181a5ea ("xen: Remove x86_32 build target.") in 2012.
With all other cleanup in place, delete the fields so we can introduce FRED
support which uses this space for different data.
Everywhere which used the es field as an offset in cpu_user_regs needs
adjusting. However, they'll change again for FRED, so no cleanup is performed
at this juncture.
This also undoes the OoB Read workaround in show_registers(), which can now
switch back to being simple structure copy.
No functional change, but a lot of rearranging of stack and struct layout
under the hood.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
In order to support FRED, we're going to have to remove the {ds..gs} fields
from struct cpu_user_regs, meaning that it is going to have to become a
different type to the structure embedded in vcpu_guest_context_u.
struct cpu_user_regs is a name used in common Xen code (i.e. needs to stay
using this name), so renaming the public struct to be guest_user_regs in Xen's
view only.
Introduce a brand hew cpu-user-regs.h, currently containing a duplicate
structure.
Notably, this removes the need to include pubic/xen.h in ~every translation
unit in Xen (via current.h), and highlights one case where the emulator was
picking up cpu_user_regs transitively.
Include comments describing how hardware interacts with this structure under
IDT delivery, as it's quite magic to start with. FRED is going make things
more complicated.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
In order to support FRED, we're going to have to remove the {ds..gs} fields
from struct cpu_user_regs. This will impact v->arch.user_regs.
These fields are unused for HVM guests, but for PV hold the selector values
when the vCPU is scheduled out.
Introduce new fields for the selectors in struct pv_vcpu, and update:
* {save,load}_segments(), context switching
* arch_{set,set}_info_guest(), hypercalls
* vcpu_show_registers(), diagnostics
* dom0_construct(), PV dom0
to use the new storage. This removes the final user of read_sregs() so drop
it too.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
In order to support FRED, we're going to have to remove the {ds..gs} fields
from struct cpu_user_regs, meaning that it is going to have to become a
different type to the structure embedded in vcpu_guest_context_u.
In both arch_{get,set}_info_guest(), expand the memcpy()/XLAT_cpu_user_regs()
to copy the fields individually. This will allow us to eventually make them
different types.
This does cause some minor changes in behaviour for the hypercalls.
It is specifically not the case that a toolstack could set_info(); get_info();
and get an identical bit pattern back. Amongst other things, the
architectural sticky bits in registers are applied during setting.
Previously, XLAT_cpu_user_regs() omitted the _pad fields in the compat case
whereas the non-compat case included them owing to the single memcpy().
Omit the _pad fields in the non-compat case too; for all but the oldest of
CPUs, the segment selectors are zero-extended by hardware when pushed onto the
stack, so non-zero values here get lost naturally. Furthermore, FRED reuses
the space above cs and ss for extra state, and a PV guest for now at least
must not be able to write the control state.
Omit the error_code and entry_vector fields too. They're already identified
as private fields in the public API, and are stale outside of Xen's
interrupt/exception/syscall handler. They're also a very minor information
leak of which event caused the last deschedule of a vCPU.
Finally, omit saved_upcall_mask. Xen doesn't consume this, and only produces
it in {compat_,}create_bounce_frame(), based on the vcpu_info shared state and
settings about the event being injected. Similar to error_code/entry_vector,
it is stale outside of the guest's event handler.
No change that toolstacks or guests are expected to notice or care about.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The function was introduced without any caller, and never gained any.
Thus it has always been violating Misra rule 2.1 (unreachable code).
Fixes: dd6de3ab99 ("Implement Nested-on-Nested")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
While the logic there covers asymmetric cases, the resulting log
messages would likely raise more confusion than clarify anything. Split
the BSP action from the AP one, indicating the odd CPU in the AP log
message, thus avoiding the impression that global state would have
changed.
While there also
- move g_disabled into .data.ro_after_init; only the BSP will ever write
to it,
- make the function's parameter unsigned; no negative values may be
passed in. Also reflect this in svm_asid_init().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Them not being altered by any means, their __read_mostly attribute is
actually counter-productive: It causes the compiler to instantiate the
variables, when already with just the attributes dropped the compiler
can constant-propagate the values into the sole use site. Make the
situation yet more explicit by adding const.
Also switch the variables away from being plain int, and have the
parameters of __printk_ratelimit() follow suit. While there also
similarly adjust the type of "missed" and "lost", and - while touching
the adjacent line - increase lost_str[] to accommodate any unsigned
32-bit number.
Fixes: a8b1845a78 ("Miscellaneous data placement adjustments")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
It instructs the remote harts to execute one or more HFENCE.GVMA instructions
by making an SBI call, covering the range of guest physical addresses between
start_addr and start_addr + size only for the given VMID.
The remote fence operation applies to the entire address space if either:
- start_addr and size are both 0, or
- size is equal to 2^XLEN-1.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Instruct the remote harts to execute one or more HFENCE.GVMA instructions,
covering the range of guest physical addresses between start_addr and
start_addr + size for all VMIDs.
The remote fence operation applies to the entire address space if either:
- start_addr and size are both 0, or
- size is equal to 2^XLEN-1.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The current logic in the HPET interrupt ->ack() hook will perform a local
APIC EOI ahead of enabling interrupts, possibly leading to recursion in the
interrupt handler.
Fix this by doing the local APIC EOI strictly after the window with
interrupt enabled, as that prevents the recursion, and would only allow for
interrupts with higher priority to be serviced.
Use the generic ack_nonmaskable_msi_irq() and end_nonmaskable_irq()
functions, removing the need for hpet_msi_ack().
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Fixes: 3ba523ff95 ('CPUIDLE: enable MSI capable HPET for timer broadcast')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Since commit 341f271cf8 ("xen/evtchn: fully restrict concept of pIRQ for
arches with pIRQ support only"), the corresponding PPC arch pIRQ callbacks
become unreachable, so drop them.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Since commit 341f271cf8 ("xen/evtchn: fully restrict concept of pIRQ for
arches with pIRQ support only"), the corresponding Arm arch pIRQ callbacks
become unreachable, so drop them.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Julien Grall <jgrall@amazon.com>
The API is unergonomic to use, and leads to poor code generation because of
unnecessary forcing of data to the stack.
Rename build_id_p to xen_build_id, and build_id_len to xen_build_id_len, make
them __ro_after_init, and export the variables directly.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Ross Lagerwall <Ross.lagerwall@citrix.com>
Both callsites call them as a pair, and more generally, anyone wanting the
changeset wants the buildid too.
This involves rearranging console_init_preirq() to ensure xen_build_init() is
ahead of print_version().
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The conversion from a function pointer with the 'noreturn' attribute
('void noreturn (*)(...)') to a function pointer type ('void (*)(...)'
causes type incompatibility according to MISRA C Rule 11.1, which
forbids conversions between incompatible function pointer types.
The violation occurs at the call site:
smp_call_function(halt_this_cpu, NULL, 0);
where 'halt_this_cpu' with type 'void noreturn (*)(void *)' is passed to
'smp_call_function' expecting function pointer of type 'void (*)(void *)'.
The 'noreturn' attribute does not change the function calling convention
or parameter handling at runtime, making the conversion safe.
For now, configure Eclair to just treat implicit conversions that lose
the "noreturn" attribute on a function 'void (*)(void*)' as safe.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com> # docs
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com> # ECLAIR
MISRA C Rule 2.1 states: "A project shall not contain unreachable code".
Functions that are non-returning and are not explicitly annotated with
the `noreturn' attribute are considered a violation of this rule.
In certain cases, some functions might be non-returning in specific build
configurations (when assertions are enabled, i.e., when `NDEBUG' is not
defined). This is due to calls to `__builtin_unreachable()' in the
expansion of the macro `ASSERT_UNREACHABLE()'.
Conversely, in builds where `NDEBUG' is defined (assertions are disabled),
the macro `ASSERT_UNREACHABLE()' expands to an empty construct
(`do { } while (0)'), which does not affect the execution flow. This allows
such functions to return normally in such builds, avoiding unreachable code.
To account for that in specific builds, the `noreturn` property of
`__builtin_unreachable()` is overridden in the ECLAIR configuration to
deviate these violations.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Part of it stated the opposite of what actual behavior is.
Fixes: 7126b7f806 ("x86/CPU: re-work populating of cpu_data[]")
Reported-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Add a guest config parameter "xenstore_feature_mask" allowing to limit
the Xenstore features the guest can see and use. This can be needed in
order to allow migrating a guest to a host running a Xenstore version
providing less features than the source host.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Nick Rosbrook <enr0n@ubuntu.com> # tools/golang
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
This patch adds a systemd sleep hook script to stop the xen-watchdog
service before system suspend and start it again after resume.
Stopping the watchdog before a system suspend operation may look unsafe.
Let's imagine the following situation: 'systemctl suspend' does not
interact with the running service at all. In such a case, the Xen
watchdog daemon freezes just before suspend. If this happens, for
example, right before sending a ping, and Xen has not yet marked the
domain as suspended (is_shutting_down), the Xen watchdog timer may
trigger a false alert.
This is an almost impossible situation, because typically:
ping time = watchdog timeout / 2
and the watchdog timeout is usually set to a relatively large value
(dozens of seconds).
Still, this is more likely with very short watchdog timeouts. It may
happen in the following scenarios:
* Significant delays occur between freezing Linux tasks and
triggering the ACPI or PSCI sleep request or handler.
* Long delays happen inside Xen between the entrance to the sleep
trigger and the actual forwarding of the sleep request further.
A similar situation may occur on resume with short timeouts. During the
resume operation, Xen restores timers and the domain context. The Xen
watchdog timer also resumes. If it schedules the domain right before the
watchdog timeout expires, and the daemon responsible for pinging is not
yet running, a timeout might occur.
Both scenarios are rare and typically require very small watchdog
timeouts combined with significant delays in Xen or the Linux kernel
during suspend/resume flows.
Conceptually, however, if activating and pinging the Xen watchdog is the
responsibility of the domain and its services, then the domain should
also manage the watchdog service/daemon lifecycle. This is similar to
what is already done by the Xen watchdog driver inside the Linux kernel.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
When removing qemu-trad support, libxl__domain_build_info_setdefault()
was modified to only allow qemu-xen as a device model. This change
resulted in an error at domain creation when qemu-xen isn't there.
As this is a perfectly fine situation for PV and PVH guests without
any qemu based backends, handle this case gracefully.
Fixes: 19ab8356ab ("tools: remove support for running a guest with qemu-traditional")
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
do_sched_op(SCHEDOP_yield) just calls vcpu_yield(). Remove the indirection
through the hypercall handler and use the function directly.
Export vcpu_block_enable_events() to perform the same for SCHEDOP_block.
Not a functional change.
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Add the Xenstore feature value to the output of "xl info" in order to
prepare for a future capability to limit Xenstore features visible by
a guest.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
SYMBOL_NAME_SIZE is 124, not 128. Use the symbolic name there as well,
to avoid any disconnect.
While there correct indentation on the following line as well.
Coverity ID: 1659391
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
When running xl in a domU, it doesn't have access to the Xen command
line. Before the non-truncating xc_xenver_cmdline(), it was always set
with strdup, possibly of an empty string. Now it's NULL. Treat it the
same as empty cmdline, as it was before. Autoballoon isn't relevant for
xl devd in a domU anyway.
Fixes: 75f9160762 ("tools: Introduce a non-truncating xc_xenver_cmdline()")
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
On platforms without PIRQ support evtchn_move_pirqs()/send_guest_pirq()
functions are unreachable (Misra rule 2.1).
Move these function under CONFIG_HAS_PIRQ ifdefs to fix Misra rule 2.1
violation and resolve call of evtchn_move_pirqs() from common /sched/core.c
vcpu_move_irqs() code by moving evtchn_move_pirqs() into x86
arch_move_irqs() callback (which is converted to define).
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Juergen Gross <jgross@suse.com> # xen/sched
While technically possible to support live-patching on MPU systems, today
the code depends on vmap. However, this relationship is not reflected in
Kconfig and allows to enable live-patching on MPU, where HAS_VMAP is not
selected.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
HAS_PASSTHROUGH should only be selected on MMU systems. It's been like
that until commit 163c6b5898 added possibility to select HAS_PASSTHROUGH
if PCI_PASSTHROUGH is enabled on Arm64. This is incorrect as it may result
in enabling passthrough/ build on MPU systems. PCI_PASSTHROUGH should
depend on HAS_PASSTHROUGH instead.
Fixes: 163c6b5898 ("xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Pass the live_update bool to stubdom_init() in order to be able to
handle it properly under Mini-OS.
As stubdom_init() will (re-)create the 9pfs device needed for
reading the saved state, call stubdom_init() before lu_read_state().
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Stefano Stabellini