[Qemu-devel] libslirp and QEMU slirp

[Qemu-devel] libslirp and QEMU slirp

[Stefan Hajnoczi]

Hi,
There was a talk about new developments in VDEplug at FOSDEM 2017.
The QEMU slirp code has been extracted into a library:
https://fosdem.org/2017/schedule/event/iaas_modvde/

QEMU's slirp code does not have many contributors.  Other projects
using slirp are probably in this situation too.  Spinning the QEMU
slirp code out into an external library seems like a good idea because
it could help focus on new developments like IPv6 support and ease the
maintenance burden.

I'm proposing this topic for discussion because there might be common
ground for Samuel from QEMU and the VDE folks to collaborate.

Samuel: Should QEMU join forces with libslirp?

If you would like to speak rather than email, QEMU has a developer
conference call on Tuesday 14th of February at 13:00-14:00 UTC.  The
agenda is open for topics and it would be a good forum to share ideas
on slirp code maintenance and future direction.  All that's required
is an email to Juan Quintela <quintela@redhat.com> and he can schedule
the call and provide dial-in details.

Stefan

Re: [Qemu-devel] libslirp and QEMU slirp

[Samuel Thibault]

Hello,

Stefan Hajnoczi, on Mon 06 Feb 2017 11:55:05 +0000, wrote:
> I'm proposing this topic for discussion because there might be common
> ground for Samuel from QEMU and the VDE folks to collaborate.
> 
> Samuel: Should QEMU join forces with libslirp?

Well, there are not that many forces from the QEMU side :)

Personally, I'm fine with seeing slirp move to a separate playground
that qemu would depend on and others could contribute to.  It just needs
to be integrated to distros so that qemu can get it.

That being said, the integration of slirp and qemu is not so loose,
notably on the top of my head:

- we are using timers for icmp announcements
- qemu needs to be able to save/restore state, with compatibility with
previous versions

We'd need to see how that can be expressed as a library.

Samuel

Re: [Qemu-devel] libslirp and QEMU slirp

[Renzo Davoli]

Hi,

On Wed, Feb 08, 2017 at 11:10:50PM +0100, Samuel Thibault wrote:
> Hello,
> 
> Stefan Hajnoczi, on Mon 06 Feb 2017 11:55:05 +0000, wrote:
> > I'm proposing this topic for discussion because there might be common
> > ground for Samuel from QEMU and the VDE folks to collaborate.
> > 
> > Samuel: Should QEMU join forces with libslirp?
> 
> Well, there are not that many forces from the QEMU side :)
Neither on VDE side ;-) but many ants can move mountains...
> 
> - we are using timers for icmp announcements
> - qemu needs to be able to save/restore state, with compatibility with
> previous versions

