[Qemu-devel] [PATCH 4/4] Mac OS X generic support v2
This patch implements Mac OS X specific parts that are necessary to get i386 and x86_64 versions of qemu working. Since both hosts need this patch, I seperated it from the architecture specific ones. It does: - not force always_inline - only define [u]intXX types if they are not already defined - nullify spin-functions using #define instead of inline function - include osdep.h in host-utils qemu-mac-generic.patch Description: Binary data
[Qemu-devel] [PATCH 0/4] Intel Mac OS X Host support v2
Hi, supporting Mac OS X on Intel has been a long standing issue. The Q project has done a fabulous job maintaining patches that make things work for i386 Mac OS X, but do invasive changes to qemu internals. This set of patches attempts to make Mac OS X host support as compatible as possible to the existing Linux host and PowerPC Mac OS X support. Of course this means, that as long as Linux gcc4 support is broken, it won't work on Mac OS X either. Nevertheless all changes necessary to support the binary format (Mach-O) and several other minor issues that are Mac specific can be easily added to the existing code base without harming other platforms. This way people who want to run qemu on Mac OS X only have to maintain gcc4 patches and no Apple specific ones. This is version 2 of the patchset, adding support for and removing parts made obsolete by TCG. Please comment on these patches. Commits are welcome too. Regards, Alex
[Qemu-devel] [PATCH 3/4] Mac OS X i386 support v2
No Mac OS X specific patches are required to get i386 host support with gcc4 non-working ;-).
[Qemu-devel] [PATCH 2/4] Mac OS X x86_64 support v2
This patch implements Mac OS X specific parts that are necessary to get x86_64 versions of qemu working. It does: - add osx x86_64 detection to configure - add -fomit-frame-pointer if available - set the pagezero size to 4GB, so 32bit lea still works - fix redeclarations of int64_t and uint64_t qemu-mac-x86_64.patch Description: Binary data
[Qemu-devel] [PATCH 1/4] dyngen Mach-O support for i386 and x86_64 v2
This patch extends the existing support for the Mach-O binary format in dyngen from PowerPC to PowerPC, i386 and x86_64. v2 now includes support for TCG qemu-macho.patch Description: Binary data
Re: [Qemu-devel] [PATCH] OpenGL for OS X
On Feb 1, 2008, at 5:45 PM, Mike Kronenberg wrote: After a little discussion on the list, I made this patch for cocoa.m, to replace CoreGraphic by OpenGL. Great! Thank you. It's way faster than CG, but it requires a Mac with OpenGL capable Graphics Card and at least 8mb of VRAM. I think starting with G4 and Highend G3, this requirements are met. Maybe I will try if I find some spare time, but as far as I know Apple provides a quite powerful OpenGL emulation. Last time I ran osx on Vesa output, everything worked just fine. features: [new] draws dirty lines of the window as needed, implemented with OpenGL (used the extensions as proposed by Pierre) [new] window can be resized [fix] conditional builds for Leopard, without linking to a specific sdk [fix] lineflicker in fullscreen mode The Question is, where to draw the line - or - if it needs a switch for CG/OpenGL support for cocoa. As this OpenGL implementation is based on the Apple pass-through extensions, I don't think it'd make a good start for a generic implementation. Additionally I believe SDL is a good choice for the output too, as they implement optimizations for the specific platforms. The only sad part is that I have not seen a 64-bit capable SDL on Mac OS X ;-). Please test and comment. Mike [1] http://www.kberg.ch/qemu/091patches/cocoa_m_OpenGL.diff.gz Apart from this core dump which I received after playing a bit with an ubuntu image, the patch looks fine to me. It's a lot faster than the previous one. Regards, Alex Process: qemu-system-x86_64 [58929] Path:/Users/alex/Documents/business/suse/qemu.patches.mac/ qemu.nonpatched/qemu/x86_64-softmmu/qemu-system-x86_64 Identifier: qemu-system-x86_64 Version: ??? (???) Code Type: X86-64 (Native) Parent Process: bash [1763] Date/Time: 2008-02-05 09:56:07.071 +0100 OS Version: Mac OS X 10.5.1 (9B18) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x239ae600 Crashed Thread: 0 Thread 0 Crashed: 0 libGLImage.dylib 0x7fff8464e490 void glgConvertTo_32GLGConverter_ABGR8_ARGB8, (GLGMemory)1(GLGOperation const*, GLDPixelMode const*) + 96 1 libGLImage.dylib 0x7fff84627eb3 glgProcessPixelsWithProcessor + 1187 2 ...er.AppleIntelGMA950GLDriver 0x03599adc glrLoadSysTexture + 4188 3 ...er.AppleIntelGMA950GLDriver 0x0357f8cc glrLoadCurrentTextures + 556 4 ...er.AppleIntelGMA950GLDriver 0x035b2f0a gldUpdateDispatch + 394 5 GLEngine0x14cd8fee glBegin_Exec + 302 6 qemu-system-x86_64 0x01089dca -[QemuCocoaView drawRect:] + 506 (cocoa.m:384) 7 com.apple.AppKit 0x7fff8396f479 -[NSView _drawRect:clip:] + 3618 8 com.apple.AppKit 0x7fff8396dfeb -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1234 9 com.apple.AppKit 0x7fff8396e37e -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 2149 10 com.apple.AppKit 0x7fff8396c7c5 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView :] + 806 11 com.apple.AppKit 0x7fff8396c06c -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView :] + 328 12 com.apple.AppKit 0x7fff839688dc -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 3008 13 com.apple.AppKit 0x7fff838a63cd -[NSView displayIfNeeded] + 1190 14 com.apple.AppKit 0x7fff8395b90b -[NSWindow _setFrameCommon:display:stashSize:] + 1615 15 com.apple.AppKit 0x7fff839ae2e8 _NSMoveHelperTimerCallBack + 1115 16 com.apple.CoreFoundation 0x7fff821ff5f5 CFRunLoopRunSpecific + 3813 17 com.apple.AppKit 0x7fff83b0a5c6 -[NSMoveHelper _doAnimation] + 1012 18 com.apple.AppKit 0x7fff83b86af3 -[NSMoveHelper _resizeWindow:toFrame:display:] + 535 19 com.apple.AppKit 0x7fff83996c68 -[NSWindow setFrame:display:animate:] + 955 20 qemu-system-x86_64 0x01089979 -[QemuCocoaView resizeContentToWidth:height:displayState:] + 1065 (cocoa.m:463) 21 qemu-system-x86_64 0x01030957 vga_update_display + 2679 (vga.c:1495) 22 qemu-system-x86_64 0x01007e4f gui_update + 15 (vl.c:7173) 23 qemu-system-x86_64 0x01001cc6 qemu_run_timers + 54 (vl.c:1069) 24 qemu-system-x86_64 0x01008b3a main_loop_wait + 650 (vl.c:7445) 25 qemu-system-x86_64 0x01009ee1 qemu_main + 4817 (vl.c:7527) 26 qemu-system-x86_64 0x010879fe - [QemuCocoaAppController startEmulationWithArgc:argv:] + 14 (cocoa.m:855) 27
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
Andreas Schwab, le Tue 05 Feb 2008 11:32:30 +0100, a écrit : Samuel Thibault [EMAIL PROTECTED] writes: Mmm, actually, shouldn't qemu use a more private network like a RFC1918 172.16.0.0/12 network? In which way is 172.16.0.0/12 more private than 10.0.0.0/8? Precisely thanks to the reservation page I mentioned. Samuel
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
Samuel Thibault [EMAIL PROTECTED] writes: Mmm, actually, shouldn't qemu use a more private network like a RFC1918 172.16.0.0/12 network? In which way is 172.16.0.0/12 more private than 10.0.0.0/8? Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: [Qemu-devel] Re: [PATCH 1/6] Use correct types to enable 2G support
Fabrice Bellard writes ([Qemu-devel] Re: [PATCH 1/6] Use correct types to enable 2G support): Paul Brook wrote: If we ever implement 2G ram on a 32-bit host this may need some rethinking. We can deal with that if/when it happens though. Requiring a 64-bit host for large quantities of ram seems an acceptable limitation (N.B. I'm only talking about ram size, not target physical address size). I agree. This demonstrates quite nicely why we need to get rid of the assumption that all guest memory is mapped by the host. The configuration with a 32-bit host (dom0), 64-bit guest, and of course 64-bit Xen, is very common. qemu runs (currently) in the dom0. Ian.
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
Andreas Schwab writes (Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x): Samuel Thibault [EMAIL PROTECTED] writes: Mmm, actually, shouldn't qemu use a more private network like a RFC1918 172.16.0.0/12 network? In which way is 172.16.0.0/12 more private than 10.0.0.0/8? It isn't. There is no particular reason to choose one rather than another so in that sense I disagree with Samuel. However, there are two things wrong with the current qemu arrangements. The first is that the range isn't configurable without recompiling. I agree with Johannes Schindelin that it should be. The second is that addresses chosen from RFC1918 space should be chosen randomly. Quoting the RFC: If two (or more) organizations follow the address allocation specified in this document and then later wish to establish IP connectivity with each other, then there is a risk that address uniqueness would be violated. To minimize the risk it is strongly recommended that an organization using private IP addresses choose randomly from the reserved pool of private addresses, when allocating sub-blocks for its internal allocation. I don't believe that 10.0.2.0/24 was chosen randomly :-). It would be better for qemu's default range to be a randomly chosen one. The URL Samuel quotes, www.ucam.org/cam-grin, is a personal project of mine which helps choose random addresses and which can also be used for documenting one's usage. So while this setup is being made configurable, I think it would probably be best for qemu's range to be changed to a random range. I would suggest 172.30.206.0/24 which is already used as a default for some regression testing in Xen; since Xen's and qemu's management setups are best regarded as alternatives, there is less problem with clashes. As an alternative, a new range can be chosen randomly quite easily. I think it would also be good for one of the qemu maintainers to document qemu's use in my registry. Ian.
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
Am 05.02.2008 um 12:30 schrieb Ian Jackson: I don't believe that 10.0.2.0/24 was chosen randomly :-). It would be better for qemu's default range to be a randomly chosen one. Please don't randomly choose a default subnet; knowing that QEMU uses 10.0.2.x allows to adapt to this. If however QEMU starts randomly assigning addresses we will also get random conflicts. Please stick with a default like the current and simply make it statically configurable. Andreas
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
From: Andreas Färber [EMAIL PROTECTED] Subject: Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x Date: Tue, 5 Feb 2008 13:58:28 +0100 Am 05.02.2008 um 12:30 schrieb Ian Jackson: I don't believe that 10.0.2.0/24 was chosen randomly :-). It would be better for qemu's default range to be a randomly chosen one. Please don't randomly choose a default subnet; knowing that QEMU uses 10.0.2.x allows to adapt to this. If however QEMU starts randomly assigning addresses we will also get random conflicts. Please stick with a default like the current and simply make it statically configurable. I think that the suggestion is that qemu picks, one time, a new default. This new default would be selected at random, and would be the same on all new versions of qemu. I don't think that the suggestion is to pick a random address every time qemu starts. Warner
Re: [Qemu-devel] [PATCH] OpenGL for OS X
Alexander Graf wrote: On Feb 1, 2008, at 5:45 PM, Mike Kronenberg wrote: After a little discussion on the list, I made this patch for cocoa.m, to replace CoreGraphic by OpenGL. Great! Thank you. It's way faster than CG, but it requires a Mac with OpenGL capable Graphics Card and at least 8mb of VRAM. I think starting with G4 and Highend G3, this requirements are met. Maybe I will try if I find some spare time, but as far as I know Apple provides a quite powerful OpenGL emulation. Last time I ran osx on Vesa output, everything worked just fine. features: [new] draws dirty lines of the window as needed, implemented with OpenGL (used the extensions as proposed by Pierre) [new] window can be resized [fix] conditional builds for Leopard, without linking to a specific sdk [fix] lineflicker in fullscreen mode The Question is, where to draw the line - or - if it needs a switch for CG/OpenGL support for cocoa. As this OpenGL implementation is based on the Apple pass-through extensions, I don't think it'd make a good start for a generic implementation. Additionally I believe SDL is a good choice for the output too, as they implement optimizations for the specific platforms. The only sad part is that I have not seen a 64-bit capable SDL on Mac OS X ;-). I would really like to use OpenGL on non-Apple platforms. OpenGL gives much better scaling than SDL. Typically, and OpenGL app has very little platform specific code. It would be nice if we could use similar code here. Regards, Anthony Liguori Please test and comment. Mike [1] http://www.kberg.ch/qemu/091patches/cocoa_m_OpenGL.diff.gz
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
Warner Losh wrote: From: Andreas Färber [EMAIL PROTECTED] Subject: Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x Date: Tue, 5 Feb 2008 13:58:28 +0100 Am 05.02.2008 um 12:30 schrieb Ian Jackson: I don't believe that 10.0.2.0/24 was chosen randomly :-). It would be better for qemu's default range to be a randomly chosen one. Please don't randomly choose a default subnet; knowing that QEMU uses 10.0.2.x allows to adapt to this. If however QEMU starts randomly assigning addresses we will also get random conflicts. Please stick with a default like the current and simply make it statically configurable. I think that the suggestion is that qemu picks, one time, a new default. This new default would be selected at random, and would be the same on all new versions of qemu. I don't think that the suggestion is to pick a random address every time qemu starts. I already have some scripts that depend on the 10.0.2.x default -- probably others do too. Would changing to a different subnet by default really make that much difference? 10.0.2.x is, after all, a possible random choice :) Eddie
Re: [Qemu-devel] [PATCH] OpenGL for OS X
Hi, On Tue, 5 Feb 2008, Anthony Liguori wrote: I would really like to use OpenGL on non-Apple platforms. OpenGL gives much better scaling than SDL. Typically, and OpenGL app has very little platform specific code. It would be nice if we could use similar code here. But SDL runs on many more platforms than those which have OpenGL. So if at all, this should be optional, and not replace SDL. Ciao, Dscho
Re: [Qemu-devel] [PATCH] OpenGL for OS X
Anthony Liguori wrote: Johannes Schindelin wrote: Hi, On Tue, 5 Feb 2008, Anthony Liguori wrote: I would really like to use OpenGL on non-Apple platforms. OpenGL gives much better scaling than SDL. Typically, and OpenGL app has very little platform specific code. It would be nice if we could use similar code here. But SDL runs on many more platforms than those which have OpenGL. So if at all, this should be optional, and not replace SDL. Absolutely. My thinking was just that if we're already going to have OpenGL code to support OS X (where SDL isn't an option), then we might as well make it so it's usable elsewhere. 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. Regards, Fabrice.
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
Warner Losh [EMAIL PROTECTED] wrote: From: Andreas Färber [EMAIL PROTECTED] Subject: Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x Date: Tue, 5 Feb 2008 13:58:28 +0100 Am 05.02.2008 um 12:30 schrieb Ian Jackson: I don't believe that 10.0.2.0/24 was chosen randomly :-). It would be better for qemu's default range to be a randomly chosen one. Please don't randomly choose a default subnet; knowing that QEMU uses 10.0.2.x allows to adapt to this. If however QEMU starts randomly assigning addresses we will also get random conflicts. Please stick with a default like the current and simply make it statically configurable. I think that the suggestion is that qemu picks, one time, a new default. This new default would be selected at random, and would be the same on all new versions of qemu. I don't think that the suggestion is to pick a random address every time qemu starts. It seems to me that there is a corner case where the local host has a 10.0.2.x or 10.0.x.x address which would cause a qemu guest problems that has a 10.0.2.15 address (for -net user only). I think the default should be left at 10.0.2.x, and if the localhost has a 10.0.x.x address, then one of the other ranges (172.16.x.x or 192.168.x.x) could be used. For the most part, it doesn't make any difference to the host because you don't use the 10.0.2.x address from the host, and only the guest is affected IFF running DHCP. Ben
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
On Tue, 5 Feb 2008, Ben Taylor wrote: It seems to me that there is a corner case where the local host has a 10.0.2.x or 10.0.x.x address which would cause a qemu guest problems that has a 10.0.2.15 address (for -net user only). That's right - that's the issue that I faced. I think the default should be left at 10.0.2.x, and if the localhost has a 10.0.x.x address, then one of the other ranges (172.16.x.x or 192.168.x.x) could be used. I would go one step further: Make the default *always* 10.0.2.x, but make it configurable on the command line. That way, there are no surprises ever. The rare people like me with an issue can just pass a command-line parameter in. For the most part, it doesn't make any difference to the host because you don't use the 10.0.2.x address from the host, and only the guest is affected IFF running DHCP. *nod* -- Asheesh. -- We all know Linux is great... it does infinite loops in 5 seconds. - Linus Torvalds about the superiority of Linux on the Amsterdam Linux Symposium
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
On 05/02/2008, Ian Jackson [EMAIL PROTECTED] wrote: Andreas Schwab writes (Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x): Samuel Thibault [EMAIL PROTECTED] writes: Mmm, actually, shouldn't qemu use a more private network like a RFC1918 172.16.0.0/12 network? In which way is 172.16.0.0/12 more private than 10.0.0.0/8? It isn't. There is no particular reason to choose one rather than another so in that sense I disagree with Samuel. However, there are two things wrong with the current qemu arrangements. The first is that the range isn't configurable without recompiling. I agree with Johannes Schindelin that it should be. The second is that addresses chosen from RFC1918 space should be chosen randomly. Quoting the RFC: That would break all the simplicity that user-net brings. If you want anything more complex, don't use user-net. The idea is that you don't even have to have dhcp in the guest. This rfc talks about organisations and networks that are real, not about the network inside qemu which doesn't have connectivity with another qemu network. But even on real networks static IPs usually simplify more than they break. (For example hardware that by default assumes that 192.168.0.1 is the gateway and if that's the case, works without configuration). I don't think an option to change the default 10.0.2.x addresses for usernet would be of much use either. A person looking up the option in the manuals can in the same time figure out how to set up non-user-net networking, or simply recompile. And the person will only look for it once they find out about the ip collision (most people won't). Regards
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
I think in VBox the Slirp IP address can be changed. I didn't take that part to my patch: http://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00470.html but it should be easy to add. Currently all NICs share the same subnet.
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
Asheesh Laroia [EMAIL PROTECTED] wrote: On Tue, 5 Feb 2008, Ben Taylor wrote: It seems to me that there is a corner case where the local host has a 10.0.2.x or 10.0.x.x address which would cause a qemu guest problems that has a 10.0.2.15 address (for -net user only). That's right - that's the issue that I faced. I've run into that before too.. I think the default should be left at 10.0.2.x, and if the localhost has a 10.0.x.x address, then one of the other ranges (172.16.x.x or 192.168.x.x) could be used. I would go one step further: Make the default *always* 10.0.2.x, It is. but make it configurable on the command line. That way, there are no surprises ever. The rare people like me with an issue can just pass a command-line parameter in. The point I was trying to make is that qemu could easily arbitrate the guest network based on how the host is configured. If the host has a 10.0.x.x network (and I suppose if we want to be thorough, a 10.0.x.x route), then it punts to 172.16.x.x (and does the same check) and then tries a couple of 192.168.x.x networks. Eventually the guest gets a local network that won't conflict with the user's network infrastructure. Obviously, if you have a 10.0.x.x, a 172.16.x.x and a 192.168.x.x network, having a configurable guest network is probably loads simpler. Ben
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
but make it configurable on the command line. That way, there are no surprises ever. The rare people like me with an issue can just pass a command-line parameter in. The point I was trying to make is that qemu could easily arbitrate the guest network based on how the host is configured. If the host has a 10.0.x.x network (and I suppose if we want to be thorough, a 10.0.x.x route), then it punts to 172.16.x.x (and does the same check) and then tries a couple of 192.168.x.x networks. I really dislike this kind of guesswork. It makes it very hard to debug/reproduce problems, and means you're never really sure what qemu is going to do. IMHO One of the really nice features of qemu is that it is host independent. Paul
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
On Tue, 5 Feb 2008, Paul Brook wrote: but make it configurable on the command line. That way, there are no surprises ever. The rare people like me with an issue can just pass a command-line parameter in. The point I was trying to make is that qemu could easily arbitrate the guest network based on how the host is configured. If the host has a 10.0.x.x network (and I suppose if we want to be thorough, a 10.0.x.x route), then it punts to 172.16.x.x (and does the same check) and then tries a couple of 192.168.x.x networks. I really dislike this kind of guesswork. It makes it very hard to debug/reproduce problems, and means you're never really sure what qemu is going to do. IMHO One of the really nice features of qemu is that it is host independent. I agree with this - guesswork and invisible options can be confusing. That's why I suggest what I think is the simplest solution: Just let this be overridable on the command line. -- Asheesh. -- Don't suspect your friends -- turn them in! -- Brazil
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Jackson wrote: So while this setup is being made configurable, I think it would probably be best for qemu's range to be changed to a random range. The customizable subnet is obviously the preferred choice, but if I had to choose a subnet I'd choose 192.168.255.0/24. Someone thinks it's a broadcast subnet ;-) - -- Flavio Visentin GPG Key: http://www.zipman.it/gpgkey.asc There are only 10 types of people in this world: those who understand binary, and those who don't. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHqNkYusUmHkh1cnoRAsXTAJ44TEWsXvg0o2KPPwLAlAXI+GjiBwCfTlug +SmdxGnjlDgOhg8BWKuyrVA= =WBCX -END PGP SIGNATURE-
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
On Tue, 5 Feb 2008, Jernej Simončič wrote: On Tuesday, February 5, 2008, 22:34:04, Asheesh Laroia wrote: I agree with this - guesswork and invisible options can be confusing. That's why I suggest what I think is the simplest solution: Just let this be overridable on the command line. Isn't the user-net IP irrelevant to the outside? AFAIK, it just causes Qemu to act as a normal TCP/IP client to the OS it's running on, and the guest OS simply can't accept incoming connections (nobody actually knows that the program issuing the connections is actually hosting an OS inside). The problem I stated in the original message in the thread http://lists.gnu.org/archive/html/qemu-devel/2008-02/msg00109.html is that I want to connect from the *guest* to the *host*. Since the host and the guest are on the same subnet, only inside the guest the subnet is fake, the guest cannot e.g. ssh to the host. So I patched qemu so that the guest would have a different internal IP range, and then the guest can e.g. ssh to the host. I hope that clears things up. Let me know if further clarification is necessary. -- Asheesh. -- When a camel flies, no one laughs if it doesn't get very far!
[Qemu-devel] Re: 2.6.24 says serial8250: too much work for irq4 a lot.
On Tuesday 05 February 2008 15:07:27 H. Peter Anvin wrote: Rob Landley wrote: When running a 2.6.24 kernel built for x86-64 under qemu via serial console, doing CPU-intensive things that also produce a lot of output (such as compiling software) tends to produce the error message in the title. Anybody have a clue why? It doesn't seem to cause an actual problem, but it's kind of annoying. (If it's a qemu issue, I can go bother them. It's possible that qemu isn't delivering interrupts as often as it expects, since that's limited by the granularity of the host timer; I know the clock in qemu can run a bit slow because it only gets clock interrupts when the host system isn't too busy to schedule the emulator. But this doesn't usually cause a problem. I _think_ the message is just a this should never happen type warning, which is happening to me. But I break stuff. :) This is because Qemu spews data to the serial port without any rate limiting; this causes the in-kernel serial port driver to think the port is stuck. The serial port emulation needs to make it possible to drain the virtual FIFO every now and then, as opposed to filling it again immediately. -hpa Thanks. cc'd the right list on this one. :) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
Paul Brook wrote: but make it configurable on the command line. That way, there are no surprises ever. The rare people like me with an issue can just pass a command-line parameter in. The point I was trying to make is that qemu could easily arbitrate the guest network based on how the host is configured. If the host has a 10.0.x.x network (and I suppose if we want to be thorough, a 10.0.x.x route), then it punts to 172.16.x.x (and does the same check) and then tries a couple of 192.168.x.x networks. I really dislike this kind of guesswork. It makes it very hard to debug/reproduce problems, and means you're never really sure what qemu is going to do. IMHO One of the really nice features of qemu is that it is host independent. If it _doesn't_ guess, i.e. uses the fixed default of 10.0.2.x (or any other), then it's _not_ host independent. VM images which run perfectly on many hosts will breaks on some hosts, which happen to use a conflicted subnet on their host interfaces. That's not host independence. Whereas if it does the auto-selection suggested (I don't regard pick an address not used already by the host as guesswork), then many VM images will run without change on more hosts. It makes sense to have a configuration option to statically set the subnet used by Qemu, of course. Auto-selection seems like it would be useful for some things - especially VM images which are shipped with run Qemu with these options to use this image. -- Jamie
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
On Wednesday 06 February 2008, Jamie Lokier wrote: Paul Brook wrote: but make it configurable on the command line. That way, there are no surprises ever. The rare people like me with an issue can just pass a command-line parameter in. The point I was trying to make is that qemu could easily arbitrate the guest network based on how the host is configured. If the host has a 10.0.x.x network (and I suppose if we want to be thorough, a 10.0.x.x route), then it punts to 172.16.x.x (and does the same check) and then tries a couple of 192.168.x.x networks. I really dislike this kind of guesswork. It makes it very hard to debug/reproduce problems, and means you're never really sure what qemu is going to do. IMHO One of the really nice features of qemu is that it is host independent. If it _doesn't_ guess, i.e. uses the fixed default of 10.0.2.x (or any other), then it's _not_ host independent. Well, obviously anything that involves talking to the host or the outside world is never going to completely host independent. Your case will also break if you run it on a machine with no internet connection. The environment inside qemu is consistent. If you have qemu automagically guess things then the gust OS also has to be capable of coping with things changing underneath it. Paul
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 my MacBook, fullscreen SDL with a HW surface can indeed perform much better (550 Mpixels/sec) than fullscreen GL (190 Mpixels/sec). With a SW surface, results are equivalent to GL though. In windowed (800x600) mode, SDL performs at 28 Mpixels/sec and GL at 150 Mpixels/sec. So, SDL 1.2 for OSX (CG?) in windowed mode is indeed sub-optimal. I have not tried with SDL trunk yet. You can get my tests as svn co http://svn.beauchesne.info/svn/gwenole/projects/blitter-tests/trunk blitter-tests Note: I am not sure if I am using GL/PBOs correctly though I followed the specs. I mean the tests run e.g. on Linux but not on Windows with the same level of drivers (nvidia 169.xx). In the latter case, the program crashes in glUnmapBuffer()... Regards, Gwenolé.
