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

[Stefan Hajnoczi]

On Sat, Apr 21, 2012 at 9:51 AM, Nicholas A. Bellinger
<address@hidden> wrote:
> On Fri, 2012-04-20 at 12:09 +0100, Stefan Hajnoczi wrote:
>> On Fri, Apr 20, 2012 at 8:46 AM, Paolo Bonzini <address@hidden> wrote:
>> > Il 20/04/2012 09:00, Nicholas A. Bellinger ha scritto:
>
> <SNIP>
>
>> > - no support for migration (there can be pending SCSI requests at
>> > migration time, that need to be restarted on the destination)
>>
>> Yes and it hasn't been thought through by me at least ;-).  So
>> migration is indeed a challenge that needs to be worked through.
>>
>> > - no support for non-raw images (fix: use NBD on a Unix socket? perhaps
>> > add an NBD backend to lio)
>>
>> For me this is the biggest issue with kernel-level storage for virtual
>> machines.  We have NBD today but it goes through the network stack
>> using a limited protocol and probably can't do zero-copy.
>>
>> The most promising option I found was dm-userspace
>> (http://wiki.xensource.com/xenwiki/DmUserspace), which implements a
>> device-mapper target with an in-kernel MMU-like lookup mechanism that
>> calls out to userspace when block addresses need to be translated.
>> It's not anywhere near to upstream and hasn't been pushed for several
>> years.  On the plus side we could also write a userspace
>> implementation of this so that QEMU image formats continue to be
>> portable to other host OSes without duplicating code.
>>
>> If tcm_vhost only works with raw images then I don't see it as a
>> realistic option given the effort it will require to complete and
>> maintain.
>>
>
> So there has been interest in the past for creating a TCM backend that
> allows for a userspace passthrough, but so far the code to do this has
> not materialized yet..
>
> There are pieces of logic from STGT that provide an interface for doing
> something similar that still exist in the upstream kernel.  Allowing
> different QEMU formats to be processed (in userspace) through a hybrid
> TCM backend driver that fits into the existing HBA/DEV layout in
> /sys/kernel/config/target/$HBA/$DEV/ is what would be required to really
> do this properly..

Could you point to the existing upstream code?

I think the hybrid TCM backend driver means a way for a userspace
process to execute SCSI Tasks from the target - implementing a subset
of se_subsystem_api in userspace?

If we solve the problem at the block driver level instead of inside
the SCSI target then it's also possible for the host to inspect VM
disk images similar to loopback devices (mount -o loop).  Do you think
putting the userspace interface into the SCSI target has advantages
over the block driver or device-mapper level?

Stefan