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
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
