net: Allow creating vsocks in listen mode.

[WhatAmISupposedToPutHere]

Previously all vsocks were expected to be connected from the guest. This patch adds support for sockets that are listened to by the guest and are connected from the host.

[tylerfanelli]

Thanks! Any readily-available testing methods?

[WhatAmISupposedToPutHere]

Build the linked PR from muvm, and launch a second command in the same vm. The second one will use this feature to send the launch request.

[slp]

This looks great, thanks. I only requested a minor change to force the library users to provide a healthy path for the unix socket.

[mtjhrc]

Thanks, I'll try to test this later, but for now I realized something:

If I am not mistaken, this only starts listening on the socket once the vsock device is activated, so if you want to connect to the socket from host, you would have to wait until the guest boot process initializes the vsock device.
Is this intended or useful for your use case? If so, it should at least be documented, because the users of libkrun could easily run into a race condition where they sometimes try to connect to the socket before the guest boots. An alternative could be to call listen on the socket before krun_add_vsock_port2 returns.

[WhatAmISupposedToPutHere]

Yes, the socket file appearing only after the vm is ready to process incoming connection is desired, that way the vm can wait for the file to appear before sending the requests.

[slp]

@mtjhrc Do you want to take a second look or can we merge it already?

[mtjhrc]

Sorry for the delay. I managed to test this just by adding a listening vsock in chroot_vm and using it in the guest.
Now I understand how it's meant to be used. Still I am unsure if we generally want to bind the sockets at the device initialization stage, but if It works for you this is fine for now, and we could always add another API later.

So for me this is good to merge! Thanks