[Qemu-devel] Re: [PATCH v2 2/3] Cocoa: ppc64 host support

[Mike Kronenberg]

On 06.12.2009, at 14:00, Andreas Faerber wrote:

> -int rectCount;
> +NSInteger rectCount;

I know that this is endorsed by apple since 10.5 but NSInteger will break 
compiling on Tiger and older. Int on the other hand is only throwing a warning 
on Leopard if I'm not mistaken.

Especially with qemu, one has to have an eye on the type... NSInteger can be an 
int or a long, depending on the host...

#if __LP64__ || NS_BUILD_32_LIKE_64
typedef long NSInteger;
typedef unsigned long NSUInteger;
#else
typedef int NSInteger;
typedef unsigned int NSUInteger;
#endif

I have no G5 at hand to test either.

Mike

smime.p7s
Description: S/MIME cryptographic signature

[Qemu-devel] [PATCH] OSX x86_32 host support

[Mike Kronenberg]

Looks like I'm a little late for the party, as always :) .

I really encourage everyone to work towards a gcc4.x solution for OS X.

I just read and tried Alexanders x86_64 patch, as I finished our x86_32.
If we could reach an out of the box solution for OS X, that would be  
great!


You'll find the patches at [1]
It's basically an adaption of Pauls, Gwenoles and the Qs gcc4 OS X x86  
patches.


Best regards
Mike

[1] http://www.kronenberg.org/qemu

smime.p7s
Description: S/MIME cryptographic signature

Re: [Qemu-devel] [PATCH] OSX x86_32 host support

[Mike Kronenberg]

 Alex,


You'll find the patches at [1]
It's basically an adaption of Pauls, Gwenoles and the Qs gcc4 OS X  
x86 patches.


I'd rather go with Michael Matz's gcc4 patches. They look more sane  
and clean to me than Gwenoles do and I believe the 5% performance  
hit that goes with them is no real problem, as most people should be  
using x86_64 nowadays anyway. On OSX this is even less of a problem,  
as only few Intel Macs are not capable of running x86_64 code  
(namely the Core Solo and Core Duo generation) and there is no need  
to run an x86_64 kernel to use x86_64 userspace code.
And I'm one of them, stuck with a Core Duo Macbook pro, which will  
stay for some more time :)

But I do have a Core 2 Duo to test x86-64.

If by any chance you find the time to do this, please try to get  
Michael Matz's patches conditional for gcc4 (no performance hit on  
gcc3) and do the mach-o i386 support separate from that. I believe  
this way everyone benefits from it and we could finally remove the  
gcc3 dependency.


Cheers,

Alex


Yes, I'll do probably a clean patch on top of yours, so that all hosts  
can be satisfied.


Best Mike

smime.p7s
Description: S/MIME cryptographic signature

Re: [Qemu-devel] [PATCH 1/5] Fix i386 Host

[Mike Kronenberg]

On 18.01.2008, at 00:25, Andreas Färber wrote:



Am 17.01.2008 um 18:34 schrieb Alexander Graf:

I tested sparc-softmmu, ppc-softmmu, ppc64-softmmu, i386-softmmu  
on Linux/i386 from your gcc4 branch. It compiles okay on gcc (GCC)  
4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2). Runtime  
behavior was identical to CVS+gcc-3.4.


Could you please test gcc4 for PowerPC as well? I don't see a  
reason this should not work on OSX/PPC.


As mentioned earlier, on OSX/ppc QEMU worked even without this patch  
mostly (with always_inline fix applied), only when running Q I got  
occasional crashes.


The gcc4 git branch plus always_inline fix compiles sparc-softmmu  
fine on powerpc-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc.  
build 5465). As usual there are some signedness warnings. It ran as  
fine as without the fix. The other softmmus and the combination with  
Q I haven't checked yet.


Is this patch supposed to work on OSX/i386 as well as is, or does  
that require some of the existing patches?


Andreas




OS X/i386 needs at least a fix for "relocation_info".
You find a stab at it in qemu-0.9.1-osx-intel-port.patch[1]... put it  
must first be adapted to Alex's patches.


Mike

[1] 
http://www.kju-app.org/proj/browser/branches/0_9_1/patches/qemu-0.9.1-osx-intel-port.patch?format=raw

smime.p7s
Description: S/MIME cryptographic signature

Re: [Qemu-devel] [PATCH 1/5] Fix i386 Host

[Mike Kronenberg]

On 18.01.2008, at 01:40, Mike Kronenberg wrote:



On 18.01.2008, at 00:25, Andreas Färber wrote:



Am 17.01.2008 um 18:34 schrieb Alexander Graf:

I tested sparc-softmmu, ppc-softmmu, ppc64-softmmu, i386-softmmu  
on Linux/i386 from your gcc4 branch. It compiles okay on gcc  
(GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2).  
Runtime behavior was identical to CVS+gcc-3.4.


Could you please test gcc4 for PowerPC as well? I don't see a  
reason this should not work on OSX/PPC.


As mentioned earlier, on OSX/ppc QEMU worked even without this  
patch mostly (with always_inline fix applied), only when running Q  
I got occasional crashes.


The gcc4 git branch plus always_inline fix compiles sparc-softmmu  
fine on powerpc-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc.  
build 5465). As usual there are some signedness warnings. It ran as  
fine as without the fix. The other softmmus and the combination  
with Q I haven't checked yet.


Is this patch supposed to work on OSX/i386 as well as is, or does  
that require some of the existing patches?


Andreas




OS X/i386 needs at least a fix for "relocation_info".
You find a stab at it in qemu-0.9.1-osx-intel-port.patch[1]... put  
it must first be adapted to Alex's patches.


Mike

[1] 
http://www.kju-app.org/proj/browser/branches/0_9_1/patches/qemu-0.9.1-osx-intel-port.patch?format=raw



I tried it quick and dirty with Alex osx-patch (without exec-all.h  
part) on a x86_64.
everything except ppc-softmmu (/tmp/qemu/target-ppc/exec.h:135:2:  
error: #endif without #if) compiled fine. I'm going to make some more  
test and try to use Alex relocation fix on host i386.


Mike

smime.p7s
Description: S/MIME cryptographic signature

[Qemu-devel] [patch] cocoa.m - Core Graphics support

[Mike Kronenberg]

This is a complete rewrite of cocoa.m to support Core Graphics.

As mentioned in earlier threads, the QuickDraw API is depreciated  
starting with OS X 10.4.

Now with OS X 10.5 it won't even compile QuickDraw code on x86_64.


This implementation of cocoa.m has the following features:

[new] partial drawing of the window as needed, implemented with CG.
[new] fullscreen support
[new] tablet support
[new] View menu and item to enter Fullscreen (cmd-f)
[new] Help menu and items to show qemu-doc.html (cmd-?) and qemu- 
tec.html in the OS X "Help Viewer"

[new] -name is shown in Title-bar of window
[fix] Application menu creation for 10.4+ (API is private as of 10.4)
[fix] Mouse-clicks on the guests window widgets are no longer  
intercepted
[fix] apple keyboard shortcuts forwarded (minimize (cmd-m), hide QEMU  
(cmd-h), quit QEMU (cmd-q))


It should compile on ppc/intel starting form 10.3 (10.2 with the known  
workarounds).


Please test and comment

Mike

File as .gz
http://www.kberg.ch/qemu/091patches/cocoa.m.gz




/*
 * QEMU Cocoa CG display driver
 *
 * Copyright (c) 2008 Mike Kronenberg
 *
 * Permission is hereby granted, free of charge, to any person  
obtaining a copy
 * of this software and associated documentation files (the  
"Software"), to deal
 * in the Software without restriction, including without limitation  
the rights
 * to use, copy, modify, merge, publish, distribute, sublicense, and/ 
or sell
 * copies of the Software, and to permit persons to whom the Software  
is

 * furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be  
included in

 * all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,  
EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF  
MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT  
SHALL
 * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES  
OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,  
ARISING FROM,
 * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER  
DEALINGS IN

 * THE SOFTWARE.
 */

#import 

#include "qemu-common.h"
#include "console.h"
#include "sysemu.h"


//#define DEBUG

#ifdef DEBUG
#define COCOA_DEBUG(...)  { (void) fprintf (stdout, __VA_ARGS__); }
#else
#define COCOA_DEBUG(...)  ((void) 0)
#endif

#define cgrect(nsrect) (*(CGRect *)&(nsrect))
#define COCOA_MOUSE_EVENT \
if (isTabletEnabled) { \
kbd_mouse_event((int)(p.x * 0x7FFF / screen.width), (int) 
((screen.height - p.y) * 0x7FFF / screen.height), 0, buttons); \

} else if (isMouseGrabed) { \
kbd_mouse_event((int)[event deltaX], (int)[event deltaY],  
0, buttons); \

} else { \
[NSApp sendEvent:event]; \
}

typedef struct {
int width;
int height;
int bitsPerComponent;
int bitsPerPixel;
} QEMUScreen;

int qemu_main(int argc, char **argv); // main defined in qemu/vl.c
NSWindow *normalWindow;
id cocoaView;
static void *screenBuffer;

int gArgc;
char **gArgv;

// keymap conversion
int keymap[] =
{
//  SdlImacImacHSdlH104xtH  104xtC  sdl
30, //  0   0x000x1eA   QZ_a
31, //  1   0x010x1fS   QZ_s
32, //  2   0x020x20D   QZ_d
33, //  3   0x030x21F   QZ_f
35, //  4   0x040x23H   QZ_h
34, //  5   0x050x22G   QZ_g
44, //  6   0x060x2cZ   QZ_z
45, //  7   0x070x2dX   QZ_x
46, //  8   0x080x2eC   QZ_c
47, //  9   0x090x2fV   QZ_v
0,  //  10  0x0AUndefined
48, //  11  0x0B0x30B   QZ_b
16, //  12  0x0C0x10Q   QZ_q
17, //  13  0x0D0x11W   QZ_w
18, //  14  0x0E0x12E   QZ_e
19, //  15  0x0F0x13R   QZ_r
21, //  16  0x100x15Y   QZ_y
20, //  17  0x110x14T   QZ_t
2,  //  18  0x120x021   QZ_1
3,  //  19  0x130x032   QZ_2
4,  //  20  0x140x043   QZ_3
5,  //  21  0x150x054   QZ_4
7,  //  22  0x160x076   QZ_6
6,  //  23  0x170x065   QZ_5
13, //  24  0x180x0d=   QZ_EQUALS
10, //  25  0x190x0a9   QZ_9
8,  //  26  0x1A0x087   QZ_7
12, //  27  0x1B0x0c-   QZ_MINUS
9,  //  28  0x1C0x098   QZ_8
11, //  29  

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Mike Kronenberg]

On 30.01.2008, at 19:59, Alexander Graf wrote:



On Jan 21, 2008, at 5:18 PM, Mike Kronenberg wrote:


This is a complete rewrite of cocoa.m to support Core Graphics.

As mentioned in earlier threads, the QuickDraw API is depreciated  
starting with OS X 10.4.

Now with OS X 10.5 it won't even compile QuickDraw code on x86_64.


This implementation of cocoa.m has the following features:

[new] partial drawing of the window as needed, implemented with CG.
[new] fullscreen support
[new] tablet support
[new] View menu and item to enter Fullscreen (cmd-f)
[new] Help menu and items to show qemu-doc.html (cmd-?) and qemu- 
tec.html in the OS X "Help Viewer"

[new] -name is shown in Title-bar of window
[fix] Application menu creation for 10.4+ (API is private as of 10.4)
[fix] Mouse-clicks on the guests window widgets are no longer  
intercepted
[fix] apple keyboard shortcuts forwarded (minimize (cmd-m), hide  
QEMU (cmd-h), quit QEMU (cmd-q))


It should compile on ppc/intel starting form 10.3 (10.2 with the  
known workarounds).


Please test and comment


I'm sorry that I didn't find the time to test this implementation  
before.


It's damn slow.

I ran it using my x86_64 on 10.5.1, targetting x86_64-softmmu and  
booting a linux kernel. I could literally see every like getting  
repainted (which btw did not happen with my quick hacky version I  
sent to the list some time ago).


I think the major problem is that too much is being done during  
drawRect. If I understand the code correctly, you create CGImage  
objects on every repaint, which is prone to be slow.


Why not simply reuse the framebuffer qemu provides anyway and leave  
everything else to CG?


Alex





Hi Alex,

yes, as stated earlyer, it is slower than Quickdraw, especially if the  
whole screen is redrawn. Overal emulation speed for GUI apps is  
faster, dough, as only small portions of the screen are redrawn.


Unfortunateley, there is no "official" direct access to the  
framebuffer anymore, since apple depreciated QuickDraw. [1]
This way, there is no sharing/direct mapping of the cg framebuffer and  
qemu screenbuffer anymore.
Every time, a section needs display, that part of the qemu  
screenbuffer is mapped to a cg image and then copied on top of the CG  
stack.
CG is fully OpenGL based, so basically, if it needs to refresh an  
area, it has to load the area as texture, hence the copy.


Offtoppic about updated regions in Windows:
While testing with Quartzdebug, I realized, that qemu is updating  
always the whole screenwidth even if only the mouse is moved... is  
this a qemu problem, or is this the default windows behaviour?


Mike

[1] http://developer.apple.com/documentation/Carbon/Conceptual/QuickDrawToQuartz2D/tq_image_data/chapter_6_section_2.html#/ 
/apple_ref/doc/uid/TP40001098-CH227-BBCFFDBB

smime.p7s
Description: S/MIME cryptographic signature

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Mike Kronenberg]

I ran it using my x86_64 on 10.5.1, targetting x86_64-softmmu and  
booting a linux kernel. I could literally see every like getting  
repainted (which btw did not happen with my quick hacky version I  
sent to the list some time ago).


You did not notice the effect with Your implementation, because the  
the whole screen is redrawn every time.

With this implementation, only the parts requested by qemu are updated.

If You take a dosprompt, every line that moves up, triggers a redraw  
(only for the specific line) - this is why you notice the redraw.

You can test this easily with the Quartz debugger.

But never the less, overall speed is much faster with partial redraw,  
than if You redraw the whole screen every time.


Mike




smime.p7s
Description: S/MIME cryptographic signature

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

[Mike Kronenberg]

After a little discussion on the list, I made this patch for cocoa.m,  
to replace CoreGraphic by OpenGL.


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.

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.


Please test and comment.

 Mike

[1] http://www.kberg.ch/qemu/091patches/cocoa_m_OpenGL.diff.gz





--- /Users/mike/Documents/Qemu091gcc4/qemu/cocoa.m_original.m	 
2008-01-21 17:11:30.0 +0100
+++ /Users/mike/Documents/Qemu091gcc4/qemu/cocoa.m	2008-02-01  
17:11:41.0 +0100

