[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-s390x] [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated cryp

From: Tony Krowiak
Subject: Re: [qemu-s390x] [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters
Date: Tue, 5 Dec 2017 10:09:25 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0

On 12/05/2017 09:06 AM, Cornelia Huck wrote:
On Mon, 27 Nov 2017 19:39:32 -0500
Tony Krowiak <address@hidden> wrote:

On 11/22/2017 08:47 AM, Cornelia Huck wrote:
On Tue, 21 Nov 2017 11:08:01 -0500
Tony Krowiak <address@hidden> 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
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.
Yes, the new type makes this distinct enough so that we can think about
this later.

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
...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.
OK, so I admit that I lost track a bit. Are there any remaining issues
beyond the feature handling? Would it make sense to post a v2?
I was planning on posting a V2 once the features issue is settled.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]