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@xxxxxxxxxxxxx>
Reviewed-by: Bjoern Walk <bwalk@xxxxxxxxxxxxx>
---
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
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
@@ -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@xxxxxxxxxx>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
