From: Eric Farman <farman@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: Eric Farman <farman@linux.vnet.ibm.com>
Subject: [Qemu-devel] [PATCH v3 0/3] scsi-generic and BLKSECTGET
Date: Fri, 20 Jan 2017 17:25:24 +0100 [thread overview]
Message-ID: <20170120162527.66075-1-farman@linux.vnet.ibm.com> (raw)
In the Linux kernel, I see two (three) places where the BLKSECTGET ioctl is
handled:
(1) block/(compat_)ioctl.c -- (compat_)blkdev_ioctl
(2) drivers/scsi/sg.c -- sg_ioctl
The former has been around forever[1], and returns a short value measured in
sectors. A sector is generally assumed to be 512 bytes.
The latter has been around for slightly less than forever[2], and returns an
int that measures the value in bytes. A change to return the block count
was brought up a few years ago[3] and nacked.
As a convenient example, if I use the blockdev tool to drive the ioctl to a
SCSI disk and its scsi-generic equivalent, I get different results:
# lsscsi -g
[0:0:8:1077166114]disk IBM 2107900 .217 /dev/sda /dev/sg0
# blockdev --getmaxsect /dev/sda
2560
# blockdev --getmaxsect /dev/sg0
20
Now, the value for /dev/sda looks "correct" to me.
# cd /sys/devices/css0/0.0.0125/0.0.1f69/host0/rport-0\:0-8/
# cd target0\:0\:8/0\:0\:8\:1077166114/
# cat block/sda/queue/max_sectors_kb
1280
# cat block/sda/queue/hw_sector_size
512
And the math checks out:
max_sectors_kb * 1024 / hw_sector_size == getmaxsect
-OR-
1280 * 1024 / 512 = 2560
For /dev/sg0, it appears the answer is coming from the sg_ioctl result
which is already multiplied by the block size, and then looking at only the
upper half (short) of the returned big-endian fullword:
(1280 * 1024 / 512) * 512 = 1310720 = x00140000 => x0014 = 20
The reason for all this? Well, QEMU recently added a BLKSECTGET ioctl
call[4] which we see during guest boot. This code presumes the value is in
blocks/sectors, and converts it to bytes[5]. Not that this matters, because
the short/int discrepancy gives us "zero" on s390x.
Also, that code doesn't execute for scsi-generic devices, so the conversion
to bytes is correct, but I'd like to extend this code to interrogate
scsi-generic devices as well. This is important because libvirt converts
a specified virtio-scsi device to its /dev/sgX address for the QEMU
commandline.
Changes:
v2->v3:
- Move byte/sector conversions to patch 2 [Fam Zheng]
- Rename "max_sectors" when holding a byte value [Fam Zheng]
v1->v2:
- Patch 3, make hdev_get_max_transfer_length return bytes [Fam Zheng]
[1] The initial kernel git commit
[2] kernel commit 44ec95425c1d9dce6e4638c29e4362cfb44814e7
[3] https://lkml.org/lkml/2012/6/27/78
[4] qemu commit 6f6071745bd0366221f5a0160ed7d18d0e38b9f7
[5] qemu commit 5def6b80e1eca696c1fc6099e7f4d36729686402
Eric Farman (3):
hw/scsi: Fix debug message of cdb structure in scsi-generic
block: Fix target variable of BLKSECTGET ioctl
block: get max_transfer limit for char (scsi-generic) devices
block/file-posix.c | 19 +++++++++++--------
hw/scsi/scsi-generic.c | 5 +++--
include/block/block.h | 1 +
3 files changed, 15 insertions(+), 10 deletions(-)
--
2.8.4
next reply other threads:[~2017-01-20 16:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-20 16:25 Eric Farman [this message]
2017-01-20 16:25 ` [Qemu-devel] [PATCH v3 1/3] hw/scsi: Fix debug message of cdb structure in scsi-generic Eric Farman
2017-01-20 16:25 ` [Qemu-devel] [PATCH v3 2/3] block: Fix target variable of BLKSECTGET ioctl Eric Farman
2017-02-01 0:25 ` [Qemu-devel] [Qemu-block] " Max Reitz
2017-02-01 13:18 ` Eric Farman
2017-01-20 16:25 ` [Qemu-devel] [PATCH v3 3/3] block: get max_transfer limit for char (scsi-generic) devices Eric Farman
2017-01-22 14:29 ` [Qemu-devel] [PATCH v3 0/3] scsi-generic and BLKSECTGET Fam Zheng
2017-01-24 11:23 ` Paolo Bonzini
2017-01-24 12:09 ` Fam Zheng
2017-01-24 12:17 ` Eric Farman
2017-01-31 11:37 ` [Qemu-devel] [Qemu-block] " John Snow
2017-01-31 23:47 ` Max Reitz
2017-02-01 9:51 ` John Snow
2017-02-01 19:55 ` Max Reitz
2017-02-08 22:33 ` Max Reitz
2017-02-09 9:32 ` [Qemu-devel] " Paolo Bonzini
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=20170120162527.66075-1-farman@linux.vnet.ibm.com \
--to=farman@linux.vnet.ibm.com \
--cc=qemu-block@nongnu.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.