|
From: | Paolo Bonzini |
Subject: | Re: [Qemu-devel] [RFC PATCH] implement vmware pvscsi device |
Date: | Fri, 15 Apr 2011 22:56:38 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7 |
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).
There seem to be recent/exotic commands that can have both data-in and data-out buffers.
That can fit by adding more stuff at the end of the buffer. It can be in the first version, or it can be an extra feature for later. Since QEMU currently cannot handle it, probably it would need negotiation even if it were in the first version.
The sense buffer length is also not necessarily 96 bytes max, I believe.
I couldn't find that in either SPC or SAM indeed. It seems like a pretty widespread assumption though. Perhaps Nicholas or Hannes know where it comes from.
Paolo
[Prev in Thread] | Current Thread | [Next in Thread] |