qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu in full emulation on win32


From: Stefan Weil
Subject: Re: [Qemu-devel] qemu in full emulation on win32
Date: Wed, 18 Jul 2012 18:35:16 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

Am 18.07.2012 08:30, schrieb Alexey Kardashevskiy:
Hi!

Found 2 problems while I was debugging qemu/ppc64-softmmu/qemu-system-ppc64.exe
WindowsXP SP3 Pro, 32bit, i686-pc-mingw32-gcc (GCC) 4.5.2.


1. The size of the following is 7 bytes on linux and 8 bytes on Windows:
struct {
     uint32_t hi;
     uint64_t child;
     uint64_t parent;
     uint64_t size;
} __attribute__((packed)) ranges[];

The structure is used between QEMU and Open Firmware (powerpc bios) so it is 
important.

The Feature is described here:
http://stackoverflow.com/questions/7789668/why-would-the-size-of-a-packed-structure-be-different-on-linux-and-windows-when
Shortly there is packing and ms-packing and they are different :)

The solutions are:
1. Add MS-specific #pragma pack(push,1) and #pragma pack(pop).
2. Add -mno-ms-bitfields (gcc >= 4.7.0)
3. Change the structure above to use only uint32_t.

What is the common way of solving such problems in QEMU?

Problem 1 is solved with solution 4 (your own patch) although
that patch does not change the structure size to 7 bytes :-)





2. QEMU cannot allocate 1024MB for the guest RAM. Literally, VirtualAlloc() 
fails on 1024MB BUT it does not if I allocate 1023MB and 64MB by 2 subsequent 
calls. We allocate RAM via memory_region_init_ram(). I am pretty sure this is 
not happening on 64bit Windows and I suspect that it is happening with 
qemu-system-x86.exe, is not it?

Do we care that there is actually enough RAM and we could allocate it in 
several chunks?


Please try the patch which I'm going to send.

On w64, VirtualAlloc() _can_ allocate large quantities of contiguous virtual memory.

On w32, it is normally restricted to the lower 2 GiB which are already fragmented by the code (executable, shared libraries) and data. Larger quantities are available when the executable is allowed to use the upper 2 GiB, too. That's what my patch does.

Regards,

Stefan W.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]