All of lore.kernel.org
 help / color / mirror / Atom feed
From: lma <lma@suse.de>
To: qemu-devel@nongnu.org
Cc: pbonzini@redhat.com, stefanha@redhat.com
Subject: A question about how to calculate the "Maximum transfer length" in case of its absence in the Block Limits VPD device response from the hardware
Date: Thu, 17 Apr 2025 19:27:26 +0800	[thread overview]
Message-ID: <20db3af2ece22f598b54a47ec350b466@suse.de> (raw)

Hi all,

In case of SCSI passthrough, If the Block Limits VPD device response is 
absent from hardware, QEMU handles it.

There are several variables involved in this process as follows:
* The bl.max_transfer
* The bl.max_iov that is associated with IOV_MAX.
* The bl.max_hw_iov that is associated with the max_segments sysfs 
setting for the relevant block device on the host.
* The bl.max_hw_transfer that is associated with the BLKSECTGET ioctl, 
in other words related to the current max_sectors_kb sysfs setting of 
the relevant block device on the host.

Then take the smallest value and return it as the result of "Maximum 
transfer length" after relevant calculation, See:
static uint64_t calculate_max_transfer(SCSIDevice *s)
{
     uint64_t max_transfer = blk_get_max_hw_transfer(s->conf.blk);
     uint32_t max_iov = blk_get_max_hw_iov(s->conf.blk);

     assert(max_transfer);
     max_transfer = MIN_NON_ZERO(max_transfer,
                                 max_iov * qemu_real_host_page_size());

     return max_transfer / s->blocksize;
}


However, due to the limitation of IOV_MAX, no matter how powerful the 
host scsi hardware is, the "Maximum transfer length" that qemu emulates 
in bl vpd page is capped at 8192 sectors in case of 4kb page size and 
512 bytes logical block size.
For example:
host:~ # sg_vpd -p bl /dev/sda
Block limits VPD page (SBC)
   ......
   Maximum transfer length: 0 blocks [not reported]
   ......


host:~ # cat /sys/class/block/sda/queue/max_sectors_kb
16384

host:~ # cat /sys/class/block/sda/queue/max_hw_sectors_kb
32767

host:~ # cat /sys/class/block/sda/queue/max_segments
4096


Expected:
guest:~ # sg_vpd -p bl /dev/sda
Block limits VPD page (SBC)
   ......
   Maximum transfer length: 0x8000
   ......

guest:~ # cat /sys/class/block/sda/queue/max_sectors_kb
16384

guest:~ # cat /sys/class/block/sda/queue/max_hw_sectors_kb
32767


Actual:
guest:~ # sg_vpd -p bl /dev/sda
Block limits VPD page (SBC)
   ......
   Maximum transfer length: 0x2000
   ......

guest:~ # cat /sys/class/block/sda/queue/max_sectors_kb
4096

guest:~ # cat /sys/class/block/sda/queue/max_hw_sectors_kb
32767


It seems the current design logic is not able to fully utilize the 
performance of the scsi hardware. I have two questions:
1. I'm curious that is it reasonable to drop the logic about IOV_MAX 
limitation, directly use the return value of BLKSECTGET as the maximum 
transfer length when QEMU emulates the block limit page of scsi vpd?
    If we doing so, we will have maximum transfer length in the guest 
that is consistent with the capabilities of the host hardware。

2. Besides, Assume I set a value(eg: 8192 in kb) to max_sectors_kb in 
guest which doesn't exceed the capabilities of the host hardware(eg: 
16384 in kb) but exceeds the limit(eg: 4096 in kb) caused by IOV_MAX,
    Any risks in readv()/writev() of raw-posix?

Lin


             reply	other threads:[~2025-04-17 11:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-17 11:27 lma [this message]
2025-04-18 15:34 ` A question about how to calculate the "Maximum transfer length" in case of its absence in the Block Limits VPD device response from the hardware Stefan Hajnoczi
2025-04-23  9:47   ` lma
2025-04-23 13:24     ` Stefan Hajnoczi
     [not found]       ` <32c2072d6fc017786f4d6ef0dd681ae7@suse.de>
2025-04-24 14:51         ` Stefan Hajnoczi
2025-04-25  3:21           ` lma

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=20db3af2ece22f598b54a47ec350b466@suse.de \
    --to=lma@suse.de \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /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.