Re: [Qemu-devel] [Qemu-discuss] How to select specific qemu net 'nic' device

Re: [Qemu-devel] [Qemu-discuss] How to select specific qemu net 'nic' device

[Peter Maydell]

On 23 November 2018 at 04:13, mbilal <muhammad_bilal@mentor.com> wrote:
> Hi,
>
> I'm using qemu emulation for xilinx zcu102 platform, this board have four
> networking GEM0, GEM1, GEM2 and GEM3 devices.
>
> To run network demo on this board *only* require GEM3 device to be configure
> while other GEM devices don't need to be configure, that's why u-boot and
> other RTOS only configure GEM3 device.
>
>
> QEMU is enabling these GEM devices  with networking '-net nic' option and
> QEMU consider first '-net nic' option for GEM0 and second '-net nic' option
> for GEM1 and so on. that's why if need to enable GEM3 network device we must
> need to give following full command line options
>
> -net nic -net nic -net nic -net nic -net user, ...
>
> In this way all four GEM devices would be enable but first three GEM0-GEM2
> devices are un-configured and useless. In our case QEMU is being *crashed*
> due to trying to use these un-configured GEM devices to o send/receive GDB
> breakoint/interrupt cause. IIUC QEMU uses first device in the -nic loop
> i.e
>
> qemu-system-aarch64: hw/net/cadence_gem.c:921: gem_receive: Assertion
> `!first_desc' failed.

If QEMU asserts like this, this is a bug in QEMU. I've cc'd
the maintainers of the Xilinx board.

Could you provide a complete set of instructions to reproduce
this bug, please ? (full command line, guest image, etc)

Could you also tell us which version of QEMU you are using?
If possible, try with the current git master or
with the 3.1 rc2 release candidate we've just put out, to
see if it's already been fixed.

thanks
-- PMM

Re: [Qemu-devel] [Qemu-discuss] How to select specific qemu net 'nic' device

[Edgar E. Iglesias]

On Fri, Nov 23, 2018 at 02:59:32PM +0500, mbilal wrote:
> Hi,
> 
> Thanks for reply.
> 
> According to your suggestion I've tested with 3.1 rc2 release and problem is
> still exist in this release also.
> 
> Here is my reproducible scenario.


Thanks,

I've had a look and the assert looks bogus to me.
We shouldn't be asserting on RX descriptor setups when the receiver is disabled.

I'll send a patch in a moment.

Best regards,
Edgar



> 
> QEMU launching
> --------------
> 
> ./qemu-system-aarch64 -M xlnx-zcu102 -m 1G -kernel /dev/null -S -s  -net nic
> -net nic -net nic -net nic -net user,hostfwd=tcp::8080-:8080 -smp 1 -serial
> stdio -serial /dev/null
> 
> gdb session
> ------------
> 
> (gdb) file zcu102_net_uni.out
> Reading symbols from zcu102_net_uni.out...done.
> (gdb) tar rem :1234
> Remote debugging using :1234
> _ld_text_start () at os/arch/armv8/common/arch_asm.S:381
> 381	    MOV     X14, X0
> (gdb) load
> Loading section .text, size 0x59c0c lma 0x0
> Loading section .rodata, size 0x2bbc lma 0x59c0c
> Loading section .rtl.data, size 0x770 lma 0x5c7c8
> Loading section .data, size 0x4dc lma 0x5cf54
> Start address 0x0, load size 381972
> Transfer rate: 23313 KB/sec, 2021 bytes/write.
> (gdb) c
> Continuing.
> ^C
> 
> 
> So any breakpoint or Ctrl-C asserts the QEMU.
> 
> qemu-system-aarch64: qemu-3.1.0-rc2/hw/net/cadence_gem.c:982: gem_receive:
> Assertion `!first_desc' failed.
> 
> 
> Our networking demo application running fine unless you interrupt the GDB
> (either with breakpoints or interrupt signal).
> You can see following message on QEMU console which is the indication of
> demo is fine (it also well tested on actual hardware)
> 
> Open the following Nucleus node address in your web browser:
>     http://127.0.0.1:8080/
> 
> 
> I'm attaching demo application binary.
> 
> 
> 
> 
> Thanks for care about this issue,
> -Bilal
> 
> 
> 
> On 11/23/2018 01:59 PM, Peter Maydell wrote:
> > On 23 November 2018 at 04:13, mbilal <muhammad_bilal@mentor.com> wrote:
> > > Hi,
> > > 
> > > I'm using qemu emulation for xilinx zcu102 platform, this board have four
> > > networking GEM0, GEM1, GEM2 and GEM3 devices.
> > > 
> > > To run network demo on this board *only* require GEM3 device to be configure
> > > while other GEM devices don't need to be configure, that's why u-boot and
> > > other RTOS only configure GEM3 device.
> > > 
> > > 
> > > QEMU is enabling these GEM devices  with networking '-net nic' option and
> > > QEMU consider first '-net nic' option for GEM0 and second '-net nic' option
> > > for GEM1 and so on. that's why if need to enable GEM3 network device we must
> > > need to give following full command line options
> > > 
> > > -net nic -net nic -net nic -net nic -net user, ...
> > > 
> > > In this way all four GEM devices would be enable but first three GEM0-GEM2
> > > devices are un-configured and useless. In our case QEMU is being *crashed*
> > > due to trying to use these un-configured GEM devices to o send/receive GDB
> > > breakoint/interrupt cause. IIUC QEMU uses first device in the -nic loop
> > > i.e
> > > 
> > > qemu-system-aarch64: hw/net/cadence_gem.c:921: gem_receive: Assertion
> > > `!first_desc' failed.
> > 
> > If QEMU asserts like this, this is a bug in QEMU. I've cc'd
> > the maintainers of the Xilinx board.
> > 
> > Could you provide a complete set of instructions to reproduce
> > this bug, please ? (full command line, guest image, etc)
> > 
> > Could you also tell us which version of QEMU you are using?
> > If possible, try with the current git master or
> > with the 3.1 rc2 release candidate we've just put out, to
> > see if it's already been fixed.
> > 
> > thanks
> > -- PMM
> > 

Re: [Qemu-devel] [Qemu-discuss] How to select specific qemu net 'nic' device

[Edgar E. Iglesias]

On Fri, Nov 23, 2018 at 02:20:17PM +0100, Edgar E. Iglesias wrote:
> On Fri, Nov 23, 2018 at 02:59:32PM +0500, mbilal wrote:
> > Hi,
> > 
> > Thanks for reply.
> > 
> > According to your suggestion I've tested with 3.1 rc2 release and problem is
> > still exist in this release also.
> > 
> > Here is my reproducible scenario.
> 
> 
> Thanks,
> 
> I've had a look and the assert looks bogus to me.
> We shouldn't be asserting on RX descriptor setups when the receiver is disabled.
> 
> I'll send a patch in a moment.
> 
> Best regards,
> Edgar

+ Jason

Hi,

I've sent a patch to fix te GEM model.
The assert in the GEM model was wrong IMO but I also think the net layer
is behaving a bit suspicious in this case. The qemu_flush_or_purge_queued_packets()
path is delivering queued packets to a net model without checking can_receive().
Without digging too much into the details my gut feeling is that the net layer
shouldn't be doing this. I may be missing something though.

Here's the backtrace:
(gdb) bt
#0  0x00007ffff39e0e97 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff39e2801 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff39d239a in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff39d2412 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x0000555555b47de6 in gem_receive (nc=<optimized out>, 
    buf=<optimized out>, size=346)
    at /home/edgar/src/c/qemu/qemu/hw/net/cadence_gem.c:982
#5  0x0000555555bf033d in nc_sendv_compat (flags=<optimized out>, iovcnt=1, 
    iov=0x7fffffffd620, nc=0x555556edd360)
    at /home/edgar/src/c/qemu/qemu/net/net.c:701
#6  qemu_deliver_packet_iov (sender=<optimized out>, flags=<optimized out>, 
    iov=0x7fffffffd620, iovcnt=1, opaque=0x555556edd360)
    at /home/edgar/src/c/qemu/qemu/net/net.c:733
#7  0x0000555555bf2a85 in qemu_net_queue_deliver (size=<optimized out>, 
    data=<optimized out>, flags=<optimized out>, sender=<optimized out>, 
    queue=0x555556edd4e0) at /home/edgar/src/c/qemu/qemu/net/queue.c:164
#8  qemu_net_queue_flush (queue=0x555556edd4e0)
    at /home/edgar/src/c/qemu/qemu/net/queue.c:261
#9  0x0000555555bf0d3c in qemu_flush_or_purge_queued_packets (
    nc=0x555556edd360, purge=<optimized out>)
    at /home/edgar/src/c/qemu/qemu/net/net.c:607
#10 0x0000555555bf0dd9 in net_vm_change_state_handler (opaque=<optimized out>, 
    running=0, state=<optimized out>)
    at /home/edgar/src/c/qemu/qemu/net/net.c:1423
#11 0x0000555555a641c7 in vm_state_notify (running=running@entry=0, 
    state=state@entry=RUN_STATE_SHUTDOWN)
    at /home/edgar/src/c/qemu/qemu/vl.c:1562
#12 0x0000555555889b0a in do_vm_stop (state=RUN_STATE_SHUTDOWN, 
    send_stop=<optimized out>) at /home/edgar/src/c/qemu/qemu/cpus.c:1074
#13 0x0000555555844200 in main (argc=<optimized out>, argv=<optimized out>, 
    envp=<optimized out>) at /home/edgar/src/c/qemu/qemu/vl.c:4648
(gdb) q


Cheers,
Edgar


> 
> 
> 
> > 
> > QEMU launching
> > --------------
> > 
> > ./qemu-system-aarch64 -M xlnx-zcu102 -m 1G -kernel /dev/null -S -s  -net nic
> > -net nic -net nic -net nic -net user,hostfwd=tcp::8080-:8080 -smp 1 -serial
> > stdio -serial /dev/null
> > 
> > gdb session
> > ------------
> > 
> > (gdb) file zcu102_net_uni.out
> > Reading symbols from zcu102_net_uni.out...done.
> > (gdb) tar rem :1234
> > Remote debugging using :1234
> > _ld_text_start () at os/arch/armv8/common/arch_asm.S:381
> > 381	    MOV     X14, X0
> > (gdb) load
> > Loading section .text, size 0x59c0c lma 0x0
> > Loading section .rodata, size 0x2bbc lma 0x59c0c
> > Loading section .rtl.data, size 0x770 lma 0x5c7c8
> > Loading section .data, size 0x4dc lma 0x5cf54
> > Start address 0x0, load size 381972
> > Transfer rate: 23313 KB/sec, 2021 bytes/write.
> > (gdb) c
> > Continuing.
> > ^C
> > 
> > 
> > So any breakpoint or Ctrl-C asserts the QEMU.
> > 
> > qemu-system-aarch64: qemu-3.1.0-rc2/hw/net/cadence_gem.c:982: gem_receive:
> > Assertion `!first_desc' failed.
> > 
> > 
> > Our networking demo application running fine unless you interrupt the GDB
> > (either with breakpoints or interrupt signal).
> > You can see following message on QEMU console which is the indication of
> > demo is fine (it also well tested on actual hardware)
> > 
> > Open the following Nucleus node address in your web browser:
> >     http://127.0.0.1:8080/
> > 
> > 
> > I'm attaching demo application binary.
> > 
> > 
> > 
> > 
> > Thanks for care about this issue,
> > -Bilal
> > 
> > 
> > 
> > On 11/23/2018 01:59 PM, Peter Maydell wrote:
> > > On 23 November 2018 at 04:13, mbilal <muhammad_bilal@mentor.com> wrote:
> > > > Hi,
> > > > 
> > > > I'm using qemu emulation for xilinx zcu102 platform, this board have four
> > > > networking GEM0, GEM1, GEM2 and GEM3 devices.
> > > > 
> > > > To run network demo on this board *only* require GEM3 device to be configure
> > > > while other GEM devices don't need to be configure, that's why u-boot and
> > > > other RTOS only configure GEM3 device.
> > > > 
> > > > 
> > > > QEMU is enabling these GEM devices  with networking '-net nic' option and
> > > > QEMU consider first '-net nic' option for GEM0 and second '-net nic' option
> > > > for GEM1 and so on. that's why if need to enable GEM3 network device we must
> > > > need to give following full command line options
> > > > 
> > > > -net nic -net nic -net nic -net nic -net user, ...
> > > > 
> > > > In this way all four GEM devices would be enable but first three GEM0-GEM2
> > > > devices are un-configured and useless. In our case QEMU is being *crashed*
> > > > due to trying to use these un-configured GEM devices to o send/receive GDB
> > > > breakoint/interrupt cause. IIUC QEMU uses first device in the -nic loop
> > > > i.e
> > > > 
> > > > qemu-system-aarch64: hw/net/cadence_gem.c:921: gem_receive: Assertion
> > > > `!first_desc' failed.
> > > 
> > > If QEMU asserts like this, this is a bug in QEMU. I've cc'd
> > > the maintainers of the Xilinx board.
> > > 
> > > Could you provide a complete set of instructions to reproduce
> > > this bug, please ? (full command line, guest image, etc)
> > > 
> > > Could you also tell us which version of QEMU you are using?
> > > If possible, try with the current git master or
> > > with the 3.1 rc2 release candidate we've just put out, to
> > > see if it's already been fixed.
> > > 
> > > thanks
> > > -- PMM
> > > 
> 
>