On 11/28/20 8:17 PM, Halil Pasic wrote:
On Tue, 24 Nov 2020 16:40:10 -0500 Tony Krowiak <akrowiak@xxxxxxxxxxxxx> wrote: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 twofold: 1. The AP architecture does not preclude assignment of APQNs to an AP configuration that are not available to the system. 2. APQNs that do not reference a queue device bound to the vfio_ap device driver will not be assigned to the guest's CRYCB, so the guest will not get access to queues not bound to the vfio_ap driver. Signed-off-by: Tony Krowiak <akrowiak@xxxxxxxxxxxxx>Again code looks good. I'm still worried about all the incremental changes (good for review) and their testability.
I'm not sure what your concern is here. Is there an expectation that each patch needs to be testable by itself, or whether the functionality in each patch can be easily tested en masse? I'm not sure some of these changes can be tested with an automated test because the test code would have to be able to dynamically change the host's AP configuration and I don't know if there is currently a way to do this programmatically. In order to test the effects of dynamic host crypto configuration manually, one needs access to an SE or HMC with DPM.
