Add couple of additional info lines to make it easier to match
test suite output and results.
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

gcc and clang warn about incompatible pointer types due to the recent
cmpxchg changes:

drivers/gpu/drm/drm_lock.c:75:10: error: passing 'typeof (lock)' (aka 'volatile unsigned int *') to parameter of type 'void *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
                   prev = cmpxchg(lock, old, new);
                          ^~~~~~~~~~~~~~~~~~~~~~~
   include/asm-generic/atomic-instrumented.h:1685:2: note: expanded from macro 'cmpxchg'
           arch_cmpxchg(__ai_ptr, __VA_ARGS__); \
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To avoid this simply cast pointers to unsigned long and use them
instead of void pointers. This allows to stay with functions, instead
of using complex defines and having to deal with all their potential
side effects.
Reported-by: kernel test robot <lkp@intel.com>
Fixes: d2b1f6d2 ("s390/cmpxchg: get rid of gcc atomic builtins")
Link: https://lore.kernel.org/linux-s390/202104130131.sMmSqpb5-lkp@intel.com/Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Trigger a warning if any of unwinder tests fail. This should help to
prevent quiet ignoring of test results when panic_on_warn is enabled.
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Handle the case of "unwind state reliable but addr is 0" like other error
cases in this function and trigger output of failing stacktrace to aid
debugging.
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Set CONFIG_FRAME_WARN to 2048, which is the default for 64 bit architectures.
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Allow the compiler to generate slightly better code by using the R
constraint.
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Add arch_ prefix to all atomic operations, and define ARCH_ATOMIC.
This enables KASAN instrumentation for all atomic operations on s390.

