Re: [PATCH v2 4/4] Add CCW configuration field "indirect_num" to vq_info_block

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Freitag, 11. März 2022 12:15:40 CET Halil Pasic wrote:
> But let me take a step back, and ask some more general questions?
> 1) What is the objective behind the mechanism which can be used by the
> driver to tell the device its maximum. I believe the indirect descriptor
> table is always allocated by the guest, so the guest has no reason to
> fear larger than its max. The only thing I can think of is some pools
> of buffers allocated and maintained by the device, where each buffer
> is the size of max payload. Is this what we have in mind here?

As described at the end on the associated virtio-spec github issue [1]:

  "
  Linux drivers

  Since torvalds/linux@44ed808 the Linux kernel ignores if individual drivers
  exceed the Queue Size (and violating the specs). Likewise there are some
  devices which use device specific config to negotiate a max. bulk data size 
  being lower than the Queue Size. The proposed spec changes would address 
  both use cases in a clean way.

  QEMU

  QEMU tolerates as well if guests drivers exceed the Queue Size. However
  currently it has a hard coded limit of max. 1024 memory segments:
  #define VIRTQUEUE_MAX_SIZE 1024
  Which limits the max. buik data size per virtio message to slightly below
  4MB
  "

So ATM when you run a Linux driver that exceeds QEMU's current limit of 1024
segments, you would get the following fatal QEMU error [2]:

  qemu-system-x86_64: virtio: too many write descriptors in indirect table

QEMU currently allocates the required space for the descriptors on the stack
and uses that hard coded value for the allocation size. Now even if you would
change that (which is a delicate bunch of code), you would still break
compatibility with Linux guests running on older QEMU hosts.

[1] https://github.com/oasis-tcs/virtio-spec/issues/122
[2] https://lore.kernel.org/netdev/cover.1640870037.git.linux_oss@crudebyte.com/

> 2) Not so long ago we had a discussion about introducing a common (device
> agnostic) configuration space (a.k.a. misc config). The indirect table
> size might be a good candidate for that as well. We essentially want
> the very same functionality for all the transports, it is just that
> we have no vehicle at the moment to do this in an uniform way. Opinions?
> 
> Regards,
> Halil

I need to leave that to other people to comment on, as I am completely unaware
about these plans. Sounds like a long-term plan to me though.

Best regards,
Christian Schoenebeck