Rather than granting permissions when mapping (an operation that DM-s are
allowed to carry out, while they can't invoke ioport-permission), check
whether permissions actually were granted when adding a mapping. This then
also allows relaxing the necessary locking.
While no longer granting permissions upon mapping is "only" at risk of
breaking guests, no longer revoking permissions upon unmapping strictly
requires callers to additionally invoke XEN_DOMCTL_ioport_permission. Or
else a security issue would arise. In-tree code already does so.
While there switch to using %pd in the two log messages.
Fixes: 192c4dabc3 ("domctl and p2m changes for PCI passthru")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger@xenproject.org>
Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Embedding the symbol table can shift sections and flip relaxation
decisions, changing code size and thus the set of emitted tools/symbols
(e.g. gap end markers). Re-link with a regenerated table when its
size differs from the previous pass.
This takes the same remedy as commit 35de7285d5 ("Arm: do a 4th
linking pass if necessary"), though the underlying cause differs:
here no symbol (dis)appears from the ELF symbol table; instead the
set of end markers emitted by tools/symbols legitimately changes,
because want_symbol_end() depends on code layout, and layout differs
between passes due to linker relaxation.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
DstMem processing early in x86_emulate() raises #UD when EVEX.Z is set
with a memory destination. Open-coded checks like this one are therefore
dead / unreachable code, violating Misra rules.
Fixes: 4037a62ef9 ("x86emul: support AVX512F floating-point conversion insns")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
schedule_cpu_rm() clears the cpupool pointer of the scheduling
resource before calling sched_deinit_pdata():
sr->cpupool = NULL;
...
sched_deinit_pdata(data->old_ops, data->ppriv_old, cpu);
For RTDS, rt_deinit_pdata() calls move_repl_timer() when the
replenishment timer lives on the cpu being removed, and
move_repl_timer() dereferences get_sched_res(old_cpu)->cpupool
without checking it for NULL. Removing a pCPU owning the timer from
an RTDS cpupool therefore dereferences NULL + 0x10 (the res_valid
member) and panics:
(XEN) Data Abort Trap. Syndrome=0x1c28005
(XEN) Walking Hypervisor VA 0x10 on CPU0 via TTBR ...
(XEN) Xen call trace:
(XEN) [<...>] find_next_bit+0x74/0xa8 (PC)
(XEN) [<...>] rt.c#move_repl_timer+0xb8/0xec (LR)
(XEN)
(XEN) Panic on CPU 0:
(XEN) CPU0: Unexpected Trap: Data Abort
Reproducer, on any host with at least 2 pCPUs and RTDS compiled in
(observed on arm64, but the path is common code):
xl cpupool-create name="test" sched="rtds"
xl cpupool-cpu-remove Pool-0 1
xl cpupool-cpu-add test 1
xl cpupool-cpu-remove test 1
The last command moves the RTDS replenishment timer to cpu1 (first
and only cpu of the pool) and then removes cpu1, hitting the NULL
dereference in the sched_deinit_pdata() callback.
Use the cpupool back-pointer of the scheduler instead of the one of
the scheduling resource. It is set by cpupool_create() before any
pCPU can be assigned to the pool and stays valid for the whole
lifetime of the scheduler, so it is still available when
rt_deinit_pdata() runs. Other schedulers already rely on it the same
way, e.g. credit2 in cpu_add_to_runqueue().
Fixes: b6f5334aea ("sched: fix cpu offlining with core scheduling")
Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Left over from 2754857001 ("Bring back console_start_log_everything()
as a milder alternative to"), which dropped the sole use only a few weeks
after its introduction.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
We know that opcode_table[0x0f] is 0, there's no need to check that. Up
until ab082ffa87 ("x86emul: generate and make use of a canonical opcode
representation") or maybe already c4e7a67e3a ("x86emul: drop
SrcInvalid") this may have been justified, but it no longer is.
This eliminates a Misra C:2012 rule 2.2 ("There shall be no dead code")
violation.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The current order is derived from expanding XLAT_cpu_user_regs() which used
the x86_32 cpu_user_regs order. This is correct for one the blocks, but not
the others.
In order to work with the prefetcher, rather than against it, loads want to be
in field order. Make this so for the three paths reading an x86_64
cpu_user_regs.
No functional change.
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Commit 9f892f84c2 ("x86/domctl: Stop using XLAT_cpu_user_regs()")
converted memcpy() of the cpu_user_regs structure to explicit copy of
its fields. In the compat case, it intentionally missed few of them,
named in the commit message. But the 64bit case missed also r8-r15
registers, which was not intentional. This, at least, caused Linux
6.18.x crash when resuming PVH domU.
Fix it by adding missing assignments.
Fixes: 9f892f84c2 ("x86/domctl: Stop using XLAT_cpu_user_regs()")
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Release-acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
AFL has pointed out that the op_bytes-is-not-0 assertion in common SIMD
handling can trigger for these insns. Indeed when the (relevant part of)
the controlling mask register is 0, no memory is accessed at all. Leave
op_bytes unaltered in this case, to engage the short-circuiting in common
SIMD handling when fault_suppression is true and op_bytes is 0.
While there also correct a related typo in the test harness.
Fixes: 65f82d4ce1 ("x86emul: support AVX512{F,_VBMI2} compress/expand insns")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
{__,}printk_ratelimit() are predicates. Make that pronounced by updating the
return value to boolean.
Not a functional change.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Make console_init_ring() more efficient by using memcpy()'s, rather than
copying the ring a byte at a time.
No functional change intended.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Roger Pau Monne <roger.pau@citrix.com>
Both conring{,_size} should be RO after initialization is completed.
Change the conring integer parameters type to `unsigned int` as required
by CODING_STYLE.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Move the little bit that's still left in x86/x86_emulate.c into a __XEN__
conditional in x86/x86_emulate/x86_emulate.c. Move what are roughly the
test/fuzzing harness counterparts from there into the corresponding #else.
Interestingly more recent gcc takes issue with three static const arrays
which are unused when HVM=n (noticeable in particular in the shim build).
Apparently such are diagnosed only when present in the top-level file, but
not when living in an #include-d one.
Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
As explained in the comment partially in context, and contrary to what was
said in commit 8af337dfb8 ("x86/entry: Use POP_GPRS and remove
RESTORE_ALL"), the restore_all_xen() path cannot use default offsets for
SPEC_CTRL_COND_VERW.
Getting this wrong is surprisingly benign. VERW doesn't fault for any limit
or descriptor reasons.
However, in SVM vCPU context LDTR is the guest's not Xen's. When the segment
selector VERW uses happens to be an LDT selector, the CPU accesses the guest
LDTR in Xen context:
(XEN) ----[ Xen-4.23.0 x86_64 debug=y Not tainted ]----
(XEN) CPU: 14
(XEN) RIP: e008:[<ffff82d0402007f2>] x86_64/entry.S#restore_all_xen+0x72/0x80
(XEN) RFLAGS: 0000000000010002 CONTEXT: hypervisor (d3v1)
...
(XEN) Xen code around <ffff82d0402007f2> (x86_64/entry.S#restore_all_xen+0x72/0x80):
(XEN) 5f f6 44 24 7c 08 74 05 <0f> 00 6c 24 44 48 83 c4 08 48 cf 0f 1f 00 fc 0f
...
(XEN) Xen call trace:
(XEN) [<ffff82d0402007f2>] R x86_64/entry.S#restore_all_xen+0x72/0x80
(XEN) [<ffff82d0402e79f6>] F nestedhap_fix_p2m+0x5f/0xc9
(XEN) [<ffff82d0402e7c8f>] F nestedhvm_hap_nested_page_fault+0x11e/0x22e
(XEN) [<ffff82d0402cd59d>] F hvm_hap_nested_page_fault+0x1b8/0x5d2
(XEN) [<ffff82d0402ad7de>] F svm_vmexit_handler+0xbe9/0x18b3
(XEN) [<ffff82d040202542>] F svm_asm_do_resume+0x162/0x172
(XEN)
(XEN) Pagetable walk from 000000000000fff8:
(XEN) L4[0x000] = 0000000000000000 ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 14:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0000]
(XEN) Faulting linear address: 000000000000fff8
(XEN) ****************************************
In this case, the guest's LDT obviously has a base of 0 and limit of 0xffff
for the segmentation checks to pass and a memory access to be attempted.
Fixes: 8af337dfb8 ("x86/entry: Use POP_GPRS and remove RESTORE_ALL")
Reported-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
pv_map_ldt_shadow_page() takes the whole guest PTE, adds _PAGE_RW to it, then
installs it into Xen's pagetables. It has had this behaviour ever since LDT
support was added in 2003.
However, it allows the guest to control the software available bits and
cacheability. This happens to be benign right now, but is bad form.
Use only the guest frame, and construct the mapping as regular RW frame, and
notably includes NX. This is how the GDT logic already works.
Fixes: 005c272397 ("Finished virtualisation of x86 LDT")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Just because vcpu_id is within d->max_vcpus doesn't mean d->vcpu[vcpu_id] is
non-NULL. Use the proper accessor to look up a vcpu object.
Reported-by: Michal Orzel <michal.orzel@amd.com>
Fixes: acf65e5a25 ("xen/arm: vgic-v3: Emulate correctly the re-distributor")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Julien Grall <julien@xen.org>
A malformed partial DTB specifying both '#address-cells = <0>' and
'#size-cells = <0>' causes '(address_cells * 2 + size_cells)' to
evaluate to 0. This sum is subsequently used as a divisor when
calculating the number of regions in the 'xen,reg' property inside
handle_passthrough_prop():
len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
sizeof(uint32_t));
This leads to a division by zero exception in the Xen hypervisor during
boot, causing a hypervisor panic/crash.
Fix this by validating that both 'address_cells' and 'size_cells'
are within the range of [1, 2] at the top of handle_passthrough_prop().
Any invalid cell size combination is safely rejected early with an error
message and return -EINVAL.
Furthermore, update handle_passthrough_prop() to use the sizeof(*cell)
instead of sizeof(uint32_t).
Fixes: 9ce974c475 ("xen/arm: assign devices to boot domains")
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
construct_domain() creates the secondary vCPUs in a loop, but on a
vcpu_create() failure it only prints a message and breaks out of the
loop returning success. As a result the domain can be partially
constructed with fewer vCPUs than d->max_vcpus. This causes two contract
violations:
- Xen-Guest: domain's FDT is generated before vCPU creation - Xen exposes
incorrect information (e.g. two vCPUs listed in a device tree while only
one is actually created),
- User-Xen: unlike x86, on Arm port we try to bail out as soon as
possible on unsatisfied user requests (e.g. user requested two vCPUs
for a domain but it was created with only one).
Return an error instead of breaking out of the loop. Both callers
(construct_domU() and construct_hwdom()) already propagate a negative
return value and fail domain construction.
Fixes: 6b0e8e4334 ("xen/arm: allocate secondaries dom0 vcpus")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Add new job-level EXTRA_XEN_OPTS variable, in addition to CONSOLE_OPTS.
FRED is not yet enabled by default on Intel systems, but is expected to
function. Explicitly turn it on for added test coverage in the short term.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
For now run similar set of tests as ADL.
Exclude suspend test for now. While firmware claims S3 is supported,
suspend attempt fails (power LED blinks for a few seconds, and
then system reboots). With no messages on the serial console, even with
`sync_console`.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
There is no need to store the page pointers simply to transcribe the same
information into iov later. Drop the guest_data intermediate array.
These days, linux has a maximum limit of 1024 iovs. Libc under the hood will
subdivide the submission if necessary, which is why our general case of 1026
submissions works.
xenforeignmemory_map() maps the requested guest memory contiguously, and
except for PV pagetable frames, we submit contiguously into the stream. When
safe to do, merge adjacent vectors by extending iov_len, reducing the
likelihood that libc needs to subdivide the submission.
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The APM description of the AltMovCR8 feature bit is:
"LOCK MOV CR0 means MOV CR8"
Adjust the decode logic to behave like this.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Current argo_dprintk() implementation is a wrapper around raw printk().
Rewire it through gprintk() to allow for better debugging context
(such as domain ID).
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Drop XENLOG_ERR from the logline since argo_dprintk() already injects
the proper log level indicator.
Also, drop "argo: " prefix, since it is also injected by argo_dprintk()
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Switch the log line to argo_dprintk() so it is enabled only in debug
environments, as it can spam the logs when a dom0 service using the Argo
hypercall tries to communicate with a domain that is still starting up.
Note that this also lowers the log level to debug when the argo_dprintk()
facility is enabled.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Construct all of the headers together in one block, rather than a field at a
time. Initialise as many of the fields as possible at declaration time.
Start filling in iov[] earlier, to allow for future simplifications.
No practical change.
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
For reasons which escape me, rec_pfns are allocated separately to the rest of
the batch allocations.
Allocate them all together. This will allow for future simplifications to be
performed in an incremental mannor.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Construct xc_sr_rhdr directly rather than in two halves.
Use size_t for combined_len, which allows the later size check to spot a few
more cases which might have truncated.
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
Currently, during ARM Xen's SMP initialization, if there is
a Device Tree error (such as an invalid 'enable-method'),
cpu_possible_map can end up being sparse.
The issue here is that nr_cpu_ids is calculated in a way that
doesn't properly account for the maximum CPU ID when the map is
sparse, causing a mismatch. For example, if cpu_possible_map is
0xff0f, nr_cpu_ids becomes 12, but the actual maximum CPU ID
is 15. Xen's common code is built on the assumption that
'CPU ID < nr_cpu_ids', so this mismatch can break things.
To fix this, modify dt_smp_init_cpus() so that if the
arch_cpu_init() call fails, we don't consume the CPU ID slot.
Fixes: 4557c22928 ("xen: arm: rewrite start of day page table and cpu bring up")
Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
PUSH_AND_CLEAR_GPRS is shorter than SAVE_ALL in terms of emitted code.
lstar_enter() and cstar_enter() do not need CLD. The SYSCALL instruction
sanitises flags based on MSR_SYSCALL_MASK. For all other cases, place the CLD
instruction next to STAC/CLAC so the flag handling is together.
Get rid of the compat=1 special case for PV32. It's not obviously a win, and
PV32 is getting increasingly rare these days.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
POP_GPRS is shorter than RESTORE_ALL in terms of emitted code.
By separating the popping of entry_vector/error_code off the stack,
SPEC_CTRL_COND_VERW doesn't need custom displacements.
Get rid of the compat=1 special case for PV32. It's not obviously a win, and
PV32 is getting increasingly rare these days.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
PUSH_AND_CLEAR_GPRS is shorter than SAVE_ALL in terms of emitted code.
SAVE_ALL hides a CLD instruction which is not needed anywhere here.
* VMX VMExit always clears flags. VMX VMentry failure never switched away
from the host flags, so they're still good.
* SVM VMRUN always saves and restores the host flags.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This is slightly stale mentioning SWAPGS and not LKGS. However, take the
opportunity to make the comment more general and less likely to bitrot.
It would be a serious vulnerability for operating systems generally if CPL3
could modify GS_SHADOW at all.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
arch_domain_create() and arch_sanitise_domain_config() are prerequisites for
domain_create().
arch_sanitise_domain_config() currently returns 0, as there is no specific
work required at this stage.
arch_domain_create() performs basic initialization, such as setting up the P2M
and initializing of next unused phandle.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Introduce HAS_STATIC_MEMORY so that STATIC_MEMORY can be enabled or
disabled on a per-architecture basis. ARM selects the new flag; RISC-V
does not, so CONFIG_STATIC_MEMORY is unavailable on RISC-V and
randconfig builds no longer require an explicit STATIC_MEMORY=n override
to avoid a compilation error.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
As map_device_irqs_to_domain() is used unconditionally by common part of
dom0less code, move the prototype to a common header.
fdt-domain-build.h is chosen as map_device_irqs_to_domain() could be
also called indirectly in Arm's DOM0-related code and DT overlay feature.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
C-stubdom was meant as a base for building new Mini-OS based stubdoms.
It hasn't seen any work for many years now and creating new stubdoms
should use UNIKRAFT instead of Mini-OS.
So remove c-stubdom.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Given the need to calculate the base anyway, it's easier to do so entirely on
the stack.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
It can be used as-is for VMX. For SVM the special treatment of %rax needs
accounting for.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
... rather than papering over guest flaws: Strings passed ought to be nul-
terminated (yet sadly libxc hasn't been doing so thus far). This way we
also avoid order-1 allocations, seeing that all present callers pass
PAGE_SIZE for max_size.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> # Changelog
Jan Beulich