This is the s390 variant of commit 8bf705d1 ("locking/atomic/x86:
Switch atomic.h to use atomic-instrumented.h").
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

s390 is the only architecture in the kernel which makes use of gcc's
atomic builtin functions. Even though I don't see any technical
problem with that right now, remove this code and open-code
compare-and-swap loops again, like every other architecture is doing
it also.
We can switch to a generic implementation when other architectures are
doing that also.

See also https://lwn.net/Articles/586838/ for forther details.

This basically reverts commit f318a122 ("s390/cmpxchg: use
compiler builtins").
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

s390 is the only architecture in the kernel which makes use of gcc's
atomic builtin functions. Even though I don't see any technical
problem with that right now, remove this code and open-code
compare-and-swap loops again, like every other architecture is doing
it also.
We can switch to a generic implementation when other architectures are
doing that also.

See also https://lwn.net/Articles/586838/ for forther details.
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Use the R,T, and S constraints instead of the Q constraint in atomic
inline assemblies wherever possible. This allows the compiler to
generate better code. (~ -2kb code size).
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Move all remaining inline assemblies from atomic.h to
atomic_ops.h. That way all atomic inline assemblies are
contained within only a single header file.
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

The bitops code was optimized to generate test under mask instructions
with the __bitops_byte() helper. However that was many years ago and
in the meantime a lot of new instructions were introduced.

Changing the code so that it always operates on longs nowadays even
generates shorter code (~ -20kb, defconfig, gcc 10, march=zE12).
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Add conditional trap handlers similar to conditional system calls
(COND_SYSCALL), to reduce the number of ifdefs.

Trap handlers which may or may not exist depending on config options
are supposed to have a COND_TRAP entry, which redirects to
default_trap_handler() for non-existent trap handlers during link
time.

This allows to get rid of the secure execution trap handlers for the
!PGSTE case.
Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Currently zpci_configure_device() can be called on a zPCI function in
two completely different states. Either the underlying zPCI function has
already been configured by the platform and we are only doing the
scanning to get it usable by Linux drivers. Or the underlying function
is in Standby and we first do an SCLP to get it configured. This makes
zpci_configure_device() harder to reason about. Since calling
zpci_configure_device() on a function in Standby only happens in
enable_slot() simply pull out the SCLP call and setting of zdev->state
and thus call zpci_configure_device() under the same circumstances as
in the event handling code.
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Now that the zbus can be created without being scanned we can go one
step further and make registering a device to a zbus independent from
scanning it. This way the zbus handling becomes much more natural
in that functions can be registered on the zbus to be scanned later more
closely resembling the handling of both real PCI hardware and other
virtual PCI busses like Hyper-V's virtual PCI bus (see for example
drivers/pci/controller/pci-hyperv.c:create_root_hv_pci_bus()).

Having zbus registration separate from scanning allows us to return
fully initialized but still disabled zdevs from zpci_create_device()
which can then be configured just as we would configure a zdev from
standby (minus the SCLP Configure already done by the platform).  There
is still the exception that a PCI function with non-zero devfn can be
plugged before its PCI bus, which depends on the function with zero
devfn, is created. In this case the zdev returend from
zpci_create_device() is still missing its bus, hotplug slot, and
resources which need to be created later but at least it doesn't wait in
the enabled state and can otherwise be treated as initialized.

With this we also separate the initial PCI scan using CLP List PCI
Functions into two phases. In the CLP loop's callback we only register
each function with a virtual zbus creating the latter as needed. Then,
after we have built this virtual PCI topology based on our list of
zbusses, we can make use of the common code functionality to scan each
complete zbus as a separate child bus.
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Acked-by: Pierre Morel <pmorel@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

In a later change we will first collect all PCI functions from the CLP
List PCI functions call, then register them to/creating the relevant
zbus. Then only after we've created our virtual bus structure will we
scan all zbusses iterating over the zbus list. Since scanning is
relatively slow a spinlock is a bad fit for protecting the
loop over the devices on the zbus. Furthermore doing the probing on the
bus we need to use pci_lock_rescan_remove() as devices are added to
the PCI subsystem and that is a mutex which can't be locked nested
inside a spinlock section. Note that the contention of this lock should
be very low either way as zbusses are only added/removed concurrently on
hotplug events.
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

In the existing code the creation of the PCI bus and the scanning of
function zero all happens in zpci_scan_bus(). This in turn requires
functions to be enabled and their resources to be available before the
PCI bus is even created.

This not only means that functions are enabled long before they are
actually made available to the common PCI subsystem. In case of
functions with non-zero devfn which appeared before the function with
devfn zero they can wait arbitrarily long in this enabled but not
scanned state.

Fix this by separating the creation of the PCI bus from scanning it and
only prepare, that is enable and setup MMIO bus resources, functions
just before they are scanned. As they may be scanned multiple times
track if we already created resources in the zdev.
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Acked-by: Pierre Morel <pmorel@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Pull setting the maximum bus speed and multifunction attribute into
zpci_bus_scan() in preparation for handling bus creation separately
from scanning the bus.
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Acked-by: Pierre Morel <pmorel@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

To match zpci_bus_scan_device() and the PCI common code terminology and
to remove some code duplication, we pull the multiple uses of
pci_scan_single_device() into a function. For now this has the side
effect of adding each device to the PCI bus separately and locking and
unlocking the rescan/remove lock for each instead of just once per bus.
This is clearly less efficient but provides a correct intermediate
behavior until a follow on change does both the adding and scanning only
once per bus.
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Acked-by: Pierre Morel <pmorel@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Convert the program check table to C. Which allows to get rid of yet
another assembler file, and also enables proper type checking for the
table.
Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Use DECLARE_WAIT_QUEUE_HEAD to declare and statically initialize the
work_queue_head_t.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Baisong Zhong <zhongbaisong@huawei.com>
Fixes: 37564ed8 ("s390/uv: add prot virt guest/host indication files")
Link: https://lore.kernel.org/r/2f7d62a4-3e75-b2b4-951b-75ef8ef59d16@huawei.comSigned-off-by: Heiko Carstens <hca@linux.ibm.com>

* fixes:
  s390/entry: save the caller of psw_idle
  s390/entry: avoid setting up backchain in ext|io handlers
  s390/setup: use memblock_free_late() to free old stack
  s390/irq: fix reading of ext_params2 field from lowcore
  s390/unwind: add machine check handler stack
  s390/cpcmd: fix inline assembly register clobbering
  MAINTAINERS: add backups for s390 vfio drivers
  s390/vdso: fix initializing and updating of vdso_data
  s390/vdso: fix tod_steering_delta type
  s390/vdso: copy tod_steering_delta value to vdso_data page
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Currently psw_idle does not allocate a stack frame and does not
save its r14 and r15 into the save area. Even though this is valid from
call ABI point of view, because psw_idle does not make any calls
explicitly, in reality psw_idle is an entry point for controlled
transition into serving interrupts. So, in practice, psw_idle stack
frame is analyzed during stack unwinding. Depending on build options
that r14 slot in the save area of psw_idle might either contain a value
saved by previous sibling call or complete garbage.

  [task    0000038000003c28] do_ext_irq+0xd6/0x160
  [task    0000038000003c78] ext_int_handler+0xba/0xe8
  [task   *0000038000003dd8] psw_idle_exit+0x0/0x8 <-- pt_regs
 ([task    0000038000003dd8] 0x0)
  [task    0000038000003e10] default_idle_call+0x42/0x148
  [task    0000038000003e30] do_idle+0xce/0x160
  [task    0000038000003e70] cpu_startup_entry+0x36/0x40
  [task    0000038000003ea0] arch_call_rest_init+0x76/0x80

So, to make a stacktrace nicer and actually point for the real caller of
psw_idle in this frequently occurring case, make psw_idle save its r14.

  [task    0000038000003c28] do_ext_irq+0xd6/0x160
  [task    0000038000003c78] ext_int_handler+0xba/0xe8
  [task   *0000038000003dd8] psw_idle_exit+0x0/0x6 <-- pt_regs
 ([task    0000038000003dd8] arch_cpu_idle+0x3c/0xd0)
  [task    0000038000003e10] default_idle_call+0x42/0x148
  [task    0000038000003e30] do_idle+0xce/0x160
  [task    0000038000003e70] cpu_startup_entry+0x36/0x40
  [task    0000038000003ea0] arch_call_rest_init+0x76/0x80
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Currently when interrupt arrives to cpu while in kernel context
INT_HANDLER macro (used for ext_int_handler and io_int_handler)
allocates new stack frame and pt_regs on the kernel stack and
sets up the backchain to jump over the pt_regs to the frame which has
been interrupted. This is not ideal to two reasons:

1. This hides the fact that kernel stack contains interrupt frame in it
   and hence breaks arch_stack_walk_reliable(), which needs to know that to
   guarantee "reliability" and checks that there are no pt_regs on the way.

2. It breaks the backchain unwinder logic, which assumes that the next
   stack frame after an interrupt frame is reliable, while it is not.
   In some cases (when r14 contains garbage) this leads to early unwinding
   termination with an error, instead of marking frame as unreliable
   and continuing.

To address that, only set backchain to 0.

Fixes: 56e62a73 ("s390: convert to generic entry")
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

For static initialization of list_head variable, use LIST_HEAD
instead of INIT_LIST_HEAD function.
Suggested-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

For static initialization of spinlock_t variable, use DEFINE_SPINLOCK
instead of explicitly calling spin_lock_init().
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Use memblock_free_late() to free the old machine check stack to the
buddy allocator instead of leaking it.

Fixes: b61b1595 ("s390: add stack for machine check handler")
Cc: Vasily Gorbik <gor@linux.ibm.com>
Acked-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Due to historical reasons mark_kernel_pXd() functions
misuse the notion of physical vs virtual addresses
difference.
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

This patch fixes a lockdep splat introduced by commit f21916ec
("s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated").
The lockdep splat only occurs when starting a Secure Execution guest.
Crypto virtualization (vfio_ap) is not yet supported for SE guests;
however, in order to avoid this problem when support becomes available,
this fix is being provided.

The circular locking dependency was introduced when the setting of the
masks in the guest's APCB was executed while holding the matrix_dev->lock.
While the lock is definitely needed to protect the setting/unsetting of the
matrix_mdev->kvm pointer, it is not necessarily critical for setting the
masks; so, the matrix_dev->lock will be released while the masks are being
set or cleared.

Keep in mind, however, that another process that takes the matrix_dev->lock
can get control while the masks in the guest's APCB are being set or
cleared as a result of the driver being notified that the KVM pointer
has been set or unset. This could result in invalid access to the
matrix_mdev->kvm pointer by the intervening process. To avoid this
scenario, two new fields are being added to the ap_matrix_mdev struct:

struct ap_matrix_mdev {
	...
	bool kvm_busy;
	wait_queue_head_t wait_for_kvm;
   ...
};

The functions that handle notification that the KVM pointer value has
been set or cleared will set the kvm_busy flag to true until they are done
processing at which time they will set it to false and wake up the tasks on
the matrix_mdev->wait_for_kvm wait queue. Functions that require
access to matrix_mdev->kvm will sleep on the wait queue until they are
awakened at which time they can safely access the matrix_mdev->kvm
field.

Fixes: f21916ec ("s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated")
Cc: stable@vger.kernel.org
Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

struct ccw1 is declared twice. One has been declared
at 21st line. Remove the duplicate.
Signed-off-by: Wan Jiabing <wanjiabing@vivo.com>
Acked-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

wait_queue_head_t can be initialized automatically with
DECLARE_WAIT_QUEUE_HEAD() rather than explicitly calling
init_waitqueue_head().
Signed-off-by: Shixin Liu <liushixin2@huawei.com>
Acked-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

static spinlock can be initialized automatically with DEFINE_SPINLOCK()
rather than explicitly calling spin_lock_init().
Signed-off-by: Shixin Liu <liushixin2@huawei.com>
Acked-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

On s390 each PCI device has a user-defined ID (UID) exposed under
/sys/bus/pci/devices/<dev>/uid. This ID was designed to serve as the PCI
device's primary index and to match the device within Linux to the
device configured in the hypervisor. To serve as a primary identifier
the UID must be unique within the Linux instance, this is guaranteed by
the platform if and only if the UID Uniqueness Checking flag is set
within the CLP List PCI Functions response.

While the UID has been exposed to userspace since commit ac4995b9
("s390/pci: add some new arch specific pci attributes") whether or not
the platform guarantees its uniqueness for the lifetime of the Linux
instance while defined is not visible from userspace. Remedy this by
exposing this as a per device attribute at

/sys/bus/pci/devices/<dev>/uid_is_unique

Keeping this a per device attribute allows for maximum flexibility if we
ever end up with some devices not having a UID or not enjoying the
guaranteed uniqueness.
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Viktor Mihajlovski <mihajlov@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

The contents of the ext_params2 field of the lowcore should just be
copied to the pt_regs structure, not dereferenced.

Fixes crashes / program check loops like this:

Krnl PSW : 0404c00180000000 00000000d6d02b3c (do_ext_irq+0x74/0x170)
           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
Krnl GPRS: 0000000000000000 80000000000b974e 00000000d71abee0 00000000d71abee0
           0000000080030000 000000000000000f 0000000000000000 0000000000000000
           0000000000000001 00000380000bf918 00000000d73ef780 00000380000bf518
           0000000080348000 00000000d6d13350 00000000d6d02b1e 00000380000bf428
Krnl Code: 00000000d6d02b2e: 58100080            l       %r1,128
           00000000d6d02b32: 5010b0a4            st      %r1,164(%r11)
          #00000000d6d02b36: e31001b80104        lg      %r1,4536
          >00000000d6d02b3c: e31010000004        lg      %r1,0(%r1)
           00000000d6d02b42: e310b0a80024        stg     %r1,168(%r11)
           00000000d6d02b48: c01000242270        larl    %r1,00000000d7187028
           00000000d6d02b4e: d5071000b010        clc     0(8,%r1),16(%r11)
           00000000d6d02b54: a784001b            brc     8,00000000d6d02b8a
Call Trace:
 [<00000000d6d02b3c>] do_ext_irq+0x74/0x170
 [<00000000d6d0ea5c>] ext_int_handler+0xc4/0xf4
 [<00000000d621d266>] die+0x106/0x188
 [<00000000d62305b8>] do_no_context+0xc8/0x100
 [<00000000d6d02790>] __do_pgm_check+0xe0/0x1f0
 [<00000000d6d0e950>] pgm_check_handler+0x118/0x160
 [<00000000d6d02b3c>] do_ext_irq+0x74/0x170
 [<00000000d6d0ea5c>] ext_int_handler+0xc4/0xf4
 [<00000000d621d266>] die+0x106/0x188
 [<00000000d62305b8>] do_no_context+0xc8/0x100
 [<00000000d6d02790>] __do_pgm_check+0xe0/0x1f0
 [<00000000d6d0e950>] pgm_check_handler+0x118/0x160
 [<00000000d6d02b3c>] do_ext_irq+0x74/0x170
 [<00000000d6d0ea5c>] ext_int_handler+0xc4/0xf4
 [<0000000000000000>] 0x0
 [<00000000d6d0e57a>] default_idle_call+0x42/0x110
 [<00000000d629856e>] do_idle+0xce/0x160
 [<00000000d62987be>] cpu_startup_entry+0x36/0x40
 [<00000000d621f2f2>] smp_start_secondary+0x82/0x88

Cc: Sven Schnelle <svens@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Fixes: 56e62a73 ("s390: convert to generic entry")
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Fixes: b61b1595 ("s390: add stack for machine check handler")
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Register variables initialized using arithmetic. That leads to
kasan instrumentaton code corrupting the registers contents.
Follow GCC guidlines and use temporary variables for assigning
init values to register variables.

Fixes: 94c12cc7 ("[S390] Inline assembly cleanup.")
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Link: https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Local-Register-Variables.htmlSigned-off-by: Heiko Carstens <hca@linux.ibm.com>

In commit dee60c0d ("s390/pci: add zpci_event_hard_deconfigured()")
we added a zdev_enabled() check to what was previously an uncoditional
call to zpci_disable_device(). There are two problems with that. Firstly
zpci_had_deconfigured() is only called on event 0x0304 for which the
device is always already disabled by the platform so it is always false.
Secondly zpci_disable_device() not only disables the device but also
calls zpci_dma_exit_device() which is thus not called and we leak the
DMA tables.

Fix this by calling zpci_disable_device() unconditionally to perform
Linux side cleanup including the freeing of DMA tables.

Fixes: dee60c0d ("s390/pci: add zpci_event_hard_deconfigured()")
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Acked-by: Pierre Morel <pmorel@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

No need to add an align attribute for an integer.
The alignment is correct anyway.
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Add a backup for s390 vfio-pci, an additional backup for vfio-ccw
and replace the backup for vfio-ap as Pierre is focusing on other
areas.
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Acked-by: Eric Farman <farman@linux.ibm.com>
Acked-by: Halil Pasic <pasic@linux.ibm.com>
Acked-by: Pierre Morel <pmorel@linux.ibm.com>
Acked-by: Jason J. Herne <jjherne@linux.ibm.com>
Link: https://lore.kernel.org/r/1616679712-7139-1-git-send-email-mjrosato@linux.ibm.comSigned-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>