mirror of
https://github.com/kata-containers/kata-containers.git
synced 2026-07-01 22:50:54 +00:00
0d5bde2181
The shared filesystem device builder in `prepare_virtiofs` was hardcoding `queue_size = 0` and `queue_num = 0` on the `ShareFsConfig` it hands to the hypervisor, ignoring `SharedFsInfo.virtio_fs_queue_size` parsed from `configuration.toml` entirely. For qemu, this is silently broken: the cmdline generator's `DeviceVhostUserFs::set_queue_size` treats 0 as "not set" and skips the `queue-size=` argument when emitting the `vhost-user-fs-pci` device, so QEMU falls back to its built-in default of 128, regardless of what the user configured. For Cloud Hypervisor it happens to work in practice today, but only because `ch::handle_share_fs_device` and `TryFrom<ShareFsSettings> for FsConfig` substitute a hardcoded 1024 when the incoming `queue_num`/`queue_size` are zero. That fallback masks the real bug; the toml value still never reaches the VMM. Add a `get_shared_fs_info` accessor on `DeviceManager` mirroring the existing `get_block_device_info` helper, and use it in `prepare_virtiofs` to populate `ShareFsConfig.queue_size` from `SharedFsInfo.virtio_fs_queue_size`. Use a single virtqueue (`queue_num = 1`), matching what runtime-go hardcodes for both qemu (govmm `QemuFSParams` does not emit `num-queues=`) and CH (`numQueues := int32(1)` in `clh.go`). The CH-side fallback and the CH config template are addressed in a follow-up commit. Signed-off-by: Aurélien Bombo <abombo@microsoft.com>