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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux