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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cb4d43b9-bfe1-b2a0-179c-a6362a5f1380@linux.ibm.com>
Date:   Mon, 31 Aug 2020 14:34:16 -0400
From:   Tony Krowiak <akrowiak@...ux.ibm.com>
To:     Cornelia Huck <cohuck@...hat.com>
Cc:     linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, freude@...ux.ibm.com, borntraeger@...ibm.com,
        mjrosato@...ux.ibm.com, pasic@...ux.ibm.com,
        alex.williamson@...hat.com, kwankhede@...dia.com,
        fiuczy@...ux.ibm.com, frankja@...ux.ibm.com, david@...hat.com,
        imbrenda@...ux.ibm.com, hca@...ux.ibm.com, gor@...ux.ibm.com
Subject: Re: [PATCH v10 16/16] s390/vfio-ap: update docs to include dynamic
 config support



On 8/25/20 6:45 AM, Cornelia Huck wrote:
> On Fri, 21 Aug 2020 15:56:16 -0400
> Tony Krowiak <akrowiak@...ux.ibm.com> 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@...ux.ibm.com>
>> ---
>>   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
> (...)
>