On 02/14/2012 02:11 AM, Michael S. Tsirkin wrote:
On Tue, Feb 14, 2012 at 11:49:55AM +1100, ronnie sahlberg wrote:
By just exposing this device to the kernel, the kernel keeps sending,
or if not the kernel maybe some other process trying to poll the
status?
every few seconds :
PREVENT_ALLOW_MED
On Tue, Feb 14, 2012 at 11:49:55AM +1100, ronnie sahlberg wrote:
> By just exposing this device to the kernel, the kernel keeps sending,
> or if not the kernel maybe some other process trying to poll the
> status?
>
> every few seconds :
> PREVENT_ALLOW_MEDIUM_REMOVAL prevent removal
> PREVENT_AL
On Tue, Feb 14, 2012 at 10:33 AM, Michael S. Tsirkin wrote:
> On Tue, Feb 14, 2012 at 10:30:59AM +1100, ronnie sahlberg wrote:
>> On Tue, Feb 14, 2012 at 9:59 AM, Michael S. Tsirkin wrote:
>> > On Tue, Feb 14, 2012 at 07:53:26AM +1100, ronnie sahlberg wrote:
>> >> On Tue, Feb 14, 2012 at 7:42 AM,
On Mon, 13 Feb 2012 10:19:56 +0100, Paolo Bonzini wrote:
> block layer _is_ growing support for new operations: discard is already
> there, write same is in the works, extended copy will also come in due
> time. Perhaps we'll add them to virtio-blk, perhaps not.
FYI, I'd take patches for disca
On Tue, Feb 14, 2012 at 10:30:59AM +1100, ronnie sahlberg wrote:
> On Tue, Feb 14, 2012 at 9:59 AM, Michael S. Tsirkin wrote:
> > On Tue, Feb 14, 2012 at 07:53:26AM +1100, ronnie sahlberg wrote:
> >> On Tue, Feb 14, 2012 at 7:42 AM, ronnie sahlberg
> >> wrote:
> >> > On Tue, Feb 14, 2012 at 2:12
On Tue, Feb 14, 2012 at 9:59 AM, Michael S. Tsirkin wrote:
> On Tue, Feb 14, 2012 at 07:53:26AM +1100, ronnie sahlberg wrote:
>> On Tue, Feb 14, 2012 at 7:42 AM, ronnie sahlberg
>> wrote:
>> > On Tue, Feb 14, 2012 at 2:12 AM, Hannes Reinecke wrote:
>> >> On 02/13/2012 02:18 PM, Michael S. Tsirki
On Tue, Feb 14, 2012 at 07:53:26AM +1100, ronnie sahlberg wrote:
> On Tue, Feb 14, 2012 at 7:42 AM, ronnie sahlberg
> wrote:
> > On Tue, Feb 14, 2012 at 2:12 AM, Hannes Reinecke wrote:
> >> On 02/13/2012 02:18 PM, Michael S. Tsirkin wrote:
> >>> On Tue, Feb 14, 2012 at 12:13:36AM +1100, ronnie sa
On Tue, Feb 14, 2012 at 7:42 AM, ronnie sahlberg
wrote:
> On Tue, Feb 14, 2012 at 2:12 AM, Hannes Reinecke wrote:
>> On 02/13/2012 02:18 PM, Michael S. Tsirkin wrote:
>>> On Tue, Feb 14, 2012 at 12:13:36AM +1100, ronnie sahlberg wrote:
On Tue, Feb 14, 2012 at 12:00 AM, Michael S. Tsirkin
>
On Tue, Feb 14, 2012 at 2:12 AM, Hannes Reinecke wrote:
> On 02/13/2012 02:18 PM, Michael S. Tsirkin wrote:
>> On Tue, Feb 14, 2012 at 12:13:36AM +1100, ronnie sahlberg wrote:
>>> On Tue, Feb 14, 2012 at 12:00 AM, Michael S. Tsirkin
>>> wrote:
On Mon, Feb 13, 2012 at 02:54:03PM +0200, Dor L
On 02/13/2012 02:18 PM, Michael S. Tsirkin wrote:
> On Tue, Feb 14, 2012 at 12:13:36AM +1100, ronnie sahlberg wrote:
>> On Tue, Feb 14, 2012 at 12:00 AM, Michael S. Tsirkin wrote:
>>> On Mon, Feb 13, 2012 at 02:54:03PM +0200, Dor Laor wrote:
Only if you use the pci multi-function option but t
On Tue, Feb 14, 2012 at 12:13:36AM +1100, ronnie sahlberg wrote:
> On Tue, Feb 14, 2012 at 12:00 AM, Michael S. Tsirkin wrote:
> > On Mon, Feb 13, 2012 at 02:54:03PM +0200, Dor Laor wrote:
> >> Only if you use the pci multi-function option but that kills
> >> standard hot unplug
> >
> > It doesn't
On 02/13/2012 02:13 PM, ronnie sahlberg wrote:
On Tue, Feb 14, 2012 at 12:00 AM, Michael S. Tsirkin wrote:
On Mon, Feb 13, 2012 at 02:54:03PM +0200, Dor Laor wrote:
Only if you use the pci multi-function option but that kills
standard hot unplug
It doesn't kill it as such, rather you can't u
On Tue, Feb 14, 2012 at 12:00 AM, Michael S. Tsirkin wrote:
> On Mon, Feb 13, 2012 at 02:54:03PM +0200, Dor Laor wrote:
>> Only if you use the pci multi-function option but that kills
>> standard hot unplug
>
> It doesn't kill it as such, rather you can't unplug luns individually.
Isnt that just
On Mon, Feb 13, 2012 at 02:54:03PM +0200, Dor Laor wrote:
> Only if you use the pci multi-function option but that kills
> standard hot unplug
It doesn't kill it as such, rather you can't unplug luns individually.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a m
On 02/13/2012 02:40 PM, Nicholas A. Bellinger wrote:
Hi Dor, James& Co,
On Mon, 2012-02-13 at 09:57 +0200, Dor Laor wrote:
On 02/13/2012 09:05 AM, Christian Borntraeger wrote:
On 12/02/12 21:16, James Bottomley wrote:
Well, no-one's yet answered the question I had about why.
Just to give o
Hi Dor, James & Co,
On Mon, 2012-02-13 at 09:57 +0200, Dor Laor wrote:
> On 02/13/2012 09:05 AM, Christian Borntraeger wrote:
> > On 12/02/12 21:16, James Bottomley wrote:
> >> Well, no-one's yet answered the question I had about why.
> >
> > Just to give one example from a different angle:
> > In
On Mon, Feb 13, 2012 at 8:05 AM, Christian Borntraeger
wrote:
> On 12/02/12 21:16, James Bottomley wrote:
> > Could someone please explain to me why you can't simply fix virtio-blk?
>
> I dont think that virtio-scsi will replace virtio-blk everywhere. For non-scsi
> block devices, image files or l
On 02/12/2012 09:16 PM, James Bottomley wrote:
Well, no-one's yet answered the question I had about why. virtio-scsi
seems to be a basic duplication of virtio-blk except that it seems to
fix some problems virtio-blk has. Namely queue parameter discover,
which virtio-blk doesn't seem to do.
Th
On 02/13/2012 09:05 AM, Christian Borntraeger wrote:
On 12/02/12 21:16, James Bottomley wrote:
Well, no-one's yet answered the question I had about why.
Just to give one example from a different angle:
In the big datacenters tape libraries are still very important, and lots
of them have a scsi
On 12/02/12 21:16, James Bottomley wrote:
> Well, no-one's yet answered the question I had about why.
Just to give one example from a different angle:
In the big datacenters tape libraries are still very important, and lots
of them have a scsi attachement. virtio-blk certainly is not the right
w
On Sun, 12 Feb 2012 14:16:17 -0600, James Bottomley
wrote:
> On Thu, 2012-02-09 at 10:25 +0100, Paolo Bonzini wrote:
> > On 02/08/2012 02:37 PM, Christian Hoff wrote:
> > > Again, I have already done much testing with virtio-scsi and can confirm
> > > that the code is working flawlessly. In my op
On Thu, 2012-02-09 at 10:25 +0100, Paolo Bonzini wrote:
> On 02/08/2012 02:37 PM, Christian Hoff wrote:
> > Again, I have already done much testing with virtio-scsi and can confirm
> > that the code is working flawlessly. In my opinion, virtio-scsi is a
> > worthwhile addition to virtio-block and s
Paolo Bonzini wrote:
> James, will you include virtio-scsi in 3.4?
The key arguments from my side for inclusion of virtio-scsi are:
- Support for SCSI multipathing, which can optionally be done on the host
operating system.
- We can now use other SCSI(non-block) devices and make them accessible t
On 02/08/2012 02:37 PM, Christian Hoff wrote:
Again, I have already done much testing with virtio-scsi and can confirm
that the code is working flawlessly. In my opinion, virtio-scsi is a
worthwhile addition to virtio-block and should be considered for inclusion
into mainline kernel code.
Thank
Paolo Bonzini wrote:
> Christian Hoff wrote:
> > Instead the format has some disadvantages:
> > - It uses up 8 bytes where 3 bytes would be sufficient in order to
store
> > both the target ID and LUN number information
> > - The format limits us to 255 target IDs. I agree that the LUN limit
is
>
On 02/07/2012 02:59 PM, Christian Hoff wrote:
Instead the format has some disadvantages:
- It uses up 8 bytes where 3 bytes would be sufficient in order to store
both the target ID and LUN number information
- The format limits us to 255 target IDs. I agree that the LUN limit is
probably more a t
012 14:18
Subject:
Re: Pe: [PATCH v5 1/3] virtio-scsi: first version
On 07/02/12 13:31, Paolo Bonzini wrote:
> The structure of the LUN is defined by SAM, not by me.
Ok, got it.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a m
On 07/02/12 13:31, Paolo Bonzini wrote:
> The structure of the LUN is defined by SAM, not by me.
Ok, got it.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/07/2012 12:56 PM, Christian Borntraeger wrote:
The 14-bit limitation can be lifted. SAM defines a 24-bit LUN format too,
but I've never seen it used in practice.
Why not lift that limitation before the first version is committed upstream?
Because nobody supports >14-bit LUNs. The in-k
>> +cmd->req.cmd = (struct virtio_scsi_cmd_req){
>> +.lun[0] = 1,
>> +.lun[1] = sc->device->id,
>> +.lun[2] = (sc->device->lun>> 8) | 0x40,
>> +.lun[3] =
On 02/07/2012 12:10 PM, Michael S. Tsirkin wrote:
Also, lun[1] = sc->device->id means that only 255 SCSI target IDs will be
> >supported. Think about bigger usage scenarios, such as FCP networks with
> >several hundred HBAs in the net. If you want to have the target ID<->HBA
> >mapping the sam
On Tue, Feb 07, 2012 at 10:54:54AM +0100, Paolo Bonzini wrote:
> >Also, lun[1] = sc->device->id means that only 255 SCSI target IDs will be
> >supported. Think about bigger usage scenarios, such as FCP networks with
> >several hundred HBAs in the net. If you want to have the target ID<->HBA
> >mapp
On 02/06/2012 10:51 AM, Christian Hoff wrote:
Hello Paolo,
first let me say that your patch is working fine on my local clone of the
qemu repository.
Let me ask just one question about the format of the data being
transmitted over the virtqueue.
Paolo Bonzini wrote:
+cmd->req.c
Hello Paolo,
first let me say that your patch is working fine on my local clone of the
qemu repository.
Let me ask just one question about the format of the data being
transmitted over the virtqueue.
Paolo Bonzini wrote:
+cmd->req.cmd = (struct virtio_scsi_cmd_req){
+
34 matches
Mail list logo
