Re: [PATCH v8 00/22] vfio-ap: guest dedicated crypto adapters

[Tony Krowiak]

On 08/08/2018 12:25 PM, Cornelia Huck wrote:
> 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.

That may very well be the case, but we decided on bare bones expedite
acceptance.

> > 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? :)

That is the invisible point. Only the all-knowing, all-seeing can 
discern its
presence ;)

> > 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.

Excellent!

> > 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.

There weren't any issues. They are included here solely because they are 
needed to
build the kernel and are not yet available in our master branch.

> > 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.

I was told they are available in the mainline, but I'm not entirely sure 
what that means
and I didn't verify it. They are included here precisely
because they are not yet available in our master branch and our code is 
dependent upon
them.

> > 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.

Got it.

>