[libvirt] [PATCH v1 19/19] qemu: Allow the specification of a vhost-scsi devno

Eric Farman farman at linux.vnet.ibm.com
Wed Aug 17 19:38:01 UTC 2016



On 08/09/2016 08:13 AM, Michal Privoznik wrote:
> On 25.07.2016 22:48, Eric Farman wrote:
>> In the case of other SCSI host devices, the device that is created
>> within the guest will be within the usual SCSI namespace
>> (e.g., host:bus:target:lun).  But for vhost-scsi, the actual naming
>> structure will come from the host configuration, and will be
>> invisible to both QEMU and Libvirt.  So specifying one with an
>> <address type='drive' ...> tag (as is often done for virtio-scsi)
>> doesn't make sense in this case, as it will be ignored.
>>
>> Nevertheless, we need something to identify our vhost-scsi device,
>> so for that we'll drop back to the devno mapping that we use for
>> other disks.  (This option exists only for vhost-scsi-ccw, but not
>> vhost-scsi-pci.  Hrm...)  This becomes <address type='ccw' ...> in
>> the case of s390 systems, and puts the device number on the
>> resulting QEMU command line.  Thus, existing device number conflict
>> detection can be used across other devices that may or may not be
>> specified in the guest XML.
>>
>> If one is not specified, we need to be sure to allocate one so that
>> we can avoid polluting the device numbers with silently-created
>> entries.
>>
>> Signed-off-by: Eric Farman <farman at linux.vnet.ibm.com>
>> Reviewed-by: Bjoern Walk <bwalk at linux.vnet.ibm.com>
>> Reviewed-by: Boris Fiuczynski <fiuczy at linux.vnet.ibm.com>
>> ---
>>   src/conf/domain_conf.c         | 19 +++++++++++++++++--
>>   src/qemu/qemu_command.c        |  7 +++++++
>>   src/qemu/qemu_domain_address.c | 10 ++++++++++
>>   3 files changed, 34 insertions(+), 2 deletions(-)
> I don't feel confident enough to review this one. The code looks okay,
> but from higher perspective I have no idea what it does. Sorry.

In testing my rework to Daniel Berrange's comment to patch 10 
(https://www.redhat.com/archives/libvir-list/2016-August/msg00464.html) 
this patch ends up going away.  So, no worries on the uncertainty here!

  - Eric




More information about the libvir-list mailing list