Re: [Qemu-devel] [PULL 40/41] vhost-user-scsi: Introduce vhost-user-scsi host device

[Paolo Bonzini]

On 18/07/2017 18:32, Marc-André Lureau wrote:
> 
> 
> On Thu, Jun 15, 2017 at 1:20 PM Paolo Bonzini <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     From: Felipe Franciosi <address@hidden <mailto:address@hidden>>
> 
>     This commit introduces a vhost-user device for SCSI. This is based
>     on the existing vhost-scsi implementation, but done over vhost-user
>     instead. It also uses a chardev to connect to the backend. Unlike
>     vhost-scsi (today), VMs using vhost-user-scsi can be live migrated.
> 
>     To use it, start Qemu with a command line equivalent to:
> 
>     qemu-system-x86_64 \
>            -chardev socket,id=vus0,path=/tmp/vus.sock \
>            -device vhost-user-scsi-pci,chardev=vus0,bus=pci.0,addr=...
> 
>     A separate commit presents a sample application linked with libiscsi to
>     provide a backend for vhost-user-scsi.
> 
>     Signed-off-by: Felipe Franciosi <address@hidden
>     <mailto:address@hidden>>
>     Message-Id: <address@hidden
>     <mailto:address@hidden>>
>     Signed-off-by: Paolo Bonzini <address@hidden
>     <mailto:address@hidden>>
>     ---
> 
> 
> I just realized the patch was missing qemu-options.hx update. Oh wait,
> virtio-scsi-pci isn't documented either?
> 
> Would it have been possible to add a vhost-user-chr=chr argument on
> virtio-scsi-pci instead of introducing a new device? Would that make
> sense (to share code, argument etc)?

No, it wouldn't make sense.

The reason is that vhost-scsi devices are configured entirely outside
QEMU, and for this reason vhost-scsi/vhost-user-scsi do not expose a
SCSI bus at the QEMU level.  They do share code (through the
virtio-scsi-common superclass), but they are fundamentally different.

The vhost-blk device probably would also be a separate class, for the
same reason.  There is no way to define a -drive option with a chardev
backend.

Even vhost-user-net is somewhat hackish in its use of -netdev in my
opinion, because it cannot implement ->receive (except for the RARP
hack) and it bypasses things such as filters and hubs.

Paolo