From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id F3190F94 for ; Fri, 23 Jun 2017 17:36:29 +0200 (CEST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jun 2017 08:36:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,378,1493708400"; d="scan'208";a="118068872" Received: from tanjianf-mobl.ccr.corp.intel.com (HELO [10.255.30.157]) ([10.255.30.157]) by fmsmga005.fm.intel.com with ESMTP; 23 Jun 2017 08:36:27 -0700 To: Frederico Cadete , "yuanhan.liu@linux.intel.com" , "maxime.coquelin@redhat.com" References: <1498143499.8893.38.camel@oneaccess-net.com> Cc: John Sucaet , "dev@dpdk.org" From: "Tan, Jianfeng" Message-ID: Date: Fri, 23 Jun 2017 23:36:26 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1498143499.8893.38.camel@oneaccess-net.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] bug: virtio PMD sends malformed packets for 32-bit processes on 64-bit kernel X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 15:36:30 -0000 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