[dpdk-dev] [PATCH v2] net/virtio-user: fix not working on 32-bit system

[Jim Murphy]

On Tue, Sep 19, 2017 at 7:17 PM, Tan, Jianfeng <jianfeng.tan at intel.com>
wrote:

> Hi Jim,
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jim Murphy
> > Sent: Wednesday, September 20, 2017 6:24 AM
> > To: dev at 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
>
>