Re:[Qemu-devel] [PATCH v2] vhost-vsock: report QMP event whensetrunning

[<ning.bo9@zte.com.cn>]

[-- Attachment #1.1: Type: text/plain, Size: 1805 bytes --]

> This can be done efficiently as follows:
> 1. kata-runtime listens on a vsock port
> 2. kata-agent-port=PORT is added to the kernel command-line options
> 3. kata-agent parses the port number and connects to the host
> 
> This eliminates the reconnection attempts.

There will be an additional problem if do this:
Who decides which port the `runtime` should listen?

Consider the worst case: 
The ports selected by two `runtime` running in parallel always conflict, 
and this case is unavoidable, even if we can reduce the possibility of conflicts through algorithms.
Because we don't have a daemon that can allocate unique port to `runtime`.


> Userspace APIs to avoid the 2 second wait already exist:
> 
> 1. The SO_VM_SOCKETS_CONNECT_TIMEOUT socket option controls the connect
>    timeout for this socket.

Yes, it has the same effect

> 2. Non-blocking connect allows the userspace process to do other things
>    while a connection attempt is being made.

I don't think the `tunime` has anything to do except wait for the response from the `agent` at that moment



Now let me sort out the currently known methods:
1. `runtime` does not connect until it receives the qmp event reported by qemu when the `agent` opens the vsock device.
    - The method looks inappropriate now.
2. adding a special case for vhost_vsock.ko.
    - Also inappropriate.
3. connect to `runtime` from `agent`.
    - `runtime` may not be able to choose the right port.
4. Use `SO_VM_SOCKETS_CONNECT_TIMEOUT` option.
    - The effect is similar to method 2, no need to modify the kernel module code.

I have an additional question:
If useing method 4, when `runtime` calls connect use NONBLOCK option with very short timeout in an infinite loop, the kernel maybe frequently creates timers. Is there any other side effects?

[-- Attachment #2: signature.asc --]
[-- Type: application/octet-stream, Size: 500 bytes --]

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAl3yHvUACgkQnKSrs4Gr
c8jg5ggAqaIQAS2Z81lTIi4bs475raquTl3SUzc+6T8yciP/Xs1Sb7tVdHx3WwFq
v1eqefEKrNNpdjUncOKoHRa4uMQZJSlVaJCsEmHUKBGOQPi+hJ8X0Q57/w4hEYQ6
bXrVPlwFK1vBzPPTr1w4qKbKIJyqCYrjhxUxr2KeVr1q8jpvdxnXTILTLWU1JCNS
Fh1l69CTM0RjtRiW4mbskNspNCluS5sq3KG0PMCBW+VqPNP9rXL6C3qpIwM1RY9p
XTrUNSS4wqRNXl2Ug/Pt52Vwr4YAAezsyC+JOCUZbC3nvzR/C2L4i1p/HLVvOuDI
9nsEqtr1Cj7xBuCKq9KCTfS2jpCsTg==
=0QNN
-----END PGP SIGNATURE-----
\r