Re: [PATCH v7 00/22] vfio-ap: guest dedicated crypto adapters

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

 



On 26.07.2018 21:54, Christian Borntraeger wrote:
> 2 weeks ago we had a final one week bringup session with all involved
> folks for crypto passthrough: ap bus, kernel, libvirt. v7 is the result
> of the workshop + one additional week of testing and further fixing by
> Halil, Pierre and Michael. As Tony is on vacation, I am going to send
> out this patch set. From my point of view this is now stable
> interface-wise.  Plan is that Tony acts as a maintainer, together with
> Halil and Pierre for the vfio-ap driver.  As this is mostly related to
> the AP bus, this will go via Martin Schwidefskys tree (but with review
> on the kernel.org kvm and s390 list).  When KVM code is involved, this
> will probably involve a topic branch that I will merge as well in
> kvm-next.
> 
> Alex, Kirti: Can you have a look again and ack the vfio/mdev part?
> 
> FWIW, the patches are also available at
> https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git/log/?h=ap
> 
> Notes:
> =====
> 
> Patches 1-6 (by Harald) posted with this series are forthcoming via
> Martins tree and are base changes in the ap driver/bus that we use as a
> foundation. They have been included here because some of the functions
> in this patch series are dependent upon them.
> 
> Testers, the good news is that this patch series works with the v6 QEMU
> patches. The bad news is that there is no new QEMU patchset version
> yet. 
> 
> Limitations:
> ===========
> 
> When an AP queue is bound to the vfio_ap driver and in use by a mediated
> device (assigned), it must not be reassigned back to the host zcrypt
> driver by the host admin. Otherwise the queue might be used in the host
> and guest at the same time. (A misconfiguration that acts as shoot yourself
> in the foot similar to giving a disk to two guests. We probably will
> fence this off in a later version)
> 
> 
> Abstract:
> ========
> 
> On s390, we have cryptographic coprocessor cards, which are modeled on
> Linux as devices on the AP bus. Each card can be partitioned into domains
> which can be thought of as a set of hardware registers for processing 
> crypto commands. Crypto commands are sent to a specific domain within a
> card is via a queue which is identified as a (card,domain) tuple. We model 
> this something like the following (assuming we have access to cards 3 and 
> 4 and domains 1 and 2):
> 
> AP -> card3 -> queue (3,1)
>             -> queue (3,2)
>    -> card4 -> queue (4,1)
>             -> queue (4,2)
> 
> If we want to virtualize this, we can use a feature provided by the
> hardware. We basically attach a satellite control block to our main
> hardware virtualization control block and the hardware takes care of
> most of the rest.
> 
> For this control block, we don't specify explicit tuples, but a list of
> cards and a list of domains. The guest will get access to the cross
> product.
> 
> Because of this, we need to take care that the lists provided to
> different guests don't overlap; i.e., we need to enforce sane
> configurations. Otherwise, one guest may get access to things like
> secret keys for another guest.
> 
> The idea of this patch set is to introduce a new device, the matrix
> device. This matrix device hangs off a different root and acts as the
> parent node for mdev devices.
> 
> If you now want to give the tuples (4,1) and (4,2), you need to do the
> following:
> 
> - Make sure the queues (4,1) and (4,2) belong to vfio_ap (see patches
>   #5 and #6)
> - Create the mediated device.
> - Assign card 4 and domains 1 and 2 to the mediated device
> - Optionally activate the mediated device.
> 
> QEMU will now simply consume the mediated device and things should work.
> 
> For a complete description of the architecture and concepts underlying
> the design, see the Documentation/s390/vfio-ap.txt file included with this
> patch set.
> 

I want to have a look at the KVM and vSIE parts, but I'm afraid I won't
have time before mid of next week (University ...)


-- 

Thanks,

David / dhildenb



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux