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 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
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
19 matches
Mail list logo
