Le 18/12/2015 07:51, Chen Gang a écrit :
>
> I found this issue during my working time, it is about sw_64 (almost the
> same as alpha) host running i386 wine programs.
>
> I also found another issue, but I am not quite sure whether it is worth
> enough for our upstream: The related fix patch is below, which will let
> the initialization slower, but for most archs, they have no this issue.
>
> linux-user/mmap.c: Always zero MAP_ANONYMOUS memory in target_mmap()
>
> In some architectures, they have no policy to zero MAP_ANONYMOUS memory,
> which will cause issue for qemu target_mmap.
>
> Signed-off-by: Chen Gang <gang.chen.5...@gmail.com>
>
> diff --git a/linux-user/mmap.c b/linux-user/mmap.c
> index 7b459d5..9c9152d 100644
> --- a/linux-user/mmap.c
> +++ b/linux-user/mmap.c
> @@ -567,6 +567,10 @@ abi_long target_mmap(abi_ulong start, abi_ulong len, int
> prot,
> printf("\n");
> #endif
> tb_invalidate_phys_range(start, start + len);
> + if ((prot & PROT_WRITE) && (flags & MAP_ANONYMOUS)
> + && ((flags & MAP_PRIVATE) || (fd == -1))) {
> + memset(g2h(start), 0, len);
> + }
IMHO, their kernel needs a fix, mmap(2):
MAP_ANONYMOUS
The mapping is not backed by any file; its contents are initial‐
ized to zero.
> mmap_unlock();
> return start;
> fail:
>
>
> Thanks.
Laurent
