Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 19 7月, 2022 10 次提交
    • T
      s390/vfio-ap: prepare for dynamic update of guest's APCB on assign/unassign · 8ee13ad9
      由 Tony Krowiak 提交于 
      The functions backing the matrix mdev's sysfs attribute interfaces to
assign/unassign adapters, domains and control domains must take and
release the locks required to perform a dynamic update of a guest's APCB
in the proper order.

The proper order for taking the locks is:

matrix_dev->guests_lock => kvm->lock => matrix_dev->mdevs_lock

The proper order for releasing the locks is:

matrix_dev->mdevs_lock => kvm->lock => matrix_dev->guests_lock

Two new macros are introduced for this purpose: One to take the locks and
the other to release the locks. These macros will be used by the
assignment/unassignment functions to prepare for dynamic update of
the KVM guest's APCB.
Signed-off-by: NTony Krowiak <akrowiak@linux.ibm.com>
Signed-off-by: NAlexander Gordeev <agordeev@linux.ibm.com>
      8ee13ad9
    • T
      s390/vfio-ap: use proper locking order when setting/clearing KVM pointer · b84eb8e0
      由 Tony Krowiak 提交于 
      The group notifier that handles the VFIO_GROUP_NOTIFY_SET_KVM event must
use the required locks in proper locking order to dynamically update the
guest's APCB. The proper locking order is:

       1. matrix_dev->guests_lock: required to use the KVM pointer to
          update a KVM guest's APCB.

       2. matrix_mdev->kvm->lock: required to update a KVM guest's APCB.

       3. matrix_dev->mdevs_lock: required to store or access the data
          stored in a struct ap_matrix_mdev instance.

Two macros are introduced to acquire and release the locks in the proper
order. These macros are now used by the group notifier functions.
Signed-off-by: NTony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: NJason J. Herne <jjherne@linux.ibm.com>
Signed-off-by: NAlexander Gordeev <agordeev@linux.ibm.com>
      b84eb8e0
    • T
      s390/vfio-ap: introduce new mutex to control access to the KVM pointer · 21195eb0
      由 Tony Krowiak 提交于 
      The vfio_ap device driver registers for notification when the pointer to
the KVM object for a guest is set. Recall that the KVM lock (kvm->lock)
mutex must be taken outside of the matrix_dev->lock mutex to prevent the
reporting by lockdep of a circular locking dependency (a.k.a., a lockdep
splat):