libslirp is using qemu's slirp code. 
If you try a diff between your "slirp" directory and libslirp's "src" directory
you'll find that there are only 3 lines added:
(at the date of the code extraction, e.g. qemu git's tag 1f8b56e7cebc71d80aec27a4760024b56acc957a)

In slirp.h:
#include <qemu2libslirp.h>

Which includes stubs and specific implementations to give slirp all the stuff
provided by qemu's core or other libraries used by qemu.

In tcp_subr.c:
400a401,403
>       if ((ret = unixtcp_fconnect(so, af)) >= 0)
>               return ret;

which adds a nice feature that IMHO would be useful in qemu, too.
unixtcp_fconnect creates a TCP to AF_UNIX socket redirection.
The VM running on qemu (or in VDE a VM connected to the virtual net)
can redirect a default route port (say 10.0.2.2:6000) to a UNIX socket
(say /tmp/.X11-unix/0). In this example X clients using the X display 10.0.2.2:0 
can appear on the X server of the host.

Timers have been reimplemented using the qemu's API.
save/restore are dummy stubs in libslirp. Qemu's code is still there but it is not used
by libslirp.

In this way we can inherit all bugfixes and new feature from Qemu at almost no cost.

It would be a nice project to create a common codebase for libslirp.
The project sould be interesting for other VM projects (virtualbox-OSE?) and
maybe many others. We could collect several ants...

Libslirp/QEMU integration is not so difficult.
As a first step:
* Qemu could add the UNIX socket redirect feature, or at least a unixtcp_fconnect dummy function
returning -1 (#ifndef LIBSLIRP)
* #include <qemu2libslirp.h>
could be added in slirp.h (inside an #ifdef LIBSLIRP).
In this way we could share exactly the same codebase.

One further step:
* discuss how to reduce/eliminate qemu-specific dependence
* create an API for save/restore

These are only my two (euro)cents.

ciao
	renzo

Re: [Qemu-devel] libslirp and QEMU slirp

[Thomas Huth]

On 12.02.2017 08:30, Renzo Davoli wrote:
> Hi,
> 
> On Wed, Feb 08, 2017 at 11:10:50PM +0100, Samuel Thibault wrote:
>> Hello,
>>
>> Stefan Hajnoczi, on Mon 06 Feb 2017 11:55:05 +0000, wrote:
>>> I'm proposing this topic for discussion because there might be common
>>> ground for Samuel from QEMU and the VDE folks to collaborate.
>>>
>>> Samuel: Should QEMU join forces with libslirp?
>>
>> Well, there are not that many forces from the QEMU side :)
> Neither on VDE side ;-) but many ants can move mountains...
>>
>> - we are using timers for icmp announcements
>> - qemu needs to be able to save/restore state, with compatibility with
>> previous versions
> 
> libslirp is using qemu's slirp code.
[...]
> Timers have been reimplemented using the qemu's API.
> save/restore are dummy stubs in libslirp. Qemu's code is still there but it is not used
> by libslirp.

Well, sure, but if this libslirp is going to evolve into a
QEMU-independent library, such timer and save/restore hacks likely
should go away from the library and implemented on the side of the
consuming application instead.

> It would be a nice project to create a common codebase for libslirp.
> The project sould be interesting for other VM projects (virtualbox-OSE?) and
> maybe many others. We could collect several ants...

FWIW, I know that WinUAE is using QEMU's slirp code, too.

I've got a question: Is there already a project page and public
repository for libslirp available somewhere? I did not find anything
useful with Google yet...

 Thomas

Re: [Qemu-devel] libslirp and QEMU slirp

[Renzo Davoli]

Hi Thomas,

> FWIW, I know that WinUAE is using QEMU's slirp code, too.
thank you! I'll have a look of it.
> 
> I've got a question: Is there already a project page and public
> repository for libslirp available somewhere? I did not find anything
> useful with Google yet...
Sure:

https://github.com/rd235/libslirp

ciao
	renzo

Re: [Qemu-devel] libslirp and QEMU slirp

[Stefan Hajnoczi]

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

On Sun, Feb 12, 2017 at 08:30:19AM +0100, Renzo Davoli wrote:
> It would be a nice project to create a common codebase for libslirp.
> The project sould be interesting for other VM projects (virtualbox-OSE?) and
> maybe many others. We could collect several ants...
> 
> Libslirp/QEMU integration is not so difficult.
> As a first step:
> * Qemu could add the UNIX socket redirect feature, or at least a unixtcp_fconnect dummy function
> returning -1 (#ifndef LIBSLIRP)
> * #include <qemu2libslirp.h>
> could be added in slirp.h (inside an #ifdef LIBSLIRP).
> In this way we could share exactly the same codebase.
> 
> One further step:
> * discuss how to reduce/eliminate qemu-specific dependence
> * create an API for save/restore

Eliminating QEMU dependencies is feasible, I think.  libslirp could have
no "qemu" strings in the code :).  Applications like QEMU need to query
libslirp for timers and fds so they can be integrated into event loops
(select(2)).

Once there is a working libslirp that arbitrary programs can link
against it can be packaged (rpm, deb, etc) and announced.  That might
attract new contributors.

Stefan

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