Re: [Qemu-devel] [PATCH] OpenGL for OS X

Hi, 2008/2/5, Fabrice Bellard <[EMAIL PROTECTED]>: > This is an SDL related issue (i.e. SDL may or may not use OpenGL to > display graphics). Fixing SDL for Mac OS X would also be interesting. I think SDL trunk (1.3) supports OpenGL rendering more specifically for various platforms. Besides, on

Re: [Qemu-devel] 4G address space remapping on 64-bit host

Hi, 2007/6/29, Paul Brook <[EMAIL PROTECTED]>: I'd expect the overhead of SIGSEGV+mmap to be prohibitive. I don't have numbers to back this up, but experience with MIPS system emulation shows that TLB miss cost can have significant effect on overall performance. I'd say this can't be worse tha

Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts

Hi, 2007/6/26, Karl Magdsick <[EMAIL PROTECTED]>: With proper support from the compiler, it's theoretically possible on x86-64 systems to use 32-bit pointers in long mode (16 general purpose 64-bit registers). (There's an instruction prefix that will cause the CPU to perform 32-bit pointer cal

Re: [Qemu-devel] Using native libraries

Hi, I'm sure someone's probably had a similar idea before, and it's probably not practical for some reason I'm overlooking-- but is there a reason Qemu can't dynamically translate library calls to use the native libraries instead of requiring emulated libraries as well? It should be poss

qemu + gcc4 (Was: [Qemu-devel] [RFC/experimental patch] qemu (x86_64 on x86_64 -no-kqemu) compiles with gcc4 and works)

386, x86_64 (linux-only) } - host CPU (compiled as): { i386, x86_64 } PS: I have not tested yet on MacOS X. Regards, Gwenole 2007-04-20 Gwenole Beauchesne <[EMAIL PROTECTED]> * gcc4 host support. --- qemu-0.9.0/target-i386/ops_template.h.gcc4 2005-02-21 20:23:59.0 + +++

[Qemu-devel] [PATCH] Increase max -kernel size

Hi, The following patch increases max kernel size to 8 MB when qemu is invoked with -kernel and -initrd. Otherwise, x86_64 kernel panics when loading the initrd (e.g. /x86_64/isolinux/alt0/{vmlinuz,all.rdz}). Thanks, Gwenole. 2007-03-27 Gwenole Beauchesne <[EMAIL PROTECTED]>

[Qemu-devel] [PATCH] Fix CPU chaining in linux-user emulation

Hi, This patch fixes chaining of CPU instances. It was simply trashed with the memcpy() thus causing problems in threaded programs (N > 2): an infinite loop in next cpu_init(). --- qemu-0.9.0/linux-user/syscall.c.cpuchain2007-02-13 14:41:12.0 +0100 +++ qemu-0.9.0/linux-user/syscall.c

Re: [Qemu-devel] Re: strange crash on FreeBSD-current/amd64 (pointertruncation?)

On Thu, 8 Feb 2007, Rob Landley wrote: > Is there an LLP64 platform other than Windows-64? I don't know, probably OS/400? Though I doubt about any interest in QEMU there. ;-) > And the insane legacy reasons Windows decided on a broken approach are > explained here: > http://blogs.msdn.com/oldne

Re: [Qemu-devel] Re: strange crash on FreeBSD-current/amd64 (pointer truncation?)

Regards, Gwenole Beauchesne <http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/qemu/ current/SOURCES/qemu-0.8.3-preserve-host-registers.patch> qemu-0.8.3-preserve-host-registers.patch Description: Binary data ___ Qemu-devel mailing

RE: [Qemu-devel] Re: strange crash on FreeBSD-current/amd64 (pointertruncation?)

On Fri, 2 Feb 2007, Gwenole Beauchesne wrote: > The proper fix would be to not globally allocate registers for the whole > program but only for the micro-ops. Then, make the necessary > save/restore around the gen_func call. Hmm, I realized in the train that this wouldn't

RE: [Qemu-devel] Re: strange crash on FreeBSD-current/amd64 (pointertruncation?)

On Fri, 2 Feb 2007, Paul Robinson wrote: > But the T0, T1, and T2 registers are being saved for the benefit of the > host not the target. FWIW, I use the following patch for Virtual Box on x86_64. The proper fix would be to not globally allocate registers for the whole program but only for the mi

[Qemu-devel] QEMU for Intel Mac

Hi, Patches and test binaries are here: A screenshot: I have not really tested graphically. But the owner of the iMac I was using tried Windows ME and it worked:

Re: [Qemu-devel] Translation cache sizes

Hi, With those changes in place, the same boot-to-kdm process requires only about 57 translations to be made, and 2 cache flushes to happen. Of course the cost is an extra 48M of memory use. I faced a similar problem in Basilisk II. MacOS 8.x had a tendency to invalidate the code cache a

