From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40036) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SsGtZ-0005am-56 for qemu-devel@nongnu.org; Fri, 20 Jul 2012 13:23:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SsGrd-0003cw-5N for qemu-devel@nongnu.org; Fri, 20 Jul 2012 13:21:41 -0400 Received: from v220110690675601.yourvserver.net ([78.47.199.172]:51875) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SsGrc-0003cf-Rm for qemu-devel@nongnu.org; Fri, 20 Jul 2012 13:19:41 -0400 Message-ID: <50099328.4040106@weilnetz.de> Date: Fri, 20 Jul 2012 19:19:36 +0200 From: Stefan Weil MIME-Version: 1.0 References: <1342629463-3378-1-git-send-email-sw@weilnetz.de> <5008D62D.5080705@ozlabs.ru> <5008EB55.4070709@weilnetz.de> <5008EEA8.4010004@ozlabs.ru> <5008F514.90003@ozlabs.ru> <5008FCCE.3080501@ozlabs.ru> In-Reply-To: <5008FCCE.3080501@ozlabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] configure: Support system emulation with large memory on w32 hosts List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy Cc: qemu-devel@nongnu.org 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 >>>>>> --- >>>>>> >>>>>> 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