lkml.org 
[lkml]   [2017]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters
    On Mon, 27 Nov 2017 19:39:32 -0500
    Tony Krowiak <akrowiak@linux.vnet.ibm.com> wrote:

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

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

    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?

    \
     
     \ /
      Last update: 2017-12-05 15:10    [W:4.146 / U:0.540 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site