qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Artem Pisarenko
Subject: [Qemu-devel] "socket" host network backend: suggested improvements and fixes
Date: Wed, 30 May 2018 16:34:03 +0600

Hi to all.

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

С уважением,
  Артем Писаренко


reply via email to

[Prev in Thread] Current Thread [Next in Thread]