Re: [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters

[Tony Krowiak <akrowiak@linux.vnet.ibm.com>]

On 11/22/2017 08:47 AM, Cornelia Huck wrote:
> On Tue, 21 Nov 2017 11:08:01 -0500
> Tony Krowiak <akrowiak@linux.vnet.ibm.com> wrote:
>
>
>> I am not quite sure what you are asking, but I'll attempt to answer
>> what I think you're asking. A new type of mediated matrix device
>> will be introduced to configure a virtual matrix for a guest that
>> provides the interfaces to map a virtual adapter/domain ID to one
>> or more real adapter/domain IDs. If by virtualization facility,
>> you are talking about the VFIO AP matrix driver, then yes,
>> the driver will handle ioctl requests based on the type of the
>> mediated matrix device through which the request was submitted:
>>
>> If the request is to configure the KVM guest's matrix:
>>
>> * If the mediated matrix device type is passthrough:
>>     * Do validation of matrix
>>     * Configure the APM, AQM and ADM in the KVM guest's CRYCB
>>       according to the configuration specified via the mediated
>>       device's sysfs attribute files.
>> * If the mediated matrix device type is virtual:
>>     * Do validation of matrix
>>     * No need to configure CRYCB since all instructions will be
>>       intercepted
> Ok, so we would have two distinct paths here...
It depends upon what you mean by two distinct paths. Configuring the
mediated device would require a new mediated device type for virtualized
AP matrices. The ioctl for configuring the KVM guest's CRYCB would
require an additional check to determine whether the CRYCB need be
configured or not.
>
>> If the request is to execute an intercepted AP instruction:
>>
>> * If the mediated matrix device type is passthrough:
>>     * Forward the instruction to the AP device and return the
>>       result to QEMU.
>>
>> * If the mediated matrix device type is virtual:
>>
>>     * Retrieve all of the real APQNs mapped to the virtual
>>       adapter and domain IDs configured in the mediated matrix
>>       device's sysfs attribute files
>>     * If there is more than one APQN mapping, then determine
>>       which would be best to use - algorithm TBD
>>     * Forward the instruction to the AP device and return the
>>       result.
> ...and two distinct paths for most instructions here as well.
The driver would require additional ioctls to handle
interception of all AP instructions for virtual matrices and additional
code to remap virtual APQNs to real APQNs and determine which real APQN
to which intercepted instructions should be forwarded.
>
>> Of course, these are just preliminary ideas at this time.
>> I've only prototyped the sysfs configuration interfaces. No
>> back end prototyping has been undertaken yet. If the ideas do
>> not pan out, however; I think virtualization can be introduced
>> as an independent design.
> Yes, let's cross that bridge when we get to it.
That is the plan. Given Pierre's objections, I thought it might help
to touch on this.
>