On 07/01/2011 09:14 AM, Hannes Reinecke wrote:
Actually, the kernel does _not_ do a LUN remapping.
Not the kernel, the in-kernel target. The in-kernel target can and will
map hardware LUNs (target_lun in drivers/target/*) to arbitrary LUNs
(mapped_lun).
Put in another way: the virtio-scsi
On Mon, Jul 4, 2011 at 2:38 PM, Hai Dong,Li haido...@linux.vnet.ibm.com wrote:
So if I understand correctly, virtio-scsi looks like an SCSI tranport
protocol,
such as iSCSI, FCP and SRP which use tcp/ip, FC and Infiniband RDMA
respectively as the transfer media while virtio-scsi uses virtio,
On 06/29/2011 11:39 AM, Stefan Hajnoczi wrote:
Of course, when doing so we would be lose the ability to freely remap
LUNs. But then remapping LUNs doesn't gain you much imho.
Plus you could always use qemu block backend here if you want
to hide the details.
And you could
On 07/01/2011 08:41 AM, Paolo Bonzini wrote:
On 06/29/2011 11:39 AM, Stefan Hajnoczi wrote:
Of course, when doing so we would be lose the ability to
freely remap
LUNs. But then remapping LUNs doesn't gain you much imho.
Plus you could always use qemu block backend here if you want
to
On 07/01/2011 09:14 AM, Hannes Reinecke wrote:
Actually, the kernel does _not_ do a LUN remapping.
Not the kernel, the in-kernel target. The in-kernel target can and will
map hardware LUNs (target_lun in drivers/target/*) to arbitrary LUNs
(mapped_lun).
Put in another way: the virtio-scsi
On 06/12/2011 09:51 AM, Michael S. Tsirkin wrote:
If a device uses more than one queue it is the responsibility of the
device to ensure strict request ordering.
Maybe I misunderstand - how can this be the responsibility of
the device if the device does not get the information about
the
On 06/14/2011 10:39 AM, Hannes Reinecke wrote:
If, however, we decide to expose some details about the backend, we
could be using the values from the backend directly.
EG we could be forwarding the SCSI target port identifier here
(if backed by real hardware) or creating our own SAS-type
On Wed, Jun 29, 2011 at 10:23:26AM +0200, Paolo Bonzini wrote:
On 06/12/2011 09:51 AM, Michael S. Tsirkin wrote:
If a device uses more than one queue it is the responsibility of the
device to ensure strict request ordering.
Maybe I misunderstand - how can this be the responsibility of
On Wed, Jun 29, 2011 at 9:33 AM, Paolo Bonzini pbonz...@redhat.com wrote:
On 06/14/2011 10:39 AM, Hannes Reinecke wrote:
If, however, we decide to expose some details about the backend, we
could be using the values from the backend directly.
EG we could be forwarding the SCSI target port
On Tue, Jun 14, 2011 at 05:30:24PM +0200, Hannes Reinecke wrote:
Which is exactly the problem I was referring to.
When using more than one channel the request ordering
_as seen by the initiator_ has to be preserved.
This is quite hard to do from a device's perspective;
it might be able to
On Sun, Jun 12, 2011 at 10:51:41AM +0300, Michael S. Tsirkin wrote:
For example, if the driver is crazy enough to put
all write requests on one queue and all barriers
on another one, how is the device supposed to ensure
ordering?
There is no such things as barriers in SCSI. The thing that
On Wed, Jun 29, 2011 at 10:23:26AM +0200, Paolo Bonzini wrote:
I agree here, in fact I misread Hannes's comment as if a driver
uses more than one queue it is responsibility of the driver to
ensure strict request ordering. If you send requests to different
queues, you know that those requests
On 06/29/2011 12:03 PM, Christoph Hellwig wrote:
I agree here, in fact I misread Hannes's comment as if a driver
uses more than one queue it is responsibility of the driver to
ensure strict request ordering. If you send requests to different
queues, you know that those requests are
On Wed, Jun 29, 2011 at 10:39:42AM +0100, Stefan Hajnoczi wrote:
I think we're missing a level of addressing. We need the ability to
talk to multiple target ports in order for list target ports to make
sense. Right now there is one implicit target that handles all
commands. That means there
On 06/29/2011 12:07 PM, Christoph Hellwig wrote:
On Wed, Jun 29, 2011 at 10:39:42AM +0100, Stefan Hajnoczi wrote:
I think we're missing a level of addressing. We need the ability to
talk to multiple target ports in order for list target ports to make
sense. Right now there is one implicit
On 06/10/2011 04:35 PM, Paolo Bonzini wrote:
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.
On 06/12/2011 09:51 AM, Michael S. Tsirkin wrote:
On Fri, Jun 10, 2011 at 02:55:35PM +0200, Hannes Reinecke wrote:
Device operation: request queues
The driver queues requests to an arbitrary request queue, and they are
used by the device on that same queue.
On Tue, Jun 14, 2011 at 9:39 AM, Hannes Reinecke h...@suse.de wrote:
On 06/10/2011 04:35 PM, Paolo Bonzini wrote:
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
On Fri, Jun 10, 2011 at 02:55:35PM +0200, Hannes Reinecke wrote:
Device operation: request queues
The driver queues requests to an arbitrary request queue, and they are
used by the device on that same queue.
What about request ordering?
If requests are
On Thu, 09 Jun 2011 08:59:27 +0200, Paolo Bonzini pbonz...@redhat.com wrote:
On 06/09/2011 01:28 AM, Rusty Russell wrote:
after some preliminary discussion on the QEMU mailing list, I present a
draft specification for a virtio-based SCSI host (controller, HBA, you
name it).
OK,
On Fri, Jun 10, 2011 at 12:33 PM, Rusty Russell ru...@rustcorp.com.au wrote:
On Thu, 09 Jun 2011 08:59:27 +0200, Paolo Bonzini pbonz...@redhat.com wrote:
On 06/09/2011 01:28 AM, Rusty Russell wrote:
after some preliminary discussion on the QEMU mailing list, I present a
draft
On 06/10/2011 02:14 PM, Stefan Hajnoczi wrote:
Paolo, I'll switch the Linux guest LLD and QEMU virtio-scsi skeleton
that I have to comply with the spec. Does this sound good or did you
want to write these from scratch?
Why should I want to write things from scratch? :) Just send me again a
On 06/07/2011 03:43 PM, Paolo Bonzini wrote:
Hi all,
after some preliminary discussion on the QEMU mailing list, I present a
draft specification for a virtio-based SCSI host (controller, HBA, you
name it).
The virtio SCSI host is the basis of an alternative storage stack for
KVM. This
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
On 06/09/2011 01:28 AM, Rusty Russell wrote:
after some preliminary discussion on the QEMU mailing list, I present a
draft specification for a virtio-based SCSI host (controller, HBA, you
name it).
OK, I'm impressed. This is very well written and it doesn't make any of
the obvious
On Tue, 07 Jun 2011 15:43:49 +0200, Paolo Bonzini pbonz...@redhat.com wrote:
Hi all,
after some preliminary discussion on the QEMU mailing list, I present a
draft specification for a virtio-based SCSI host (controller, HBA, you
name it).
OK, I'm impressed. This is very well written and I
26 matches
Mail list logo
