Quoting Boris Fiuczynski (2018-10-25 07:35:44)
On 10/25/18 1:54 PM, Boris Fiuczynski wrote:
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@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@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-Pe... Or you could have a look at "Chapter 47. Generic cryptographic device driver" here: http://public.dhe.ibm.com/software/dw/linux390/docu/l418dd35.pdf
Thanks for the info. The Halil 2018 doc was good for orienting. Can't say I understand the details but I don't see problems in the source code it's self. Reviewed-by: Chris Venteicher <cventeic@redhat.com>
@@ -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@redhat.com>
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- libvir-list mailing list libvir-list@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