On 01.02.2017 20:55, Max Reitz wrote: > On 20.01.2017 17:25, Eric Farman wrote: >> 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(-) > > Thank you, I've applied the series to my block tree (with the macro > definitions in patch 2 switched as proposed): > > https://github.com/XanClic/qemu/commits/block
Noticed now that Paolo has already merged this. Well, then out it goes. Too bad the swap of BDRV_REQUEST_MAX_BYTES and BDRV_REQUEST_MAX_SECTORS is not in his tree. Well, I'll make it an own patch then. Max
signature.asc
Description: OpenPGP digital signature
