If your networking is failing after updating to the latest git version of QEMU...

If your networking is failing after updating to the latest git version of QEMU...

[Thomas Huth]

... it might have happened due to the removal of the "slirp" submodule from 
the git repository. For example if you see an error message like this:

  Parameter 'type' expects a netdev backend type

this likely means that the "user" mode backend type is not available in your 
binary anymore. To fix it, simply install "libslirp-devel" (or libslirp-dev 
or however it is called) from your OS distribution and recompile.

See also the commit message here:
  https://gitlab.com/qemu-project/qemu/-/commit/5890258aeeba303704

  Thomas

Re: If your networking is failing after updating to the latest git version of QEMU...

[Philippe Mathieu-Daudé via]

On 28/9/22 10:27, Thomas Huth wrote:
> 
> ... it might have happened due to the removal of the "slirp" submodule 
> from the git repository. For example if you see an error message like this:
> 
>   Parameter 'type' expects a netdev backend type
> 
> this likely means that the "user" mode backend type is not available in 
> your binary anymore. To fix it, simply install "libslirp-devel" (or 
> libslirp-dev or however it is called) from your OS distribution and 
> recompile.

Thanks for the hint Thomas. I'm afraid many developers will miss your
email.

Jason, Marc-André, could we improve the buildsys check or display
a more helpful information from the code instead?

Thanks,

Phil.

Re: If your networking is failing after updating to the latest git version of QEMU...

[Jason Wang]

On Thu, Sep 29, 2022 at 1:06 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> On 28/9/22 10:27, Thomas Huth wrote:
> >
> > ... it might have happened due to the removal of the "slirp" submodule
> > from the git repository. For example if you see an error message like this:
> >
> >   Parameter 'type' expects a netdev backend type
> >
> > this likely means that the "user" mode backend type is not available in
> > your binary anymore. To fix it, simply install "libslirp-devel" (or
> > libslirp-dev or however it is called) from your OS distribution and
> > recompile.
>
> Thanks for the hint Thomas. I'm afraid many developers will miss your
> email.
>
> Jason, Marc-André, could we improve the buildsys check or display
> a more helpful information from the code instead?

It looks to me we need to improve the build.

Thanks

>
> Thanks,
>
> Phil.
>

Re: If your networking is failing after updating to the latest git version of QEMU...

[Thomas Huth]

On 29/09/2022 04.32, Jason Wang wrote:
> On Thu, Sep 29, 2022 at 1:06 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> On 28/9/22 10:27, Thomas Huth wrote:
>>>
>>> ... it might have happened due to the removal of the "slirp" submodule
>>> from the git repository. For example if you see an error message like this:
>>>
>>>    Parameter 'type' expects a netdev backend type
>>>
>>> this likely means that the "user" mode backend type is not available in
>>> your binary anymore. To fix it, simply install "libslirp-devel" (or
>>> libslirp-dev or however it is called) from your OS distribution and
>>> recompile.
>>
>> Thanks for the hint Thomas. I'm afraid many developers will miss your
>> email.
>>
>> Jason, Marc-André, could we improve the buildsys check or display
>> a more helpful information from the code instead?
> 
> It looks to me we need to improve the build.

I'm not sure there is anything to improve in the build system - 
configure/meson.build are just doing what they should: Pick the default 
value for "slirp" if the user did not explicitly specify "--enable-slirp".

But the error message is not very helpful. It should rather say something 
like (partly suggested by Daniel in IRC yesterday already):

  Type 'user' is not a supported netdev backend by this QEMU build. Please 
check the spelling or whether it has been enabled at compilation time.

... or something like this.

Someone interested to write a patch?

  Thomas

Re: If your networking is failing after updating to the latest git version of QEMU...

[Alex Bennée]

Thomas Huth <thuth@redhat.com> writes:

> On 29/09/2022 04.32, Jason Wang wrote:
>> On Thu, Sep 29, 2022 at 1:06 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>>
>>> On 28/9/22 10:27, Thomas Huth wrote:
>>>>
>>>> ... it might have happened due to the removal of the "slirp" submodule
>>>> from the git repository. For example if you see an error message like this:
>>>>
>>>>    Parameter 'type' expects a netdev backend type
>>>>
>>>> this likely means that the "user" mode backend type is not available in
>>>> your binary anymore. To fix it, simply install "libslirp-devel" (or
>>>> libslirp-dev or however it is called) from your OS distribution and
>>>> recompile.
>>>
>>> Thanks for the hint Thomas. I'm afraid many developers will miss your
>>> email.
>>>
>>> Jason, Marc-André, could we improve the buildsys check or display
>>> a more helpful information from the code instead?
>> It looks to me we need to improve the build.
>
> I'm not sure there is anything to improve in the build system -
> configure/meson.build are just doing what they should: Pick the
> default value for "slirp" if the user did not explicitly specify
> "--enable-slirp".

