On Mon, May 24, 2010 at 08:45:31AM -0700, Richard Henderson wrote: > On 05/24/2010 07:57 AM, Edgar E. Iglesias wrote: > > I took a look at the code again and I dont really understand how the > > particular case when we get a high address from the kernel while > > mmap_min_addr is busy case is supposed to work :/ > > In fact, for CRIS it never works on my host. > > Indeed, there are many cases for which it doesn't work for the Alpha > target either.
Ye, what puzzled me was that if I am not completely senile, CRIS apps used to emulate on my x86_64 host not so long ago :) > > I changed it locally to keep scanning after a wrap until we succeed to > > allocate a chunk or rewrap (SLOW) but at least I can run dynamically > > linked CRIS programs again. > > Yep. My hack had been similar, except that I used the PageDesc tree > to help speed things up. But PageDesc is hardly an ideal data structure > in which to search, since it quickly devolves into a linear search of > the address space. > > Probably the easiest real fix is to re-read /proc/self/maps each time > the mmap_next_start guess fails and the kernel's returned address is > out of range. > > Another is using the MMAP_32BIT flag on x86-64 host whenever a 31-bit > address is appropriate for the guest. E.g. mips32, where architecturally > the high half of the address space is reserved for kernel mode. MAP_32BIT sounds good as long as guest_base is not used. When used I guess we'd need to fallback to something else anyway.. Maybe these issues are something too look more at during the bug day? :) In the meantime, I've patched the cris git to use the MAP_32BIT and to fallback to a super ugly and slow linear scan.. Thanks again for the help, Cheers > See > http://www.mail-archive.com/qemu-devel@nongnu.org/msg28924.html > for more ideas on the subject. > > > > r~
