Re: [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 (address@hidden, 
    address@hidden)
    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 <address@hidden> 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
> > > 
> 
>