On 09/13/2016 04:55 PM, John Ferlan wrote:
[...]diff --git a/src/util/virscsi.c b/src/util/virscsi.c index 4843367..290b692 100644 --- a/src/util/virscsi.c +++ b/src/util/virscsi.c @@ -105,6 +105,32 @@ virSCSIDeviceGetAdapterId(const char *adapter, return -1; } +int +virSCSIOpenVhost(int *vhostfd, + size_t *vhostfdSize)Well this is dangerous... I can pass "any" value value here and really cause some damage. Why the need for a loop?Well, I guess I only half-cleaned it up. I'm not aware of any mechanism to pass multiple fd's for vhost-scsi-pci or vhost-scsi-ccw into QEMU (unlike the virtio-scsi-{ccw|pci} paths), so I started ripping the loops out. Looking at it now, I guess I didn't rip out nearly as much as I thought I did. So, more to remove I guess. Unless leaving it there for an "if the future ever arrives" case is a problem.Doh - search on 'vhost-net' to find qemuInterfaceOpenVhostNet... That's a multiple open model and depending on virtio.queues which is something I believe I was asking about for an attribute num_queues...
Yeah, that was the starting point. What I'd discovered, and why I started ripping this apart, is that QEMU itself doesn't have an option to pass multiple fd's for a vhost-scsi device. So while for vhost-net has fd= and (vhost)fds=, vhost-scsi only has vhostfd=.
qemu-system-s390x: -device vhost-scsi-ccw,wwpn=naa.500140594524c195,vhostfds=5: Property '.vhostfds' not found
The queues parameter operates in conjunction with the number of virtqueue rings that are instantiated for the guest process.
- Eric -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list