On 11/28/20 8:09 PM, Halil Pasic wrote:
On Tue, 24 Nov 2020 16:40:09 -0500 Tony Krowiak <[email protected]> wrote:The APCB is a control block containing the masks that specify the adapters, domains and control domains to which a KVM guest is granted access. When the vfio_ap device driver is notified that the KVM pointer has been set, the guest's APCB is initialized from the AP configuration of adapters, domains and control domains assigned to the matrix mdev. The linux device model, however, precludes passing through to a guest any devices that are not bound to the device driver facilitating the pass-through. Consequently, APQNs assigned to the matrix mdev that do not reference AP queue devices must be filtered before assigning them to the KVM guest's APCB; however, the AP architecture precludes filtering individual APQNs, so the APQNs will be filtered by APID. That is, if a given APQN does not reference a queue device bound to the vfio_ap driver, its APID will not get assigned to the guest's APCB. For example: Queues bound to vfio_ap: 04.0004 04.0022 04.0035 05.0004 05.0022 Adapters/domains assigned to the matrix mdev: 04 0004 0022 0035 05 0004 0022 0035 APQNs assigned to APCB: 04.0004 04.0022 04.0035 The APID 05 was filtered from the matrix mdev's matrix because queue device 05.0035 is not bound to the vfio_ap device driver. Signed-off-by: Tony Krowiak <[email protected]>This adds filtering. So from here guest_matrix may be different than matrix also for an mdev that is associated with a guest. I'm still grappling with the big picture. Have you thought about testability? How is a testcase supposed to figure out which behavior is to be deemed correct?
This patch is going away for v13 which is forthcoming. The filtering of the mdev's matrix will become part of the hot plug patch and will be used whenever changes to the mdev's matrix are made (i.e., assign/unassign), when AP queue devices are bound to and unbound from the vfio_ap device driver and when the host AP configuration changes. This resolves a couple of issues that have been brought up in these reviews: 1. Keeps the expected behavior across the various means of changing the guest's AP configuration. 2. Simplifies the code.
I don't like the title line. It implies that guest apcb was uninitialized before. Which is not the case.
This patch is going away for v13.
