Re: [Qemu-devel] [PATCH] configure: Support system emulation with large memory on w32 hosts

[Stefan Weil <sw@weilnetz.de>]

Am 20.07.2012 08:38, schrieb Alexey Kardashevskiy:
> On 20/07/12 16:05, Alexey Kardashevskiy wrote:
>> On 20/07/12 15:37, Alexey Kardashevskiy wrote:
>>> On 20/07/12 15:23, Stefan Weil wrote:
>>>> Am 20.07.2012 05:53, schrieb Alexey Kardashevskiy:
>>>>> On 19/07/12 02:37, Stefan Weil wrote:
>>>>>> 32-bit applications on Windows normally only get virtual memory in
>>>>>> the lower 2 GiB address space.
>>>>>>
>>>>>> Because of memory fragmentation, VirtualAlloc() usually won't get 1 GiB
>>>>>> of contiguous virtual memory in that address space. Therefore running
>>>>>> system emulations with 1 GiB or more RAM will abort with a failure.
>>>>>>
>>>>>> The linker flag --large-address-aware allows addresses in the upper 2 GiB.
>>>>>> With this flag, it is possible to run emulated machines with up to
>>>>>> 2047 MiB RAM.
>>>>>>
>>>>>> Signed-off-by: Stefan Weil<sw@weilnetz.de>
>>>>>> ---
>>>>>>
>>>>>> I tested the executables with large address awareness on a 64 bit Windows
>>>>>> (works) and with Wine on Debian 32 bit Linux (no longer aborts, but hangs
>>>>>> when 1024 or more MiB are requested).
>>>>>>
>>>>>> Maybe the support for large addresses is broken in my Wine version.
>>>>>> Please report any different test results.
>>>>>
>>>>> I tried with native WindowsXP, the patch did not help.
>>>>>
>>>>> QEMU was compiled with the new parameter:
>>>>>
>>>>> Install prefix    c:/Program Files/QEMU
>>>>> BIOS directory    c:/Program Files/QEMU
>>>>> binary directory  c:/Program Files/QEMU
>>>>> library directory c:/Program Files/QEMU/lib
>>>>> include directory c:/Program Files/QEMU/include
>>>>> config directory  c:/Program Files/QEMU
>>>>> Source path       /home/aik/testken/qemu
>>>>> C compiler        i686-pc-mingw32-gcc
>>>>> Host C compiler   gcc
>>>>> CFLAGS            -O2 -D_FORTIFY_SOURCE=2 -g
>>>>> QEMU_CFLAGS       -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN
>>>>> -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
>>>>> -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings
>>>>> -Wmissing-prototypes -fno-strict-aliasing  -fstack-protector-all
>>>>> -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs
>>>>> -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers
>>>>> -Wold-style-declaration -Wold-style-definition -Wtype-limits
>>>>> LDFLAGS           -Wl,--nxcompat -Wl,--no-seh -Wl,--large-address-aware
>>>>> -Wl,--dynamicbase -Wl,--warn-common -m32 -static -g
>>>>> make              make
>>>>> install           install
>>>>> python            python
>>>>> smbd              /usr/sbin/smbd
>>>>> host CPU          i386
>>>>> host big endian   no
>>>>> target list       ppc64-softmmu
>>>>> [...]
>>>>>
>>>>>
>>>>>
>>>>> qemu/ppc64-softmmu/qemu-system-ppc64 -M pseries -m 1024 -nographic -L
>>>>> qemu/pc-bios/ -net none -append console=hvc0 -initrd ./1.cpio -kernel
>>>>> ./guest.vmlinux.n -net nic,model=virtio -net user,hostfwd=tcp::5555-:22
>>>>> -drive file=test-virtio-blk.img,if=virtio,index=0,media=disk,cache=unsafe
>>>>> ***qemu_memalign 200 (512) size 800 (2048)
>>>>> Warning: Disabling some instructions which are not emulated by TCG (0x0, 0x6)
>>>>> ***qemu_vmalloc 40000000 (1073741824)
>>>>> Failed to allocate memory: 8
>>>>>
>>>>> This application has requested the Runtime to terminate it in an unusual way.
>>>>> Please contact the application's support team for more information.
>>>>>
>>>>>
>>>>> The lines with *** are mine printf("%s %x(%u)", __func__, etc).
>>>>>
>>>>> It still works with "-m 1023".
>>>>
>>>> Do you have enough RAM? Even with 64 bit Windows 7, I am
>>>> limited to -m 7000 with 64 bit QEMU on a 8 GiB host.
>>>> 32 bit QEMU runs there with up to 2047 MiB.
>>>
>>>
>>> I put another VirtualAlloc(64MB) call in qemu_vmalloc(1023MB) to check if
>>> it fails but it did not so it is possible to allocate 1087MB but in 2 pieces.
>>>
>>>
>>>> On 32 bit Windows XP, I'd expect that you need 2 GiB (or better
>>>> 3 GiB) of physical RAM in your host, and close all other
>>>> programs before you try QEMU.
>>>
>>> How do other programs matter? It is virtual 2GB per process, no?
>>> Ah, anyway, it has 2.994.340KB of physical RAM, swapping is enabled, the
>>> task manager shows at least "2000000" in "Available", one cygwin shell is
>>> running.
>>> And QEMU can always alloc 1023MB (in one chunk) and never 1024MB (also in
>>> one chunk). For me it looks like XP limitation but I could not find any
>>> mention of it in MSDN.
>>>
>>>
>>>> Maybe I can run a test with Windows XP during the weekend.
>>>>
>>>> By the way: the patch must be modified to work for 64 bit QEMU.
>>>> MinGW-w64's ld shows the new parameter in its help, but does
>>>> not support it for 64 bit executables.
>>>
>>>
>>> Not sure if I understood :)
>>> The compiler I use is "i686-pc-mingw32-gcc -m32", target is ppc64-softmmu.
>>>
>>>
>>
>> Did a simple test inside QEMU, ran it twice:
>>
>> run#1: first alloc 64MB, then 1023MB - failed.
>> va(0x4000000) ->  ptr=1d0d0000, last error = 0
>> va(0x3FF00000) ->  ptr=00000000, last error = 8
>>
>> run#2: first alloc 1023MB, then 64MB - succeeded.
>> va(0x3FF00000) ->  ptr=1d0d0000, last error = 0
>> va(0x4000000) ->  ptr=5d130000, last error = 0
>>
>> As we can see, there is 340000h gap between 2 chunks.
>>
>> Have no idea what that means :) May be something is wrong with my machine,
>> dunno.
>
> Looked further, c:\windows\system32\sysctl32.dll is mapped there so there
> is just no big chunk of RAM. But still there is some RAM, it is just
> fragmented.

Yes, that's the problem: the QEMU executable and all the DLLs
occupy RAM in the range from 0 to 2 GiB, so this area is very
fragmented and it's impossible to get a large contiguous memory
area (which VirtualAlloc requires!).

On 64 bit Windows, addresses from 2 GiB to 4 GiB can be used
with --large-address-aware, so there is no such problem.
With 64 bit executables, even more RAM above 4 GiB is available.

If you have enough RAM, you can configure a 32 bit Windows to
provide 3 GiB instead of 2 GiB to user applications. This
non-standard configuration also allows larger sizes for VirtualAlloc.

See 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778%28v=vs.85%29.aspx

for more information.

See http://qemu.weilnetz.de/w32/virtualalloc-test/ for a simple test program.

Regards,

Stefan Weil