[Qemu-devel] [PATCH] MacOS X for Intel host support

Hi, I am not fully satisfied with those patches though. The dyngen-exec.h & exec-all.h bits should be improved and depend on gcc4 patches. TODO: - try test-i386 - use 80-bit long doubles? --- qemu-0.8.0/target-i386/exec.h.osx-intel-port2005-12-19 23:51:53.0 +0100 +++ qemu-0.8.0/

[Qemu-devel] [PATCH] Enforce 16-byte stack boundaries

Hi, This restores 16-byte stack alignment. --- qemu-0.8.0/Makefile.target.enforce-16byte-stack-boundary2006-02-12 17:46:54.0 +0100 +++ qemu-0.8.0/Makefile.target 2006-02-12 17:55:24.0 +0100 @@ -67,7 +67,7 @@ endif ifeq ($(ARCH),i386) CFLAGS+=-fomit-frame-pointer -OP_CFLA

[Qemu-devel] [PATCH] More FORCE_RETs

Hi, This tries to enforce one single exit point per function. Mostly useful with gcc4 patches. --- qemu-0.8.0/target-i386/op.c.i386-FORCE_RET 2005-12-19 23:51:53.0 +0100 +++ qemu-0.8.0/target-i386/op.c 2006-02-12 17:51:40.0 +0100 @@ -1032,6 +1032,7 @@ void OPPROTO op_aaa(void)

Re: [Qemu-devel] Qemu on Intel Macs

Hi, Anyone out there feel qualified to help me get this going? Its a bit beyond my ability at this time and I would be happy to compensate for time. I still haven't had the time to merge back to QEMU the following change:

Re: [Qemu-devel] [PATCH] support for Mac OS X default compiler

On Tue, 20 Dec 2005, Daniel Egger wrote: > On 19.12.2005, at 23:35, Fabrice Bellard wrote: > > > Does -fno-tree-ch works on PC ? > > Yes. However using it might introduce a performance hit. I think Fabrice meant does the -fno-tree-ch trick works on x86 with gcc4 too? The answer is no. __

Re: [Qemu-devel] Re: Debian blues (Re: Problem compiling with gcc 3.3 on 2.6.14 (Debian))

Hi, > Case in point : I distinctly reember reading a convoluted thread in one > of the Debian lists about this /etc/alternative issue for gcc... Was I > drunk ? Or what ? I don't know what all this rant is about but it's always best to keep the system compiler as chosen by the distributor. If

Re: [Qemu-devel] Re: Qemu-devel Digest, Vol 32, Issue 41

Hi, On 21/11/05, Richard Neill <[EMAIL PROTECTED]> wrote: Dear All, I thought you might like to know the following: Neither Qemu 0.7.2 nor 0.7.1 will compile under gcc 4.0.1, which is the default under Mandrake 2006. It works fine with the older 3.3.6 though. i don't understand why it i

[Qemu-devel] GCC 4 patches

Hi, The following patches makes it possible to build QEMU with GCC 4 on x86. However, there is still a problem with x86_64-softmmu. It may be a genuine GCC bug though I don't see what's wrong with do_interrupt_real(). IOW, if I build this function with GCC 3.3, x86_64-softmmu works fine, otherwis

Re: [Qemu-devel] [patch] NPTL/TLS support

On Sun, 14 Aug 2005, Paul Brook wrote: > This is sufficient to run single-threaded NPTL enabled binaries. I've not yet > implemented the futex syscalls, so multithreaded applications probaby won't > work. I followed another approach for our packages: don't use NPTL libraries.

[Qemu-devel] [PATCH] more auxv entries for x86

-10-23 Gwenole Beauchesne <[EMAIL PROTECTED]> * linux-user/elfload.c (create_elf_tables): Add AT_PLATFORM and AT_HWCAP entries to auxiliary vector. * linux-user/main.c (main): setup global_env earlier for elf_exec. --- qemu/linux-user/elfload.c.auxv 2005-09-05 10:26:

Re: [Qemu-devel] Bug report

Le mercredi, 2 nov 2005, à 01:00 Europe/Paris, Karl Magdsick a écrit : gcc 4.x is known not to compile qemu, due to a register allocation bug in gcc. It can be fixed at QEMU's level with additional patches than posted here and actually I have it working for x86 system emulation. Unfortunatel

Re: [Qemu-devel] Re: Current state of GCC 4 (non-)"support" on x86-64 ?

On Sun, 9 Oct 2005, Michel Pelletier wrote: > A copule others on this thread mentioned that you can compile the kqemu > module with gcc 4 and the rest of qemu with gcc 3.x. Did this work for > you? Did it create a performance boost? I don't think you'd gain much since most of the time is spen

Re: [Qemu-devel] qemu 0.7.1 + dkms-qvm86-0.7.1 (mandriva cooker) produces version mismatch

