Re: [Qemu-devel] [PULL V3 00/20] Net patches

[Peter Maydell]

On 26 May 2016 at 03:16, Jason Wang <address@hidden> wrote:
> The following changes since commit 287db79df8af8e31f18e262feb5e05103a09e4d4:
>
>   Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into 
> staging (2016-05-24 13:06:33 +0100)
>
> are available in the git repository at:
>
>   https://github.com/jasowang/qemu.git tags/net-pull-request
>
> for you to fetch changes up to 136796b070ddd09dd14ef73e77ae20419ba6554a:
>
>   net/net: Add SocketReadState for reuse codes (2016-05-26 09:58:22 +0800)
>
> ----------------------------------------------------------------
>
> Main changes:
> - e1000e emulation
> - convet vmxnet3 to use DMA api
> Changes from V2:
> - fix clang build
> Changes from V1:
> - fix 32bit build

Hi. I'm afraid this introduces new errors in the clang sanitizer output
from make check: all the check-qtest-i386 and check-qtest-x86_64
runs produce output like:

/home/petmay01/linaro/qemu-for-merges/hw/pci/pcie.c:641:25: runtime
error: left shift of 4092 by 20 places cannot be
 represented in type 'int'
/home/petmay01/linaro/qemu-for-merges/hw/pci/pcie.c:642:45: runtime
error: left shift of 4092 by 20 places cannot be
 represented in type 'int'
==14902==WARNING: Trying to symbolize code, but external symbolizer is
not initialized!
/home/petmay01/linaro/qemu-for-merges/include/qemu/bswap.h:120:1:
runtime error: store to misaligned address 0x2b23c01e6674 for type
'uint64_t' (aka 'unsigned long'), which requires 8 byte alignment
0x2b23c01e6674: note: pointer points here
  03 00 01 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00
00 00  00 00 00 00 00 00 00 00
              ^

The stuff about left shifts is just the usual shift-into-sign-bit
which we haven't yet sorted out what we're doing with (ie
whether we can ignore them and shut up the sanitizer without
silencing other interesting warnings), but we shouldn't be doing
misaligned stores of 64-bit values.

Apologies for the lack of any backtraces in the output, but
this is almost certainly the result of trying to do le64_to_cpu()
or cpu_to_le64() on a buffer which isn't necessarily aligned
(usually some pointer into guest memory). Use the functions
ldq_le_p() and stq_le_p() instead, which will handle a
potentially misaligned pointer for you. (There are similar
functions for other access widths too.)

thanks
-- PMM