Re: [Qemu-devel] [PATCH] linux-user: Add TARGET_MAP_STACK and TARGET_MAP_HUGETLB for all remaining architectures

[Helge Deller]

On 11.03.2017 22:53, Richard Henderson wrote:
> On 03/12/2017 04:30 AM, Helge Deller wrote:
>> Add the missing defines and for TARGET_MAP_STACK and TARGET_MAP_HUGETLB
>> for alpha, mips, ppc and x86, and fix the mmap_flags translation table
>> to translate those flags between host and target architecture.
>>
>> Signed-off-by: Helge Deller <address@hidden>
>>
>> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
>> index cec8428..03ed370 100644
>> --- a/linux-user/syscall.c
>> +++ b/linux-user/syscall.c
>> @@ -5875,6 +5875,8 @@ static bitmask_transtbl mmap_flags_tbl[] = {
>>      { TARGET_MAP_LOCKED, TARGET_MAP_LOCKED, MAP_LOCKED, MAP_LOCKED },
>>          { TARGET_MAP_NORESERVE, TARGET_MAP_NORESERVE, MAP_NORESERVE,
>>            MAP_NORESERVE },
>> +    { TARGET_MAP_STACK, TARGET_MAP_STACK, MAP_STACK, MAP_STACK },
>> +    { TARGET_MAP_HUGETLB, TARGET_MAP_HUGETLB, MAP_HUGETLB, MAP_HUGETLB },
> 
> I don't see any point in this. First, MAP_STACK is ignored by the
> kernel, and has been for some time. 

Yes, the kernel ignores the native MAP_STACK define.

> Second, the size of huge pages varies widely between different targets,
> and we're not really able to map the sizes between guest and host.

This might probably not be necessary, if the userspace app simply asks
which huge page sizes are supported (e.g. by procfs entries or via 
"hugeadm --page-sizes-all").

But the main intention of my patch was not to fix MAP_STACK or MAP_HUGETLB,
but more to ensure that those flags are avoided to be handed over to the host.
For example, TARGET_MAP_STACK is 0x40000 on hppa, and if it's not filtered out
in e.g. a mmap() call, then this becomes to MAP_HUGETLB on x86_64 (which is 
0x40000 on x86_64).  

Helge