* see commit 0cc00c8d ("Fix circular lockdep when setting/clearing
  crypto masks")

* see commit 86956e70 ("replace open coded locks for
  VFIO_GROUP_NOTIFY_SET_KVM notification")

With the introduction of support for hot plugging/unplugging AP devices
passed through to a KVM guest, a new guests_lock mutex is introduced to
ensure the proper locking order is maintained:

struct ap_matrix_dev {
        ...
        struct mutex guests_lock;
       ...
}

The matrix_dev->guests_lock controls access to the matrix_mdev instances
that hold the state for AP devices that have been passed through to a
KVM guest. This lock must be held to control access to the KVM pointer
(matrix_mdev->kvm) while the vfio_ap device driver is using it to
plug/unplug AP devices passed through to the KVM guest.

Keep in mind, the proper locking order must be maintained whenever
dynamically updating a KVM guest's APCB to plug/unplug adapters, domains
and control domains:

    1. matrix_dev->guests_lock: required to use the KVM pointer - stored in
       a struct ap_matrix_mdev instance - to update a KVM guest's APCB

    2. matrix_mdev->kvm->lock: required to update a guest's APCB

    3. matrix_dev->mdevs_lock: required to access data stored in a
       struct ap_matrix_mdev instance.
Signed-off-by: NTony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: NJason J. Herne <jjherne@linux.ibm.com>
Signed-off-by: NAlexander Gordeev <agordeev@linux.ibm.com>
      21195eb0
    • T
      s390/vfio-ap: rename matrix_dev->lock mutex to matrix_dev->mdevs_lock · d0786556
      由 Tony Krowiak 提交于 
      The matrix_dev->lock mutex is being renamed to matrix_dev->mdevs_lock to
better reflect its purpose, which is to control access to the state of the
mediated devices under the control of the vfio_ap device driver.
Signed-off-by: NTony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: NJason J. Herne <jjherne@linux.ibm.com>
Signed-off-by: NAlexander Gordeev <agordeev@linux.ibm.com>
      d0786556
    • T
      s390/vfio-ap: allow assignment of unavailable AP queues to mdev device · e2126a73
      由 Tony Krowiak 提交于 
      The current implementation does not allow assignment of an AP adapter or
domain to an mdev device if each APQN resulting from the assignment
does not reference an AP queue device that is bound to the vfio_ap device
driver. This patch allows assignment of AP resources to the matrix mdev as
long as the APQNs resulting from the assignment:
   1. Are not reserved by the AP BUS for use by the zcrypt device drivers.
   2. Are not assigned to another matrix mdev.

The rationale behind this is that the AP architecture does not preclude
assignment of APQNs to an AP configuration profile that are not available
to the system.
Signed-off-by: NTony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: NHalil Pasic <pasic@linux.ibm.com>
Signed-off-by: NAlexander Gordeev <agordeev@linux.ibm.com>
      e2126a73
    • T
      s390/vfio-ap: refresh guest's APCB by filtering AP resources assigned to mdev · 48cae940
      由 Tony Krowiak 提交于 
      Refresh the guest's APCB by filtering the APQNs and control domain numbers
assigned to the matrix mdev.

Filtering of APQNs:
-----------------
APQNs that do not reference an AP queue device bound to the vfio_ap device
driver must be filtered from the APQNs assigned to the matrix mdev before
they can be assigned to the guest's APCB. Given that the APQNs are
configured in the guest's APCB as a matrix of APIDs (adapters) and APQIs
(domains), it is not possible to filter an individual APQN. For example,
suppose the matrix of APQNs is structured as follows:

                   APIDs
             3      4      5
        0  (3,0)  (4,0)  (5,0)
APQIs   1  (3,1)  (4,1)  (5,1)
        2  (3,2)  (4,2)  (5,2)

Now suppose APQN (4,1) does not reference a queue device bound to the
vfio_ap device driver. If we filter APID 4, the APQNs (4,0), (4,1) and
(4,2) will be removed. Similarly, if we filter domain 1, APQNs (3,1),
(4,1) and (5,1) will be removed.

To resolve this dilemma, the choice was made to filter the APID - in this
case 4 - from the guest's APCB. The reason for this design decision is
because the APID references an AP adapter which is a real hardware device
that can be physically installed, removed, enabled or disabled; whereas, a
domain is a partition within the adapter. It therefore better reflects
reality to remove the APID from the guest's APCB.

Filtering of control domains:
----------------------------
Any control domains that are not assigned to the host's AP configuration
will be filtered from those assigned to the matrix mdev before assigning
them to the guest's APCB.
Signed-off-by: NTony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: NJason J. Herne <jjherne@linux.ibm.com>
Signed-off-by: NAlexander Gordeev <agordeev@linux.ibm.com>
      48cae940
    • T
      s390/vfio-ap: introduce shadow APCB · 49b0109f
      由 Tony Krowiak 提交于 
      The APCB is a field within the CRYCB that provides the AP configuration
to a KVM guest. Let's introduce a shadow copy of the KVM guest's APCB and
maintain it for the lifespan of the guest.

The shadow APCB serves the following purposes:

1. The shadow APCB can be maintained even when the mediated device is not
   currently in use by a KVM guest. Since the mediated device's AP
   configuration is filtered to ensure that no AP queues are passed through
   to the KVM guest that are not bound to the vfio_ap device driver or
   available to the host, the mediated device's AP configuration may differ
   from the guest's. Having a shadow of a guest's APCB allows us to provide
   a sysfs interface to view the guest's APCB even if the mediated device
   is not currently passed through to a KVM guest. This can aid in
   problem determination when the guest is unexpectedly missing AP
   resources.

2. If filtering was done in-place for the real APCB, the guest could pick
   up a transient state. Doing the filtering on a shadow and transferring
   the AP configuration to the real APCB after the guest is started or when
   AP resources are assigned to or unassigned from the mediated device, or
   when the host configuration changes, the guest's AP configuration will
   never be in a transient state.
Signed-off-by: NTony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: NHalil Pasic <pasic@linux.ibm.com>
Signed-off-by: NAlexander Gordeev <agordeev@linux.ibm.com>
      49b0109f
    • T
      s390/vfio-ap: manage link between queue struct and matrix mdev · 11cb2419
      由 Tony Krowiak 提交于 
      Let's create links between each queue device bound to the vfio_ap device
driver and the matrix mdev to which the queue's APQN is assigned. The idea
is to facilitate efficient retrieval of the objects representing the queue
devices and matrix mdevs as well as to verify that a queue assigned to
a matrix mdev is bound to the driver.

The links will be created as follows:

 * When the queue device is probed, if its APQN is assigned to a matrix
   mdev, the structures representing the queue device and the matrix mdev
   will be linked.

 * When an adapter or domain is assigned to a matrix mdev, for each new
   APQN assigned that references a queue device bound to the vfio_ap
   device driver, the structures representing the queue device and the
   matrix mdev will be linked.

The links will be removed as follows:

 * When the queue device is removed, if its APQN is assigned to a matrix
   mdev, the link from the structure representing the matrix mdev to the
   structure representing the queue will be removed. Since the storage
   allocated for the vfio_ap_queue will be freed, there is no need to
   remove the link to the matrix_mdev to which the queue's APQN is
   assigned.

 * When an adapter or domain is unassigned from a matrix mdev, for each
   APQN unassigned that references a queue device bound to the vfio_ap
   device driver, the structures representing the queue device and the
   matrix mdev will be unlinked.

 * When an mdev is removed, the link from any queues assigned to the mdev
   to the mdev will be removed.
Signed-off-by: NTony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: NHalil Pasic <pasic@linux.ibm.com>
Signed-off-by: NAlexander Gordeev <agordeev@linux.ibm.com>
      11cb2419
    • T
      s390/vfio-ap: move probe and remove callbacks to vfio_ap_ops.c · 260f3ea1
      由 Tony Krowiak 提交于 
      Let's move the probe and remove callbacks into the vfio_ap_ops.c
file to keep all code related to managing queues in a single file. This
way, all functions related to queue management can be removed from the
vfio_ap_private.h header file defining the public interfaces for the
vfio_ap device driver.
Signed-off-by: NTony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: NHalil Pasic <pasic@linux.ibm.com>
Signed-off-by: NAlexander Gordeev <agordeev@linux.ibm.com>
      260f3ea1
    • T
      s390/vfio-ap: use new AP bus interface to search for queue devices · 034921cd
      由 Tony Krowiak 提交于 
      This patch refactors the vfio_ap device driver to use the AP bus's
ap_get_qdev() function to retrieve the vfio_ap_queue struct containing
information about a queue that is bound to the vfio_ap device driver.
The bus's ap_get_qdev() function retrieves the queue device from a
hashtable keyed by APQN. This is much more efficient than looping over
the list of devices attached to the AP bus by several orders of
magnitude.
Signed-off-by: NTony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: NHalil Pasic <pasic@linux.ibm.com>
Reviewed-by: NJason J. Herne <jjherne@linux.ibm.com>
Signed-off-by: NAlexander Gordeev <agordeev@linux.ibm.com>
      034921cd
  3. 05 7月, 2022 1 次提交
  5. 20 6月, 2022 1 次提交
  7. 19 6月, 2022 19 次提交
  9. 18 6月, 2022 9 次提交