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

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(a)linux.ibm.com&gt; >>> Reviewed-by: Bjoern Walk <bwalk(a)linux.ibm.com&gt; >>> --- >>>   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...

> >>> >>> @@ -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(a)redhat.com&gt; >> >> -- >> libvir-list mailing list >> libvir-list(a)redhat.com >> https://www.redhat.com/mailman/listinfo/libvir-list > > -- > libvir-list mailing list > libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list >