Shouldn't it be the other way round and fail to configure unless the
user explicitly calls --disable-slirp?

>
> But the error message is not very helpful. It should rather say
> something like (partly suggested by Daniel in IRC yesterday already):
>
>  Type 'user' is not a supported netdev backend by this QEMU build.
>  Please check the spelling or whether it has been enabled at
> compilation time.
>
> ... or something like this.
>
> Someone interested to write a patch?
>
>  Thomas


-- 
Alex Bennée

Re: If your networking is failing after updating to the latest git version of QEMU...

[Peter Maydell]

On Mon, 3 Oct 2022 at 10:09, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Thomas Huth <thuth@redhat.com> writes:
>
> > On 29/09/2022 04.32, Jason Wang wrote:
> >> On Thu, Sep 29, 2022 at 1:06 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> >>> Jason, Marc-André, could we improve the buildsys check or display
> >>> a more helpful information from the code instead?
> >> It looks to me we need to improve the build.
> >
> > I'm not sure there is anything to improve in the build system -
> > configure/meson.build are just doing what they should: Pick the
> > default value for "slirp" if the user did not explicitly specify
> > "--enable-slirp".
>
> Shouldn't it be the other way round and fail to configure unless the
> user explicitly calls --disable-slirp?

Our standard pattern for configure options is:
 --enable-foo : check for foo; if it can't be enabled, fail configure
 --disable-foo : don't even check for foo, and don't build it in
 no option given : check for foo, decide whether to build in support if
                   it's present

-- PMM

Re: If your networking is failing after updating to the latest git version of QEMU...

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Mon, 3 Oct 2022 at 10:09, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>>
>> Thomas Huth <thuth@redhat.com> writes:
>>
>> > On 29/09/2022 04.32, Jason Wang wrote:
>> >> On Thu, Sep 29, 2022 at 1:06 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>> >>> Jason, Marc-André, could we improve the buildsys check or display
>> >>> a more helpful information from the code instead?
>> >> It looks to me we need to improve the build.
>> >
>> > I'm not sure there is anything to improve in the build system -
>> > configure/meson.build are just doing what they should: Pick the
>> > default value for "slirp" if the user did not explicitly specify
>> > "--enable-slirp".
>>
>> Shouldn't it be the other way round and fail to configure unless the
>> user explicitly calls --disable-slirp?
>
> Our standard pattern for configure options is:
>  --enable-foo : check for foo; if it can't be enabled, fail configure
>  --disable-foo : don't even check for foo, and don't build it in
>  no option given : check for foo, decide whether to build in support if
>                    it's present

Don't we make a distinction between libs that are truly optional and
those you probably need. It seems missing working networking is one of
those things we should be telling the user about unless explicitly
disabled. It is after all how we worked before, we would silently
checkout libslirp and build it for you.

>
> -- PMM


-- 
Alex Bennée

Re: If your networking is failing after updating to the latest git version of QEMU...

[Peter Maydell]

On Mon, 3 Oct 2022 at 11:25, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Mon, 3 Oct 2022 at 10:09, Alex Bennée <alex.bennee@linaro.org> wrote:
> >>
> >>
> >> Thomas Huth <thuth@redhat.com> writes:
> >>
> >> > On 29/09/2022 04.32, Jason Wang wrote:
> >> >> On Thu, Sep 29, 2022 at 1:06 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> >> >>> Jason, Marc-André, could we improve the buildsys check or display
> >> >>> a more helpful information from the code instead?
> >> >> It looks to me we need to improve the build.
> >> >
> >> > I'm not sure there is anything to improve in the build system -
> >> > configure/meson.build are just doing what they should: Pick the
> >> > default value for "slirp" if the user did not explicitly specify
> >> > "--enable-slirp".
> >>
> >> Shouldn't it be the other way round and fail to configure unless the
> >> user explicitly calls --disable-slirp?
> >
> > Our standard pattern for configure options is:
> >  --enable-foo : check for foo; if it can't be enabled, fail configure
> >  --disable-foo : don't even check for foo, and don't build it in
> >  no option given : check for foo, decide whether to build in support if
> >                    it's present
>
> Don't we make a distinction between libs that are truly optional and
> those you probably need.

Yes. If something is truly mandatory then configure will always
fail. This is true for zlib and glib, for instance...

> It seems missing working networking is one of
> those things we should be telling the user about unless explicitly
> disabled. It is after all how we worked before, we would silently
> checkout libslirp and build it for you.

