Il 24/08/2012 02:45, Nicholas A. Bellinger ha scritto:
So up until very recently, TCM would accept an I/O request for an DATA
I/O type CDB with a max_sectors larger than the reported max_sectors for
it's TCM backend (regardless of backend type), and silently generate N
backend 'tasks' to
On 08/24/2012 09:56 AM, Paolo Bonzini wrote:
Il 24/08/2012 02:45, Nicholas A. Bellinger ha scritto:
So up until very recently, TCM would accept an I/O request for an DATA
I/O type CDB with a max_sectors larger than the reported max_sectors for
it's TCM backend (regardless of backend type), and
On Fri, Aug 24, 2012 at 12:43:34PM +0200, Hannes Reinecke wrote:
On 08/24/2012 09:56 AM, Paolo Bonzini wrote:
Il 24/08/2012 02:45, Nicholas A. Bellinger ha scritto:
So up until very recently, TCM would accept an I/O request for an DATA
I/O type CDB with a max_sectors larger than the reported
Il 24/08/2012 12:43, Hannes Reinecke ha scritto:
Hehe. So finally someone else stumbled across this one.
All is fine and dandy as long as you're able to use scsi-disk.
As soon as you're forced to use scsi-generic we're in trouble.
With scsi-generic we actually have two problems:
1)
On Wed 22 Aug 2012 10:13:44 PM CST, Paolo Bonzini wrote:
Il 22/08/2012 15:13, Stefan Hajnoczi ha scritto:
http://lists.gnu.org/archive/html/qemu-devel/2010-12/msg01741.html
This is a real problem in practice. IE. the USB CD-ROM on this POWER7
blade limits transfers to 0x1e000 bytes for
Il 23/08/2012 11:31, Cong Meng ha scritto:
For disks, this should be fixed simply by using scsi-block instead of
scsi-generic.
CD-ROMs are indeed more complicated because burning CDs cannot be done
with syscalls. :/
So, as the problem exist to CD-ROM, I will continue to get these patches
On Thu, Aug 23, 2012 at 11:03 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 23/08/2012 11:31, Cong Meng ha scritto:
For disks, this should be fixed simply by using scsi-block instead of
scsi-generic.
CD-ROMs are indeed more complicated because burning CDs cannot be done
with syscalls. :/
Il 23/08/2012 12:08, Stefan Hajnoczi ha scritto:
I'm still trying to understand the extent of the problem.
The problem occurs for _USB_ CD-ROMs according to Ben. Passthrough of
USB storage devices should be done via USB passthrough, not virtio-scsi.
If we do USB passthrough via the SCSI
On Thu, Aug 23, 2012 at 11:52 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 23/08/2012 12:08, Stefan Hajnoczi ha scritto:
I'm still trying to understand the extent of the problem.
The problem occurs for _USB_ CD-ROMs according to Ben. Passthrough of
USB storage devices should be done via
On Thu, 2012-08-23 at 11:08 +0100, Stefan Hajnoczi wrote:
On Thu, Aug 23, 2012 at 11:03 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 23/08/2012 11:31, Cong Meng ha scritto:
For disks, this should be fixed simply by using scsi-block instead of
scsi-generic.
CD-ROMs are indeed more
On Tue, Aug 21, 2012 at 7:31 PM, Blue Swirl blauwir...@gmail.com wrote:
On Tue, Aug 21, 2012 at 8:23 AM, Cong Meng m...@linux.vnet.ibm.com wrote:
diff --git a/block_int.h b/block_int.h
index d72317f..a9d07a2 100644
--- a/block_int.h
+++ b/block_int.h
@@ -333,6 +333,10 @@ struct
On 08/21/2012 06:14 PM, Paolo Bonzini wrote:
Il 21/08/2012 11:52, Stefan Hajnoczi ha scritto:
Using /sys/dev/block or /sys/dev/char seems easier, and lets you
retrieve the parameters for block devices too.
what do you mean with block devices? Using /dev/sda instead of
/dev/sg0?
Yes.
Il 22/08/2012 13:04, Cong Meng ha scritto:
Cong, what is the limit that the host HBA enforces (and what is the
HBA)? What commands see a problem? Is it fixed by using scsi-block
instead of scsi-generic (if you can use scsi-block at all, i.e. it's not
a tape or similar device)?
I don't see
On Wed, Aug 22, 2012 at 02:09:28PM +0200, Paolo Bonzini wrote:
Il 22/08/2012 13:04, Cong Meng ha scritto:
Cong, what is the limit that the host HBA enforces (and what is the
HBA)? What commands see a problem? Is it fixed by using scsi-block
instead of scsi-generic (if you can use
Il 22/08/2012 15:13, Stefan Hajnoczi ha scritto:
http://lists.gnu.org/archive/html/qemu-devel/2010-12/msg01741.html
This is a real problem in practice. IE. the USB CD-ROM on this POWER7
blade limits transfers to 0x1e000 bytes for example and the Linux sr
driver on the guest is going to try
This patch adds some queue limit parameters into block drive. And inits them
for sg block drive. Some interfaces are also added for accessing them.
Signed-off-by: Cong Meng m...@linux.vnet.ibm.com
---
block/raw-posix.c | 58 +
block_int.h
Il 21/08/2012 10:23, Cong Meng ha scritto:
+static void sg_get_queue_limits(BlockDriverState *bs, const char *filename)
+{
+DIR *ffs;
+struct dirent *d;
+char path[MAXPATHLEN];
+
+snprintf(path, MAXPATHLEN,
+ /sys/class/scsi_generic/sg%s/device/block/,
+
On Tue 21 Aug 2012 04:48:17 PM CST, Paolo Bonzini wrote:
Il 21/08/2012 10:23, Cong Meng ha scritto:
+static void sg_get_queue_limits(BlockDriverState *bs, const char *filename)
+{
+DIR *ffs;
+struct dirent *d;
+char path[MAXPATHLEN];
+
+snprintf(path, MAXPATHLEN,
+
On Tue, Aug 21, 2012 at 9:23 AM, Cong Meng m...@linux.vnet.ibm.com wrote:
This patch adds some queue limit parameters into block drive. And inits them
for sg block drive. Some interfaces are also added for accessing them.
Signed-off-by: Cong Meng m...@linux.vnet.ibm.com
---
On Tue, Aug 21, 2012 at 10:41 AM, Cong Meng m...@linux.vnet.ibm.com wrote:
On Tue 21 Aug 2012 04:48:17 PM CST, Paolo Bonzini wrote:
Il 21/08/2012 10:23, Cong Meng ha scritto:
+static void sg_get_queue_limits(BlockDriverState *bs, const char
*filename)
+{
+DIR *ffs;
+struct
Il 21/08/2012 11:52, Stefan Hajnoczi ha scritto:
Using /sys/dev/block or /sys/dev/char seems easier, and lets you
retrieve the parameters for block devices too.
what do you mean with block devices? Using /dev/sda instead of
/dev/sg0?
Yes.
However, I'm worried of the consequences
On Tue, Aug 21, 2012 at 8:23 AM, Cong Meng m...@linux.vnet.ibm.com wrote:
This patch adds some queue limit parameters into block drive. And inits them
for sg block drive. Some interfaces are also added for accessing them.
Signed-off-by: Cong Meng m...@linux.vnet.ibm.com
---
22 matches
Mail list logo