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>
After performing a live update in stubdom environment some information
about inter-domain event channels is lost. In order to set this
information again, call xenevtchn_bind() from new_domain() in the
restore case.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
In order to reactivate an event channel after kexec() of Mini-OS,
libxenevtchn needs to allocate the port data for the event channel
and set the handler again. Add a new interface xenevtchn_bind()
for that purpose, available under Mini-OS only.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
When running in a stubdom environment xenevtchn_fdopen() won't work,
as any file descriptor state is lost across kexec().
Use a wrapper to replace the call of xenevtchn_fdopen() with the
really needed xenevtchn_open() when running on top of Mini-OS.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
With Mini-OS now supporting the O_CLOEXEC flag for the kexec case,
set the related cloexec flag in minios.c.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
With Mini-OS now supporting O_CLOEXEC for the kexec case, no longer
ignore the XENEVTCHN_NO_CLOEXEC flag in minios.c.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
Mini-OS doesn't support using mmap() for accessing a file. In order
to support reading the live update state from a 9pfs based file, use
fread() instead of mmap().
While adding the offset member to lu_state, change the type of "size"
to size_t in order to avoid problems with state exceeding 4GB.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Add an additional "caps" argument to the libxenmanage functions to
obtain a domains capabilities - control, hardware, and xenstore.
Update the xenstored callers at the same time.
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
When vpci fails to initialize an extended capability of device, it
just returns an error and vPCI gets disabled for the whole device.
So, add function to hide extended capability when initialization
fails. And remove the failed extended capability handler from vpci
extended capability list.
Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
When vpci fails to initialize a legacy capability of device, it just
returns an error and vPCI gets disabled for the whole device. That
most likely renders the device unusable, plus possibly causing issues
to Xen itself if guest attempts to program the native MSI or MSI-X
capabilities if present.
So, add new function to hide legacy capability when initialization
fails. And remove the failed legacy capability from the vpci emulated
legacy capability list.
Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Refactor REGISTER_VPCI_INIT to contain more capability specific
information, this will benefit further follow-on changes to hide
capability when initialization fails.
What's more, change the definition of init_header() since it is
not a capability and it is needed for all devices' PCI config space.
After refactor, the "priority" of initializing capabilities isn't
needed anymore, so delete its related codes.
Note:
Call vpci_make_msix_hole() in the end of init_msix() since the change
of sequence of init_header() and init_msix().
The cleanup hook is also added in this change, even if it's still
unused. Further changes will make use of it.
Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
This change removes some piece of code working around with
some compiler warnings.
No functional change.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Having multiple values wrapped onto as few lines as practical is good for
space efficiency, but causes complex collisions for hypercall backports and
local policy changes. Reformat to use one value per line.
No functional change, only whitespace changes.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Most indentation is with tabs, but a few spaces have slipped in. Switch them
back to tabs.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Hypercalls are not free; cache colouring is an experimental feature, and
ignoring an -EOPNOTSUPP is bad form.
Now that Xen has been fixed to initialise colouring information correctly for
domains, xc_domain_set_llc_colors() only needs calling for domains with
explicit configuration.
Rearrange the logic to avoid the hypercall in the general case, leaving a
comment explaining why it is performed so early.
Fixes: 748bd725fb ("tools: add support for cache coloring configuration")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Right now, domains start with no colouring information and depend on a
XEN_DOMCTL_set_llc_colors(nr=0) hypercall in order to get default colours.
This in turn forces the toolstack to make a hypercall for all VMs even those
without colouring configured, and to ignore errors if Xen doesn't have
colouring active.
Introduce domain_llc_coloring_init(), replacing domain_set_default_colors(),
and call it during the trivial initialisation in domain_create(). Leave two
comments explaining the positioning.
The -EEXISTs condition in domain_set_llc_colors() needs adjusting as a
consequence, but that's easy enough to keep working as before.
Fixes: 6cdea3444e ("xen/arm: add Dom0 cache coloring support")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
domain_destroy() is the wrong position to be freeing colouring information,
which is only used for allocations.
The comment in context identifies how domain_destroy() can be called multiple
times on the same domain, leading to a double free of d->llc_colors as it's
the wrong side of the atomic_cmpxchg() to be made safe.
Furthermore, by freeing d->llc_colors but leaving d->num_llc_colors nonzero,
alloc_color_heap_page() can in principle use after free.
Make domain_llc_coloring_free() idempotent, zeroing d->num_llc_colors and
NULL-ing d->llc_colors after freeing, and call it from domain_teardown().
Fixes: 6985aa5e0c ("xen: extend domctl interface for cache coloring")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Using:
xfree(__va(__pa(d->llc_colors)));
is an extraordinarily expensive way of writing:
xfree((void *)d->llc_colours);
Combined with the comment indicating that this was intention, the patch should
have been rejected outright.
Correct the type of d->llc_colours by removing the bogus const on it, and
remove the cast when freeing it.
No functional change.
Fixes: 6985aa5e0c ("xen: extend domctl interface for cache coloring")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Use the more "modern" forms, thus doing away with effectively open-
coding xmalloc_array() at the same time. While there is a difference in
generated code, as xmalloc_bytes() forces SMP_CACHE_BYTES alignment, if
code really cared about such higher than default alignment, it should
request so explicitly.
While at it also use XVFREE() instead of open-coding it, or instead of
leaving a dangling pointer, and change loop induction variable types.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@cloud.com>
Use the more "modern" forms consistently, thus doing away with
effectively open-coding xmalloc_array() at the same time. While there
is a difference in generated code, as xmalloc_bytes() forces
SMP_CACHE_BYTES alignment, if code really cared about such higher than
default alignment, it should request so explicitly.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
In order to fix CI error of a randconfig picking both PV_SHIM_EXCLUSIVE=y and
HVM=y results in hvm.c being built, but domctl.c not being built, which leaves
a few functions, like domctl_lock_acquire/release() undefined, causing linking
to fail.
To fix that, we intend to move domctl.o out of the PV_SHIM_EXCLUSIVE Makefile
/hypercall-defs section, with this adjustment, we also need to remove
redundant vnuma_destroy() stub definition to not break compilation.
Above change will leave dead code in the shim binary temporarily and will be
fixed with the introduction of CONFIG_DOMCTL.
Fixes: 568f806cba ("xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"")
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Add a new function to emulate extended capability list for dom0,
and call it in init_header(). So that it will be easy to hide an
extended capability whose initialization fails.
As for the extended capability list of domU, just move the logic
into above function and keep hiding it for domU.
Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citirx.com>
Include the event channel in struct xenstore_domain_interface. This way
the toolstack or xen can communicate the event channel to xenstored in
memory xenstored already needs to access.
xenstored maps the grant with the well known GNTTAB_RESERVED_XENSTORE
index, so no further information is needed.
Suggested-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Expose a domain's capabilities - control, hardware or xenstore - through
stable get domain state hypercall.
The xenstore domain can use this information to assign appropriate
permissions on connections.
Repurpose the 16bit pad field for this purpose.
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@amd.com>
Add support for XS_SET_FEATURE and XS_GET_FEATURE to xenstored.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Add per domain server features, which are initialized by the supported
features at domain introduction, or by live update from the migration
stream. This requires to add the DOMAIN_DATA record to the migration
stream, but for now it will only contain the feature word.
Advertise the Xenstore features to guests by setting the appropriate
bits in the ring page.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Add all the missing migration record structures and defines to the
xenstore_state.h header file.
Update the version of the migration stream to "2". In order to allow
receiving version 1 streams, change the version check of the header
to reject only streams with a version higher than the current known
one.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
In order to prepare xenstored supporting migration stream versions
other than 1, add a parameter to the live update command allowing to
specify the version of the migration stream.
This will allow going back from xenstored using version 2 per default
to a xenstored only accepting version 1.
For now only version 1 is supported.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Add functions for getting and setting Xenstore features to libxenstore:
xs_get_features_supported(): return the features supported by the
running Xenstore implementation as defined in xs_wire.h via the
XENSTORE_SERVER_FEATURE_* macros.
xs_get_features_domain(): return the features offered for a specific
domain.
xs_set_features_domain(): set the features available for a specific
domain.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
ARINC653 specification requires partition scheduling to be deterministic
and periodic over time.
However, the use of current timestamp (now) as the baseline to calculate
next_major_frame and next_switch_time introduces a delay in the start of
major frame at every period, which breaks determinism and periodicity in
partition scheduling.
For example, we observe 3.5 msec of accumulated delay at the 21st major
frame with the following configuration.
Target : qemuarm64
xen version : 4.19 (43aeacff86, x86/IRQ: constrain creator-domain-ID assertion)
dom1 : 10 msec runtime
dom2 : 10 msec runtime
$ a653_sched -p Pool-arinc dom1:10 dom2:10
0.014553536 ---x d?v? runstate_change d1v0 runnable->running //1st major
frame
0.034629712 ---x d?v? runstate_change d1v0 runnable->running //2nd major
frame
<snip>
0.397747008 |||x d?v? runstate_change d1v0 runnable->running //20th
major frame
0.418066096 -||x d?v? runstate_change d1v0 runnable->running //21st
major frame
This is due to an inherent delta between the time value the scheduler timer
is programmed to be fired with and the time value the schedule function
is executed.
Another observation that breaks the deterministic behavior of partition
scheduling is a delayed execution of schedule(); It was called 14 msec
later than programmed.
1.530603952 ---x d?v? runstate_change d1v0 runnable->running
1.564956784 --|x d?v? runstate_change d1v0 runnable->running
Enforce the periodic behavior of partition scheduling by using the value
next_major_frame as the base to calculate the start of major frame and
the next domain switch time.
Per discussion with Nathan Studer, there are odd cases the first minor
frame can be also missed. In that scenario, iterate through the schedule
after resyncing the expected next major frame.
Per suggestion from Stewart Hildebrand, use a modulo operation to
calculate the start of next major frame.
Fixes: 22787f2e10 ("ARINC 653 scheduler")
Suggested-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Suggested-by: Nathan Studer <nathan.studer@dornerworks.com>
Signed-off-by: Anderson Choi <anderson.choi@boeing.com>
Reviewed-by: Stewart Hildebrand <stewart@stew.dk>
Use the more "modern" form, thus doing away with effectively open-coding
xmalloc_array() at the same time. While there is a difference in
generated code, as xmalloc_bytes() forces SMP_CACHE_BYTES alignment, if
code really cared about such higher than default alignment, it should
request so explicitly.
Also clear the pointers when freeing them.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
When a running unit is about to be scheduled out due to a competing unit
with the highest remaining credit, the residual credit of the previous
unit is currently ignored in csched2_runtime() because it hasn't yet
been reinserted into the runqueue.
As a result, two equally weighted, busy units can often each be granted
almost the maximum possible runtime (i.e. consuming CSCHED2_CREDIT_INIT
in one shot) when only those two are active. In broad strokes two units
switch back and forth every 10ms (CSCHED2_MAX_TIMER). In contrast, when
more than two busy units are competing, such coarse runtime allocations
are rarely seen, since at least one active unit remains in the runqueue.
To ensure consistent behavior, have csched2_runtime() take into account
the previous unit's latest credit when it still can/wants to run.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Reviewed-by: Juergen Gross <jgross@suse.com>
Introduce new CI job to run x86 XTF argo test under QEMU to smoke test argo
feature functionality in upstream CI.
The new job lead time is ~30s, limit max job duration to 60s.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Scratch page quarantining is tied to specific IOMMU implementations, not
architectures, so tie it to AMD_IOMMU and INTEL_IOMMU instead of X86.
Fixes: dd7e55a884 ("iommu: restrict scratch page quarantining to x86")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
When attempting to xl pci-assignable-remove a PCI device, we encounter:
$ xl pci-assignable-remove 00:01.0
(XEN) SMMUv3: <no-node>: not attached to domain 32753
(XEN) d[IO]: deassign (0000:00:01.0) failed (-3)
libxl: error: libxl_pci.c:910:libxl__device_pci_assignable_remove: failed to de-quarantine 0000:00:01.0
When a PCI device is being deassigned from domIO,
arm_smmu_deassign_dev() should return before checking the smmu domain.
Fixes: 63919fc4d1 ("xen/arm: smmuv3: Add PCI devices support for SMMUv3")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
In arm_smmu_deassign_dev(), the return value from to_smmu_domain() is
NULL-checked. However, the implementation of to_smmu_domain() is a
container_of lookup, so the return value is unlikely to ever be NULL. In
case of a NULL argument to to_smmu_domain(), we will attempt to
dereference the non-NULL return value and encounter undefined behavior
and a crash:
$ xl pci-assignable-remove 00:01.0
(XEN) ================================================================================
(XEN) UBSAN: Undefined behaviour in drivers/passthrough/arm/smmu-v3.c:221:9
(XEN) applying non-zero offset ffffffffffffffc0 to null pointer
(XEN) Xen WARN at common/ubsan/ubsan.c:174
(XEN) ----[ Xen-4.21-unstable arm64 debug=y ubsan=y Tainted: C ]----
...
(XEN) Xen call trace:
(XEN) [<00000a0000350b2c>] ubsan.c#ubsan_epilogue+0x14/0xf0 (PC)
(XEN) [<00000a00003523e0>] __ubsan_handle_pointer_overflow+0x94/0x13c (LR)
(XEN) [<00000a00003523e0>] __ubsan_handle_pointer_overflow+0x94/0x13c
(XEN) [<00000a0000392f9c>] smmu-v3.c#to_smmu_domain+0x3c/0x40
(XEN) [<00000a000039e428>] smmu-v3.c#arm_smmu_deassign_dev+0x54/0x43c
(XEN) [<00000a00003a0300>] smmu-v3.c#arm_smmu_reassign_dev+0x74/0xc8
(XEN) [<00000a00003a7040>] pci.c#deassign_device+0x5fc/0xe0c
(XEN) [<00000a00003ade7c>] iommu_do_pci_domctl+0x7b4/0x90c
(XEN) [<00000a00003a34c0>] iommu_do_domctl+0x58/0xf4
(XEN) [<00000a00002ca66c>] do_domctl+0x2690/0x2a04
(XEN) [<00000a0000454d88>] traps.c#do_trap_hypercall+0xcf4/0x15b0
(XEN) [<00000a0000458588>] do_trap_guest_sync+0xa88/0xdd8
(XEN) [<00000a00003f8480>] entry.o#guest_sync_slowpath+0xa8/0xd8
(XEN)
(XEN) ================================================================================
(XEN) Data Abort Trap. Syndrome=0x4
(XEN) Walking Hypervisor VA 0xfffffffffffffff8 on CPU1 via TTBR 0x00000000406d0000
(XEN) 0TH[0x1ff] = 0x0
(XEN) CPU1: Unexpected Trap: Data Abort
(XEN) ----[ Xen-4.21-unstable arm64 debug=y ubsan=y Tainted: C ]----
...
(XEN) Xen call trace:
(XEN) [<00000a000039e494>] smmu-v3.c#arm_smmu_deassign_dev+0xc0/0x43c (PC)
(XEN) [<00000a000039e428>] smmu-v3.c#arm_smmu_deassign_dev+0x54/0x43c (LR)
(XEN) [<00000a00003a0300>] smmu-v3.c#arm_smmu_reassign_dev+0x74/0xc8
(XEN) [<00000a00003a7040>] pci.c#deassign_device+0x5fc/0xe0c
(XEN) [<00000a00003ade7c>] iommu_do_pci_domctl+0x7b4/0x90c
(XEN) [<00000a00003a34c0>] iommu_do_domctl+0x58/0xf4
(XEN) [<00000a00002ca66c>] do_domctl+0x2690/0x2a04
(XEN) [<00000a0000454d88>] traps.c#do_trap_hypercall+0xcf4/0x15b0
(XEN) [<00000a0000458588>] do_trap_guest_sync+0xa88/0xdd8
(XEN) [<00000a00003f8480>] entry.o#guest_sync_slowpath+0xa8/0xd8
Fix by changing to_smmu_domain() to return NULL in case of a NULL
argument.
Fixes: 452ddbe359 ("xen/arm: smmuv3: Add support for SMMUv3 driver")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
Enable the use of IOMMU + PCI in dom0 without having to specify
"pci-passthrough=yes". Due to possible platform specific dependencies
of the PCI host, we rely on dom0 to initialize it and perform
a PCI PHYSDEVOP calls to add each device to SMMU.
Because pci_passthrough is not always enabled on all architectures, add
a new function arch_pci_device_physdevop that checks if we need to enable
a subset of the PCI subsystem related to managing IOMMU configuration
for PCI devices.
Enable pci_init() for initializing Xen's internal PCI subsystem, and
allow PCI PHYSDEV ops when pci-passthrough is disabled.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
On Arm without pci-passthrough=on Xen does not know anything about
present PCI devices due to PHYSDEVOP_pci_device_add not executing. This
causes PHYSDEVOP_pci_device_reset to fail when trying to find the device
that is being reset and return ENODEV.
Add explicit is_pci_passthrough_enabled check to return a more
meaningful EOPNOTSUPP code.
This change should not affect x86 behavior as pci-passthrough is always
enabled there.
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
These functions never return to their caller,
causing a violation of MISRA C Rule 2.1:
"A project shall not contain unreachable code".
Add the `noreturn' attribute to fix this.
No functional changes.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> # EFI
Michal Orzel