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

[Jason Wang <jasowang@redhat.com>]

On 2016年05月26日 23:08, Peter Maydell wrote:
> On 26 May 2016 at 03:16, Jason Wang <jasowang@redhat.com> 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
>                ^

Sorry for the trouble again. Wonder the correct way to enable sanitizer, 
after I add "-fsanitizer=address", it produces tons of warnings and 
errors but don't find the above outputs.

> 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.

I agree.

>
> 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

Leonid and Dmitry, please check the guest memory access as suggested 
above and respin the series. I will hold the pull until the new version.

Thanks