From: Stefan Hajnoczi <stefanha@gmail.com>
To: Hannes Reinecke <hare@suse.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel@nongnu.org,
"Nicholas A. Bellinger" <nab@linux-iscsi.org>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH] implement vmware pvscsi device
Date: Mon, 18 Apr 2011 16:27:08 +0100 [thread overview]
Message-ID: <BANLkTin38eDD3xWokLVKjieG72A0_ex39A@mail.gmail.com> (raw)
In-Reply-To: <4DAC4516.6090600@suse.de>
On Mon, Apr 18, 2011 at 3:05 PM, Hannes Reinecke <hare@suse.de> wrote:
> On 04/15/2011 10:56 PM, Paolo Bonzini wrote:
>>
>> On 04/15/2011 05:04 PM, Stefan Hajnoczi wrote:
>>>
>>> The way I approached virtio-scsi was to look at the SCSI Architecture
>>> Model document and some of the Linux SCSI code. I'm not sure if
>>> letting virtio-blk SCSI pass-through or scsi-generic guide us is a
>>> good approach.
>>>
>>> How do your ioprio and barrier relate to SCSI?
>>
>> Both are part of the transport protocol, which can provide
>> additional features with respect to SAM. For example SCSI doesn't
>> provide the full details of hotplug/hotunplug, or doesn't have a way
>> for the guest to trigger a drive unplug on the host, but these are
>> all desirable features for virtio-scsi (and they are supported by
>> vmw_pvscsi by the way).
>>
> And this is something I really miss in the current proposals, namely
> a working transport layer.
>
> The SCSI spec (SPC etc) itself just handles command delivery between
> initiator and target. Anything else (like hotplug, error recovery, target
> addressing etc) is out of the scope of the spec and needs to be implemented
> on another layer (that's the ominous
> transport layer).
>
> Hence any protocol implemented to the above spec would be missing those
> parts, and they would need to be implemented additionally.
> Which also explains why these features are missing when just using SCSI CDBs
> as the main command container.
>
> My proposal would be to implement a full virtio-scsi _host_, and extend the
> proposal to be able to handle the transport layer too.
> At the lastest we would need to include a LUN address before the CDB, and
> define TMF command values for proper error recovery.
>
> That way we could handle hotplug / -unplug via a simple host rescan, and
> would even be able to pass-in NPIV hosts.
In my prototype there is a header and a footer for the request and
response, respectively:
http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=blob;f=include/linux/virtio_scsi.h;hb=refs/heads/tcm_vhost
We definitely need more than plain CDB pass-through.
Stefan
next prev parent reply other threads:[~2011-04-18 15:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-15 13:42 [Qemu-devel] [RFC PATCH] implement vmware pvscsi device Paolo Bonzini
2011-04-15 14:01 ` Stefan Hajnoczi
2011-04-15 14:17 ` Paolo Bonzini
2011-04-15 14:28 ` Stefan Hajnoczi
2011-04-15 14:37 ` Paolo Bonzini
2011-04-15 15:04 ` Stefan Hajnoczi
2011-04-15 20:56 ` Paolo Bonzini
2011-04-18 14:05 ` Hannes Reinecke
2011-04-18 15:27 ` Stefan Hajnoczi [this message]
2011-04-18 16:09 ` Paolo Bonzini
2011-04-15 14:55 ` Hannes Reinecke
2011-04-15 14:59 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BANLkTin38eDD3xWokLVKjieG72A0_ex39A@mail.gmail.com \
--to=stefanha@gmail.com \
--cc=hare@suse.de \
--cc=mst@redhat.com \
--cc=nab@linux-iscsi.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).