On Wed, 8 Aug 2018 10:44:10 -0400 Tony Krowiak <akrowiak@xxxxxxxxxxxxxxxxxx> wrote: > From: Tony Krowiak <akrowiak@xxxxxxxxxxxxx> > > Several major objections were raised to design changes introduced in the v7 > patch series, so in order to avoid an extended discussion around these > objections and to expedite acceptance of the series, the following changes > have been made for v8: > > 1. Removed the AP bus's ability to designate queues as 'used by host' or as > 'used by alternate driver(s)'. The bind/unbind sysfs interfaces will be > used for managing the connection of AP queue devices to a zcrypt driver > or the VFIO AP driver. I don't think the idea of pools is bad per se; I mainly did not like the sysfs interface and the dynamic interactions. We can probably reintroduce something like that later on, if it is still useful. > > 2. Removed the 'activate' sysfs interfaces which allowed for over > provisioning of the mediated device as well as creation of mdevs with > overlapping matrixes. It was pointed out that both of these enhancements > break the mdev model. Consistency checking of the mdev matrix has > therefore been returned to the mediated matrix device's sysfs interfaces > for assigning adapters and domains: > > * Verify that APQNs assigned to the mediated device are bound to the > VFIO AP device driver > > * Verify that no APQN assigned to the mediated matrix device is assigned > to any other mediated matrix device. Ok, that makes sense. Where's point 3? :) > > 4. Reworked the handling of the CRYCB in vSIE based upon patches introduced > by David in the mainline. I had reviewed David's patches and they looked good to me. > > Notes: > ===== > > Patches 1-4 (by Harald) posted with this series are forthcoming via > Martins tree and are based on changes in the ap driver/bus that we use as a > foundation. They have been included here because some of the functions > in this patch series are dependent upon them. I don't remember anything contentious in these. > > Patches 5-6 (by David) are posted with this series because they are not > currently in our master branch. Patches 19 and 20 of this series are > dependent upon them. I believe David's patches are available in the > mainline now. I don't see them queued yet, but as said, they looked fine to me. > > This patch series works with the v6 QEMU patches. There is no new QEMU > patchset version yet because there have been no review comments worthy of > creating a new series; only a couple of extremely minor nits. Once the kernel part is merged, I'd need a respin anyway due to the kernel headers updates.