...but building without libslirp is perfectly reasonable for some
configurations, eg where you know you're going to be using QEMU
in a TAP network config, and you don't want to have libslirp in
your binary so you don't have to think about whether you need to
act on security advisories relating to it. "no slirp" isn't like
"no zlib", where you can't build a QEMU at all. I think it's more
like gtk support, where we will happily configure without gtk/sdl/etc
and only build in the VNC frontend -- that's a working configuration
in some sense, but for the inexperienced user a QEMU which doesn't
produce a GUI window is almost certainly not what they wanted.

So we could:
 * say that we will opt for consistency, and have the slirp
   detection behave like every other optional library
 * say that slirp is a special case purely because we used to
   ship it as a submodule and so users are used to it being present
 * say that slirp is a special case because it's "optional but
   only experts will want to disable it", and think about what
   other configure options (like GUI support) we might want to
   move into this category

I don't think there's an obvious right answer here...

thanks
-- PMM

Re: If your networking is failing after updating to the latest git version of QEMU...

[Daniel P. Berrangé]

On Mon, Oct 03, 2022 at 11:36:36AM +0100, Peter Maydell wrote:
> On Mon, 3 Oct 2022 at 11:25, Alex Bennée <alex.bennee@linaro.org> wrote:
> >
> >
> > Peter Maydell <peter.maydell@linaro.org> writes:
> >
> > > On Mon, 3 Oct 2022 at 10:09, Alex Bennée <alex.bennee@linaro.org> wrote:
> > >>
> > >>
> > >> Thomas Huth <thuth@redhat.com> writes:
> > >>
> > >> > On 29/09/2022 04.32, Jason Wang wrote:
> > >> >> On Thu, Sep 29, 2022 at 1:06 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> > >> >>> Jason, Marc-André, could we improve the buildsys check or display
> > >> >>> a more helpful information from the code instead?
> > >> >> It looks to me we need to improve the build.
> > >> >
> > >> > I'm not sure there is anything to improve in the build system -
> > >> > configure/meson.build are just doing what they should: Pick the
> > >> > default value for "slirp" if the user did not explicitly specify
> > >> > "--enable-slirp".
> > >>
> > >> Shouldn't it be the other way round and fail to configure unless the
> > >> user explicitly calls --disable-slirp?
> > >
> > > Our standard pattern for configure options is:
> > >  --enable-foo : check for foo; if it can't be enabled, fail configure
> > >  --disable-foo : don't even check for foo, and don't build it in
> > >  no option given : check for foo, decide whether to build in support if
> > >                    it's present
> >
> > Don't we make a distinction between libs that are truly optional and
> > those you probably need.
> 
> Yes. If something is truly mandatory then configure will always
> fail. This is true for zlib and glib, for instance...
> 
> > It seems missing working networking is one of
> > those things we should be telling the user about unless explicitly
> > disabled. It is after all how we worked before, we would silently
> > checkout libslirp and build it for you.
> 
> ...but building without libslirp is perfectly reasonable for some
> configurations, eg where you know you're going to be using QEMU
> in a TAP network config, and you don't want to have libslirp in
> your binary so you don't have to think about whether you need to
> act on security advisories relating to it. "no slirp" isn't like
> "no zlib", where you can't build a QEMU at all. I think it's more
> like gtk support, where we will happily configure without gtk/sdl/etc
> and only build in the VNC frontend -- that's a working configuration
> in some sense, but for the inexperienced user a QEMU which doesn't
> produce a GUI window is almost certainly not what they wanted.
> 
> So we could:
>  * say that we will opt for consistency, and have the slirp
>    detection behave like every other optional library
>  * say that slirp is a special case purely because we used to
>    ship it as a submodule and so users are used to it being present
>  * say that slirp is a special case because it's "optional but
>    only experts will want to disable it", and think about what
>    other configure options (like GUI support) we might want to
>    move into this category
> 
> I don't think there's an obvious right answer here...

What I find particularly wierd about slirp, is how we have conditionalized
the behaviour of a bare 'qemu-system-XXX' invokation. In a fully featured
build, a no-args QEMU will be equiv to "-net nic,model=MODEL -net user",
but in a non-SLIRP build a no-args QEMU is merely "-net nic,model=MODEL".

If you specified "-net nic,model=MODEL" normally, you would get a message
printed:

   warning: hub 0 is not connected to host network

but we squelch this warning for the built-in default network, even though
the defaults are useless because of the missing backend.

I'm surprised we didn't just entirely remove the default NIC when no slirp
is present, given it can't do anything useful with the traffic. The
complete absence of a NIC would give a stronger sign to users that
something is different.

Ultimately it is only this 'no args' default case that is a significant
problem, as the explicit slirp args case we can report a clear error
message that explains the missing feature. Is 'no args' default important
enough that we need to make slirp diverge from normal configure/meson
practice for detecting libs ?

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|