From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42195 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PUsrR-0004Ec-At for qemu-devel@nongnu.org; Mon, 20 Dec 2010 22:26:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PUsrQ-0001f3-5l for qemu-devel@nongnu.org; Mon, 20 Dec 2010 22:26:01 -0500 Received: from gate.crashing.org ([63.228.1.57]:58043) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PUsrP-0001dl-KP for qemu-devel@nongnu.org; Mon, 20 Dec 2010 22:26:00 -0500 From: Benjamin Herrenschmidt Content-Type: text/plain; charset="UTF-8" Date: Tue, 21 Dec 2010 14:25:46 +1100 Message-ID: <1292901946.16694.688.camel@pasglop> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] scsi-generic and max request size List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel Cc: Kevin Wolf , Hannes Reinecke 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.