On Mon, Jul 4, 2011 at 2:38 PM, Hai Dong,Li 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, an virtual
> IO
> channel
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 de
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 de
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
>
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 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
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 requ
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: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
On Wed, Jun 29, 2011 at 12:23:38PM +0200, Hannes Reinecke wrote:
> The general idea here is that we can support NPIV.
> With NPIV we'll have several scsi_hosts, each of which is assigned a
> different set of LUNs by the array.
> With virtio we need to able to react on LUN remapping on the array
> s
On 06/29/2011 12:31 PM, Michael S. Tsirkin wrote:
On Wed, Jun 29, 2011 at 12:06:29PM +0200, Paolo Bonzini wrote:
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
On Wed, Jun 29, 2011 at 12:06:29PM +0200, Paolo Bonzini wrote:
> 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 yo
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 ta
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 9:33 AM, Paolo Bonzini 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 identifier here
>>
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 respon
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
identifi
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 o
On Tue, Jun 14, 2011 at 9:39 AM, Hannes Reinecke 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 queu
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.
Wh
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.
Ap
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 re
> 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.
> Plea
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 stack wou
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
p
On Fri, Jun 10, 2011 at 12:33 PM, Rusty Russell wrote:
> On Thu, 09 Jun 2011 08:59:27 +0200, Paolo Bonzini 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 h
On Thu, 09 Jun 2011 08:59:27 +0200, Paolo Bonzini 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, I'm i
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 mis
On Tue, 07 Jun 2011 15:43:49 +0200, 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).
OK, I'm impressed. This is very well written and I doesn't make any
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 stack would overcome several limitations of the current
30 matches
Mail list logo