Re: [PATCH 0/6] tcm_vhost/virtio-scsi WIP code for-3.6

[Anthony Liguori <aliguori@xxxxxxxxxx>]

On 07/04/2012 10:05 AM, Michael S. Tsirkin wrote:
> On Wed, Jul 04, 2012 at 04:52:00PM +0200, Paolo Bonzini wrote:
> > Il 04/07/2012 16:02, Michael S. Tsirkin ha scritto:
> > > On Wed, Jul 04, 2012 at 04:24:00AM +0000, Nicholas A. Bellinger wrote:
> > > > From: Nicholas Bellinger<nab@xxxxxxxxxxxxxxx>
> > > >
> > > > Hi folks,
> > > >
> > > > This series contains patches required to update tcm_vhost<->  virtio-scsi
> > > > connected hosts<->  guests to run on v3.5-rc2 mainline code.  This series is
> > > > available on top of target-pending/auto-next here:
> > > >
> > > >     git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git tcm_vhost
> > > >
> > > > This includes the necessary vhost changes from Stefan to to get tcm_vhost
> > > > functioning, along a virtio-scsi LUN scanning change to address a client bug
> > > > with tcm_vhost I ran into..  Also, tcm_vhost driver has been merged into a single
> > > > source + header file that is now living under /drivers/vhost/, along with latest
> > > > tcm_vhost changes from Zhi's tcm_vhost tree.
> > > >
> > > > Here are a couple of screenshots of the code in action using raw IBLOCK
> > > > backends provided by FusionIO ioDrive Duo:
> > > >
> > > >     http://linux-iscsi.org/images/Virtio-scsi-tcm-vhost-3.5-rc2-3.png
> > > >     http://linux-iscsi.org/images/Virtio-scsi-tcm-vhost-3.5-rc2-4.png
> > > >
> > > > So the next steps on my end will be converting tcm_vhost to submit backend I/O from
> > > > cmwq context, along with fio benchmark numbers between tcm_vhost/virtio-scsi and
> > > > virtio-scsi-raw using raw IBLOCK iomemory_vsl flash.
> > >
> > > OK so this is an RFC, not for merge yet?
> >
> > Patch 6 definitely looks RFCish, but patch 5 should go in anyway.
> >
> > Paolo
>
> I was talking about 4/6 first of all.
> Anyway, it's best to split, not to mix RFCs and fixes.

What is the use-case that we're targeting for this?

I certainly think it's fine to merge this into the kernel...  maybe something 
will use it.  But I'm pretty opposed to taking support for this into QEMU.  It's 
going to create more problems than it solves specifically because I have no idea 
what problem it actually solves.

We cannot avoid doing better SCSI emulation in QEMU.  That cannot be a long term 
strategy on our part and vhost-scsi isn't going to solve that problem for us.

Regards,

Anthony Liguori


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html