[libvirt] [PATCH v2 1/3] qemu: add vfio-ap capability

Boris Fiuczynski fiuczy at linux.ibm.com
Thu Oct 25 11:54:59 UTC 2018


On 10/25/18 5:17 AM, Chris Venteicher wrote:
> Quoting Thomas Huth (2018-10-19 06:58:34)
>> On 2018-10-18 16:54, Boris Fiuczynski wrote:
>>> Introduce vfio-ap capability.
>>>
>>> Signed-off-by: Boris Fiuczynski <fiuczy at linux.ibm.com>
>>> Reviewed-by: Bjoern Walk <bwalk at linux.ibm.com>
>>> ---
>>>   src/qemu/qemu_capabilities.c | 2 ++
>>>   src/qemu/qemu_capabilities.h | 1 +
>>>   2 files changed, 3 insertions(+)
>>>
>>> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
>>> index e228f52ec0..2ca5af3297 100644
>>> --- a/src/qemu/qemu_capabilities.c
>>> +++ b/src/qemu/qemu_capabilities.c
>>> @@ -508,6 +508,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
>>>                 /* 315 */
>>>                 "vfio-pci.display",
>>>                 "blockdev",
>>> +              "vfio-ap",
>>>       );
>>>   
> 
> The statement "On s390, we have cryptographic coprocessor cards,
> which are modeled on Linux as devices on the AP bus."
> was made in email titled "s390: vfio-ap: guest dedicated crypto adapters"
> 
Patch 6 of the qemu patch series 
(https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg01997.html) 
has a very detailed documentation (docs/vfio-ap.txt) covering IBM 
Adjunct Processor (AP) Cryptographic Facility.

> Does this imply other devices can exist on an AP Bus?
The AP bus is a linux construct used to represent the cryptographic 
devices available via the Adjunct Processor Cryptographic Facility.
This implies even so there are different cards they all are crypto cards.

> 
> Any chance this should be something like "vfio-ap.crypto" in the same
> way a "vfio-pci.display" entry is listed above seemingly implying a
> display device on a more generic pci bus? Or does "vfio-ap" always imply
> crypto?
Yes, it always is crypto only. Actually a vfio-ap mediated device is 
used to specify the configuration of the ap bus including all cards, 
usage domains and control domains passed into a qemu guest.

> 
> Having difficulty sorting out the relationships between adjunct
> processor, crypto processor and ap bus from the patch docs and initial
> review of the references.
Maybe the KVM forum session of Halil Pasic can help a bit...?
https://events.linuxfoundation.org/wp-content/uploads/2017/12/vfio-ap-The-Perils-of-the-Weird-Halil-Pasic-IBM.pdf

> 
>>>
>>> @@ -1092,6 +1093,7 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
>>>       { "vhost-vsock-device", QEMU_CAPS_DEVICE_VHOST_VSOCK },
>>>       { "mch", QEMU_CAPS_DEVICE_MCH },
>>>       { "sev-guest", QEMU_CAPS_SEV_GUEST },
>>> +    { "vfio-ap", QEMU_CAPS_DEVICE_VFIO_AP },
>>>   };
>>>   
>>>   static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsVirtioBalloon[] = {
>>> diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
>>> index 934620ed31..6bb9a2c8f0 100644
>>> --- a/src/qemu/qemu_capabilities.h
>>> +++ b/src/qemu/qemu_capabilities.h
>>> @@ -492,6 +492,7 @@ typedef enum { /* virQEMUCapsFlags grouping marker for syntax-check */
>>>       /* 315 */
>>>       QEMU_CAPS_VFIO_PCI_DISPLAY, /* -device vfio-pci.display */
>>>       QEMU_CAPS_BLOCKDEV, /* -blockdev and blockdev-add are supported */
>>> +    QEMU_CAPS_DEVICE_VFIO_AP, /* -device vfio-ap */
>>>   
>>>       QEMU_CAPS_LAST /* this must always be the last item */
>>>   } virQEMUCapsFlags;
>>>
>>
>> Reviewed-by: Thomas Huth <thuth at redhat.com>
>>
>> --
>> libvir-list mailing list
>> libvir-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/libvir-list
> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
> 


-- 
Mit freundlichen Grüßen/Kind regards
    Boris Fiuczynski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294




More information about the libvir-list mailing list