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

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

 



Hi Nicholas,

On 04/19/2012 06:53 PM, Nicholas A. Bellinger wrote:
On Thu, 2012-04-19 at 07:30 -0500, Anthony Liguori wrote:
However, for storage, be it scsi or direct access, the same problem really
doesn't exist.  There isn't an obvious benefit to being in the kernel.


In the modern Linux v3.x tree, it was decided there is an obvious
benefit to fabric drivers developers for going ahead and putting proper
SCSI target logic directly into the kernel..  ;)

I'm sure there are obvious benefits to having the kernel have SCSI target logic. I'm not claiming that there isn't.

But there is not an obvious benefit to doing SCSI emulation *for virtual machine* guests in the kernel.

Guests are unconditionally hostile. There is no qualification here. Public clouds are the obvious example of this.

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.

Good or bad, QEMU runs as a very unprivileged user confined by SELinux and very soon, sandboxed with seccomp. There's an obvious benefit to putting complex code into an environment like this.


There are many downsides though.  It's a big security risk.  SCSI is a complex
protocol and I'd rather the piece of code that's parsing and emulating SCSI cdbs
was unprivileged and sandboxed than running within the kernel context.


It has historically been a security risk doing raw SCSI passthrough of
complex CDBs to underlying SCSI LLD code, because SCSI CDB emulation
support within specific LLDs had an easy and sure-fire chance to get
said complex CDB emulation wrong..  (eg: no generic library in the
kernel for LLDs until libata was created)

That's a perfectly good argument for having TCM in the kernel

With Linux v3.x hosts we now have universal target mode support in the
upstream kernel for BLOCK+FILEIO backends with full SPC-3 (NAA IEEE
Registered Extended WWN naming, Explict/Implict ALUA multipath,
Persistent Reservations) using a control plane with ConfigFS
representing objects at the VFS layer for parent/child and intra-module
kernel data structure relationships.

We also have userspace rtslib (supported in downstream distros) that
exposes the ConfigFS layout of tcm_vhost fabric endpoints as easily
scriptable python library objects into higher level application code.

And that's all goodness :-)


So before we get too deep in patches, we need some solid justification first.


So the potential performance benefit is one thing that will be in favor
of vhost-scsi,

Why? Why would vhost-scsi be any faster than doing target emulation in userspace and then doing O_DIRECT with linux-aio to a raw device?

? I think the ability to utilize the underlying TCM fabric
and run concurrent ALUA multipath using multiple virtio-scsi LUNs to the
same /sys/kernel/config/target/core/$HBA/$DEV/ backend can potentially
give us some nice flexibility when dynamically managing paths into the
virtio-scsi guest.

The thing is, you can always setup this kind of infrastructure and expose a raw block device to userspace and then have QEMU emulate a target and turn that into O_DIRECT + linux-aio.

We can also use SG_IO to inject SCSI commands if we really need to. I'd rather we optimize this path. If nothing else, QEMU should be filtering SCSI requests before the kernel sees them. If something is going to SEGV, it's far better that it's QEMU than the kernel.

We cannot avoid doing SCSI emulation in QEMU. SCSI is too fundamental to far too many devices. So the prospect of not having good SCSI emulation in QEMU is not realistic.

Regards,

Anthony Liguori

Also, since client side ALUA is supported across pretty much all server
class SCSI clients in the last years, it does end up getting alot of
usage in the SCSI world.  It's a client side SCSI multipath feature that
is fabric independent, and that we know is already supported for free
across all Linux flavours + other modern server class guests.




--nab


--
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


[Index of Archives]     [Linux SCSI]     [Kernel Newbies]     [Linux SCSI Target Infrastructure]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Device Mapper]

  Powered by Linux