In article <4bb2540b.90...@twiddle.net> you write:
>On 03/30/2010 12:16 PM, Juergen Lock wrote:
>> I first tried to replace the endaddr in the !h2g_valid(endaddr) case with
>> ((abi_ulong)1 << L1_MAP_ADDR_SPACE_BITS) - 1
>> if TARGET_ABI_BITS > L1_MAP_ADDR_SPACE_BITS (which comes from the condition
>> of the assert in page_set_flags() that was triggered on the ~0ul value),
>> but that caused the qemu process to grow into swap and made the box
>> usuable when that code was reached and I had to kill qemu. (The box has
>> 8 GB RAM.) And so I thought just leaving that page range unprotected
>> if only the start address is valid was the lesser evil...
>
>What's are the real arguments to the page_set_flags that causes things
>to go into swap? I can't imagine the range really being so large that
>it causes massive allocation within that function...
Oh sorry if that was not clear, things go into swap if I _replace_ the
endaddr ~0ul (which caused the assert) with the max value the assert
still tolerates i.e.
((abi_ulong)1 << L1_MAP_ADDR_SPACE_BITS) - 1
which in this case seems to be 0x7fffffffffff:
#3 0x0000000060012731 in page_set_flags (start=140737488224256,
end=18446744073709551615, flags=32)
at
/usr/ports/emulators/qemu-devel-20100323a/work/qemu-snapshot-20100323_20/exec.c:2426
2426 assert(end < ((abi_ulong)1 << L1_MAP_ADDR_SPACE_BITS));
(gdb) i li 2426
Line 2426 of
"/usr/ports/emulators/qemu-devel-20100323a/work/qemu-snapshot-20100323_20/exec.c"
starts at address 0x60012662 <page_set_flags+34>
and ends at 0x60012675 <page_set_flags+53>.
(gdb) disassemble 0x60012662 0x60012675
Dump of assembler code from 0x60012662 to 0x60012675:
0x0000000060012662 <page_set_flags+34>: mov $0x7fffffffffff,%rax
^^^^^^^^^^^^^^
0x000000006001266c <page_set_flags+44>: cmp %rax,%rsi
0x000000006001266f <page_set_flags+47>: ja 0x60012718 <page_set_flags+216>
End of assembler dump.
(gdb) q
Cheers,
Juergen