On Fri, 26 Aug 2005, Pascal Terjan wrote: > do you use the same package version of qemu and dkms-qvm86 ? Actually also make sure you don't have a stale qvm86 module already prior to the dkms'ed variant from MDK. e.g. one you manually built and placed in a more prioritized location than the output

Re: [Qemu-devel] Mirror for QEMU (sources)

On Wed, 3 Aug 2005, Herbert Poetzl wrote: > > I update them almost each time I update the cooker packages. > > but unfortunately I could not find a src rpm for > those binary mandriva rpms of qemu :/ cooker/SRPMS/contrib on any mirror you may find. Except proxad.net at this time, which is a lit

Re: [Qemu-devel] [Patch Submission] QEMU with GCC/Win32

On Sun, 31 Jul 2005, Paul Brook wrote: > The gcc4 changes are a different matter. I discusses this with Fabrice on > IRC > shortly after submitting the patch. The patch is pretty invasive, high risk, > and potentially hard to debug and maintain. Talking of which, I don't know if I have sent y

Re: [Qemu-devel] Anyone familiar with the slirp code?

Le samedi, 23 jul 2005, à 00:05 Europe/Paris, Jim C. Brown a écrit : On Fri, Jul 22, 2005 at 08:45:16PM +0200, Gwenole Beauchesne wrote: AFAICS, slirp code in qemu cvs and other projects works on x86_64. Nope. Then please provide a clear testcase. My testing limited to 32-bit Ubuntu Live

Re: [Qemu-devel] Anyone familiar with the slirp code?

Hi, From what I can tell, I can't see how the code would ever work on any 64 bit machine - can anyone here confirm if this is indeed the case? AFAICS, slirp code in qemu cvs and other projects works on x86_64. Really try CVS instead of 0.7.0. ;-) Bye, Gwenolé. ___

Re: [Qemu-devel] mini documentation of "info registers" output

Le samedi, 2 jul 2005, à 06:12 Europe/Paris, Mulyadi Santosa a écrit : hm, i seeBTW, these two lazy flags, CCS and CCD, they are the representation of EFLAGS? CCS/CCD = Condition Codes Source/Destination values. Those represent part of the state (input and/or result + operation type) used

[Qemu-devel] [PATCH] Handle .LCn symbols in dyngen

Note: I probably should have simply used the extern char __dot_sym __asm__(".sym") trick from the HOST_SPARC case, which this patch clobbers. What dot symbols were emitted on sparc host? 2005-06-02 Gwenole Beauchesne <[EMAIL PROTECTED]> * dyngen.c: handle .LCn sym

[Qemu-devel] [PATCH] Fix gcc4 patch

Hi, I got a "No return instruction found in op_lmsw_T0" when building qemu with the gcc4 patch + gcc3.3. push imm8 was misdecoded. Also fixed the imul case at the same time. Tested with gcc 3.3.4 (hammer-branch), 3.4.3, 4.0.1 (4.0-branch). 2005-06-02 Gwenole Beauchesne <[EM

Re: [Qemu-devel] [patch] gcc4 host support

On Thu, 19 May 2005, Paul Brook wrote: > Do you have a URL? Neither google nor freshmeat.net turn up anything useful. Sorry, here it is: (used for valgrind 3.0) > It would be nice if we could use some sort of porta

Re: [Qemu-devel] [patch] gcc4 host support

Le mercredi, 18 mai 2005, à 22:48 Europe/Paris, Paul Brook a écrit : It's been said before that the long-term solution is to [incrementally] remove dyngen altogether, and replace it with a had-written code generator. I've discussed this in a bit more detail with Fabrice, and have an almost-working

Re: [Qemu-devel] [PATCH] Mingw32 cross compile fixes from 64-bit host

On Wed, 18 May 2005, Paul Brook wrote: > It doesn't really make any difference, but wouldn't it be more consistent to > use [u]int8_t instead of char? OK, here is a patch that uses uint8_t and also changes the cross_prefix to i386-mingw32msvc- so that we are consistent with the later use of i386

[Qemu-devel] [PATCH] Mingw32 cross compile fixes from 64-bit host

Hi, I had the following in my tree for a while but forgot to submit it. This fixes cross compilation to mingw32 from 64-bit host (x86_64). Actually, this makes dyngen aware of correct COFF format. 2004-12-27 Gwenole Beauchesne <[EMAIL PROTECTED]> * a.out.h: Cross compilation

[Qemu-devel] [PATCH] slirp 64-bit fixes

Hi, Here are some 64-bit fixes to slirp. Tested on x86_64 as -user-net with a single FTP transaction. You may not need all hunks though. 2005-05-15 Gwenole Beauchesne <[EMAIL PROTECTED]> * Merge slirp 64-bit fixes from Basilisk II tree. --- qemu-0.7.0/slirp/bootp.c.slirp-64bit