@@ -22,12 +22,17 @@
  * THE SOFTWARE.
  */

+#include 
+
 #import 

+#import 
+
 #include "qemu-common.h"
 #include "console.h"
 #include "sysemu.h"

+#define titleBarHeight 21.0

 //#define DEBUG

@@ -54,6 +59,16 @@
 int bitsPerPixel;
 } QEMUScreen;

+typedef struct {
+float x;
+float y;
+float width;
+float height;
+float dx;
+float dy;
+float zoom;
+} COCOADisplayProperties;
+
 int qemu_main(int argc, char **argv); // main defined in qemu/vl.c
 NSWindow *normalWindow;
 id cocoaView;
@@ -246,18 +261,19 @@
 QemuCocoaView
  --
 */
[EMAIL PROTECTED] QemuCocoaView : NSView
[EMAIL PROTECTED] QemuCocoaView : NSOpenGLView
 {
 QEMUScreen screen;
+COCOADisplayProperties displayProperties;
 NSWindow *fullScreenWindow;
-float cx,cy,cw,ch,cdx,cdy;
-CGDataProviderRef dataProviderRef;
+GLuint screen_tex;
 int modifiers_state[256];
 BOOL isMouseGrabed;
 BOOL isFullscreen;
 BOOL isAbsoluteEnabled;
 BOOL isTabletEnabled;
 }
+- (void) setContentDimensionsForFrame:(NSRect)rect;
 - (void) resizeContentToWidth:(int)w height:(int)h displayState: 
(DisplayState *)ds;

 - (void) grabMouse;
 - (void) ungrabMouse;
@@ -266,17 +282,16 @@
 - (void) setAbsoluteEnabled:(BOOL)tIsAbsoluteEnabled;
 - (BOOL) isMouseGrabed;
 - (BOOL) isAbsoluteEnabled;
-- (float) cdx;
-- (float) cdy;
 - (QEMUScreen) gscreen;
+- (COCOADisplayProperties) displayProperties;
 @end

 @implementation QemuCocoaView
-- (id)initWithFrame:(NSRect)frameRect
+- (id)initWithFrame:(NSRect)frameRect pixelFormat: 
(NSOpenGLPixelFormat *)format

 {
-COCOA_DEBUG("QemuCocoaView: initWithFrame\n");
+COCOA_DEBUG("QemuCocoaView: initWithFrame:pixelFormat\n");

-self = [super initWithFrame:frameRect];
+self = [super initWithFrame:frameRect pixelFormat:format];
 if (self) {

 screen.bitsPerComponent = 8;
@@ -284,6 +299,8 @@
 screen.width = frameRect.size.width;
 screen.height = frameRect.size.height;

+displayProperties.zoom = 1.0;
+
 }
 return self;
 }
@@ -295,110 +312,118 @@
 if (screenBuffer)
 free(screenBuffer);

