Re: [PATCH v10 16/16] s390/vfio-ap: update docs to include dynamic config support

[Tony Krowiak]

On 8/25/20 6:45 AM, Cornelia Huck wrote:
> On Fri, 21 Aug 2020 15:56:16 -0400
> Tony Krowiak <akrowiak@xxxxxxxxxxxxx> wrote:
>
> > Update the documentation in vfio-ap.rst to include information about the
> > AP dynamic configuration support (i.e., hot plug of adapters, domains
> > and control domains via the matrix mediated device's sysfs assignment
> > attributes).
> >
> > Signed-off-by: Tony Krowiak <akrowiak@xxxxxxxxxxxxx>
> > ---
> >   Documentation/s390/vfio-ap.rst | 362 ++++++++++++++++++++++++++-------
> >   1 file changed, 285 insertions(+), 77 deletions(-)
> >
> > diff --git a/Documentation/s390/vfio-ap.rst b/Documentation/s390/vfio-ap.rst
> > index e15436599086..8907aeca8fb7 100644
> > --- a/Documentation/s390/vfio-ap.rst
> > +++ b/Documentation/s390/vfio-ap.rst
> > @@ -253,7 +253,7 @@ The process for reserving an AP queue for use by a KVM guest is:
> >   1. The administrator loads the vfio_ap device driver
> >   2. The vfio-ap driver during its initialization will register a single 'matrix'
> >      device with the device core. This will serve as the parent device for
> > -   all mediated matrix devices used to configure an AP matrix for a guest.
> > +   all matrix mediated devices used to configure an AP matrix for a guest.
> This (and many other changes here) seems to be unrelated to the new
> feature. Split that out into a separate patch that can be applied right
> away? That would make this patch smaller and easier to review; it's
> hard to figure out which parts deal with the new feature, and which parts
> simply got an update.
>
> Also, do you want to do similar wording changes in the QEMU
> documentation for vfio-ap?

Will do.

> >   3. The /sys/devices/vfio_ap/matrix device is created by the device core
> >   4. The vfio_ap device driver will register with the AP bus for AP queue devices
> >      of type 10 and higher (CEX4 and newer). The driver will provide the vfio_ap
> (...)
>
> > @@ -435,6 +481,10 @@ available to a KVM guest via the following CPU model features:
> >      can be made available to the guest only if it is available on the host (i.e.,
> >      facility bit 12 is set).
> >   
> > +4. apqi: Indicates AP queue interrupts are available on the guest. This facility
> > +   can be made available to the guest only if it is available on the host (i.e.,
> > +   facility bit 65 is set).
> > +
> >   Note: If the user chooses to specify a CPU model different than the 'host'
> >   model to QEMU, the CPU model features and facilities need to be turned on
> >   explicitly; for example::
> > @@ -444,7 +494,7 @@ explicitly; for example::
> >   A guest can be precluded from using AP features/facilities by turning them off
> >   explicitly; for example::
> >   
> > -     /usr/bin/qemu-system-s390x ... -cpu host,ap=off,apqci=off,apft=off
> > +     /usr/bin/qemu-system-s390x ... -cpu host,ap=off,apqci=off,apft=off,apqi=off
> Isn't that an already existing facility that was simply lacking
> documentation? If yes, split it off?

Yes and will do.

> >   
> >   Note: If the APFT facility is turned off (apft=off) for the guest, the guest
> >   will not see any AP devices. The zcrypt device drivers that register for type 10
> (...)