Hi Cadete,
On 6/22/2017 10:58 PM, Frederico Cadete wrote:
Hello, I believe commit 260aae9a [1] has introduced a regression for the case of 32-bit process running on a 64-bit kernel. The commit is effectively casting mbuf->buf_physaddr to uintptr_t before dereferencing it. It truncates the physical address to the width of the process's uint, and in the the aforementioned combination this loses important bits. I can confirm this under GDB. When virtqueue_enqueue_xmit is filling in start_dp, I get this result: (gdb) p /x cookie->buf_physaddr $5 = 0x12f94a000 (gdb) p /x start_dp[idx].addr $6 = 0x2f94a080
Now you are testing a virtio-pci device and app is compiled into a 32-bit executable on 64-bit VM system?
On my system, I capture the packet that goes out to the host and I see it has the correct size but the content is all-zeroes. I would like to propose a patch that would work for all supported combinations of user/kernel bitwidth *and* virtio-pci/virtio-user. But I don't really see how that could work, given virtio-user tries to store a physical address in rte_mbuf's "void *buf_addr", and this is not always big enough for a physical address.
virtio-user does not store a physical address in rte_mbuf's "void *buf_addr", instead, it uses this field in rte_mbuf to fill desc's addr which is always 64bit long.
Any suggestions on if and how this could be fixed? Meanwhile, the bug affects dpdk 17.05, 17.02.1 and master. Users not requiring virtio-user support can avoid it by setting CONFIG_VIRTIO_USER=n during compilation. Best regards, Frederico Cadete
