Memory synchronization error between kvm and target, e1000(dpdk)

[Leonid Myravjev]

Hi folks.

I use linux with dpdk drivers on the target system, and e1000 emulation device with tap interface for host. I use kvm for accelerate.
Version qemu 4.0.94 and master (Nov 12 10:14:33 2019)
Version dpdk stable-17.11.4
Version linux host 4.15.0-66-generic (ubuntu 18.04)

I type command "ping <target ip> -f" and wait about 1-2 minutes. Network subsystem freezes.

For receive the eth pack from host system (tap interface) to host system the e1000 using ring buffer.

The e1000 write body of eth pack, set E1000_RXD_STAT_DD flag and move RDH (Ring Device Head).
(file hw/net/e1000.c function e1000_receive_iov() )

The dpdk driver is reading from E1000_RXD_STAT_DD flags (ignoring RDH), if flag is set: read buffer, unset flag E1000_RXD_STAT_DD and move RDT (Ring Device Tail).
(source drivers/net/e1000/em_rxtx.c function eth_em_recv_scattered_pkts() )

I see what the driver unet E1000_RXD_STAT_DD (rxdp->status = 0; ), but sometimes rxdp->status remains equal to 7. On the next cycle, this this buffer is read, RDT moved to far. RDH becomes equal RDT and network is freezes.

If I insert some delay after unset E1000_RXD_STAT_DD, and repeatedly unset E1000_RXD_STAT_DD (if rxdp->status == 7 ), then all work fine.
If check E1000_RXD_STAT_DD without delay, status rxdp->status always valid.

This only appears on kvm. If I use tcg all works fine.

I trying set watchpoint for memory on the qemu (for tcg), and see, that for one package cycle of set/unse STAT_DD repeated once.

I trying set watchpoint for memory on the qemu (for kvm), and see, that rxdp->status changed to 0(unset) only once, but is changes immediately before set flag.

Please help me with advice on how to catch and fix this error.
Theoretically, it would help me to trace the memory access when writing to E1000_RXD_STAT_DD, RHD and RDT, both from the target and the host system. But I have no idea how this can be done.

[Thomas Huth (th-huth)]

The QEMU project is currently considering to move its bug tracking to
another system. For this we need to know which bugs are still valid
and which could be closed already. Thus we are setting older bugs to
"Incomplete" now.

If you still think this bug report here is valid, then please switch
the state back to "New" within the next 60 days, otherwise this report
will be marked as "Expired". Or please mark it as "Fix Released" if
the problem has been solved with a newer version of QEMU already.

Thank you and sorry for the inconvenience.

[Launchpad Janitor (janitor)]

[Expired for QEMU because there has been no activity for 60 days.]