qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH] implement vmware pvscsi device


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC PATCH] implement vmware pvscsi device
Date: Fri, 15 Apr 2011 16:37:37 +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 04:28 PM, Stefan Hajnoczi wrote:
> Nothing formal.  I'm trying to learn SCSI as I go along:
> 
> 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
> 
> That's the interface I'm using.  Requests are:
> 
> [Header][CDB][Data-out buffers*][Data-in buffers*][Footer]
> 
> The footer gets filled in with the response.

My interface is exactly the same as virtio-blk's SCSI passthrough requests:

------------------------------ 8<-- ----------------------------

Device operation: request queue
-------------------------------

The driver queues requests to the virtqueue, and they are used by the device
(not necessarily in order).  Each request is of the form

Requests have the following format:

    struct virtio_scsi_req {
        u32 type;
        u32 ioprio;
        char cmd[];
        char data[][512];
        u8 sense[SCSI_SENSE_BUFFERSIZE];
        u32 sense_len;
        u32 residual;
        u8 status;
        u8 response;
    };

    #define VIRTIO_SCSI_T_CMD             2
    #define VIRTIO_SCSI_T_BARRIER         0x80000000

    /* status values */
    #define VIRTIO_SCSI_S_OK              0
    #define VIRTIO_SCSI_S_FAILURE         1
    #define VIRTIO_SCSI_S_CLOSED          128

The type of the request must currently be VIRTIO_SCSI_T_SCSI_CMD.
The VIRTIO_SCSI_T_BARRIER field indicates that this request acts
as a barrier and that all preceding requests must be complete
before this one, and all following requests must not be started
until this is complete.  Note that a barrier does not flush caches
in the underlying backend device in host, and thus does not serve
as data consistency guarantee.  The driver must send a SYNCHRONIZE
CACHE command to flush the host cache.

The ioprio field will indicate the priority of this request, with
higher values corresponding to higher priorities.

The cmd and data fields must reside in separate buffers.  The cmd field
indicates the command to perform and is always read-only.  The data field
may be either read-only or write-only, depending on the request.

Remaining fields are filled in by the device.  The sense_len field
indicates the number of bytes actually written to the sense buffer,
while the residual field indicates the residual size, calculated as
data_length - number_of_transferred_bytes.

The response byte is written by the device to be one of the following

The status byte is written by the device to be the SCSI status code.

- VIRTIO_SCSI_S_OK when the request was completed and the status byte
  is filled with a SCSI status code (not necessarily "GOOD").

- VIRTIO_SCSI_S_FAILURE for host or guest error.

- VIRTIO_SCSI_S_CLOSED if the virtqueue is not currently associated
  to a LU.

----------------------------------------------------------------

There is more meat to handle hotplug/hotunplug and to choose which
LUNs maps to which virtqueue, but you can wait a few days to know
the details.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]