lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 10 Jun 2011 10:35:50 -0400 (EDT)
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Hannes Reinecke <hare@...e.de>
Cc:	Linux Virtualization <virtualization@...ts.linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	qemu-devel <qemu-devel@...gnu.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Stefan Hajnoczi <stefanha@...ux.vnet.ibm.com>,
	Christoph Hellwig <chellwig@...hat.com>,
	"Michael S. Tsirkin" <mst@...hat.com>, kvm@...r.kernel.org
Subject: Re: virtio scsi host draft specification, v3

> If requests are placed on arbitrary queues you'll inevitably run on
> locking issues to ensure strict request ordering.
> I would add here:
> 
> If a device uses more than one queue it is the responsibility of the
> device to ensure strict request ordering.

Applied with s/device/guest/g.

> Please do not rely in bus/target/lun here. These are leftovers from
> parallel SCSI and do not have any meaning on modern SCSI
> implementation (eg FC or SAS). Rephrase that to
> 
> The lun field is the Logical Unit Number as defined in SAM.

Ok.

> >      The status byte is written by the device to be the SCSI status
> >      code.
>
> ?? I doubt that exists. Make that:
> 
> The status byte is written by the device to be the status code as
> defined in SAM.

Ok.

> >      The response byte is written by the device to be one of the
> >      following:
> >
> >      - 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_UNDERRUN if the content of the CDB requires
> >      transferring
> >        more data than is available in the data buffers.
> >
> >      - VIRTIO_SCSI_S_ABORTED if the request was cancelled due to a
> >      reset
> >        or another task management function.
> >
> >      - VIRTIO_SCSI_S_FAILURE for other host or guest error. In
> >      particular,
> >        if neither dataout nor datain is empty, and the
> >        VIRTIO_SCSI_F_INOUT
> >        feature has not been negotiated, the request will be
> >        immediately
> >        returned with a response equal to VIRTIO_SCSI_S_FAILURE.
> >
> And, of course:
> 
> VIRTIO_SCSI_S_DISCONNECT if the request could not be processed due
> to a communication failure (eg device was removed or could not be
> reached).

Ok.

> This specification implies a strict one-to-one mapping between host
> and target. IE there is no way of specifying more than one target
> per host.

Actually no, the intention is to use hierarchical LUNs to support
more than one target per host.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