qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: qemu-devel <qemu-devel@nongnu.org>
Cc: Kevin Wolf <kwolf@redhat.com>, Hannes Reinecke <hare@suse.de>
Subject: [Qemu-devel] scsi-generic and max request size
Date: Tue, 21 Dec 2010 14:25:46 +1100	[thread overview]
Message-ID: <1292901946.16694.688.camel@pasglop> (raw)

Hi folks !

There's an odd problem I've encountered with my scsi host (basically an
powerpc "vscsi" compatible with IBM PAPR).

When using /dev/sg (ie, scsi-generic), there seem to be no way I can
find to retrieve the underlying driver's max request transfer size.

This can normally be obtained with the BLKSECTGET ioctl under Linux (I'm
not familiar with other OSes here). However, this is a bit buggy as
well, ie, afaik, this doesn't work with 32-bit binaries on 64-bit
kernels (the compat ioctl doesn't seem to work on /dev/sg).

For now, qemu doesn't pass that from its bdev layer, which means that
scsi-generic doesn't pass it to its own "upper" layer neither.

What that means is two fold I suppose:

 - For real SCSI HBAs, how do you limit the transfer size anyways ? You
can't start breaking up user requests without taking risks with tags
etc...

 - For vscsi, I can expose the limit I want via the SRP interface, but
scsi-generic doesn't tell me what it is :-)

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 to give me bigger requests than that
if I don't start limiting them, which will cause all sort of errors.

Cheers,
Ben.

             reply	other threads:[~2010-12-21  3:26 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-21  3:25 Benjamin Herrenschmidt [this message]
2010-12-21  3:38 ` [Qemu-devel] scsi-generic and max request size ronnie sahlberg
2010-12-21  3:52   ` Benjamin Herrenschmidt
2010-12-21  8:44     ` Hannes Reinecke
2010-12-21 22:05       ` Benjamin Herrenschmidt
2010-12-22 13:54         ` Hannes Reinecke
2010-12-22 13:27           ` Christoph Hellwig
2010-12-22 22:06             ` Benjamin Herrenschmidt
2010-12-22 23:19             ` Alexander Graf
2010-12-22 21:59           ` Benjamin Herrenschmidt
2010-12-22 23:23             ` Alexander Graf
2010-12-22 23:35               ` Benjamin Herrenschmidt
2010-12-22 23:39                 ` Alexander Graf
2010-12-22 23:44                   ` Benjamin Herrenschmidt
2010-12-22 23:49                     ` Alexander Graf
2010-12-23  0:00                       ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1292901946.16694.688.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=hare@suse.de \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).