Messages in this thread | | | Date | Wed, 8 Aug 2018 18:25:13 +0200 | From | Cornelia Huck <> | Subject | Re: [PATCH v8 00/22] vfio-ap: guest dedicated crypto adapters |
| |
On Wed, 8 Aug 2018 10:44:10 -0400 Tony Krowiak <akrowiak@linux.vnet.ibm.com> wrote:
> From: Tony Krowiak <akrowiak@linux.ibm.com> > > 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.
| |