On 05/28/20 18:39, annie li wrote:
On 5/27/2020 2:00 PM, Laszlo Ersek wrote:
(4) Annie: can you try launching QEMU with the following flag:
This limits the I/O size to 1M.Indeed -- as I just pointed out under your other email, I previously
missed that the host kernel-side unit was not "sector" but "4K page". So
yes, the value 2048 above is too strict.
The EFI_BAD_BUFFER_SIZE logic reducesOK!
0x4000 doesn't survive here.That's really interesting. I'm not sure why that happens.
... Is it possible that vhost_scsi_handle_vq() -- in the host kernel --
puts stuff in the scatter-gather list *other* than the transfer buffers?
Some headers and such? Maybe those headers need an extra page.
If that works, then I *guess* the kernel-side vhost device model
You mean the vhost device on the guest side here, right? In WindowsWith vhost, the virtio-scsi device model is split between QEMU and the
host kernel. While QEMU manages the "max_sectors" property (= accepts it
from the command line, and exposes it to the guest driver), the host
kernel (i.e., the other half of the device model) ignores the same property.
Consequently, although the guest driver obeys "max_sectors" for limiting
the transfer size, the host kernel's constants may prove *stricter* than
that. Because, the host kernel ignores "max_sectors". So one idea is to
make the host kernel honor the "max_sectors" limit that QEMU manages.
The other two ideas are: use larger constants in the kernel, or use a
smaller "max_sectors" default in QEMU.
The goal behind all three alternatives is the same: the limit that QEMU
exposes to the guest driver should satisfy the host kernel.