Re: [Qemu-devel] "socket" host network backend: suggested improvements and fixes

[Stefan Hajnoczi <stefanha@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3594 bytes --]

On Wed, May 30, 2018 at 04:34:03PM +0600, Artem Pisarenko wrote:
> Hi to all.

Hi Artem,
I have CCed Jason Wang, the QEMU networking maintainer, so your email
gets attention.  QEMU is a high-traffic mailing list and you may not get
responses unless you CC relevant people (use scripts/get_maintainer.pl
-f path/to/source.c to look up maintainers).

> I'm working on integrating QEMU networking to simulation environment and
> found socket backend very convenient: it's simple, easy to use (i.e no
> intermediate things required, such as tap/tun adapter, vde switch, etc.)
> and transparent to host environment (i.e. it doesn't pollutes system with
> bunch of virtual devices, etc.).
> 
> Although, it have some problems, closely related to each other. I've
> investigated source code and played with it a little, but I'm not ready
> submit a complete patch. So, here are my thoughts...
> 
> 1. Internal protocol (only qemu instances can join its network devices
> between). I suggest to make it available to plug with external software,
> i.e freeze communication protocol at current state and document it in
> docs/interop/ directory.
> 
> 2. Transport options wrongly documented. Section "2.3.6 Network options"
> lists "-netdev socket,..." entries. It gives very different basic
> understanding of how it works from actual one.
>  2.1. It has two entries: listen/connect (TCP connecton) and mcast
> (multicast UDP), but 'qemu --help' outputs additional one - udp (UDP
> tunnel), which is undocumented, but looks like working.
>  2.2. Each entry has fd=h parameter, which looks like it's an optional
> parameter, but code analysis (net/socket.c) shows that, in fact, it's a
> separate transport option exclusive to listed ones. It used as follows:
> user creates/opens whatever (almost) custom socket/file it wants, connects
> it with other endpoint and passes file descriptor (handle) to qemu, which
> just recv/send over it and nothing more.
>  2.3. As a consequence, if you try to invoke any transport/variant option
> with "fd=", you'll get an error: "exactly one of listen=, connect=, mcast=
> or udp= is required". And again, error message is incomplete - it misses
> "fd=" option.
> 
> 3. "fd=" transport doesn't work with SOCK_DGRAM type sockets. It's due to
> an implementation error in net/socket.c. Function
> net_socket_receive_dgram() uses sendo() call with s->dgram_dst value which
> is undefined for this case (and, of course, cannot be defined).
> Although net_socket_fd_init() execution branch is smart enough to detect
> type of socket passed with "fd=", but its "connected" state forgotten
> afterwards. Suggested fix: replace sendto() with send(), which correctly
> assumes already connected socket, and add corresponding connect() calls for
> "mcast=" and "udp=" init sequences.
> 
> (For those, who interested, currently I've got working network
> communication with unmodified qemu 2.12.0 in Linux using UNIX domain
> sockets created by socketpair(AF_LOCAL, SOCK_STREAM, ...), one of which
> passed to spawned child qemu process via -netdev socket,fd=... and other
> one, used in parent application process to send/receive packets. Protocol,
> used by qemu, is simple and implements only data plane: it just transfers
> raw ethernet frames in binary form, for datagram-type sockets it's
> straightforward, and for stream-type sockets each frame prepended with
> uint32 length in network byte order, without any delimiters and escaping.)
> -- 
> 
> С уважением,
>   Артем Писаренко

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]