qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 1/1] linux-user: Probe the guest base for sh


From: Meador Inge
Subject: Re: [Qemu-devel] [RFC PATCH 1/1] linux-user: Probe the guest base for shared objects when needed
Date: Wed, 27 Jun 2012 21:10:50 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0

On 06/27/2012 07:47 PM, Paul Brook wrote:

>> On 28.06.2012, at 02:06, Paul Brook wrote:
>>>>> openSUSE uses a version patched so that IIUC 3G are reserved.
>>>>> Just today this failed on a system where swap got disabled and the
>>>>> mmap() thus failed.
>>>>
>>>> Err... why?  We map with MAP_NORESERVE, so swap shouldn't matter...
>>>
>>> I can't say if it's the same cause, but we fail with "ulimit -v 4046848".
>>>
>>> Incidentally, it seems a strange that we only reserve 0xf7000000 bytes,
>>> not the full 4G.
>>
>> Uh, I think that was because of the vdso shared page that is allocated on
>> top of -R.
> 
> That can't be right.  The whole point of -R is that it defines all the guest 
> accessible virtual address space.  The surrounding space is liable to be used 
> by something else, and we must not make any assumptions about it.
> 
> Further inspection shows that guest_validate_base contains some extremely 
> bogus code.
> 
> If the guest needs something at the top of its address space then we need to 
> offset address zero within the block, and ensure accesses wrap appropriately.

'guest_validate_base' is currently called for three reasons: (1) in main.c
when using -B, (2) in main.c when using -R after mapping the reserved va
region, and (3) and when probing for a guest base in probe_guest_base.

For case (1) I suppose things are pretty much the same -- we just need to map
the extra region when needed (e.g. for the ARM kernel helpers).

For case (2) maybe we can do a probing similar to what I mentioned here [1],
but taking into account what you stated above and ensuring that the probing
finds a single region for the request va region size and any needed extra stuff.

Case (3) is mostly the same as (2) but we are probing for a guest base with a
region size deduced from looking at the image we are loading.  I suppose it is
still OK to map two regions here.  The single region only applies to -R?

Thoughts?

[1] http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg04589.html

-- 
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software



reply via email to

[Prev in Thread] Current Thread [Next in Thread]