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

[mbilal]

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.



My question is that, is there a way in QEMU to only select/enable GEM3
device while other don't use in emulation ?


If there is no such option to select specific device then what do you
thing, this shouldn't be in qemu?



Thanks,
-Bilal

[Peter Maydell]

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

[Edgar E. Iglesias]

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.
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)
http://127.0.0.1:8080/
I'm attaching demo application binary.
Thanks for care about this issue,
-Bilal

Post by Peter Maydell

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

[Edgar E. Iglesias]

Post by mbilal

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=***@entry=0,
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

Post by mbilal

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.
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)
http://127.0.0.1:8080/
I'm attaching demo application binary.
Thanks for care about this issue,
-Bilal

Post by Peter Maydell

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