[Qemu-devel] Problems with recent char changes (mux, slirp)

[Qemu-devel] Problems with recent char changes (mux, slirp)

[Dr. David Alan Gilbert]

Hi Marc-André,
  I've got a bunch of different failures in current head
that seem to bisect down to your recent char changes.

Lets start with the main symptoms;
1)
  Slirp guestfwd is broken, start an nc with:
      nc -l 127.0.0.1 4444
    and then qemu with:
    -netdev user,id=unet,guestfwd=tcp:10.0.2.50:4444-tcp:localhost:4444 -device e1000,netdev=unet 

    and from the guest do:
    seq 1 10000000 | nc 10.0.2.50 4444 &
    you should get a spew of numbers coming out of nc  but on current
    head it does nothing.

    This seems to work at becdfa00cfa2995e859ccefa4b7d72a72eb96581
    but segs by 386f07d1fc02fb4316039994b855c4feb9b091ce
    and is silently broken somewhere around 72ac876248ca2d33b3e1170b2f86fb68daaacdc8

2)
  If you start qemu with qemu-system-x86_64 -nographic
  you normally get no output until you ctrl-a c at which
  you get a banner and then a (qemu) prompt, however with current
  head, at startup you get:
   ./x86_64-softmmu/qemu-system-x86_64 -nographic
   QEMU 2.7.50 monitor - type 'help' for more information
   (qemu) 

   and although it gives you a prompt it's not responsive, so you
   ctrl-ac and then you get a :
   QEMU 2.7.50 monitor - type 'help' for more information
   QEMU 2.7.50 monitor - type 'help' for more information
   (qemu) 
 
   and it works - but you've got the extra banner.

   It's fine at 6dfa8298faa0fce47c68659fd4d92e76745d4edb
   ecb672d14f092f481000ac9cd9d7dc0500692eba is broken but a bit differently
   94a40fc56036b5058b0b194d9e372a22e65ce7be doesn't build (!)

Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] Problems with recent char changes (mux, slirp)

[Paolo Bonzini]

On 27/10/2016 13:52, Dr. David Alan Gilbert wrote:
> Hi Marc-André,
>   I've got a bunch of different failures in current head
> that seem to bisect down to your recent char changes.
> 
> Lets start with the main symptoms;
> 1)
>   Slirp guestfwd is broken, start an nc with:
>       nc -l 127.0.0.1 4444
>     and then qemu with:
>     -netdev user,id=unet,guestfwd=tcp:10.0.2.50:4444-tcp:localhost:4444 -device e1000,netdev=unet 
> 
>     and from the guest do:
>     seq 1 10000000 | nc 10.0.2.50 4444 &
>     you should get a spew of numbers coming out of nc  but on current
>     head it does nothing.
> 
>     This seems to work at becdfa00cfa2995e859ccefa4b7d72a72eb96581
>     but segs by 386f07d1fc02fb4316039994b855c4feb9b091ce
>     and is silently broken somewhere around 72ac876248ca2d33b3e1170b2f86fb68daaacdc8
> 
> 2)
>   If you start qemu with qemu-system-x86_64 -nographic
>   you normally get no output until you ctrl-a c at which
>   you get a banner and then a (qemu) prompt, however with current
>   head, at startup you get:
>    ./x86_64-softmmu/qemu-system-x86_64 -nographic
>    QEMU 2.7.50 monitor - type 'help' for more information
>    (qemu) 
> 
>    and although it gives you a prompt it's not responsive, so you
>    ctrl-ac and then you get a :
>    QEMU 2.7.50 monitor - type 'help' for more information
>    QEMU 2.7.50 monitor - type 'help' for more information
>    (qemu) 
>  
>    and it works - but you've got the extra banner.
> 
>    It's fine at 6dfa8298faa0fce47c68659fd4d92e76745d4edb
>    ecb672d14f092f481000ac9cd9d7dc0500692eba is broken but a bit differently
>    94a40fc56036b5058b0b194d9e372a22e65ce7be doesn't build (!)

This one is easy.  Marc-André, can you look at (1)? :)

Paolo

Re: [Qemu-devel] Problems with recent char changes (mux, slirp)

[Dr. David Alan Gilbert]

* Paolo Bonzini (pbonzini@redhat.com) wrote:
> 
> 
> On 27/10/2016 13:52, Dr. David Alan Gilbert wrote:
> > Hi Marc-André,
> >   I've got a bunch of different failures in current head
> > that seem to bisect down to your recent char changes.
> > 
> > Lets start with the main symptoms;
> > 1)
> >   Slirp guestfwd is broken, start an nc with:
> >       nc -l 127.0.0.1 4444
> >     and then qemu with:
> >     -netdev user,id=unet,guestfwd=tcp:10.0.2.50:4444-tcp:localhost:4444 -device e1000,netdev=unet 
> > 
> >     and from the guest do:
> >     seq 1 10000000 | nc 10.0.2.50 4444 &
> >     you should get a spew of numbers coming out of nc  but on current
> >     head it does nothing.
> > 
> >     This seems to work at becdfa00cfa2995e859ccefa4b7d72a72eb96581
> >     but segs by 386f07d1fc02fb4316039994b855c4feb9b091ce
> >     and is silently broken somewhere around 72ac876248ca2d33b3e1170b2f86fb68daaacdc8
> > 
> > 2)
> >   If you start qemu with qemu-system-x86_64 -nographic
> >   you normally get no output until you ctrl-a c at which
> >   you get a banner and then a (qemu) prompt, however with current
> >   head, at startup you get:
> >    ./x86_64-softmmu/qemu-system-x86_64 -nographic
> >    QEMU 2.7.50 monitor - type 'help' for more information
> >    (qemu) 
> > 
> >    and although it gives you a prompt it's not responsive, so you
> >    ctrl-ac and then you get a :
> >    QEMU 2.7.50 monitor - type 'help' for more information
> >    QEMU 2.7.50 monitor - type 'help' for more information
> >    (qemu) 
> >  
> >    and it works - but you've got the extra banner.
> > 
> >    It's fine at 6dfa8298faa0fce47c68659fd4d92e76745d4edb
> >    ecb672d14f092f481000ac9cd9d7dc0500692eba is broken but a bit differently
> >    94a40fc56036b5058b0b194d9e372a22e65ce7be doesn't build (!)
> 
> This one is easy.  Marc-André, can you look at (1)? :)

I'm not sure if it helps diagnose it, but I think incoming
traffic from the outsideinto the guest is still working, it's
just outgoing traffic that seems to be blocked.

Dave

> 
> Paolo
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] Problems with recent char changes (mux, slirp)

[Paolo Bonzini]

On 27/10/2016 19:51, Dr. David Alan Gilbert wrote:
> > This one is easy.  Marc-André, can you look at (1)? :)
>
> I'm not sure if it helps diagnose it, but I think incoming
> traffic from the outsideinto the guest is still working, it's
> just outgoing traffic that seems to be blocked.

Turns out it was even easier, just a void* screwup.  Sent a patch now.

Paolo