diff options
| author | Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> | 2018-03-06 12:44:11 -0300 |
|---|---|---|
| committer | Paolo Bonzini <pbonzini@redhat.com> | 2018-03-12 16:12:45 +0100 |
| commit | d082d16a5c521907190c58cb7e4ff5eed5c48ab1 (patch) | |
| tree | 33bcf371e0cd39fa9674c48d5ba264f25281f0ee /hw/sd/core.c | |
| parent | 4b9c264bd286af7d65892821d19e13b17259b6c4 (diff) | |
| download | focaccia-qemu-d082d16a5c521907190c58cb7e4ff5eed5c48ab1.tar.gz focaccia-qemu-d082d16a5c521907190c58cb7e4ff5eed5c48ab1.zip | |
scsi-disk.c: consider bl->max_transfer in INQUIRY emulation
The calculation of the max_transfer atribute of BlockDriverState makes considerations such as max_segments and transfer_length via the BLKSECTGET ioctl (if available). However, bl->max_transfer isn't considered when emulating the INQUIRY 'Block Limit' response to the scsi-hd devices. This leads to situations where the declared max_sectors from the INQUIRY response is inconsistent with the block limits, which isn't ideal. It can also be misleading to the user that sets /sys/block/<dev>/queue/max_sectors_kb to a certain value, then finds a different value in the guest OS for the same disk. Following the same logic scsi_read_complete from scsi-generic.c does when patching the response of the Block Limits VPD back to the guest, change the max_io_sectors value of the emulated Block Limits VPD response by considering the blk_get_max_transfer of the related BlockDriverState. Use MIN_NOT_ZERO to be sure that the minimal value is chosen. Given that we're changing max_io_sectors, consider that min_io_sectors and opt_io_sectors can't be greater than the new calculated value. Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Reviewed-by: Fam Zheng <famz@redhat.com> Message-Id: <20180306154411.18462-1-danielhb@linux.vnet.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'hw/sd/core.c')
0 files changed, 0 insertions, 0 deletions