-if (dataProviderRef)
-CGDataProviderRelease(dataProviderRef);
-
 [super dealloc];
 }

 - (void) drawRect:(NSRect) rect
 {
-COCOA_DEBUG("QemuCocoaView: drawRect\n");
+COCOA_DEBUG("QemuCocoaView: drawRect: NSRect(%f, %f, %f, %f)\n",  
rect.origin.x, rect.origin.y, rect.size.width, rect.size.height);


 if ((int)screenBuffer == -1)
 return;

-// get CoreGraphic context
-CGContextRef viewContextRef = [[NSGraphicsContext currentContext]  
graphicsPort];
-CGContextSetInterpolationQuality (viewContextRef,  
kCGInterpolationNone);

-CGContextSetShouldAntialias (viewContextRef, NO);
-
-// draw screen bitmap directly to Core Graphics context
-if (dataProviderRef) {
-CGImageRef imageRef = CGImageCreate(
-screen.width, //width
-screen.height, //height
-screen.bitsPerComponent, //bitsPerComponent
-screen.bitsPerPixel, //bitsPerPixel
-(screen.width * 4), //bytesPerRow
+// remove old texture
+if( screen_tex != 0) {
+glDeleteTextures(1, &screen_tex);
+}
+
+screen_tex = 1;
+float onePixel[2];
+onePixel[0] = 2.0 / displayProperties.width;
+onePixel[1] = 2.0 / displayProperties.height;
+
+//calculate the texure rect
+NSRect clipRect;
+clipRect = NSMakeRect(
+0.0, // we update the whole width, as QEMU in vga is always  
updating whole memory pages)
+floor((float)screen.height - (rect.origin.y +  
rect.size.height) / displayProperties.dy),

+(float)screen.width,
+ceil(rect.size.height / displayProperties.dy));
+int start = (int)clipRect.origin.y * screen.width * 4;
+unsigned char *startPointer = screenBuffer;
+
+//adapt the drawRect to the textureRect
+rect = NSMakeRect(
+0.0, // we update the whole width, as QEMU in vga is al

Re: [Qemu-devel] [PATCH 0/4] Intel Mac OS X Host support

[Mike Kronenberg]

On 31.01.2008, at 16:55, Alexander Graf wrote:


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.


Please comment on these patches. Commits are welcome too.

Regards,

Alex




Hi Alex,

txs for preparing Ground for mach-o.
I think this is the right way to go, as these patches in one or the  
other form are needed with tcg, too.


ATM I try to test on a i386 Mac, but I somehow lost track of all  
patches.
I tried a build with qemu 20081018 and gcc patches 1/5, 2/5, 3/5, 4/5  
and 1/4, 2/4, 3/4 and 4/4... it builds, but loads of
/var/folders/Td/TdBadE0bFQuD2AmzgK43qTI/-Tmp-//ccIs2Keq.s: 
31549:indirect call without `*'

and the binary segfaults immediately.

Did I miss a patch... or is that where i start to debug? ;)

Mike

smime.p7s
Description: S/MIME cryptographic signature

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

[Mike Kronenberg]

On 01.02.2008, at 17:45, Mike Kronenberg wrote:

After a little discussion on the list, I made this patch for  
cocoa.m, to replace CoreGraphic by OpenGL.


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.

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.


Please test and comment.

Mike

[1] http://www.kberg.ch/qemu/091patches/cocoa_m_OpenGL.diff.gz


Just wanted to ask, if this OpenGL patch for cocoa gets applied,
else I have to fix two minor issues with the my CoreGraphics for cocoa.

Mike

smime.p7s
Description: S/MIME cryptographic signature

Re: [Qemu-devel] [PATCH] OSX x86_64 host support

[Mike Kronenberg]

Hi from Q,

Yes we have a OpenGL, CG and in dev a Core Animation version for vga  
output.
Quickdraw is depreciated since Tiger. But as QEMU has never added gcc4  
to the tool-chain, there was never a official running version on any  
Intel machine :)


Our OpenGL and CG  implementation offer fullscreen and tablet support  
as-well.
Fullscreen is very slow on the CG implementation, but was speeded up  
by Core-Animation.


I'd going with the OpenGL implementation, if the "true" opengl  
implementation for QEMU was coming ;).

Else the partial screen-redrawing of CG is faster than OpenGL.

On the other hand, the QT implementation is and remains the fastest  
solution, as no of the other allows directly accessing the video- 
buffer, which results in way more copying.


If there is need for back-porting any of this stuff, that would be no  
problem.


For the new Q front-end, we are going with a CG approach only, but we  
bypass cocoa.m altogether and mmap (shmem allows only 4mb on OS X)  
everything to the viewer app.


Mike


On 07.12.2007, at 21:19, Andreas Färber wrote:



Am 07.12.2007 um 21:12 schrieb Alexander Graf:



On Dec 7, 2007, at 6:43 PM, Pierre d'Herbemont wrote:



On Dec 7, 2007, at 1:42 PM, Alexander Graf wrote:

Right now there is no graphical output available except for VNC,  
as the cocoa output depends on deprecated APIs that are no longer  
available in 64-bit mode and SDL does not compile on x86_64  
Darwin yet.


This is the QuickDraw API? If so, it should be quite straight  
forward to use OpenGL or CoreGraphics instead...
What about not disabling Cocoa, and simply print a nice #error or  
#warning that explains that the quickdraw part needs fixing?


Pierre.





Yes, it's the QuickDraw API. I'm currently looking into this, so if  
you know anything about the transition to CoreGraphics, please let  
me know or point me to some documentation on that.


I'd rather have a proper patch for the cocoa output than anything  
else. Disabling it is only a temporary workaround to have it build  
at all.


Doesn't Q offer all three? I'm pretty sure I've been using its  
OpenGL option with success.


Andreas




Cheers,

Alex










smime.p7s
Description: S/MIME cryptographic signature

Re: [Qemu-devel] Support Questions

[Mike Kronenberg]

On 13.06.2006, at 16:37, Joe Lee wrote:

I came across a product called Iemulator and think it based on  
QEMU. If so, I wanted to know how possible is it to re-brand qemu  
to something similar to Iemulator.


IEmulator (as of the 1.7.x series) is a rebrand of a early stage  
project Q Build (http://www.kju-app.org/proj/) which is based on QEMU  
itself. Q has different graphic output and some frontend extensions  
compared to QEMU. We tried to port the natural virtualization modul  
qvm86 to OS X, too. But as QEMU has moved on, we have put a hold on  
that. So QEMU on OS X (ppc and intel) remains a simulation.


Mike



Also, I am quite new to QEMU and virtualization in general and  
wanted to know the difference between QEMU and product like OpenVZ.  
Based on my reading on them I think they are quite different. I  
suppose QEMU is more like VMware aimed at end users and OpenVZ  
would be more for Enterprise servers.


Joe



Natalia Portillo wrote:

Well,

Fabrice Bellard is main developer, and KQEMU whole developer.
Paul Brook maintains ARM system, and QVM86 whole developer.
Jocelyn Mayer (away) maintains PPC system.
Blue Swirl maintains Sparc system.
A couple of collaborators do development taks.
I maintain the OS compatibility list and do extensive operating  
system compatibility testing.


Just, for what you want that information?

El 12/06/2006, a las 20:32, Joe Lee escribió:

Wanted to know about individuals that provides support and custom  
development for QEUM.




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel







___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QEMU GUI

[Mike Kronenberg]

Great Idea...

This would be in c++ then, or do You fancy another wxWidget flavour?  
(I remember You did not like c++ in QEMU)


If people are interested, we could try to port Q as a base, since  
it's going to be obsolete anyway (either by the new QEMU GUI or  
leopard)... :)

http://www.kju-app.org
http://www.kju-app.org/proj (trac)

Mike

On 21.06.2006, at 20:11, Fabrice Bellard wrote:


Hi,

Concerning the QEMU GUI, my mind slightly evolved since my last  
posts on the topic: I think that a wxWidgets GUI would be the best  
as it is reasonnably portable and because it uses the native GUIs.


If someone is interested, I am ready to try to include such a GUI  
in the QEMU repository even if it is not usable yet.


Regards,

Fabrice.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] future OS X support

[Mike Kronenberg]

@Fabrice
How are your plans about supporting OS X in the future?

We, for our part, are eager to push dev on OS X:
- with the patches of Gwenole and pbrook, qemu 0.8.2 builds great on  
OS X ppc and intel (gcc4). All tests are OK.
- I'm willing to rewrite my OS X block.c patches for hardware CD-ROM  
support.
- I've just written a complete new cocoa frontend based on Anthony  
shmem patches (quartz and openGL). (only problem is the 4mb limit on  
OS X atm)
- There are some other small patches like basic bootorder support  
that are ready, too.


As qemu was one of the first usable emulators on OS X, it is still  
widely used and known.

Things even look like we get included on the C'T disk next month

Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Please help build qemu/darwin-user on Mac Intel

[Mike Kronenberg]

Hi,

we have decided to wait for the next qemu release until we update the  
patches for kju, as qemu dev has picked up speed, which is good.

Never the less, you can grab the patches for qemu cvs (OS X Intel) here:

http://www.kberg.ch/qemu/cvspatches20070202.zip

Best Regards
Mike

On 03.02.2007, at 08:47, Pierre d'Herbemont wrote:


Hi,

On 3 févr. 07, at 02:37, Ilya Shar wrote:


I am trying to build i386-darwin-user to run it on an
x86 Mac.  I'm on Mac OS 10.4 Intel with gcc 3.3 and
I'm getting compiler errors right away:

$ cvs
-d:pserver:[EMAIL PROTECTED]:/cvsroot/darwine


Ilya, qemu's CVS has the most up-to-date version of darwin-user  
now, so you should use it intead of the version which is in the  
darwine's cvs. Moreover to compile qemu on intel you'll need a few  
patche. The team behind Q.app has collected them for you [1]. Also  
I am not sure that gcc 3.3 can build Mac Intel binaries that are  
compliant with the current Mac OS X x86 ABI. So you may also need  
the gcc 4.0 patches that you should find in [1].


Pierre.

[1] http://www.kju-app.org/proj/browser/trunk/patches


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Please help build qemu/darwin-user on Mac Intel

[Mike Kronenberg]

Hi Ilya,

I just built from CVS before I zipped up the patches, here is the  
order I applied them:


#gcc4 patches
patch -p1 -u < ../patches/qemu-0.8.3-gcc4.patch
patch -p1 -u < ../patches/qemu-0.7.2-dyngen-check-stack-clobbers.patch
patch -p1 -u < ../patches/qemu-0.7.2-gcc4-opts.patch
patch -p1 -u < ../patches/qemu-0.8.0-gcc4-hacks.patch

#OS X86 patches
patch -p1 -u < ../patches/qemu-0.8.3-enforce-16byte-stack-boundary.patch
patch -p1 -u -f < ../patches/qemu-0.8.3-i386-FORCE_RET.patch
patch -p1 -u < ../patches/qemu-0.8.3-osx-intel-port.patch

patch -p1 -u < ../patches/qemu-0.8.0-osx-bugfix.patch

notice the force -f for the FORCE_RET patch :).
I had to update the old patches, because of changes like the updated  
defines for return(). Especially qemu-0.7.0-gcc4.patch does fail to  
apply because of that and was replaced with qemu-0.8.3-gcc4.patch.


then I configured with
./configure --prefix=../products/i386 --enable-cocoa --enable-adlib -- 
disable-gcc-check --target-list=i386-softmmu

Jep, I did not test with other targets.

Mike

On 04.02.2007, at 08:37, Ilya Shar wrote:


Hi Mike,

Thanks a lot for the patches.  I applied them
(together with qemu-0.7.0-gcc4.patch, which appears to
be necessary although it's not in the archive you
created) but in the middle of the build dyngen rejects
op.o:

../dyngen -c -o opc.h op.o
dyngen: Unable to replace ret with jmp in
op_bsfl_T0_cc
make[1]: *** [opc.h] Error 1

Did I mess up somewhere or there is something wrong
with the patches?

Thanks again for your help!
Ilya


--- Mike Kronenberg <[EMAIL PROTECTED]> wrote:


Hi,

we have decided to wait for the next qemu release
until we update the
patches for kju, as qemu dev has picked up speed,
which is good.
Never the less, you can grab the patches for qemu
cvs (OS X Intel) here:

http://www.kberg.ch/qemu/cvspatches20070202.zip

Best Regards
Mike

On 03.02.2007, at 08:47, Pierre d'Herbemont wrote:


Hi,

On 3 févr. 07, at 02:37, Ilya Shar wrote:


I am trying to build i386-darwin-user to run it

on an

x86 Mac.  I'm on Mac OS 10.4 Intel with gcc 3.3

and

I'm getting compiler errors right away:

$ cvs




-d:pserver:[EMAIL PROTECTED]:/cvsroot/darwine


Ilya, qemu's CVS has the most up-to-date version

of darwin-user

now, so you should use it intead of the version

which is in the

darwine's cvs. Moreover to compile qemu on intel

you'll need a few

patche. The team behind Q.app has collected them

for you [1]. Also

I am not sure that gcc 3.3 can build Mac Intel

binaries that are

compliant with the current Mac OS X x86 ABI. So

you may also need

the gcc 4.0 patches that you should find in [1].

Pierre.

[1]

http://www.kju-app.org/proj/browser/trunk/patches



___
Qemu-devel mailing list
Qemu-devel@nongnu.org


http://lists.nongnu.org/mailman/listinfo/qemu-devel



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel







__ 
__

Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] KQEMU Darwin port status?

[Mike Kronenberg]

Hi there,

On 17.03.2007, at 20:30, Philip Boulain wrote:

Hi! I'll keep this succinct, because I'm sure they'd be FAQ-grade  
questions if this list had a FAQ:  :)


 1) Where's the version repository for KQEMU? It doesn't appear to  
be under/alongside QEMU itself.
 2) Has anyone made any progress with porting KQEMU to Darwin x86?  
I've had a look at the GPL release (hurrah) and it looked to me  
like the platform-specific parts would mostly involve writing an I/ 
O Kit Device Driver which provided a device node with suitable  
ioctl support[1], as the FreeBSD version does. The mailing list  
archives show some activity in this area, but without 1) it's hard  
to get an overview. (There are also obvious-looking compilation  
problems with the distributed 1.3.0pre11 sources, but I'm guessing  
that someone who knows assembler better than now has fixed them by  
now.)


I have made a empty kext and a dummy client to do some tests on this  
topics. Boundary crossing is working well, so by now the kext part is  
ready.

http://www.kronenberg.org/files/kqemu_poc.zip

Unfortunately, Apple decided to remove/hide some of the vm_* API  
(especially vm_map_(un)wire in Tiger. (It was available on Panther.  
vm_map_user_pageable was never part of Darwin). So any suggestions on  
how to lock user pages in Darwin would be very welcome.


So right now, I'm reading thru lots of stuff to replace the  
unsupported kqemu-freebsd.c function calls. If someone is interested,  
I post snapshots or put it in the http://www.kju-app.org repository,  
until it's working and can be merged.




Thanks,
LionsPhil
1. http://developer.apple.com/documentation/Darwin/Conceptual/ 
KernelProgramming/boundaries/chapter_14_section_6.html


Best Regards
Mike



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] KQEMU Darwin port status?

[Mike Kronenberg]

Cool :)

just dlded your tarball, and things work well.

I'm about to add the code to the "genuine" kqemu environment. With  
kqemu Variables and function stubs.

I hope to post back soon.

Mike


On 20.03.2007, at 03:18, Philip Boulain wrote:


Mike Kronenberg wrote:
> So any suggestions on how to lock user pages in Darwin would be  
very welcome.


Philip Boulain wrote:

Thanks; looking at this post, I'm probably barking up the right tree


Right. I've cobbled up the aformentioned prototype, and it working  
insofar that the modified and now-leaky version of Mike's test  
client is allocating sequential lumps of memory when you bash the  
EXEC button, and I'm getting plausible sequential physical  
addresses out; I can also read/write to the memory via the  
IOMemoryDescriptor (the client initialises the first uint8 of the  
'lump' to 23, which will appear in the system log/console; the kext  
writes 42 to it, which will appear in the client).


http://www.ecs.soton.ac.uk/~prb/junk/qemu-devel-darwin- 
kqemu-19mar07.tar.bz2 (1934KB)


Summary of changes to Mike's earlier example:
 - 'transporter' struct now has a 'uint8_t* lump_of_ram;' member,  
to act as some application-allocated memory (it mallocs (and never  
frees, ahem) 2K each EXEC ioctl).
 - I dropped Mike's KEXT code into the HelloIOKit example, so that  
it does all the IO KEXT initialisation. I'm not convinced that this  
is actually necessary.
   A side effect is that 'kqemu.ext' is now called  
'HelloIOKit.ext'. Please bear with the quick and nasty prototype. ;)

 - The KQEMU_EXEC ioctl handling case now:
   - Constructs a IOGeneralMemoryDescriptor and initialises it to  
point to the lump_of_ram in the transporter struct
   - 'Prepares' the Descriptor. I believe that this is performing  
the required locking:
 "This involves paging in the memory, if necessary, and wiring  
it down for the duration of the transfer." [1]
   - Prints the physical address to the system log, and does the  
aformentioned read/write

   - 'Completes' the Descriptor (unlocking)
   - Destructs (pedantically: unreferences) the  
IOGeneralMemoryDescriptor


[De]constructing a fresh IOGMD each time is rough-prototype-code  
garbage. One can be recycled by just calling initWithAddress()  
again on it---at a _glance_, it looks like the kqemu_instance  
struct would be a sensible place to put it.


Phil
1. http://developer.apple.com/documentation/Darwin/Reference/ 
KernelIOKitFramework/IOMemoryDescriptor/Classes/IOMemoryDescriptor/ 
index.html




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] KQEMU Darwin port status?

[Mike Kronenberg]

Here we go:
www.kronenberg.org/qemu/qemu-devel-darwin-kqemu-20mar07.tar.bz2

- Made a new IOKit kext proj to match all the kqemu name requirements
- moved kext header inside kqemu-darwin.cpp to lessen stray darwin  
related files

- added kqemu-kernel.h to the target
- added kqemu.h to the target
- added stubs from kqemu-kernel.h
- moved the test cases to the "playground"

The kqemuClient is updated to work with the kext and its playground.

Next I will start filling in the stubs and kqemu_open/close and  
kqemu_ioctl based on Phils prototype.

- Wondering how to convert a physical address to a page index on...

feel free to be faster :)
Mike


On 20.03.2007, at 09:02, Mike Kronenberg wrote:


Cool :)

just dlded your tarball, and things work well.

I'm about to add the code to the "genuine" kqemu environment. With  
kqemu Variables and function stubs.

I hope to post back soon.

Mike


On 20.03.2007, at 03:18, Philip Boulain wrote:


Mike Kronenberg wrote:
> So any suggestions on how to lock user pages in Darwin would be  
very welcome.


Philip Boulain wrote:

Thanks; looking at this post, I'm probably barking up the right tree


Right. I've cobbled up the aformentioned prototype, and it working  
insofar that the modified and now-leaky version of Mike's test  
client is allocating sequential lumps of memory when you bash the  
EXEC button, and I'm getting plausible sequential physical  
addresses out; I can also read/write to the memory via the  
IOMemoryDescriptor (the client initialises the first uint8 of the  
'lump' to 23, which will appear in the system log/console; the  
kext writes 42 to it, which will appear in the client).


http://www.ecs.soton.ac.uk/~prb/junk/qemu-devel-darwin- 
kqemu-19mar07.tar.bz2 (1934KB)


Summary of changes to Mike's earlier example:
 - 'transporter' struct now has a 'uint8_t* lump_of_ram;' member,  
to act as some application-allocated memory (it mallocs (and never  
frees, ahem) 2K each EXEC ioctl).
 - I dropped Mike's KEXT code into the HelloIOKit example, so that  
it does all the IO KEXT initialisation. I'm not convinced that  
this is actually necessary.
   A side effect is that 'kqemu.ext' is now called  
'HelloIOKit.ext'. Please bear with the quick and nasty prototype. ;)

 - The KQEMU_EXEC ioctl handling case now:
   - Constructs a IOGeneralMemoryDescriptor and initialises it to  
point to the lump_of_ram in the transporter struct
   - 'Prepares' the Descriptor. I believe that this is performing  
the required locking:
 "This involves paging in the memory, if necessary, and wiring  
it down for the duration of the transfer." [1]
   - Prints the physical address to the system log, and does the  
aformentioned read/write

   - 'Completes' the Descriptor (unlocking)
   - Destructs (pedantically: unreferences) the  
IOGeneralMemoryDescriptor


[De]constructing a fresh IOGMD each time is rough-prototype-code  
garbage. One can be recycled by just calling initWithAddress()  
again on it---at a _glance_, it looks like the kqemu_instance  
struct would be a sensible place to put it.


Phil
1. http://developer.apple.com/documentation/Darwin/Reference/ 
KernelIOKitFramework/IOMemoryDescriptor/Classes/IOMemoryDescriptor/ 
index.html




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] KQEMU Darwin port status?

[Mike Kronenberg]

You may want to hit me with a brick :)

here is a draft not thested or whatever of kqemu-darwin.cpp before I  
have to leave...

...just for some ideads.

/note to self
 -open a folder in kju svn tonight, so that we don't have to spam  
the list to much.


Mike

On 20.03.2007, at 12:58, Mike Kronenberg wrote:


Here we go:
www.kronenberg.org/qemu/qemu-devel-darwin-kqemu-20mar07.tar.bz2

- Made a new IOKit kext proj to match all the kqemu name requirements
- moved kext header inside kqemu-darwin.cpp to lessen stray darwin  
related files

- added kqemu-kernel.h to the target
- added kqemu.h to the target
- added stubs from kqemu-kernel.h
- moved the test cases to the "playground"

The kqemuClient is updated to work with the kext and its playground.

Next I will start filling in the stubs and kqemu_open/close and  
kqemu_ioctl based on Phils prototype.

- Wondering how to convert a physical address to a page index on...

feel free to be faster :)
Mike


On 20.03.2007, at 09:02, Mike Kronenberg wrote:


Cool :)

just dlded your tarball, and things work well.

I'm about to add the code to the "genuine" kqemu environment. With  
kqemu Variables and function stubs.

I hope to post back soon.

Mike


On 20.03.2007, at 03:18, Philip Boulain wrote:


Mike Kronenberg wrote:
> So any suggestions on how to lock user pages in Darwin would be  
very welcome.


Philip Boulain wrote:
Thanks; looking at this post, I'm probably barking up the right  
tree


Right. I've cobbled up the aformentioned prototype, and it  
working insofar that the modified and now-leaky version of Mike's  
test client is allocating sequential lumps of memory when you  
bash the EXEC button, and I'm getting plausible sequential  
physical addresses out; I can also read/write to the memory via  
the IOMemoryDescriptor (the client initialises the first uint8 of  
the 'lump' to 23, which will appear in the system log/console;  
the kext writes 42 to it, which will appear in the client).


http://www.ecs.soton.ac.uk/~prb/junk/qemu-devel-darwin- 
kqemu-19mar07.tar.bz2 (1934KB)


Summary of changes to Mike's earlier example:
 - 'transporter' struct now has a 'uint8_t* lump_of_ram;' member,  
to act as some application-allocated memory (it mallocs (and  
never frees, ahem) 2K each EXEC ioctl).
 - I dropped Mike's KEXT code into the HelloIOKit example, so  
that it does all the IO KEXT initialisation. I'm not convinced  
that this is actually necessary.
   A side effect is that 'kqemu.ext' is now called  
'HelloIOKit.ext'. Please bear with the quick and nasty prototype. ;)

 - The KQEMU_EXEC ioctl handling case now:
   - Constructs a IOGeneralMemoryDescriptor and initialises it to  
point to the lump_of_ram in the transporter struct
   - 'Prepares' the Descriptor. I believe that this is performing  
the required locking:
 "This involves paging in the memory, if necessary, and  
wiring it down for the duration of the transfer." [1]
   - Prints the physical address to the system log, and does the  
aformentioned read/write

   - 'Completes' the Descriptor (unlocking)
   - Destructs (pedantically: unreferences) the  
IOGeneralMemoryDescriptor


[De]constructing a fresh IOGMD each time is rough-prototype-code  
garbage. One can be recycled by just calling initWithAddress()  
again on it---at a _glance_, it looks like the kqemu_instance  
struct would be a sensible place to put it.


Phil
1. http://developer.apple.com/documentation/Darwin/Reference/ 
KernelIOKitFramework/IOMemoryDescriptor/Classes/ 
IOMemoryDescriptor/index.html




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




//header start - included to generate less clutter in the kqemu  
repository :)

#include 

class org_qemu_driver_kqemu : public IOService {
OSDeclareDefaultStructors(org_qemu_driver_kqemu)
public:
virtual bool init(OSDictionary* dictionary = 0);
virtual void free(void);
virtual IOService* probe(IOService* provider, SInt32* score);
virtual bool start(IOService* provider);
virtual void stop(IOService* provider);
};
//header end



#include 

#include 
#include 
#include 
#include 
#include 
#include 

#import 

//#include "kqemu-darwin.h" //we included the kext header

extern "C" {
#include  /* Tutorial says for debug only */
}

#define super IOService

// Second argument must be literal (preprocessor limitation?)
OSDefineMetaClassAndStructors(org_qemu_driver_kqemu

[Qemu-devel] 2 Questions

[Mike Kronenberg]

I'm workin on the GUI for cocoa.m...
I'm able to save/stop/start WMs from the GUI
- if i stop qemu, am I able to change vars like memory/images/network 
and start qemu with a different VM without terminating qemu?

I'm able to change images for cdrom/floppy from the GUI
- is it possible to load a image for the cdrom/floppy, if i had none at 
startup (right now it's not working in my code)

Greetings Mike
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] 2 Questions

[Mike Kronenberg]

It seams that my first Mail got eaten:
Status on my Work for cocoasupport for qemu
- made a Toolbar with options to save VM, change Image for CD-Rom/Floppy
- made a Controlling app, to start and configure WMs (right now I'm 
integrating that ap im qemu)

From an earlyer Post, in which I proposed some GUI Features:
That would be great... Probably an RFC on this list about the Mac OS X 
interface
would be useful.

Pierre.

So here I am again :)
You find my proposal at
http://www.kberg.ch/cocoaqemu/
have fun and remember, this is a Feature Demo - expect instability :)
and a little Question:
if I load a VM, are the Arguments loaded with the VM or do I have to set 
them new?

Mike
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] 2 Questions [Cocoa Driver]

[Mike Kronenberg]

[ snip ]
Pierre d'Herbemont wrote:
Very nice ;) Hope you'll produce a patch, that'll get merged in cvs ;)
Yes, but first, the code needs some major cleanup.
However when I try to launch your test app here is what I get:
iBook:~/Desktop/cocoaqemu.app/Contents steg$ ./MacOS/cocoaqemu
ZeroLink: could not load .o file:  
/Users/mike/cocoaqemu/build/cocoaqemu.build/cocoaqemu.build/Objects- 
normal/ppc/main.ob
ZeroLink: could not load .o file:  
/Users/mike/cocoaqemu/build/cocoaqemu.build/cocoaqemu.build/Objects- 
normal/ppc/qemuController.ob
ZeroLink: unknown symbol '_main'
Abort trap

I bet you use nib files and so on... In this case you'll have to 
bypass  the use of Xcode, by creating the appropriate Makefiles which 
will  build the qemu.app, I have an almost clean patch [1] that you 
may want  to use as a base. Tell me is you want more infos.

Yes, it was mainly a setup for an Interface Test, I did in Interface 
Builder. I rewrote - well I wrote the real code without the nibs 
yesterday. I will put a diff on my website, but I consider the code not 
yet suitable for submitting.

Pierre.
[1]
[snap]
Mike
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] 2 Questions

[Mike Kronenberg]

[snip]
René Korthaus wrote:

  
  I really appreciate your work... where QemuX is now, I have to
admit, that's what my abilities end
  

I like and use QemuX alot, since it uses qemu with sdl, which has still
*alot of features which are not yet supportet in cocoa (sound and
keyboard for different countrys comes to my mind).
In cocoaqemu, the commandline is still working - so it can be
controlled/started by an app like QemuX - i think that is atm the
easyer way, having multiple qemus working at the same time.
So keep up the good work!

  
   (expect some GUI work) ... so I would really like to see your
work on my mac, but Tiger does not like it... When starting it
disappears fastly from Dock... I used
  

Thanks for the note! It seams I did not remove all the static links,
and I admit, I did not test it under another user. An update is in the
making.

  
  
  latest cocoaqemu build
  builds/cocoaqemu_20050429_2.zip
  from your website... that's what the
Console says:
  
  May  2 23:31:36 rene-korthaus-ibook crashdump[610]: cocoaqemu
crashed
  May  2 23:31:37 rene-korthaus-ibook crashdump[610]: crash report
written to:
/Users/cordney/Library/Logs/CrashReporter/cocoaqemu.crash.log
  ZeroLink: could not load .o file:
/Users/mike/cocoaqemu/build/cocoaqemu.build/cocoaqemu.build/Objects-normal/ppc/main.ob
  ZeroLink: could not load .o file:
/Users/mike/cocoaqemu/build/cocoaqemu.build/cocoaqemu.build/Objects-normal/ppc/qemuController.ob
  
  
  
  Crash log is attached.
  
  
  
  
  
  
  Greetings, cordney*
  

[snap]

Greetings Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] 2 Questions

[Mike Kronenberg]

Mike Kronenberg wrote:
So here I am again :)
You find my proposal at
http://www.kberg.ch/cocoaqemu/ 
That build was pretty buggy (forgot to remove some static links).
But living in a fast World: here is a new one.
Changes:
   - portet the GUI from nib to cocoa.m (no extrenal files are needed 
anymore - CVS friendly :) )
   - removed options, which can't be changed on the fly (atm)

You find the package and the diff on my website. I'll submit the patch, 
when the code is cleaner.

http://www.kberg.ch/cocoaqemu/
Greetings Mike
PS.
is it me or is the List extremely slow (are mails handselected?)
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] cocoa aproach

[Mike Kronenberg]

Hello list
I'm still working on cocoa.m, and I made some Progress with grab/ungrab 
Mouse und Keyboard.

But right now I'm working on the Interface.
- made a Toolbar with options to save VM, change Image for CD-Rom/Floppy
- made a Controlling app, to start and configure WMs
From an earlyer Post, in which I proposed some GUI Features:
That would be great... Probably an RFC on this list about the Mac OS X interface
would be useful.
Pierre.
So here I am again :)
You find my proposal at
http://www.kberg.ch/cocoaqemu/
have fun and remember, this is a Feature Demo - expect instability :)
Mike
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] cocoa.m using openGL

[Mike Kronenberg]

Peter Stewart wrote:


Hello to all,

esp. Pierre d'Herbemont,

I have changed cocoa.m (0.7.0) to use openGL with very fast texturing. 
I removed the use of QuickDraw. The DisplayState data is now DMA'd to 
the graphics card instead of copied by the CPU. This uses apple's 
texture range extensions. The change means that the transfer of 
"display memory" incurs no CPU overhead. I also put in a bit more 
mouse stuff, and made some other fixes. I can't work out how to get 
the Window to get focus once it loses it, which is really a pain.


I Shark'd it to make sure there wasn't any overhead from the 
texturing. I tested with Knoppix and FreeDOS.


I am not sure if this is of interest to people, I just had a lazy 
weekend. I would like to give the code to the qemu project, but don't 
really know how to.



thanks,
peter.



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Great News! Especially, if somebody writes a openGL driver/wrapper for 
the GuestOS.


I'm working on cocoa.m for some time now, especially UI Things. But I 
did not get around submitting the stuff yet. You find my diff on 
www.kberg.ch/cocoaqemu. It consists of a lot of changes (including mouse 
and keyboard support :) ) Last update: this weekend.


Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] cocoa.m using openGL

[Mike Kronenberg]

Peter Stewart wrote:


Hi Hetz,

I will do a comparison, and a diff, and add some more comments.


Great, I can't wait to merge and test it :)



I have a 800Mhz ibook 640M. When I ran Knoppix, and glxgears I got 
7fps on OpenGL profiler and 5fps reported by glxgears. OpenGL profiler 
reported that a maximum of 5% of the time was being spent in OpenGL. 
On average about 2% of the time was spent in OpenGL. The peak fps was 
27 fps, this happens during the text based startup of Knoppix (the 
green bar with the text spinner). I would like to run doom2 shareware 
dos based to see what fps I get, should be okay I think, but don't 
know how to get a bootable image with the shareware software on it.


Doom2 was never released as Shareware, only Doom1. If You need a 
bootable Image, I can prepare You one of Doom1.




thanks,
peter.


Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] cocoa.m using openGL

[Mike Kronenberg]

Peter Stewart wrote:


Hi,

It looks faster than the original, but I don't have a benchmark, is  
there one?

I would really like a bootable image with Doom 1 on it.


http://www.kberg.ch/cocoaqemu/files/freedosdoom.img.zip
have fun

Here is the diff for cocoa.m ( diff cocoa.m.orig cocoa.m ) (from 
0.7.0  dl): 



Somehow, I cant patch it to cocoa.m
could you post cocoa.m as a attachement, since i have not alot in common 
with cocoa.m animore :)


Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] cocoa.m using openGL

[Mike Kronenberg]

Peter Stewart wrote:


Hi,

Sorry for using up mail space, but here is the cocoa.m file.


enjoy,
peter.


Thanks amillion!

I will try it out tomorrow.

Hope I too can produce a Patch soon, so there is not to much 
unneccessary work mergin bits'n'peaces :)


Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] cocoa.m using openGL

[Mike Kronenberg]

Hello Peter and Pierre

I have woven the patch into my patch and run some basic but in other 
times often used benchmarks with doom:


i unpacked freedos and installed doom from
http://www.kberg.ch/cocoaqemu/files/freedosdoom.img.zip

then i started doom with
doom -timedemo demo3

(reboot between the runs)

realticks with QD
2542
2544
2543
2543
2545
Average: 2543.4 => 29.3662 fps

realticks with openGL
2476
2466
2447
2451
2454
Average: 2458.8 => 30.3865 fps

To get fps from these Number you have to 35*2134/realticks

=> openGL is 3.5% faster on my system

plus
- it solves some issues i had with hiding/showing the toolbar (damaging 
the qd_view)

- it could accelerate the generation of livethumbnails i am using

Testbuild and diff are on
http://www.kberg.ch/cocoaqemu

At this point I'm asking, whether my patch should/can be included into 
the CVS, what changes I should make, or how to continue...


Mike



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] cocoa.m

[Mike Kronenberg]

Natalia Portillo wrote:



El 27/05/2005, a las 12:42, Mike Kronenberg escribió:



   -cocoalivethumbnail   => qemu produces a 100x75 PNG thumbnail  
every 10 sec


GREAT!!!

But, better if can be specified how many time and/or a shortcut (like  
in virtualpc)




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


I'll put that on my todo list.

btw:
The patch provides two thumbnailer: quality and fast
- quality: just grabs the whole screen and makes a downsample => slow 
but nice
- fast: just grabs the needed bits from current_ds => like pixel 
resample in PS :)

   => BUT if you use fast, half of the pic is ok, and half is garbage
   so if someone could look over it and find the bug, that would be great.
   one could even use a 32bit pointer to further reduce the cpu time 
needed for the thumb.


Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] cocoa.m

[Mike Kronenberg]

I'm in talks with Pierre how we should proceed.

My goals were to make qemu accessible to a broader Macintosh audience.

so besides of additions to cocoa.m, I have written a Control app to 
configure, lauch and control multiple qemu instances. Together, they 
behave just like one App.


The project is called Q (atm). You find it at http://www.kberg.ch/cocoaqemu

Q consists of multiple parts:
- qemu cocoa (of corse)
- Q Control
- Windows "Driver" Pack

The new Features of QEMU cocoa can be read in the parent posting.

What is Q Control?
- create new guestPC
- edit guestPC
- delete guestPC
- start guestPC (saved WMs inkl Thumbnails are supported)
- create new Diskimage
- livethumbnails :)

What is the Windows "Driver" Pack?
The "Driver" is a single easy installable Package for Windows that does 
the following:

- configures Windows to take advantage of qemus advanced features (SMB etc)
- Mousedriver => in planing: qemu sends Mouse-Cordinates over serial to 
guestPC - Driver on guestOS polls serial and sets MouseCursor 
accordingly. This eliminates the grab hassle. So if someone is fluent in 
qemu serialport programming, please drop me a line, how to send a simple 
byte (inkl delimiter/interrup if nec) that would me save alot of time 
reading qemu code.


Pierre would like to put the whole thing in the head tree. I would be 
ready to do so, too, if this is wanted.


thanks for your time :)

Mike out






___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] cocoa.m

[Mike Kronenberg]

Pierre d'Herbemont wrote:



On 27 mai 05, at 16:51, Mike Kronenberg wrote:

Pierre would like to put the whole thing in the head tree. I would  
be ready to do so, too, if this is wanted.



I didn't realize that the Q app was a front end. It would be much  
cleaner to have it running in qemu as the cocoa qemu driver.


That is what I tried to explain :) Atm Q is like QemuX minus/plus some 
features.


That  should be done with not much troubles, if we manage to get qemu  
thread safe. Did you try that way?


Until the 7. May I was trying to get all into qemu... sources are still 
there.


I was looking into making the contoller one thread and the each qemu a 
thread, so one can run multiple qemus. It is still on the List - but 
it's a little more time intensive (I use qemu for my work) . So I gutted 
cocoa.m to the elemental UI things... like it is now and made a 
controller with the features I need a lot and I think would be useful to 
have in the final product.


I would like very much, that my patch would be comitted, so bugs can be 
fixed and features added.
As soon as we can make qemu threadsave, it's easy to merge the working 
frontend with qemu.


Mike


Pierre.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel





___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] cocoa.m using openGL

[Mike Kronenberg]

Pierre d'Herbemont wrote:



On 24 mai 05, at 17:11, Mike Kronenberg wrote:


Testbuild and diff are on
http://www.kberg.ch/cocoaqemu



It doesn't work on my iMac DV G3 400. I know that its ATI Rage 128 is 
very limited, but I think that we'll had to keep both version...


Did You get an error-message so we could include a autoswitch?



The PNG preview works but not the main screen.

I'll be able to debug a bit more in the weekend.

Pierre.




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
 


Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] cocoa.m

[Mike Kronenberg]

Pierre d'Herbemont wrote:



On 28 mai 05, at 20:36, Mike Kronenberg wrote:


Pierre d'Herbemont wrote:

That  should be done with not much troubles, if we manage to get 
qemu  thread safe. Did you try that way?



Until the 7. May I was trying to get all into qemu... sources are 
still there.


I was looking into making the contoller one thread and the each qemu 
a thread, so one can run multiple qemus. It is still on the List - 
but it's a little more time intensive (I use qemu for my work) . So I 
gutted cocoa.m to the elemental UI things... like it is now and made 
a controller with the features I need a lot and I think would be 
useful to have in the final product.


I would like very much, that my patch would be comitted, so bugs can 
be fixed and features added.
As soon as we can make qemu threadsave, it's easy to merge the 
working frontend with qemu.



For now a single-threaded qemu could be ok... The patch will be 
smaller, and the multiple instance feature may be added later. What do 
you think?



I'm looking into it, guess we have to make a qemu class and hide all the 
static stuff form the controller so we can call qemu as an object and 
dispose of it at the end, since i did not manage yet to reuse qemu 
properly for a second time (to many vars and objects to nil).


Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] OS X Package Maintainer

[Mike Kronenberg]

Pierre has asked me to maintain the OS X package.
I will glady take this task.

To keep things simple for enduser, I plan to make packages for the cocoa 
flavour of qemu. If You think there should also a sdl package, please 
inform me.


Layout of the Package:

Container: QEMU-0.7.x.dmg (compressed with attached License)

Application: QEMU.app
+-Contents/
+--info.plist
+--PkgInfo
+--MacOS/
+---qemu
+---qemu-img
+--share/
+---doc/
+qemu/
+man/
+qemu/

I patch the cocoa.m to make the package path-independent. (Patch attached).

There will be nightlies everytime Fabrice announces changes to the list.

You will find the packages at:
http://www.freeoszoo.org/download.html
http://www.kberg.ch/qemu/

have fun
Mike
Index: cocoa.m
===
RCS file: /cvsroot/qemu/qemu/cocoa.m,v
retrieving revision 1.4
diff -u -r1.4 cocoa.m
--- cocoa.m 7 Apr 2005 20:36:50 -   1.4
+++ cocoa.m 8 Jun 2005 18:21:23 -
@@ -579,6 +579,9 @@
 QemuCocoaGUIController *gui_controller;
 CPSProcessSerNum PSN;
 
+/* overrun defaults for bios_dir, so we can run qemu everywhere */
+bios_dir = [ [ NSString stringWithFormat:@"%@/share/qemu", [ [ [ NSBundle 
mainBundle ] resourcePath ] stringByDeletingLastPathComponent ] ] cString ];
+
 [NSApplication sharedApplication];
 
 if (!CPSGetCurrentProcess(&PSN))
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] OS X Package Maintainer

[Mike Kronenberg]

Natalia Portillo wrote:


Can you make a nightly build with the CVS?


I'm travelling alot, so this won't excactly nightlies, but I plan to 
make alot of CVS builds, at least every time there is an announcement of 
CVS changes by Fabrice.



And another with the patches that aren't in the CVS?


which patches exactly? There are loads... some might have minor 
conflicts, so it can't be scripted...
I have always a build up with all Patches I use (openGL, mouse, 
keyboard,GUI)


Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] OS X Package Maintainer

[Mike Kronenberg]

Natalia Portillo wrote:


Were will they be to download?


You will find the packages at:
http://www.freeoszoo.org/download.html
http://www.kberg.ch/qemu/

:)
Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] OS X Package Maintainer

[Mike Kronenberg]

Julian Seward wrote:


Can you make a nightly build with the CVS?
   



I'm surprised that Qemu does not seem to have an automated nightly
build / regression test / mail-summary-to-developers system.  We have
been doing that with Valgrind for a couple of years now and it makes 
a big difference, allowing developers to track day-to-day stability

of the system and to quickly see and fix build failures on different
platforms.

J

First, this is not a question of automatition, but where my box is at 
the time the build is generated :) I have some 24/7 linuxboxes - when I 
have a free os x box at hand, things will get even more automated. 
Second, Fabrice is very restrictive about CVS changes, which is a good 
thing for code quality.


Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Makefile.target

[Mike Kronenberg]

Hi all,

I've made a patch for OS X to use the built-in CD-ROM drive. (-cdrom 
/dev/cdrom).
I used #ifdef COCOA_CONFIG in block.c  and added -framework 
CoreFoundation -framework IOKit to COCOA_LIBS in makefile.target.

This works ok.

But I want the Patch to work with SDL, too.
So I use #ifdef __APPLE__ in block.c.

I tryed allot of thing but I'm no makefile hero :)

So, how do I add the Frameworks now?

Thanks
Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Qemu 0.7 crashes on resizing windows in OS X

[Mike Kronenberg]

Ashish Naik wrote:


Hi,
 
I read somewhere that resize  window problem on OS X was fixed prior 
to 0.7 but I still get the problem.
 
Can anyone help?


Please be more specific. What Problem do You have? Which Version do You 
use (CVS/binaries and cocoa/SDL)? What guestOS? When does the error occur?


Greetings
Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QEMU for Mac OS X

[Mike Kronenberg]

Larry Baker wrote:


Larry,

Please post this message on the qemu-devel mailing-list or the user 
forums.


Pierre.



1. I am unable to get the pre-built QEMU for Mac OS X to connect to
my Mac Mini's SuperDrive.  I tried both -cdrom /dev/disk2 and
-cdrom /dev/disk2s0.  When I make a copy of the boot disk to my
desktop with Disk Utility, -cdrom ~/Desktop/disk_name.dmg, it works
fine.  I booted a copy of BartPE (CD of Windows XP).


Hi,
I made a fix so qemu can access your cdrom drive. It's not in CVS. But 
there is a precompile binary at http://www.kberg.ch/q called 'Q'.

To access Your cdrom drive, You must leave the field for the cdrom empty...

Greetings
Mike



2. BartPE found a RealTek network interface, but DHCP failed.  (The
IP address is 0.0.0.0.)  What setup can I use to get it to work?

3. I use the SIMH VAX simulator (http://simh.trailing-edge.com/) on my
PowerMac G5 at work.  It has no trouble accessing the SuperDrive as
/dev/disk1s0, and DECnet comes up just fine.  I didn't have to do
anything special (like run as root).  Maybe there is code at
http://simh.trailing-edge.com/ you could use.

4. I tried to compile and run the latest QEMU (qemu-0.7.0.tar.gz,
./configure, make [gives some warnings], make install).  It never comes
up.  So, I removed it and went back to the pre-built (0.5.5?) Mac OS X
version.

5. Neither command in the Mac OS X version's ReadMe.rtfd works.

Any suggestions?

Larry Baker



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel





___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] freeoszoo

[Mike Kronenberg]

U n d e r a c h i e v e r wrote:


Hi

I wanted to submit a new OS image (CentOS 4 on x86) to FreeOSZoo.org.

I'm getting taken to what looks like a search or cyber-squatter's site.
Any idea what's up?

$ dig freeoszoo.org +nodebug +noadditional +nostats +noquery

; <<>> DiG 8.3 <<>> freeoszoo.org +nodebug +noadditional +nostats
+noquery 
;; res options: init recurs defnam dnsrch

;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15106
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5
;; ANSWER SECTION:
freeoszoo.org.  27m12s IN A 63.251.83.53

;; AUTHORITY SECTION:
freeoszoo.org.  33m45s IN NSdns1.name-services.com.
freeoszoo.org.  33m45s IN NSdns2.name-services.com.
freeoszoo.org.  33m45s IN NSdns3.name-services.com.
freeoszoo.org.  33m45s IN NSdns4.name-services.com.
freeoszoo.org.  33m45s IN NSdns5.name-services.com.

 


use http://quantaltro.webminds.cs.unibo.it/ until the domain is back.

Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

Based on experiences with Q, I rewrote the cocoa port.

It features now:
- Keyboard
- Mouse
- Full screen
- Hardware CD-Rom support
- Possibility to create/save guest PC profiles
- Toolbar to load images for fd/cd and save/shutdown/reset guest PC
- graphic interface to create/change/delete/start guest PCs
- new command line options (only for the cocoa port)

At the moment it lacks:
- Sound
- possibility to start multiple guest PCs

The diff is rather large (~800kb). You find diff and binaries at:
http://www.kberg.ch/q

It compiles on 10.2.x (search this list for questions on poll.h) and 10.3.x
The binaries provided should run on 10.3.x and 10.4.x


At the moment I got stuck with cleaning up after a guest PC, so I can 
start a new one or even multiple guest PCs. (this is still perfectly 
possible with multiple instances of QEMU)


I create a new Object (cocoaQemu.m) for the guest PC, then I start the 
guest PC with a new NSThread. After completion, I can create a new 
Object, but  the guest PC won't start. (I called/rewrote the functions 
in atexit but there must be some more things to be cleaned up before)


There are some Problems with multiple guest PCs at the same time, too. 
For Example: '-smb' creates a temp directory with the PID. This makes 
multiple smb configurations impossible. It might be better to use a 
timestamp.


I'm not sure whether that was ever intended.
So if you have an Idea, please drop a note.



Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

Hetz Ben Hamo wrote:


I just looked at the screenshots, and if you don't mind, I want to
offer few suggestions for your GUI:

1. RAM size - how about adding up/down arrows (in addition to what you
have right now) to increase RAM?
 

Good Idea. How should they id/decrement the value? One by one or 
doubling the Value?



2. Instead of Radio buttons in the Floppy/CDROM/Hard drive, I would
suggest to replace it with Check Boxes, so the ones that are not
needed by the user, will be grayed out until the check boxes will be
marked.
 

I look into that. Have You an Idea how we could optimize the choosing of 
cd-rom and cd-rom-image.



3. I would also suggest to add a "Boot from" pull down menu - to
select from which device to boot (useful for CD installation etc..)
 


On the list.


Thanks,
Hetz

 


Thanks.

[snip]

I'd like to keep the Panel as easy as possible, so "normal" Users won't 
be destracted by to much options.
Probably I'm gonna ad '-localtime', '-smb', and 
'-user-net'/'-dummy-net', since I activate them by default.


I'm thinking of a new way to store the images and saved VMs, too.
Maybe we could make something like vpc: A package with the config, 
disk-images and saved VMs, located in ~/Documents/QEMU PCs/


any Ideas?

Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

Jim C. Brown wrote:


On Thu, Jul 21, 2005 at 04:00:12PM +0200, Ren? Korthaus wrote:
 

That is what I was also thinking about for some time, but first we  
should then agree on an universal way of saving configurations (this  
was already been touched by the list some time ago, couldnt find the  
mails by now). As I am pretty much satisfied with saving the data in  
an xml file, I would suggest this way, but we shouldnt only focus on  
Mac OS X part, but also on other platforms.


   



I have a shell script that provides config file support for qemu called vqemu.
Basicly the format is a simple "option=value", the shell script sources the
config file in and then passes certain command line options to qemu based on
the options given.

The script should be easy to modify to use on OS X. To make it more portable
(e.g. usable on Windows), converting it to C is not terribly difficult.

 

Right now I'm using .plist(property lists), which is very common in OS 
X, because you can read them back directly in to an Array or a 
Dictionaty. It's a standardized XML File.
I'm a big fan of XML, but I'm also very much Intrested in having a 
compatible package over all platforms.
I see advantage in XML, because it's a lot more flexible and accurat in 
storing your Data - well it was defined exactly for that pourpose :)


My packages look like this:
~/Documents/QEMU/Freedos.qemu/configuration.plist
~/Documents/QEMU/Freedos.qemu/hda.img
~/Documents/QEMU/Freedos.qemu/saved.vm
~/Documents/QEMU/Freedos.qemu/thumbnail.png
or:
~/Documents/QEMU/ReactOS 15412.qemu/configuration.plist
~/Documents/QEMU/ReactOS 15412.qemu/hda.img
~/Documents/QEMU/ReactOS 15412.qemu/saved.vm
~/Documents/QEMU/ReactOS 15412.qemu/thumbnail.png

They can nicely be ziped.

A sample configuration .plist:

"http://www.apple.com/DTDs/PropertyList-1.0.dtd";>


   
   -boot
   1
   -cdrom
   
   -fda
   
   -hda
   /Users/mike/Documents/qemu/images/2gb_win2k.img
   -m
   128
   cpu
   0
   custom
   
   name
   win2ksp4
   status
   shutdown
   


I'm also looking into writing a converter for vpc packages, which are 
very similar :)


Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

Joshua Root wrote:


On 21 Jul 2005, Natalia Portillo <[EMAIL PROTECTED]> wrote:


El 21/07/2005, a las 18:33, Stealth Dave escribió:


On Jul 21, 2005, at 6:46 AM, Hetz Ben Hamo wrote:


On 7/21/05, Mike Kronenberg <[EMAIL PROTECTED]> wrote:


Hetz Ben Hamo wrote:

I'm thinking of a new way to store the images and saved VMs, too.
Maybe we could make something like vpc: A package with the config,
disk-images and saved VMs, located in ~/Documents/QEMU PCs/



Nice idea.



I would recommend ~/Library/QEMU/PCs as an alternative.  OS X tends  
to store all of its program specific configuration information in 
the Library folder, which separates it from actual Documents such  
as disk images, word processor files, images, etc.


Just $0.02 from the Peanut Gallery! :)

- Dave



Yeah but the Library is a obscure place, and VirtualPC for example  
uses Documents with packages inside and I think that is an elegant 
way and also will help deal with old users.
Also VPC uses XML for hardware description and should be easy to 
make  a XML<->XML virtual machine converter, with along qemu-img will 
allow  people to convert old VPC machines to QEMU ones (will be very 
useful  for me).



Besides which, you're not meant to go creating random folders at the 
top level of ~/Library/. If you have a single configuration file, it 
goes in ~/Library/Preferences/, or if you have a collection of things, 
you create a subfolder in ~/Library/Application Support/ and put them 
there.


I would prefer ~/Documents/QEMU/ rather than ~/Library/Application 
Support/QEMU/ since the files stored there will not just be managed 
internally by the app; the user will know about them.


Cheers,
Josh


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


I agree. I used to store the saved VMs in ~/Library/cocoaqemu/. But this 
is no good solution, for if You want to remove qemu, you lose space on 
your HD, if you are not familiar with the library. Exchanging 
preconfigured/saved PC is also a lot easyer, if you have them in a nice 
package at the top of Your Documents Folder


Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

[snip]

Right now I'm using .plist(property lists), which is very common in 
OS X, because you can read them back directly in to an Array or a 
Dictionaty. It's a standardized XML File.
I'm a big fan of XML, but I'm also very much Intrested in having a 
compatible package over all platforms.
I see advantage in XML, because it's a lot more flexible and accurat 
in storing your Data - well it was defined exactly for that pourpose :)



Fully agree.



My packages look like this:
~/Documents/QEMU/Freedos.qemu/configuration.plist
~/Documents/QEMU/Freedos.qemu/hda.img
~/Documents/QEMU/Freedos.qemu/saved.vm
~/Documents/QEMU/Freedos.qemu/thumbnail.png
or:
~/Documents/QEMU/ReactOS 15412.qemu/configuration.plist
~/Documents/QEMU/ReactOS 15412.qemu/hda.img
~/Documents/QEMU/ReactOS 15412.qemu/saved.vm
~/Documents/QEMU/ReactOS 15412.qemu/thumbnail.png



What about .qvm instead of .qemu ?


Ok for me.



They can nicely be ziped.

A sample configuration .plist:

"http://www.apple.com/DTDs/PropertyList-1.0.dtd";>


   
   -boot
   1
   -cdrom
   
   -fda
   
   -hda
   /Users/mike/Documents/qemu/images/2gb_win2k.img
   -m
   128
   cpu
   0
   custom
   
   name
   win2ksp4
   status
   shutdown
   




I assume cpu is the system the image is designed for, f.e. 
x86? What about some additional keys like author, date of creation, 
email if someone f.e. downloaded the image from the web and has 
problems getting it to run?!


This is right from Q, so its no real proposal, just to show the 
advantages of xml. cpu stands for the guest PC architekture.


I would propose 4 dicts in a containing dict:
- Description (PC Name, Platform)
- Arguments (with the real qemu arguments)
- Author (FreeOSZoo go go go!)
- Temp (to store temporary "nice to have" hints for a specific port)

Hey, FreeOSZoo'ers, what do you think would be also nice to save in 
the xml regarding distribution on your platform?

According to your site:

ToDO List:
[...]

   1. Create a FreeOSZoo hotdelivery XML format, gathering all
  information needed to download and install FreeOSZoo images. We
  hope that the FreeOSZoo hotdelivery XML format will allow the
  next generation of QEMU GUIs to connect to a distribution site
  and download the needed files automatically. We plan the XML
  file to deliver the following information:
  * Available mirrors for download
  * Bittorent  trackers
  * Host operating systems requirements
  * Guest operating systems requirements
  * List of free software bundled
  * Upgrading facilities over the Internet
  * Targeted audience (home use, ...)
  * Links to a gallery of screenshots
  * Links to tutorials and help systems
  * Links to live video presentations


[snip]

Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

Pierre d'Herbemont wrote:



On 21 juil. 05, at 15:46, Hetz Ben Hamo wrote:


On 7/21/05, Mike Kronenberg <[EMAIL PROTECTED]> wrote:


Hetz Ben Hamo wrote:



I just looked at the screenshots, and if you don't mind, I want to
offer few suggestions for your GUI:

1. RAM size - how about adding up/down arrows (in addition to  what 
you

have right now) to increase RAM?




Good Idea. How should they id/decrement the value? One by one or
doubling the Value?



My suggestion - by 8MB incrememental steps, but allow the user to type
a number in case someone wants type a specific number.



Why a slider, or arrow? A simple text box is far more simpler,  
quicker. Don't tell me that you'll click on the arrow button to get  
256, when you are at 128!


:)




2. Instead of Radio buttons in the Floppy/CDROM/Hard drive, I would
suggest to replace it with Check Boxes, so the ones that are not
needed by the user, will be grayed out until the check boxes will be
marked.



I look into that. Have You an Idea how we could optimize the  
choosing of

cd-rom and cd-rom-image.



Sure. A simple pull down menu instead of the ... circle button, where
you have 2 options:
* Physical Media
* Other (ISO) 

If the user selects Other (ISO) - a sile selection could appear to
select an ISO and then appears. If the user selects "Physical Media" -
the device name appear in the selection.



For the button title why "other". Something like "File" or "CD-ROM  
image" sounds better, more explicit.
And why don't we have an intermediate window that allow the user to  
choose a file or a device, or in the selector you specify if you want  
a device or a file. It may simplify the interface.


Like an NSPopupButon with the options
-CD Rom
-/path/to/file/if/one/was/selected
Separator
-choose an imagefile...

I'd like to keep the Panel as easy as possible, so "normal" Users  
won't

be destracted by to much options.
Probably I'm gonna ad '-localtime', '-smb', and
'-user-net'/'-dummy-net', since I activate them by default.



I think Localtime, should also be a checkbox item (in a seperate
line), and user-net / dummy net should be a radio button selection,
but all of them should be hidden until the user press the "Advanced.."
button.



Sounds like a Windows App to me :P No need for Advanced mode, the  
advanced mode sounds scary to me. Keep it simple.
Something like a "Network & File Sharing" section for -smb and -user- 
net. "Time" section for -localtime. If the interface is sufficiently  
explicit and simple no need to hide them, if the names are  
sufficiently user friendly.


This must be discussed a bit, so feel free to reply if you are not  
agree.


BTW, what does Fabrice thinks of having nib files and png in CVS?


well that would be something I'd like to know, too.
Aktually the nibs are saved as xml. (they are easyer to use until we 
have a form of UI that corresponds to our needs, that could be coded 
directly)
PNGs are not really necessary, the toolbars can be switched to text-only 
mode.


There is another matter, I'd like to discuss:
I've now integrated the controller in the qemu binary, but I dont feel 
happy with that:

1. One can't choose different architectures
2. It's a "oneshot" now (there are things in QEMU that are tied to the 
PID, and there is also a problem with cleaning up with atexit() )


I would preffer a qemu-control (or whatever) that exec()s qemu, 
qemu-x86_64, qemu-ppc as child processes, so they can run in there own 
memory-space.



Mike, thanks for the work.

Pierre. 


Thanks for Your Input.

Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

Mike Kronenberg wrote:


I'm thinking of a new way to store the images and saved VMs, too.
Maybe we could make something like vpc: A package with the config, 
disk-images and saved VMs, located in ~/Documents/QEMU PCs/


QEMU guest PC Format, a Proposal

This should serve as a base for the discussion on a Structure/Format to 
save preconfigured/saved guest PCs.



Structure:
all the Files needed by the VM are stored in a folder. The folder has an 
ending of .qvm (QEMU Virtual Machine).


Mandatory Files:
- Harddiskimages
Configuration File (configuration.plist)

Other Files:
FDImages
CDImages
Thumbnail (thumbnail.png)
VM State File (saved.vm)

Host dependent Files:
PkgInfo (OS X)
info.plist (OS X)


Format:
As a general format, I propose XML. To be more exact: PropertyLists. You 
find the definition for PropertyLists at: 
http://www.apple.com/DTDs/PropertyList-1.0.dtd


Why XML?
We live in a small world, the QEMU community started out from France and 
has now it's followers all over the world. The developers and (hard)core 
users may stick to ASCII characters. But this is not the case for a 
broader community. Localized Operating Systems and less 
interested/educated users will fast break compatibility of simple 
text/ini files. (There might even arise difficulties with 
ASCII/MacRoman) So XML is the choice in the long run.


Why PropertyList?
Because they are easy to handle. Datatypes/Values and Variable Names are 
stored as pairs:


author
Mike Kronenberg
date
2005-07-27T22:00:00Z


What should be covered by “configuration.plist”?
Version
About
Arguments
PC Data
Temporary

There is no particular Order, Data is accessed by key.


1.Version
Simple String to define the version of this configurations.plist file. 
Format: 1.0.0


2.About
Author name, Date, Copyright/left. Place for further Descriptions.

3.Arguments
To have the highest compatibility, we should stick to a simple 
option/value Scheme here, with boolean YES/NO for arguments with no 
value, like -enable-audio. There should be no host dependent switches here.


4.PC Data
PC Name, PC Description, PC Status, emulated CPU and other guest PC 
related “Meta” Information.


5.Temporary
“Nice to have” data, host dependent switches – shortly everything that 
is NOT needed to guarantee the operation of QEMU.


Sample configuration.plist:


"http://www.apple.com/DTDs/PropertyList-1.0.dtd";>



About

author
Mike Kronenberg
copyright
© 2005, Mike Kronenberg
date
2005-07-27T22:00:00Z
description
This is a sample PC configuration.

Arguments

-boot
c
-cdrom
/dev/cdrom
-hda
Harddisk1.raw

PC Data

name
My new PC
state
saved
system
qemu-system-x86_64

Temporary

Version
0.1.0






Waiting for Your Suggestions...

Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

Natalia Portillo wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Better to have a architecture/machine pair.

Architecture: x86-64
Machine: PC

Architecture: PowerPC
Machine: Core99

To be coincident with the -M flag and having the possibility of  
changing the qemu executable name (that should be in the GUI  
configuration)


I do see the logical connection of the two. But -M is a commandline 
Parameter that should remain with the other commandline arguments.


Maybe "PC Data" is not the correct name for what I had in mind: "PC 
Data" stores information, that is neccessary for a launcher app, to 
choose the correct binary and setup the right state, then apply the 
"Arguments" to this binary to start qemu.


Since binarynames could change in the future, I agree that we should use 
generic names for the Architectures. I'll list them now (please correct 
me, if I'm mistaken):

x86
x86-64 (x86_64 has more hits in google, but all the tech pages use x86-64)
PowerPC (maybe PPC will make it easyer to grep?)
SPARC
MIPS

G
Mike



El 04/08/2005, a las 8:36, Mike Kronenberg escribió:


Mike Kronenberg wrote:



I'm thinking of a new way to store the images and saved VMs, too.
Maybe we could make something like vpc: A package with the config,  
disk-images and saved VMs, located in ~/Documents/QEMU PCs/




QEMU guest PC Format, a Proposal

This should serve as a base for the discussion on a Structure/ Format 
to save preconfigured/saved guest PCs.



Structure:
all the Files needed by the VM are stored in a folder. The folder  
has an ending of .qvm (QEMU Virtual Machine).


Mandatory Files:
- Harddiskimages
Configuration File (configuration.plist)

Other Files:
FDImages
CDImages
Thumbnail (thumbnail.png)
VM State File (saved.vm)

Host dependent Files:
PkgInfo (OS X)
info.plist (OS X)


Format:
As a general format, I propose XML. To be more exact:  PropertyLists. 
You find the definition for PropertyLists at: http:// 
www.apple.com/DTDs/PropertyList-1.0.dtd


Why XML?
We live in a small world, the QEMU community started out from  France 
and has now it's followers all over the world. The  developers and 
(hard)core users may stick to ASCII characters. But  this is not the 
case for a broader community. Localized Operating  Systems and less 
interested/educated users will fast break  compatibility of simple 
text/ini files. (There might even arise  difficulties with 
ASCII/MacRoman) So XML is the choice in the long  run.


Why PropertyList?
Because they are easy to handle. Datatypes/Values and Variable  Names 
are stored as pairs:


author
Mike Kronenberg
date
2005-07-27T22:00:00Z


What should be covered by “configuration.plist”?
Version
About
Arguments
PC Data
Temporary

There is no particular Order, Data is accessed by key.


1.Version
Simple String to define the version of this configurations.plist  
file. Format: 1.0.0


2.About
Author name, Date, Copyright/left. Place for further Descriptions.

3.Arguments
To have the highest compatibility, we should stick to a simple  
option/value Scheme here, with boolean YES/NO for arguments with no  
value, like -enable-audio. There should be no host dependent  
switches here.


4.PC Data
PC Name, PC Description, PC Status, emulated CPU and other guest PC  
related “Meta” Information.


5.Temporary
“Nice to have” data, host dependent switches – shortly everything  
that is NOT needed to guarantee the operation of QEMU.


Sample configuration.plist:


"http://www.apple.com/DTDs/PropertyList-1.0.dtd";>



About

author
Mike Kronenberg
copyright
© 2005, Mike Kronenberg
date
2005-07-27T22:00:00Z
description
This is a sample PC configuration.

Arguments

-boot
c
-cdrom
/dev/cdrom
-hda
Harddisk1.raw

PC Data

name
My new PC
state
saved
system
qemu-system-x86_64

Temporary

Version
0.1.0






Waiting for Your Suggestions...

Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFC8mDXSOHwOb87puQRApVgAJ432rq0FSwpBjRaxzmgVRcr3h/cpACg2+Cd
O8Amp84ZCvMwvkEGJieWYkE=
=npr3
-END PGP SIGNATURE-


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel





___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

I have implemented .qvm as a test in Q.

Here is a sample configuration.plist and some additions to my initial 
proposal:



"http://www.apple.com/DTDs/PropertyList-1.0.dtd";>



   About
   
   Author
   Q
   Copyright
   none
   Date
   2005-08-07T19:25:41Z
   Description
   Converted guest PC from cocoaqemu.plist
   
   Arguments
   
   -boot
   c
   -cdrom
   /dev/cdrom
   -hda
   harddisk_1.img
   -localtime
   
   -m
   16
   -user-net
   
   
   PC Data
   
   architecture
   x86
   name
   Freedos
   state
   shutdown
   
   Temporary
   
   -cocoapath
   /Users/mike/Documents/QEMU/Freedos.qvm
   
   Version
   0.1.0.Q



Changes:
   - the type  for integer values:
   -m
   16
   - diskimages can have a relative path (to the .qvm root) or a 
absolute path, to an image outside the package:

   -hda
   harddisk_1.img
   - the key "architecture" for the used CPU
   architecture
   x86
   - the key "state" can take the following values:
   state
   shutdown
   running
   saved

On OS X, if you have Q installed, .qvm packages show as a single file 
and you can start QEMU by doubleclicking a .qvm package.

See the info.plist in Q.app/Contents for the Document definition.

Greetings
Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu for macosx can't boot linux partition

[Mike Kronenberg]

Just from my experienc with using CD-ROM under OS X:

say You want partition 1 of disk 5

You dont need the: /dev/disk5s1
But: /dev/rdisk5s1 wich is a raw access

Mike

Enric Pedascoll Quingles wrote:


well, now i have running macosX.4 and i want to start a qemu session
with a Debian partition, i know that macos partition is disk0s5 but
all other partitions are Debian (swap, root, home ...), i try to boot
all the disk /dev/disk0 and select Debian in a yaboot but when i type
qemu -hda /dev/disk0, qemu crash


On 9/28/05, Jonas Maebe <[EMAIL PROTECTED]> wrote:
 


On 28 sep 2005, at 16:29, Enric Pedascoll Quingles wrote:

   


i try to boot a fisical mac's partition with qemu but i don't obtain
good results
i have read in documentation files that the command is:

~#qemu -snapshot -hda /dev/(your disk)

i try several way with the same result

~#qemu -snapshot -hda /dev/hda
~#qemu -snapshot -hda /dev/disk0
~#qemu -snapshot -hda /dev/hda0s1..s2...s5

and nothing...
 


Under Mac OS X, partitions are available as /dev/diskXsY and not /dev/
hdXsY. Your boot partition /dev/disk0sY, other disks can get a
different number after every reboot.

You can find the device name of a partition (under Mac OS X 10.4.x at
least) by opening /Applications/Utilities/Disk Utility, selecting a
partition and choosing File->Get Info.


Jonas

   




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
 





___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [patch] OS X cocoa

[Mike Kronenberg]

These patches provide fixes/updates/enhancement to the native OS 
X(COCOA) port.


Since the qemu CVS version of qemu has still a broken keyboard input and 
lacks some features of it's SDL counterpart, I post two patches that 
will add features similar to SDL and more. These patches contain only 
functional enhancements and NO GUI code.


http://www.kberg.ch/qemu/osx_cocoa_1.diff.gz
- fixed/full keyboard input
- full mouse support
- support for qemu console

http://www.kberg.ch/qemu/osx_cdrom_1.diff.gz
- support for the built in CD-ROM drive (gives access to the first 
session of a CD-ROM in the drive of your mac)



Additional to these patches there is a new audio patch posted earlier by 
malc. It provides sound output via apples coreaudio - that further 
completes the native OS X(COCOA) port:

http://www.boblycat.org/~malc/code/patches/qemu/14d_aqemu.patch.gz

You enable all these features by adding --enable-cocoa to your 
./configure line.


Mike


osx_cdrom_1.diff.gz
Description: GNU Zip compressed data


osx_cocoa_1.diff.gz
Description: GNU Zip compressed data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Installing Debian PPC HOWTO

[Mike Kronenberg]

This is very helpful indeed!
There where a lot of questions lately about ppc emulation. Could you 
post the resulting image to http://free.oszoo.org ? So people have a 
easy solution to test ppc emulation? I think hetz would also be happy to 
have this howto in his qemu forum at: http://qemu.dad-answers.com/


Txs
Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Windows 95 Network driver

[Mike Kronenberg]

It's a little messed up, since I'm redesigning the website:

http://www.kberg.ch/q/index.php?p=10

You'll find even more info about configuring qemu at:
http://qemu.dad-answers.com/

G
Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [patch] OS X ppc byteswapping

[Mike Kronenberg]

This patch enables hardware byteswapping (lhbrx, lwbrx) for PowerPC on 
OS X (since OS X does not provide "byteswap.h").


http://www.kberg.ch/qemu/osx_ppc_byteswap_2.diff.gz

Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Bug report

[Mike Kronenberg]

Julien Lancien wrote:


Hi,

I am unable to compile qemu on my machine :p. I've attached the result
of the configure and make.

My gcc version is: 4.0.3 20051006 and kernel 2.6.13 vanilla.

I used the CVS snapshot, but I got mostly the same problem with the
0.7.2 version.
Tell me if you want more infos, and thanks for any help.
 




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
 


about compiling QEMU with gcc 4.x.x
http://lists.gnu.org/archive/html/qemu-devel/2005-10/msg00312.html

Greetings
Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu cpu-all.h

[Mike Kronenberg]

Hello,

I just wanted to build CVS taget i386-softmmu on a PPC G4 with OS X 
10.3.9, GCC 3.3.


I get a ton of the following compile errors:

/diff/qemu/cpu-all.h: In function `ldq_le_p':
/diff/qemu/cpu-all.h:234: warning: implicit declaration of function `ldl_p'
/diff/qemu/cpu-all.h: In function `stq_le_p':
/diff/qemu/cpu-all.h:266: warning: implicit declaration of function `stl_p'

if I move the Block with the defines:

/* target CPU memory access functions */
#if defined(TARGET_WORDS_BIGENDIAN)
/.../
#define ldl_p(p) ldl_le_p(p)
/.../
#define stl_p(p, v) stl_le_p(p, v)
/.../
#endif

on top of the file (since now, ldl_le_p and stl_le_p are defined after 
this block) it compiles fine.


But QEMU crashes very early (some seconds after starting freedos... I 
see the prompt and can enter things).


Mike






My Errorlog:

Date/Time:  2005-11-21 12:57:59 +0100
OS Version: 10.3.9 (Build 7W98)
Report Version: 2

Command: qemu
Path:./qemu
Version: ??? (???)
PID: 6567
Thread:  0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:  KERN_PROTECTION_FAILURE (0x0002) at 0x0034

Thread 0 Crashed:
0   qemu 0x00061a8c 0x1000 + 0x60a8c
1   qemu 0x0005ec40 0x1000 + 0x5dc40
2   qemu 0x0005fef0 0x1000 + 0x5eef0
3   <<>> 0x002ac4c8 receive_samples + 0x1c8d64
4   qemu 0x0006c24c 0x1000 + 0x6b24c
5   qemu 0x8084 0x1000 + 0x7084
6   qemu 0x9564 0x1000 + 0x8564
7   qemu 0x000b0b04 0x1000 + 0xafb04
8   com.apple.Foundation 0x90a27aec _nsnote_callback + 0xb0
9   com.apple.CoreFoundation 0x901da4a8 __CFXNotificationPost + 0x1b4
10  com.apple.CoreFoundation 0x901deeb8 
_CFXNotificationPostNotification + 0x340
11  com.apple.Foundation 0x90a25938 -[NSNotificationCenter 
postNotificationName:object:userInfo:] + 0x74
12  com.apple.AppKit 0x92f93380 -[NSApplication 
_postDidFinishNotification] + 0x70
13  com.apple.AppKit 0x92f9326c -[NSApplication 
_sendFinishLaunchingNotification] + 0x5c
14  com.apple.AppKit 0x92f9349c 
-[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] 
+ 0x78
15  com.apple.Foundation 0x90a7af70 -[NSAppleEventManager 
dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 0x164
16  com.apple.Foundation 0x90a81808 
_NSAppleEventManagerGenericHandler + 0x78
17  com.apple.AE 0x9272ba10 aeDispatchAppleEvent(AEDesc 
const*, AEDesc*, unsigned long, unsigned char*) + 0xd0
18  com.apple.AE 0x9272e858 
dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 0x2c

19  com.apple.AE 0x9272bc50 aeProcessAppleEvent + 0x11c
20  com.apple.HIToolbox  0x92975224 AEProcessAppleEvent + 0x3c
21  com.apple.AppKit 0x92e82484 _DPSNextEvent + 0x358
22  com.apple.AppKit 0x92e98d2c -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:] + 0x74

23  com.apple.AppKit 0x92ead0ac -[NSApplication run] + 0x21c
24  qemu 0x000b0a94 0x1000 + 0xafa94
25  qemu 0x000b0cc8 0x1000 + 0xafcc8
26  qemu 0x29dc 0x1000 + 0x19dc
27  dyld 0x8fe1a278 _dyld_start + 0x64

PPC Thread State:
 srr0: 0x00061a8c srr1: 0x0200f030vrsave: 0x
   cr: 0x44002248  xer: 0x0004   lr: 0x000617c4  ctr: 0x0005fe4c
   r0: 0x   r1: 0xbfffbeb0   r2: 0x   r3: 0x008ca1c0
   r4: 0x   r5: 0x0005f050   r6: 0x000cf050   r7: 0x008ca1c0
   r8: 0x0022   r9: 0x  r10: 0x0021  r11: 0x0034
  r12: 0x0005fe4c  r13: 0x  r14: 0x  r15: 0x000deb98
  r16: 0x  r17: 0x  r18: 0x  r19: 0x
  r20: 0x  r21: 0x00023100  r22: 0x008caa00  r23: 0x0001
  r24: 0x00199e00  r25: 0x  r26: 0x0305252c  r27: 0x00199dfc
  r28: 0x  r29: 0x  r30: 0x008ca1c0  r31: 0x00061608

Binary Images Description:
   0x1000 -0xc6fff qemu ./qemu
 0xe42000 -   0xe8 libSDL-1.2.0.dylib 
/usr/local/lib/libSDL-1.2.0.dylib

0x8083 - 0x8090efff libxml2.2.dylib /usr/lib/libxml2.2.dylib
0x81f5 - 0x81f53fff libmx.A.dylib /usr/lib/libmx.A.dylib
0x86ded000 - 0x86dfdfff com.apple.Accelerate.vecLib 3.0.3 (vecLib 
3.0.3)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
0x87e0 - 0x87f36fff com.apple.vImage 1.2.0
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
0x88be - 0x88becfff com.apple.agl 2.5 (AGL-2.5)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL
0x8fd5 - 0x8fd50fff com.apple.Accelerate 1.0.3 (Accelerate 1.0.3)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate

0x8fe0 - 0x8fe4 dyld /usr/lib/dyld
0x9000

Re: [Qemu-devel] qemu cpu-all.h

[Mike Kronenberg]

QEMU compiles fine on ppc now, but the Problem wit DOS under PPC persists.

I tested Reactos 0.28 and Win95 and they both run fine so far.

On the Dos side I tried the Freedos image from oszoo, Freedos 
installation Floppy from fdos.org, MS DOS 6.22 and MS DOS 7.0 (win95) 
and they all fail. (either at startup or shortly later)


-> 32bit ok, 16bit/8bit failing?

I was able to run the memtest+ from the freedos installation floppy. ( 
http://www.memtest.org/ )

Sidenote: the floppy image from www.memtest.org does not work for me.

It runs OK for test 1# to 6# but fails systematically on test #7 (the 
test runs, but takes a enternity because of the error messages...)


Screenshot of memtest errors:
http://www.kberg.ch/qemu/memtest.png

-> see the errorbits, is this a endian Problem?

Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] Mac OS X: QEMU crashes when pressing dead keys

[Mike Kronenberg]

On 08.12.2005, at 18:21, Joachim Henke wrote:


This concerns the current cocoa version in cvs:  When typing into the
monitor and accidentally pressing a dead key, qemu quits  
immediately and

all unsafed data in the guest os is lost:

2005-12-04 15:15:00.833 qemu[193] Exception raised during posting  
of notification.  Ignored.  exception: *** -[NSCFString  
characterAtIndex:]: Range or index out of bounds


Even if you don't have a Mac, you can retrace this bug by following  
these

links:

http://developer.apple.com/documentation/Cocoa/Reference/ 
ApplicationKit/ObjC_classic/Classes/NSEvent.html#//apple_ref/occ/ 
instm/NSEvent/characters
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ 
ObjC_classic/Classes/NSString.html#//apple_ref/occ/instm/NSString/ 
characterAtIndex:


[event characters] returns an empty string for dead keys, and so  
calling
[[event characters] characterAtIndex:0] will raise an  
NSRangeException that

crashes qemu. The following patch fixes this bug:





To Mike Kronenberg: Q has the same problem. Pressing a dead key in the
monitor locks the emulation and you're not able to do anything  
further.
Would you be so kind to confirm this? It seems that Fabrice doesn't  
trust

my fixes. Thanks!

Regards
Jo.


Thanks for this correction,

it does indeed fix the dead key issue which I was not aware of, when  
I wrote that code to retrieve isochars. (I have no dead keys on my PB  
Keyboard :) )


Fixed this in Q. But the next Build will have to wait a little, since  
we have some other Problems on OS X.

Maybe You can help us out a little with this:

When running DOS/DOS Prompt under windows under QEMU, I experience  
crashes all the way.
With freedos I have figured out, that loading himem or xms will crash  
QEMU (Option 1). Option 3 (no Drivers) works. So it could be a memory  
mapping issue... DOOM crashes half way down.


This behaviour was introduced with the new MP Code. It's not related  
to cocoa.m, it also happens with SDL. I have the same Result with  
Tiger and Panther. There are no public builds yet... that would  
generate to much mails :)


Maybe You could just reproduce this issue?

Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Mac OS X issues

[Mike Kronenberg]

Txs for the offer,

Win and Lin are working ok for me, too.

Mike

On 09.12.2005, at 23:34, Joachim Henke wrote:


Ok, thanks for your reply.

I'm currently building qemu from CVS code several times a week, but  
I never had DOS related problems. The guest OS is Win98 SE and I  
use the DOS command prompt quite often. What are you doing, when it  
crashes qemu? Does this occur randomly or when running special  
programs/typing special commands?


It's not random, but clearly reproducable, see below.

Inspired by your e-mail I did some tests with the first "heavy" DOS  
application that came to my mind: FastTracker 2.09 - Ok, qemu is  
too slow to produce some enjoyable sound with it, but despite of  
this everything seemed to work well. While the track was running, I  
played around in the audio settings of FastTracker to tweak it a  
bit - and indeed: qemu crashed. Unfortunately, I couldn't reproduce  
this. Maybe it's just a bug in the SoundBlaster emulation which  
hasn't been totally completed yet?


The crashes occur without audio, too.

My host is an iMac G5 with Mac OS 10.4.3 and Xcode 2.2 installed. I  
use the following options to configure the build:


configure --prefix=/usr/local --cc=gcc-3.3 --host-cc=gcc-3.3 -- 
target-list=i386-softmmu --enable-coreaudio --enable-cocoa


--enable-coreaudio
is automatically added when using --enable-cocoa. I added it just for  
SDL builds, since SDL audio is not really usable on OS X...



Btw: Using "--cc=gcc" (which is gcc 4.0.2) also works fine.


Yes, the Problem with gcc 4is user-mode.

I haven't tried FreeDOS yet, but if you like, you can point me to  
an image and give me some detailed instructions to reproduce the  
himem and xms issues.


You find a freedos including doom here:
http://www.kberg.ch/q/userfiles/freedosdoom.zip

or at the oszoo.org

Crashes:
- when choosing option 1 (standard)
about 10-20 sec into doom, when playing timedemo (doom -timedemo  
demo3), otherwise, too.



This used to work great before.

Thanks,
Mike


Sincerely
Jo.


Mike Kronenberg wrote:

Thanks for this correction,

it does indeed fix the dead key issue which I was not aware of,  
when I wrote that code to retrieve isochars. (I have no dead keys  
on my PB Keyboard :) )


Fixed this in Q. But the next Build will have to wait a little,  
since we have some other Problems on OS X.

Maybe You can help us out a little with this:

When running DOS/DOS Prompt under windows under QEMU, I experience  
crashes all the way.
With freedos I have figured out, that loading himem or xms will  
crash QEMU (Option 1). Option 3 (no Drivers) works. So it could be  
a memory mapping issue... DOOM crashes half way down.


This behaviour was introduced with the new MP Code. It's not  
related to cocoa.m, it also happens with SDL. I have the same  
Result with Tiger and Panther. There are no public builds yet...  
that would generate to much mails :)


Maybe You could just reproduce this issue?

Mike



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Mac OS X issues

[Mike Kronenberg]

Your the man!

gcc4 and -fno-tree-ch did the trick for me, too.
-fno-tree-ch was mentioned earlyer on this list, to compile with gcc4  
on OS X. But since gcc4 is still not in the default toolchain, I did  
not even try :(.


Seams that we have a problem with gcc3.3 and not gcc4 for once :)

The error behavement is similar on your machine. I also got bus error  
(Sometimes it did not reach the menu, too. I started to hit the 3  
very early, so I could go right thru it... Early crashes always  
happened for me on MS-DOS 6.22 and DOS 7.


Tested it with DOS 6.22 and DOS 7 (win95). No Problems so far.

I hope Fabrice stumbles upon this.

Maybe we should make the Patch a little more selective with "ifeq ($ 
(CONFIG_DARWIN),yes)" and post it.

Don't know whether this affects other Platforms, too...

Thanks for Your work so far!

Mike


On 11.12.2005, at 15:56, Joachim Henke wrote:

I just did some tests on the freedos image from your web-site and  
my first
impression is that these crashes are something compiler related.  
When I

build qemu with

./configure --prefix=/usr/local --cc=gcc-3.3 --target-list=i386- 
softmmu --enable-cocoa


and start your image with

qemu -hda harddisk_1.img -soundhw sb16

it starts up and immediately crashes after 1 or 2 seconds (Bus  
error) -
even before I could choose one of the 3 menu options. For the next  
test I

applied the patch below and compiled qemu with GCC 4.0.1:

--- Makefile.target
+++ Makefile.target
@@ -148,7 +148,7 @@

 ifeq ($(HAVE_GCC3_OPTIONS),yes)
 # very important to generate a return at the end of every operation
-OP_CFLAGS+=-fno-reorder-blocks -fno-optimize-sibling-calls
+OP_CFLAGS+=-fno-reorder-blocks -fno-optimize-sibling-calls -fno- 
tree-ch

 endif

 ifeq ($(CONFIG_DARWIN),yes)


./configure --prefix=/usr/local --cc=gcc-4.0 --target-list=i386- 
softmmu --enable-cocoa --disable-gcc-check


With this build everything seems to work perfectly. I boot into  
option 1
and run the DOOM demo with b.bat - it runs for ca. 100 seconds and  
then

quits back to DOS saying 'timed 2134 gametics in 2325 realtics'.

Can you try if using GCC 4 helps for you too? I'll do some more  
tests now.

Hopefully I can track down the problem to someting more specific.

Jo.

Mike Kronenberg wrote:

You find a freedos including doom here:
http://www.kberg.ch/q/userfiles/freedosdoom.zip

or at the oszoo.org

Crashes:
- when choosing option 1 (standard)
about 10-20 sec into doom, when playing timedemo (doom -timedemo
demo3), otherwise, too.


This used to work great before.

Thanks,
Mike



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Mac OS X issues

[Mike Kronenberg]

Attached a diff against the last fully working CVS Snapshot I had.  
(ie, before mp was commited)


On 11.12.2005, at 21:47, Joachim Henke wrote:


gcc4 and -fno-tree-ch did the trick for me, too.
-fno-tree-ch was mentioned earlyer on this list, to compile with  
gcc4 on OS X. But since gcc4 is still not in the default  
toolchain, I did not even try :(.


Seams that we have a problem with gcc3.3 and not gcc4 for once :)
The error behavement is similar on your machine. I also got bus  
error (Sometimes it did not reach the menu, too. I started to hit  
the 3 very early, so I could go right thru it... Early crashes  
always happened for me on MS-DOS 6.22 and DOS 7.


Tested it with DOS 6.22 and DOS 7 (win95). No Problems so far.


In the meanwhile I tracked down the whole thing a little bit.  
Debugging with GDB returns these messages when qemu (pure GCC3  
build) crashes:


Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0034
0x000621e0 in tb_invalidate_phys_page_range (start=630485,  
end=630486, is_cpu_write_access=1) at /Volumes/Data/build/qemu/ 
exec.c:491

491 tb2 = tb1->jmp_next[n1];

So one could assume that the problem is in exec.c - but some more  
compiling tests have shown, that GCC4 is required _only_ for cpu- 
exec.c. All other source files can be build with GCC3 and qemu will  
still run stable on Mac OS X (such a mixed build is probably faster  
than a pure GCC4 build). I feel indeed that the problem is  
somewhere in cpu-exec.c or one of its includes - maybe they init  
the data that exec.c crashes on. Hopefully I'm a bit luckier to  
find it tomorrow.


I'm now scanning thru the changes in exec.c...


I hope Fabrice stumbles upon this.

Maybe we should make the Patch a little more selective with "ifeq  
($(CONFIG_DARWIN),yes)" and post it.

Don't know whether this affects other Platforms, too...


Yes, my patch was just a simple one for experimental purposes. It  
must not go into CVS since it breaks compilation with GCC3 or  
earlier. Despite the fact that GCC4 is required only for cpu- 
exec.c, I also think that building with GCC4 should be generally  
provided, since all emulated architectures compile cleanly with it  
(at least on Mac OS X).


Instead of requiring --disable-gcc-check, the configure script  
could write the option HAVE_GCC4=yes to config-host.mak, if it  
detects GCC4. The warning message could be kept. Makefile.target  
can then decide which CFLAGS should be used.


I could create such a patch if people agree.


my guess is, that things stay as they are, since gcc4 is not a target  
in the near future as stated many times. The GCC4 warnings was only  
added, because there where a lot of annoying posts on the list about  
"can't compile on GCC4". So GCC4 is only a workaround :) for now.  
Thing is, that only qemu-system is working when compiled by gcc4,  
qemu-user not.


Mike



regression2.diff
Description: Binary data


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Mac OS X issues

[Mike Kronenberg]

Sorry, I'm a little in a hurry...

The diff is rather big, so just

export CVS_RSH="ssh"
cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/qemu co  
-D "20051115" qemu


this should check out the last working version. I built it with GCC3  
and it was running fine.


Mike


On 13.12.2005, at 17:33, Joachim Henke wrote:

Thanks for the patch! I already browsed through the CVS history on  
savannah, but it's a bit tricky because some code parts moved  
between files when SMP support was added. Could you please provide  
a complete diff to the last fully working CVS snapshot? According  
to your patch, it dates back to September, right? I only looked at  
the changes since the beginning of November.


The GDB output I posted last time was generated after I had removed  
some 'inline' statements to find the correct code lines. The  
following is the result from unmodified CVS:


Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0010
0x00062f98 in tb_phys_invalidate (tb=0x8cad00,  
page_addr=4294967295) at /Volumes/Data/build/qemu/exec-all.h:249

249 {

This is the path to the crash (each function calling the next one):

tb_invalidate_phys_page_range() [exec.c]
tb_phys_invalidate() [exec.c]
tb_reset_jump() [exec.c]
tb_set_jmp_target() [exec-all.h]

According to GDB, qemu crashes in the moment (or shortly after)  
when tb_set_jmp_target() is called (line 442, exec.c). As I wrote  
in my last post, the crash does not occur when cpu-exec.c is  
compiled with GCC4 while everything else is compiled with GCC3.  
Compiling only exec.c with GCC4 does not help. Since cpu-exec.c  
includes exec-all.h through target-pcc/exec.h this could be a point  
to start.


Already played around changing several pieces of the code - it does  
not help - maybe I'm just too blind...


Regards
Jo.


Mike Kronenberg wrote:
Attached a diff against the last fully working CVS Snapshot I had.  
(ie, before mp was commited)


I'm now scanning thru the changes in exec.c...

my guess is, that things stay as they are, since gcc4 is not a  
target in the near future as stated many times. The GCC4 warnings  
was only added, because there where a lot of annoying posts on the  
list about "can't compile on GCC4". So GCC4 is only a  
workaround :) for now. Thing is, that only qemu-system is working  
when compiled by gcc4, qemu-user not.


Mike



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Mac OS X issues

[Mike Kronenberg]

Built and tested!

It works great now, thanks alot.
New OS X Builds are up.

Mike


On 19.12.2005, at 19:21, Joachim Henke wrote:


...just to end this thread (c:

The problem is fixed in todays CVS. Compling QEMU with GCC 3.3 on  
Mac OS X now works again: Running FreeDOS and Doom timedemo don't  
crash anymore.


http://lists.gnu.org/archive/html/qemu-devel/2005-12/msg00206.html

Many thanks to Fabrice!


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu and configuration file?

[Mike Kronenberg]

I made a proposal some month ago based on xml:
http://lists.gnu.org/archive/html/qemu-devel/2005-08/msg00034.html

I use this style of xml property lists for the configuration of the  
vm of Q (slightly alter by now).

Q is a OS X port of QEMU http://www.kberg.ch/q

I ran recently into some troubles with arguments that can appear  
multiple times, like -net and -redir.
I'm now about to changes my configuration files. Having a well  
defined style of configuration files would help making simple guest  
packages, that could be used on multiple systems...


Mike

On 04.01.2006, at 06:50, martin wrote:

 If we'd go for a config file at all with such a complicated  
structure, i see no reasons why to choose anything else than xml  
for it. We have tons of xml libs that can be used for gui's (think  
perl, tk, python etc...). Certainly better every dude writing it's  
own XuPeRpArSeR that will be broken and compatible after a major  
change in qemu ...
 Another choice would be the pure rc (just 'item = value' lines)  
without any supersmart blocks.


xml style or rc style, please no hack in betweeen :)

martin





___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu and configuration file?

[Mike Kronenberg]

I'd like to see some more things in it (besides that windows clients  
can't handle (ba)sh scripts:


- State of the machine (saved/running/snapshot)
- what cpu/machine
- further information (Author, Copyright...)
- paths that can be handled by every plattform
...

so you can g(zip) up a vm and send it to your fellow tester and he  
can run it on every plattform...


and of corse advanced configuration/packages are only good for a GUI!

Mike

else you can really stay with bat/sh ;)


On 04.01.2006, at 22:50, Johannes Schindelin wrote:


Hi,

On Wed, 4 Jan 2006, Giuseppe Della Bianca wrote:


]zac[

I like VMWare style. Maybe it should be possible to share the same
config file between qemu and VMWare, also to favour user migration.


Please, you can make an detailed example?


I can give you a perfectly simple example of a /bin/sh script ;-)

-- snip --
#!/bin/sh

qemu -m 512 -net none -usb -full-screen -serial stdio -parallel  
stdio \

-monitor stdio "$@"
-- snap --

Ciao,
Dscho



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu and configuration file?

[Mike Kronenberg]

As I mentioned in a earlier thread about config files, one of the big  
advantages of XML is it's language independence.
There are french, spanish, japanese, chinese people using qemu,  
resulting in imagenames / paths in the corresponding language.

ASCII/UTF-8 is not everything.

Mike


On 05.01.2006, at 00:41, Jernej Simončič wrote:


On Wednesday, January 4, 2006, 22:22:09, Giuseppe Della Bianca wrote:


The xml configuration file are too much hard to consult and to modify
directly from a human.


It's not hard to edit XML (when it's nicely structured, and not  
clumped all

in a single line), but from my experience it just doesn't give enough
advantage over flat files for storing simple configuration, to justify
writing the much more complex parsing code it needs.

--
< Jernej Simončič ><><><><>< http://deepthought.ena.si/ >

When things are going well, someone will inevitably experiment  
detrimentally.

   -- Boyle's Second Law



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu and configuration file?

[Mike Kronenberg]

simple example:

qemu "/Users/Jernej Simončič/Simončič_image_2.img" -m 128

can be correctly declarated and stored in a XML file while its  
generating problems with normal 8bit text files. Not necessarily on  
the creators system, but maybe on another users system, if you share  
the config file and the image with somebody...
It's already fun to exchange "normal" textfiles" between Mac  
(Macroman) and windows and linux(utf-8/iso-8950-x).


Mike

On 05.01.2006, at 01:04, Jernej Simončič wrote:


On Thursday, January 5, 2006, 0:52:07, Mike Kronenberg wrote:


As I mentioned in a earlier thread about config files, one of the big
advantages of XML is it's language independence.


And flat files are language dependant how?


There are french, spanish, japanese, chinese people using qemu,
resulting in imagenames / paths in the corresponding language.
ASCII/UTF-8 is not everything.


...so what does this have to do with XML/flat files?

--
< Jernej Simončič ><><><><>< http://deepthought.ena.si/ >

Nothing matters very much, and few things matter at all.
   -- Erhard's Contention



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] win98 user mode network not working ...

[Mike Kronenberg]

On 12.01.2006, at 13:38, Adrian Coman wrote:


Hi,

I'm a newbie with qemu and I know there have been a lot of topics  
on the qemu
networking topic, but none of them solved my problem ... I hope  
I'll get an

answer from you.

So, I have a CentOS 4.2 as host with qemu-0.8.0 installed from  
sources. As
guest I have a win98se. In w98 I configured the network to get the  
IP through

dhcp. I start qemu with:

qemu -localtime -hda win98.img

From what I read, when there is no -net option, the default network  
mode is

usermode.

The problem is that when I ping yahoo.com for example I get the IP  
of yahoo

but no response from ping ..., something like:

ping yahoo.com
Pinging yahoo.com [216.109.112.135] with 32 bytes of data:
request time out

I attached a screenshot with the output of ipconfig /all from w98.

Where did I do wrong?


nothing :)
consider qemu as a firewall that is rather restrictive:
The ping command is only working to ping your gateway (10.0.2.2).
...Yahoo was resolved, so your network is up and running...

Mike



Thanks,
Adrian

___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Qemu on Intel Macs

[Mike Kronenberg]

Hi there,

thanks to a tipster I had a look at your sheepshaver 2 days ago :).  
qemu dyngen.c is compiling with the added i386 mach lines. Later I  
had some problems with osdep.h which is used by the qemu tools. I  
disabled it for now.


Now I stuck with:
softmmu_header.h:204: error can't find a register in class  
'GENERAL_REGS' while reloading 'asm'

which is used by:
target-i386:ops_template_mem.h:  In function  
'op_cmpxchgb_kernel_T0_T1_EAX_CC


I tried with and without the gcc4 fixes... and it seams to be another  
register issue which will be a lot of reading form me :)


Mike

On 01.02.2006, at 07:48, Gwenole Beauchesne wrote:


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:


Probably on next weekend...


Jeshua Lacock ___
Programmer/OwnerPhone:  877.240.1364
http://OpenOSX.com  Fax:415.462.6211
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_


Ah, you claimed that Wintel^WBochs ran at near native performance,  
how would you communicate on QEMU then?




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Grabless pointer

[Mike Kronenberg]

Hi malc!

Great!

...great to hear, so I can burry my attempt to write support for a  
touchscreen device... it would have had way more overhead anyway.  
What I'm looking for now is a windows driver (how obviously :) ).  
From the source I can't see what device you are actually emulating  
(or is this a custom one?)


Mike

On 08.02.2006, at 22:24, malc wrote:

At http://www.boblycat.org/~malc/code/patches/qemu/1_mqemu.tgz you  
will

find two patches and binary XFree86 module that allows grabless mouse
operation.

Steps:
a. patch QEMU with 1_mqemu.patch
b. in the guest copy mouse_drv.o to /usr/X11R6/lib/modules/input

Binary mouse_drv.o should work on all XFree86 (and derivatives such as
X.Org) given that they are older than 4.1.

You can also fetch X410src-1.tgz from somewhere copy mouse.c (or patch
the orignal with 1_mouse.patch) and build it yourself.

--
mailto:[EMAIL PROTECTED]


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Grabless pointer

[Mike Kronenberg]

Txs,

I was a little fast on the send button, just saw afterwards the  
changes to mouse.c.

Was way to exited :)
(After fighting with qemu os OS X x86 for a week I'm happy for any  
good news.)


Ported your patch to cocoa.m already... but I have not tested it yet.

Mike


On 09.02.2006, at 13:51, malc wrote:


On Thu, 9 Feb 2006, Mike Kronenberg wrote:


Hi malc!


Hey Mike.

...great to hear, so I can burry my attempt to write support for a  
touchscreen device... it would have had way more overhead anyway.  
What I'm looking for now is a windows driver (how obviously :) ).  
From the source I can't see what device you are actually emulating  
(or is this a custom one?)


X86 ISA extended with one port, with a write handler (start/stop  
hack) and

a read handler (get absolute mouse location). I can not help with a
windows driver/filter since my knowlege in this area amounst to zero.

--
mailto:[EMAIL PROTECTED]


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] usb-tablet support

[Mike Kronenberg]

Hello,

I'm a little late for the party, it seems...

...never the less: here comes the patch for cocoa.m
Tested with win2k and winXP.
This patch fixes the cocoa compile problem that was introduced with  
the multi-display-support as well.


Greetings
Mike



cocoa.m_tablet_02.diff.gz
Description: GNU Zip compressed data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel