[dpdk-dev] bug: virtio PMD sends malformed packets for 32-bit processes on 64-bit kernel

[Tan, Jianfeng]

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