On Tue, Sep 19, 2017 at 7:17 PM, Tan, Jianfeng <jianfeng....@intel.com> wrote:
> Hi Jim, > > > -----Original Message----- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jim Murphy > > Sent: Wednesday, September 20, 2017 6:24 AM > > To: dev@dpdk.org > > Subject: [dpdk-dev] [PATCH v2] net/virtio-user: fix not working on 32-bit > > system > > > > Hi, > > > > The fix contained in this patch breaks under the following scenario: > > > > 1. A 64 bit host and virtual machine. Therefore all physical addresses > are > > 64 bits. > > Host, VM and application are 64bit, then I suppose there's no problem? > Right, no problem. I was just describing this as my setup. > > > 2. A 32 bit user mode DPDK process running on a 64 bit virtual machine > (64 > > bit kernel). > > Ah, this is a case we fail to cover. > Yes. > > > > In this case, the physical address is 64bits but the virtual address of > the > > user process is 32 bits so uintptr_t is only 32 bits. As a result when: > > > > (uintptr_t)(mb) + (vq)->offset) > > > > is referenced, only 32 bits are copied into the descriptor but 64 bits > are > > required because in this scenario that is the size of a physical address. > > > > So it seems like we need a way to determine the size of the physical > > address and then VIRTIO_MBUF_ADDR should be written to copy that many > > bytes > > into the uint64_t. Does anyone know how to determine the size of the > > physical address? > > It's easy to find a way to decide the length (similar to _offset_), but > copying variable length of bytes seems not an efficient way. > > I agree regarding the efficiency issue. To get something at compile time does RTE_MACHINE or something derived from it help us? Thanks, Jim Thanks, > Jianfeng > >
