>> >+
>> >+ if (nvqs < 0)
>> >+ nvqs = MAX_VQS_WITHOUT_DGRAM;
>> >+
>> >+ if (nvqs == MAX_VQS_WITH_DGRAM) {
>> >+ vvc->dgram_recv_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
>> >+
vhost_vsock_common_handle_output);
>> >+ vvc->dgram_trans_vq = virtio_add_queue(vdev,
VHOST_VSOCK_QUEUE_SIZE,
>> >+
vhost_vsock_common_handle_output);
>> >+ }
>> >+
>> > /* The event queue belongs to QEMU */
>> > vvc->event_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
>> > vhost_vsock_common_handle_output);
>>
>> Did you do a test with a guest that doesn't support datagram with QEMU
>> and hosts that do?
>>
>Yes, and it works.
>
>> I repost my thoughts that I had on v2:
>>
>> What happen if the guest doesn't support dgram?
>>
>> I think we should dynamically use the 3rd queue or the 5th queue for
>> the events at runtime after the guest acked the features.
>>
>> Maybe better to switch to an array of VirtQueue.
>>
>I think in current V3, it already dynamically use 3rd or 5th queue
>depending
>on the feature bit.
I'm not sure. IIUC when vhost_vsock_common_realize() is called, we don't
know the features acked by the guest, so how can it be dynamic?
Here we should know only if the host kernel supports it.
Maybe it works, because in QEMU we use the event queue only after a
migration to send a reset event, so you can try to migrate a guest to
check this path.