Re: [Qemu-devel] qemu git head 20100323 on FreeBSD - qemu-devel port update for testing

[Juergen Lock]

On Tue, Mar 30, 2010 at 10:09:47PM +0200, Juergen Lock wrote:
> In article <address@hidden> 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

Ok sorry about the confusion, this is a different problem, I just looked
at the value of start, it seems to be:

(gdb) p start
$2 = 0x7ffffffe0000

 So I'd say the real problem is page_set_flags() has a bug that makes
it allocate too much if the range is the last allowed page...

 Cheers,
        Juergen