Re: [Qemu-devel] [PATCH 00/16] QEMU vhost-scsi support

[Paolo Bonzini]

Il 20/04/2012 09:00, Nicholas A. Bellinger ha scritto:
> On Thu, 2012-04-19 at 19:20 -0500, Anthony Liguori wrote:
>> TCM runs in the absolute most privileged context possible.  When you're 
>> dealing 
>> with extremely hostile input, it's pretty obvious that you want to run it in 
>> the 
>> lowest privileged context as humanly possible.
> 
> The argument that a SCSI target for virtual machines is so complex that
> it can't possibly be implemented properly in the kernel is a bunch of
> non-sense.

I agree.  A VM is not any more hostile than another iSCSI initiator.
lio _always_ must assume to operates in a hostile environment.

> Being able to identify which virtio-scsi guests can actually connect via
> vhost-scsi into individual tcm_vhost endpoints is step one here.

Yes, the ACL system in lio is quite good for this.

> Well, using a raw device from userspace there is still going to be a
> SG-IO memcpy going on here between user <-> kernel in current code,
> yes..?
> 
> Being able to deliver interrupts and SGL memory directly into tcm_vhost
> cmwq kernel context for backend device execution w/o QEMU userspace
> involvement or extra SGL memcpy is the perceived performance benefit
> here.
> 
> How much benefit will this actually provide across single port and multi
> port tcm_vhost LUNs into a single guest..?  That still remains to be
> demonstrated with performance+throughput benchmarks..

Yes, this is the key.

The problems I have with vhost-scsi are, from easiest to hardest:

- completely different configuration mechanism with respect to the
in-QEMU target (fix: need to integrate configfs into scsi-{disk,generic}).

- no support for migration (there can be pending SCSI requests at
migration time, that need to be restarted on the destination)

- no support for non-raw images (fix: use NBD on a Unix socket? perhaps
add an NBD backend to lio)

- cannot migrate from lio-target to QEMU-target and vice versa.

The first three are definitely fixable.

> In order for QEMU userspace to support this, Linux would need to expose
> a method to userspace for issuing DIF protected CDBs.  This userspace
> API currently does not exist AFAIK, so a kernel-level approach is the
> currently the only option when it comes to supporting end-to-end block
> protection information originating from within Linux guests.

I think it would be worthwhile to have this in userspace too.

> (Note this is going to involve a virtio-scsi spec rev as well)

Yes.  By the way, another possible modification could be to tell the
guest what is its (initiator) WWPN.

Paolo