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

[Stefan Hajnoczi]

On Fri, Dec 13, 2019 at 03:11:54PM +0800, ning@zte.com.cn wrote:
> > 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?

Let the host kernel automatically assign a port using VMADDR_PORT_ANY.
It works like this:

  struct sockaddr_vm svm = {
  .svm_family = AF_VSOCK,
  .svm_port = VMADDR_PORT_ANY,
  .svm_cid = VMADDR_CID_ANY,
  };

  int fd = socket(AF_VSOCK, SOCK_STREAM, 0);
  ...
  if (bind(fd, (const struct sockaddr *), sizeof(svm)) < 0) {
  ...
  }

  socklen_t socklen = sizeof(svm);
  if (getsockname(fd, (struct sockaddr *), ) < 0) {
  ...
  }

  printf("cid %u port %u\n", svm.svm_cid, svm.svm_port);

> 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`.

The kernel assigns unique ports and only fails if the entire port
namespace is exhausted.  The port namespace is 32-bits so this is not a
real-world concern.

Does this information clarify how the runtime can connect to the guest
agent without loops or delays?

Stefan


signature.asc
Description: PGP signature

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

[ning.bo9]

> 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?

signature.asc
Description: Binary data