Re: [Qemu-devel] [FOR 0.12 PATCH] qdev: Replace device names containing whitespace

[Blue Swirl]

On Sat, Dec 12, 2009 at 6:04 PM, Markus Armbruster  wrote:
> Blue Swirl  writes:
>
>> On Wed, Dec 9, 2009 at 11:43 AM, Markus Armbruster  wrote:
>>> Ian Molton  writes:
>>>
 Markus Armbruster wrote:

> The place for verbose device names is DeviceInfo member desc.  The
> name should be short & sweet.

 Agreed, however...

 Why do these (maybe others) get caps in their names? they dont look
 right to me, compared to the others with nice names like usb-serial,
 piix-ide, or cirrus-vga.

> -    sysbus_register_dev("Uni-north main", sizeof(UNINState),
> +    sysbus_register_dev("Uni-north-main", sizeof(UNINState),
>                          pci_unin_main_init_device);
>      pci_qdev_register(&unin_main_pci_host_info);
> -    sysbus_register_dev("DEC 21154", sizeof(UNINState),
> +    sysbus_register_dev("DEC-21154", sizeof(UNINState),
>                          pci_dec_21154_init_device);
>      pci_qdev_register(&dec_21154_pci_host_info);
> -    sysbus_register_dev("Uni-north AGP", sizeof(UNINState),
> +    sysbus_register_dev("Uni-north-AGP", sizeof(UNINState),
>                          pci_unin_agp_init_device);
>      pci_qdev_register(&unin_agp_pci_host_info);
> -    sysbus_register_dev("Uni-north internal", sizeof(UNINState),
> +    sysbus_register_dev("Uni-north-internal", sizeof(UNINState),
>                          pci_unin_internal_init_device);
>      pci_qdev_register(&unin_internal_pci_host_info);
>  }
>>>
>>> I can downcase them.  Blue Swirl, any objections?
>>>
>>
>> I'd prefer the same names that are used by the device tree, like uni-n
>> and uni-north-agp. Though the bridge is name poorly, just
>> "pci-bridge".
>>
>> For example:
>> http://penguinppc.org/historical/dev-trees-html/imac_400_1.html
>
> If I read that document correctly, we have
>
>    old qdev name               device tree name
>    Uni-north main              uni-n
>    Uni-north AGP               uni-north-agp
>    Uni-north internal          pci
>    DEC 21154                   pci-bridge
>
> Do you want me to respin my patch?  If yes, the best way to make me do
> exactly what you want is to tell me exactly what you want.  In this
> case, tell me the names you want.

'pci' and 'pci-bridge' are too generic, so please respin with these:
   Uni-north main  uni-north
   Uni-north AGP   uni-north-agp
   Uni-north internal  uni-north-pci
   DEC 21154   dec-21154

[Qemu-devel] X86_64 problem

[Dave Dixon]

Greetings,

I'm building an initrd for netbooting headless/diskless cluster members. The
target platform is 64-bit ubuntu, and the development platform is 64-bit
ubuntu (albeit a very different computer physically). When I try qemu with
-kernel and -initrd, it says "This kernel requires an x86-64 CPU, but only
detected an i686 CPU." But it's definitely a 64-bit cpu - running a 64-bit OS.
If I show qeme -cpu ?, I get a list of only 32-bit cpus. What am I doing wrong?

Thanks,

-dave 

[Qemu-devel] [PATCH 09/11] Cocoa: Shutdown when window is closed

[Andreas Färber]

The application is not very useful once the guest window is closed.
QEMU is not a document-based application; terminating it automatically
saves the user another action and resembles SDL behavior.

Signed-off-by: Andreas Färber 
Cc: Mike Kronenberg 
Cc: Alexander Graf 
---
 cocoa.m |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/cocoa.m b/cocoa.m
index 70c249b..09ed3cd 100644
--- a/cocoa.m
+++ b/cocoa.m
@@ -712,6 +712,7 @@ static int cocoa_keycode_to_qemu(int keycode)
 - (void)toggleFullScreen:(id)sender;
 - (void)showQEMUDoc:(id)sender;
 - (void)showQEMUTec:(id)sender;
+- (void)windowWillClose:(NSNotification *)notification;
 @end
 
 @implementation QemuCocoaAppController
@@ -737,6 +738,7 @@ static int cocoa_keycode_to_qemu(int keycode)
 fprintf(stderr, "(cocoa) can't create window\n");
 exit(1);
 }
+[normalWindow setDelegate:self];
 [normalWindow setAcceptsMouseMovedEvents:YES];
 [normalWindow setTitle:[NSString stringWithFormat:@"QEMU"]];
 [normalWindow setContentView:cocoaView];
@@ -835,6 +837,11 @@ static int cocoa_keycode_to_qemu(int keycode)
 [[NSWorkspace sharedWorkspace] openFile:[NSString 
stringWithFormat:@"%@/../doc/qemu/qemu-tech.html",
 [[NSBundle mainBundle] resourcePath]] withApplication:@"Help Viewer"];
 }
+
+- (void)windowWillClose:(NSNotification *)notification
+{
+   [NSApp terminate:self];
+}
 @end
 
 
-- 
1.6.5.3

[Qemu-devel] [PATCH 04/11] Cocoa: Silence type warning

[Andreas Färber]

Add const for "qemu" character literal, to avoid:

warning: initialization discards qualifiers from pointer target type

An earlier patch by John proposed to use char[5]. Since we do not modify
the text and later copy it into malloc'ed memory, marking it as const
seems sufficient.

Signed-off-by: Andreas Färber 
Cc: John Arbuckle 
---
 cocoa.m |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/cocoa.m b/cocoa.m
index f8c2e00..0a95c77 100644
--- a/cocoa.m
+++ b/cocoa.m
@@ -791,7 +791,7 @@ static int cocoa_keycode_to_qemu(int keycode)
 if(returnCode == NSCancelButton) {
 exit(0);
 } else if(returnCode == NSOKButton) {
-char *bin = "qemu";
+const char *bin = "qemu";
 char *img = (char*)[ [ sheet filename ] 
cStringUsingEncoding:NSASCIIStringEncoding];
 
 char **argv = (char**)malloc( sizeof(char*)*3 );
-- 
1.6.5.3

[Qemu-devel] [PATCH 11/11] Cocoa: Use optimized drawing for the window

[Andreas Färber]

Default is NO.

Signed-off-by: Andreas Färber 
---
 cocoa.m |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/cocoa.m b/cocoa.m
index 7179151..fa64cf3 100644
--- a/cocoa.m
+++ b/cocoa.m
@@ -742,6 +742,7 @@ static int cocoa_keycode_to_qemu(int keycode)
 [normalWindow setAcceptsMouseMovedEvents:YES];
 [normalWindow setTitle:[NSString stringWithFormat:@"QEMU"]];
 [normalWindow setContentView:cocoaView];
+[normalWindow useOptimizedDrawing:YES];
 [normalWindow makeKeyAndOrderFront:self];
[normalWindow center];
 
-- 
1.6.5.3

[Qemu-devel] [PATCH 08/11] Cocoa: Don't unconditionally show the window

[Andreas Färber]

When QEMU was launched in no-graphic, Curses or VNC mode,
don't run it as a Cocoa application.

Based on patch by Alexander Graf.

v1:
- Avoid type mismatch warning for argv
- Drop noCocoa variable
- Coding Style changes

Signed-off-by: Andreas Färber 
Cc: Alexander Graf 
Cc: Mike Kronenberg 
---
 cocoa.m |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/cocoa.m b/cocoa.m
index d5f941b..70c249b 100644
--- a/cocoa.m
+++ b/cocoa.m
@@ -855,6 +855,16 @@ int main (int argc, const char * argv[]) {
 gArgc = argc;
 gArgv = (char **)argv;
 CPSProcessSerNum PSN;
+int i;
+
+/* In case we don't need to display a window, let's not do that */
+for (i = 1; i < argc; i++) {
+if (!strcmp(argv[i], "-vnc") ||
+!strcmp(argv[i], "-nographic") ||
+!strcmp(argv[i], "-curses")) {
+return qemu_main(gArgc, gArgv);
+}
+}
 
 NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
 [NSApplication sharedApplication];
-- 
1.6.5.3

[Qemu-devel] [PATCH 05/11] Cocoa: Fix compilation on Mac OS X v10.4 and earlier

[Andreas Färber]

NSView's enterFullScreenMode:withOptions: and
exitFullScreenModeWithOptions: are available on v10.5
and later only. Undefined methods raise warnings and
undefined constants result in errors.

Reported by Ryan Schmidt.

While at it, avoid a warning on v10.3.9,
where MAC_OS_X_VERSION_10_4 is not defined.

Spotted by John Arbuckle.

Fix associated comments.

Signed-off-by: Andreas Färber 
Cc: John Arbuckle 
Cc: Ryan Schmidt 
Cc: Mike Kronenberg 
---
 cocoa.m |   17 ++---
 1 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/cocoa.m b/cocoa.m
index 0a95c77..6f8b674 100644
--- a/cocoa.m
+++ b/cocoa.m
@@ -28,6 +28,9 @@
 #include "console.h"
 #include "sysemu.h"
 
+#ifndef MAC_OS_X_VERSION_10_4
+#define MAC_OS_X_VERSION_10_4 1040
+#endif
 #ifndef MAC_OS_X_VERSION_10_5
 #define MAC_OS_X_VERSION_10_5 1050
 #endif
@@ -331,7 +334,7 @@ static int cocoa_keycode_to_qemu(int keycode)
 0, //interpolate
 kCGRenderingIntentDefault //intent
 );
-// test if host support "CGImageCreateWithImageInRect" at compiletime
+// test if host supports "CGImageCreateWithImageInRect" at compile time
 #if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4)
 if (CGImageCreateWithImageInRect == NULL) { // test if 
"CGImageCreateWithImageInRect" is supported on host at runtime
 #endif
@@ -428,8 +431,8 @@ static int cocoa_keycode_to_qemu(int keycode)
 isFullscreen = FALSE;
 [self ungrabMouse];
 [self setContentDimensions];
-// test if host support "enterFullScreenMode:withOptions" at compiletime
-#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4)
+// test if host supports "exitFullScreenModeWithOptions" at compile time
+#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_5)
 if ([NSView 
respondsToSelector:@selector(exitFullScreenModeWithOptions:)]) { // test if 
"exitFullScreenModeWithOptions" is supported on host at runtime
 [self exitFullScreenModeWithOptions:nil];
 } else {
@@ -438,15 +441,15 @@ static int cocoa_keycode_to_qemu(int keycode)
 [normalWindow setContentView: self];
 [normalWindow makeKeyAndOrderFront: self];
 [NSMenu setMenuBarVisible:YES];
-#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4)
+#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_5)
 }
 #endif
 } else { // switch from desktop to fullscreen
 isFullscreen = TRUE;
 [self grabMouse];
 [self setContentDimensions];
-// test if host support "enterFullScreenMode:withOptions" at compiletime
-#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4)
+// test if host supports "enterFullScreenMode:withOptions" at compile time
+#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_5)
 if ([NSView 
respondsToSelector:@selector(enterFullScreenMode:withOptions:)]) { // test if 
"enterFullScreenMode:withOptions" is supported on host at runtime
 [self enterFullScreenMode:[NSScreen mainScreen] 
withOptions:[NSDictionary dictionaryWithObjectsAndKeys:
 [NSNumber numberWithBool:NO], NSFullScreenModeAllScreens,
@@ -462,7 +465,7 @@ static int cocoa_keycode_to_qemu(int keycode)
 [fullScreenWindow setHasShadow:NO];
 [fullScreenWindow setContentView:self];
 [fullScreenWindow makeKeyAndOrderFront:self];
-#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4)
+#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_5)
 }
 #endif
 }
-- 
1.6.5.3

[Qemu-devel] [PATCH 10/11] Cocoa: Suppress window resize animation

[Andreas Färber]

Disable the nice resize animation, to avoid drawing glitches
following a guest's screen size change.

Based on patch by Juha Riihimäki.

Signed-off-by: Andreas Färber 
Cc: Juha Riihimäki 
Cc: Alexander Graf 
Cc: Mike Kronenberg 
---
 cocoa.m |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/cocoa.m b/cocoa.m
index 09ed3cd..7179151 100644
--- a/cocoa.m
+++ b/cocoa.m
@@ -419,7 +419,7 @@ static int cocoa_keycode_to_qemu(int keycode)
 } else {
 if (qemu_name)
 [normalWindow setTitle:[NSString stringWithFormat:@"QEMU %s", 
qemu_name]];
-[normalWindow setFrame:NSMakeRect([normalWindow frame].origin.x, 
[normalWindow frame].origin.y - h + screen.height, w, h + [normalWindow 
frame].size.height - screen.height) display:YES animate:YES];
+[normalWindow setFrame:NSMakeRect([normalWindow frame].origin.x, 
[normalWindow frame].origin.y - h + screen.height, w, h + [normalWindow 
frame].size.height - screen.height) display:YES animate:NO];
 }
 screen.width = w;
 screen.height = h;
-- 
1.6.5.3

[Qemu-devel] [PATCH 07/11] Cocoa: Redraw the View asynchronously

[Andreas Färber]

Cf. 
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaPerformance/Articles/CustomViews.html

Based on patch by Juha Riihimäki.

Signed-off-by: Andreas Färber 
Cc: Juha Riihimäki 
Cc: Alexander Graf 
Cc: Mike Kronenberg 
---
 cocoa.m |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/cocoa.m b/cocoa.m
index dc9263a..d5f941b 100644
--- a/cocoa.m
+++ b/cocoa.m
@@ -938,7 +938,7 @@ static void cocoa_update(DisplayState *ds, int x, int y, 
int w, int h)
 w * [cocoaView cdx],
 h * [cocoaView cdy]);
 }
-[cocoaView displayRect:rect];
+[cocoaView setNeedsDisplayInRect:rect];
 }
 
 static void cocoa_resize(DisplayState *ds)
-- 
1.6.5.3

[Qemu-devel] [PATCH 06/11] Cocoa: Mark the View as opaque

[Andreas Färber]

Default is NO.

Cf. 
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaPerformance/Articles/CustomViews.html

Based on patch by Juha Riihimäki.

Signed-off-by: Andreas Färber 
Cc: Juha Riihimäki 
Cc: Alexander Graf 
Cc: Mike Kronenberg 
---
 cocoa.m |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/cocoa.m b/cocoa.m
index 6f8b674..dc9263a 100644
--- a/cocoa.m
+++ b/cocoa.m
@@ -305,6 +305,11 @@ static int cocoa_keycode_to_qemu(int keycode)
 [super dealloc];
 }
 
+- (BOOL) isOpaque
+{
+return YES;
+}
+
 - (void) drawRect:(NSRect) rect
 {
 COCOA_DEBUG("QemuCocoaView: drawRect\n");
-- 
1.6.5.3

[Qemu-devel] [PATCH 03/11] Cocoa: Silence warning on Big Endian host

[Andreas Färber]

__LITTLE_ENDIAN__ is undefined on Big Endian host.

Signed-off-by: Andreas Färber 
Cc: John Arbuckle 
---
 cocoa.m |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/cocoa.m b/cocoa.m
index f80a70b..f8c2e00 100644
--- a/cocoa.m
+++ b/cocoa.m
@@ -319,7 +319,7 @@ static int cocoa_keycode_to_qemu(int keycode)
 screen.bitsPerComponent, //bitsPerComponent
 screen.bitsPerPixel, //bitsPerPixel
 (screen.width * (screen.bitsPerComponent/2)), //bytesPerRow
-#if __LITTLE_ENDIAN__
+#ifdef __LITTLE_ENDIAN__
 CGColorSpaceCreateWithName(kCGColorSpaceGenericRGB), //colorspace 
for OS X >= 10.4
 kCGBitmapByteOrder32Little | kCGImageAlphaNoneSkipFirst,
 #else
-- 
1.6.5.3

[Qemu-devel] [PATCH 02/11] Cocoa: Silence warning for cocoa_keycode_to_qemu

[Andreas Färber]

Make cocoa_keycode_to_qemu static, to avoid:

warning: no previous prototype for ‘cocoa_keycode_to_qemu’

Signed-off-by: Andreas Färber 
Cc: John Arbuckle 
---
 cocoa.m |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/cocoa.m b/cocoa.m
index 989efd5..f80a70b 100644
--- a/cocoa.m
+++ b/cocoa.m
@@ -233,7 +233,7 @@ int keymap[] =
 */
 };
 
-int cocoa_keycode_to_qemu(int keycode)
+static int cocoa_keycode_to_qemu(int keycode)
 {
 if((sizeof(keymap)/sizeof(int)) <= keycode)
 {
-- 
1.6.5.3

[Qemu-devel] [PATCH 01/11] Cocoa: ppc64 host support

[Andreas Färber]

Fix integer usage in the Cocoa backend: NSInteger is long on LP64.

http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/NSView.html#//apple_ref/doc/uid/2014-BBCFHHCD

This makes the graphical display show up on a ppc64 host.

v3:
- Confine NSInteger to Mac OS X v10.5 and later

Signed-off-by: Andreas Färber 
---
 cocoa.m |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/cocoa.m b/cocoa.m
index 55ff2b4..989efd5 100644
--- a/cocoa.m
+++ b/cocoa.m
@@ -28,6 +28,10 @@
 #include "console.h"
 #include "sysemu.h"
 
+#ifndef MAC_OS_X_VERSION_10_5
+#define MAC_OS_X_VERSION_10_5 1050
+#endif
+
 
 //#define DEBUG
 
@@ -337,7 +341,11 @@ int cocoa_keycode_to_qemu(int keycode)
 } else {
 // selective drawing code (draws only dirty rectangles) (OS X >= 
10.4)
 const NSRect *rectList;
+#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_5)
+NSInteger rectCount;
+#else
 int rectCount;
+#endif
 int i;
 CGImageRef clipImageRef;
 CGRect clipRect;
-- 
1.6.5.3

[Qemu-devel] Cocoa: ppc64 host support and various improvements

[Andreas Färber]

Hello,

Recently, OSX/ppc64 TCG support was merged. This series replaces the
remainder of my ppc64 series, splitting it up for review and bisectability.

It starts with fixing an essential 64-bit incompatibility,
followed by elimination of all cocoa.m warnings on a v10.5 ppc64 system.

Also included are respins of patches fixing errors/warnings on older hosts
and optimizing drawing. Support for -nographic is added.

New is my modification of window close behavior plus another drawing
optimization for non-overlapping Views.

Most of these patches do not depend on each other, so could be cherry-picked
if necessary.

Also available at git://repo.or.cz/qemu/afaerber.git, branch cocoa.

Regards,

Andreas

Re: [Qemu-devel] approaches to 3D virtualisation

[Mark Williamson]

On Saturday 12 December 2009 01:58:02 Dave Airlie wrote:
> So I've been musing on the addition of some sort of 3D passthrough for
> qemu (as I'm sure have lots of ppl)
> 
> But I think the goals of such an addition need to be discussed prior
> to anyone writing a line of code.
> 
> Current existing solutions in the area:
> a) VMware virtual graphics adapter - based on DX9, has an open
> KMS/Gallium3D driver stack recently released by vmware, has certified
> Windows drivers and has a documented vGPU interface (it could be
> documented a lot better)
> 
> b) VirtualBox - seems to be GL based passthrough based on a Chromium
> backend. DX9 support, looks to be done via Wine DX->GL converter built
> into a Windows driver (not confirmed code base is crazy) I'm assuming
> chromium is being used to stream GL through the passthru but this
> definitely requires more investigation.

There may be an option c) in existence.  The OpenTC project (EU funded) 
included a secure UI project and part of that involved a prototype 
paravirtualised 3D driver.  It was done primarily by a research assistant at 
Cambridge University Computer Lab and basically added a paravirtual GPU device 
that essentially proxied Gallium-level commands across a shared memory 
transport.

There's a short paper on the work here, it was implemented for Xen but I doubt 
it's that Xen-specific:
http://www.xen.org/files/xensummit_oracle09/xensummit_chris.pdf

I think there's a longer paper that might be available somewhere.

I assume this is similar to the VMware approach, however as implemented it did 
require a Gallium 3D stack available on the host also in order to actually 
render the stuff.  ISTR the guy who worked on it mentioning that VMware may 
have implemented a Gallium->high level 3D API translator on the host side 
instead, since most hosts aren't using Gallium drivers yet.

The main reason I mention this is that I *thought* the code was meant to be 
open sourced, in which case it might at least be an interesting starting 
point.  I'm not quite sure where it *is* though!

Cheers,
Mark

PS: Whilst I'm braindumping, I also remember a guy implementing an OpenGL 
guest->host passthrough for Qemu back when Fabrice was maintainer, so that 
code should be in the archives somewhere.  Obviously that's not so useful for 
Windows guests, though Fabrice suggested maybe investigating Wine's DX->GL 
translation code.  Another GL virtualisation project is here, which is also 
GL-only (but despite the name is not Xen-only): 
http://www.cs.toronto.edu/~andreslc/xen-gl/

> Now both of these seem to be local only rendering solutions, though I
> might be underselling the vbox/chromium fun.
> 
> Now to add a remoting 3D rendering protocol is where things get ugly
> fast, and very different from current 2D rendering with offscreen
> pixmaps. The major difference is most server farms will not contain
> any 3D hardware and will not want to contain any 3D hw due to power
> considerations. Now if you have a remote protocol, and the client
> disconnects, you have to keep some sort of transaction log, and either
> replay the transactions when a client reconnects, or have some sort of
> sw rendering kick in on the server as a fallback. Now 3D sw rendering
> solutions are insanely slow and quite CPU intensive. VMware are
> working on an llvm based 3D renderer for something like this situation
> but I'm not convinced of how useable it will be.
> 
> Also with remoting you need to come up with a minimum acceptable level
> of 3D you want to expose to guests OSes depending on what the
> capabilities of the client side hw, or refuse connections unless the
> client can run all the features that you've exposed in side the guest.
> This ranges from DX7->DX11, and GL1.5 to GL3.0 situations.
> 
> I'm not sure how ppl who work with VNC see VNC fitting in with this
> sort of protocol, I expect SPICE is better placed with proper design
> to address this. Though it would firstly be nice to design a vGPU
> interface for the guest OS to work against, I lean towards the VMware
> because of the availability of guest drivers, however the Virtualbox
> one is probably also acceptable if anyone can find where it is
> documented.
> 
> This is just a sort of a brain dump from me, but I'd like to get ppl
> talking about this, since 3D is not to be considered some simple
> extension of 2D functionality,
> its a whole different world, modern GPUs are 98% of silicon dedicated
> to 3D processing, most of the current 2D type accel such as QXL
> interface provides are done using 3D engines on most GPUs, and the
> inability to render 3D on the server side of a link with any useful
> speed in current server hw.
> 
> So I suppose the main questions to answer up front are:
> 1) Rendering done on same hw as VM is running?
> just use VNC to dump the final answer over the network.
> 2) Rendering done on the client viewing end of the link where
> 

Re: [Qemu-devel] Re: approaches to 3D virtualisation

[Dave Airlie]

On Sun, Dec 13, 2009 at 1:23 AM, Anthony Liguori  wrote:
> Juan Quintela wrote:
>>
>> Dave Airlie  wrote:
>>
>
> Current existing solutions in the area:
> a) VMware virtual graphics adapter - based on DX9, has an open
> KMS/Gallium3D driver stack recently released by vmware, has certified
> Windows drivers and has a documented vGPU interface (it could be
> documented a lot better)
>
>>>
>>>
>>> http://vmware-svga.svn.sourceforge.net/viewvc/vmware-svga/trunk/doc/gpu-wiov.pdf?revision=1
>>>
>>> is a good whitepaper on the different 3D virtualisation approaches and
>>> why
>>> vmware picked what they did also.
>>>
>>> Dave.
>>>
>>
>> I have zero clue of 3D, but for the qemu part, vmware_vga is the "nicer"
>> driver.
>>
>
> I like the design of the vmware_vga driver but it has one critical flaw.
>  The Windows drivers has a EULA that prohibits their use outside of VMware.

Good point, I hadn't read the vmware EULA, this does put a spanner in the works,
unless someone is willing to write alternate drivers.

My reason for liking vmware is its not a redesign it all at once
solution, you can bring
up the emulated adapter using known working drivers (the Linux ones
have no EULA),
and confirm it works, if you then want to write Windows drivers
outside the EULA, at
least you have two platforms to validate them on, Someone could in theory write
Windows drivers under VMware itself and we could work in parallel

>
> Without reasonably licensed Windows drivers, I don't think it's viable.
>
> I'm hoping QXL can fill this niche.

It would be nice, its just the design everything at once approach
never sits well
with me, having to do the host side interface, guest vGPU and guest drivers
all at once requires a lot of blame hunting, i.e. where correct fixes go etc.

But yes ideally an open QXL that can challenge VMware would be coolest

Maybe the QXL interface can leverage some of the VMware design at least
rather than reinventing the wheel

Dave.

Re: [Qemu-devel] Re: Spice project is now open

[Daniel P. Berrange]

On Sat, Dec 12, 2009 at 05:46:08PM -0600, Anthony Liguori wrote:
> Dor Laor wrote:
> >On 12/12/2009 07:40 PM, Anthony Liguori wrote:
> >>If Spice can crash a guest, that indicates to me that Spice is
> >>maintaining guest visible state.  That is difficult architecturally
> >>because if we want to do something like introduce a secure sandbox for
> >>running guest visible emulation, libspice would have to be part of that
> >>sandbox which would seem to be difficult.
> >>
> >>The VNC server cannot crash a guest by comparison.
> >
> >That's not accurate:
> 
> Cannot crash the *guest*.  It can crash qemu but it's not guest 
> visible.  IOW, the guest never interacts directly with the VNC server.  
> The difference matters when it comes to security sandboxing and live 
> migration.
> 
> >If we'll break spice to components we have the following (and I'm not 
> >a spice expert):
> >1. QXL device/driver pair
> >   Is anyone debate we should have it in qemu?
> >   We should attach it SDL and vnc backend too anyway.
> >2. VDI (Virtual Desktop Interface)
> >   http://www.spice-space.org/vdi.html
> 
> FYI, www.spice-space.org is not responding for me.

There is a planned outage for a physical relocation of the server that
hosts spice-space.org, virt-manager.org, ovirt.org, etc & a lot of other
sites. It should be back online before Monday if all has gone to plan.

> Where #3 lives is purely a function of what level of integration it 
> needs with qemu.  There may be advantages to having it external to 
> qemu.  I actually think we should move the VNC server out of qemu...
> 
> Dan Berrange and I have been talking about being able to move VNC server 
> into a central process such that all of the VMs can have a single VNC 
> port that can be connected to.  This greatly simplifies the firewalling 
> logic that an administrator has to deal with.   That's a problem I've 
> already had to deal with for our management tools.  We use a private 
> network for management and we bridge the VNC traffic into the customers 
> network so they can see the VGA session.  But since that traffic can be 
> a large range of ports and we have to tunnel the traffic through a 
> central server to get into the customer network, it's very difficult to 
> setup without opening up a mess of ports.  I think we're currently 
> opening a few thousand just for VNC.

Actually my plan was to have a VNC proxy server, that sat between the
end user & the real VNC in QEMU. Specifically I wanted to allow for a
model where the VNC server end users connected to for console servers
was on a physically separate host from the VMs. I had a handful of
use cases, mostly to deal with an oVirt deployment where console users
could be from the internet, rather than an intranet.

 - Avoiding the need to open up many ports on firewalls
 - Allow on the fly switching between any VMs the currently authenticated
   user was authorized to view without opening more connections (avoids
   needing to re-authenticate for each VM)
 - Avoid needing to expose virtualization hosts to console users,
   since console users may be coming in from an untrusted network, or
   even the internet itself.
 - Allow seemless migration where proxy server simply re-connects to
   the VM on new host, without the end user VNC connection ever noticing.

> For VNC, to make this efficient we just need a shared memory transport 
> that we can use locally.  I doubt the added latency will matter as long 
> as we're not copying data.

That would preclude running it as an off-node service, but since latency
is important that's probably inevitable. In any case there'd be nothing 
to stop someone adding an off-node proxy in front of that anyway should
requirements truely require it. The first point of just getting away from
the one-TCP port per VM model is a worthwhile use case all of its own.

> Of course, Spice is a different thing altogether.  I have no idea 
> whether it makes sense for Spice like it would for VNC.  But I'd like to 
> understand if the option is available.

I believe Spice shares the same needs as VNC in this regard, since when
spawning a VM with Spice, each must be given a pair of unique ports (one
runs cleartext, one with TLS/SSL). 

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] Re: Spice project is now open

[Anthony Liguori]

Andrea Arcangeli wrote:

On Sat, Dec 12, 2009 at 05:52:49PM -0600, Anthony Liguori wrote:
  
This is the bit that confuses me.  VNC is not a driver.  When I say it 
cannot crash the guest, I mean that if the VNC server makes a mistake, 
there may be a SEGV in qemu or it may just result in a VNC client seeing 
corruption.  The guest does not see a bad VGA register content though or 
something like that.  VNC is a host driver or backend service or 
whatever you want to call it.  VNC does not have migration state because 
it has no guest visible state.



Again, a guest crash because of qlx interaction is not what I
mean. And the reason I wasn't even thinking about this scenario is
that the kind of paravirt-driver related guest crash you are talking
about, if it can happen, can happen even if spice lib in the qemu side
lives in a separate address space.


Yes, that's absolutely true.


 This is why this case of pure guest
crash through qlx is not relevant to decide if to have spice lib
inside our outside of qemu address space, I think that is more about
the qlx driver and not spice on the qemu side.
  


The guest visible state thing has nothing to do with where it lives.  
Sorry if that's gotten mixed in with this discussion.


The reason I care about what interacts directly with the guest is that 
I'd like to see us move qemu to where there's a very strong separate 
between guest-visible interactions and then host services to the point 
where the portions of guest-visible code could be run in a highly secure 
environment.  If all of libspice would have to live in that environment 
because it interacts with a guest directly, that would get complicated.




When you compare Spice to a virtio driver, that implies to me that
it does interact directly with the guest.  In fact, when you have a
driver passing high level commands to Spice, you would think that
the status of these commands would be pending state, no?  Let's say
the guest sends a fill rectangle command and the Spice server sends
that to a client.  The Spice server needs to know when the client
has finished that (maybe not, but let's assume it does) so there is
now a pending request that someone has to keep track of.  If you do
a savevm or a live migration, or the client disconnects, the state
of that request has to be saved somewhere (unless you tell the guest
that the client has disconnected which is how Xen handles pv device
migration).  So that's what I'm trying to understand.  How far does
the guest's visibility go?  Is the guest totally ignorant of
anything other than QXL?  If so, that's good, and I'm very happy
about it :-) Regards, Anthony Liguori



I would expect it to be ignorant about anything but qlx (what else
does it need to know), but I never looked into spice before it was
open source so it's not like I'm the right person to ask for those
details ;).
  

:-)

I'm really interested in those details.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: Spice project is now open

[Andrea Arcangeli]

On Sat, Dec 12, 2009 at 05:52:49PM -0600, Anthony Liguori wrote:
> This is the bit that confuses me.  VNC is not a driver.  When I say it 
> cannot crash the guest, I mean that if the VNC server makes a mistake, 
> there may be a SEGV in qemu or it may just result in a VNC client seeing 
> corruption.  The guest does not see a bad VGA register content though or 
> something like that.  VNC is a host driver or backend service or 
> whatever you want to call it.  VNC does not have migration state because 
> it has no guest visible state.

Again, a guest crash because of qlx interaction is not what I
mean. And the reason I wasn't even thinking about this scenario is
that the kind of paravirt-driver related guest crash you are talking
about, if it can happen, can happen even if spice lib in the qemu side
lives in a separate address space. This is why this case of pure guest
crash through qlx is not relevant to decide if to have spice lib
inside our outside of qemu address space, I think that is more about
the qlx driver and not spice on the qemu side.

With regard to VNC, as long as VNC lives in the same address space
with the guest, it can just follow a dangling pointer and corrupt and
crash the guest too like libspice or qcow2 or anything else in that
address space could too, or worse silently corrupt guest fs metadata
and leave traces of fs corruption that could emerge months or years
after the bug was fixed. qlx and paravirt definitely not required for
this, VNC can do it too.

> When you compare Spice to a virtio driver, that implies to me that
> it does interact directly with the guest.  In fact, when you have a
> driver passing high level commands to Spice, you would think that
> the status of these commands would be pending state, no?  Let's say
> the guest sends a fill rectangle command and the Spice server sends
> that to a client.  The Spice server needs to know when the client
> has finished that (maybe not, but let's assume it does) so there is
> now a pending request that someone has to keep track of.  If you do
> a savevm or a live migration, or the client disconnects, the state
> of that request has to be saved somewhere (unless you tell the guest
> that the client has disconnected which is how Xen handles pv device
> migration).  So that's what I'm trying to understand.  How far does
> the guest's visibility go?  Is the guest totally ignorant of
> anything other than QXL?  If so, that's good, and I'm very happy
> about it :-) Regards, Anthony Liguori

I would expect it to be ignorant about anything but qlx (what else
does it need to know), but I never looked into spice before it was
open source so it's not like I'm the right person to ask for those
details ;).

Re: [Qemu-devel] Re: Spice project is now open

[Anthony Liguori]

Andrea Arcangeli wrote:

On Sat, Dec 12, 2009 at 11:40:21AM -0600, Anthony Liguori wrote:
  
If Spice can crash a guest, that indicates to me that Spice is 



That's not what I meant, anything in qemu address space can crash a
guest not just spice, even qcow2 could crash a guest, you just need to
*vaddr_in_guest_physical_space = 0 through a corrupted pointer
(corrupted pointers are very rare, gcc is very pedantic, there are
tools to trap those but they historically happened a few times in the
kernel), but when I said it I didn't in mind crashing just the guest,
I meant corrupting qemu memory itself through a different corrupted
vaddr, but it is the same risk, you could flip a bit in a buffer
header holding ext4 metadata in the guest physical address space or
flip a bit in qcow2 cluster bitmap, it doesn't make a difference both
could result in fs corruption in an extremely unlikely scenario (and
that extremely unlikely scenario is the only one where the microkernel
design would eventually payoff, where you get the graphics and mouse
hosed, but the guest sill is reachable through the network). I simply
meant spice should live in the same address space where the other
virtio drivers are living for the same reasons (performance), it's no
different.


This is the bit that confuses me.  VNC is not a driver.  When I say it 
cannot crash the guest, I mean that if the VNC server makes a mistake, 
there may be a SEGV in qemu or it may just result in a VNC client seeing 
corruption.  The guest does not see a bad VGA register content though or 
something like that.  VNC is a host driver or backend service or 
whatever you want to call it.  VNC does not have migration state because 
it has no guest visible state.


When you compare Spice to a virtio driver, that implies to me that it 
does interact directly with the guest.  In fact, when you have a driver 
passing high level commands to Spice, you would think that the status of 
these commands would be pending state, no?


Let's say the guest sends a fill rectangle command and the Spice server 
sends that to a client.  The Spice server needs to know when the client 
has finished that (maybe not, but let's assume it does) so there is now 
a pending request that someone has to keep track of.  If you do a savevm 
or a live migration, or the client disconnects, the state of that 
request has to be saved somewhere (unless you tell the guest that the 
client has disconnected which is how Xen handles pv device migration).


So that's what I'm trying to understand.  How far does the guest's 
visibility go?  Is the guest totally ignorant of anything other than 
QXL?  If so, that's good, and I'm very happy about it :-)


Regards,

Anthony Liguori

Re: [Qemu-devel] Re: Spice project is now open

[Anthony Liguori]

Dor Laor wrote:

On 12/12/2009 07:40 PM, Anthony Liguori wrote:

If Spice can crash a guest, that indicates to me that Spice is
maintaining guest visible state.  That is difficult architecturally
because if we want to do something like introduce a secure sandbox for
running guest visible emulation, libspice would have to be part of that
sandbox which would seem to be difficult.

The VNC server cannot crash a guest by comparison.


That's not accurate:


Cannot crash the *guest*.  It can crash qemu but it's not guest 
visible.  IOW, the guest never interacts directly with the VNC server.  
The difference matters when it comes to security sandboxing and live 
migration.


If we'll break spice to components we have the following (and I'm not 
a spice expert):

1. QXL device/driver pair
   Is anyone debate we should have it in qemu?
   We should attach it SDL and vnc backend too anyway.
2. VDI (Virtual Desktop Interface)
   http://www.spice-space.org/vdi.html


FYI, www.spice-space.org is not responding for me.


   It's an abstraction layer for graphics/keyboard/mouse/sound
   /usb/serial.
   We need it anyway regardless of spice. What is our user like to
   switch from vnc to SDL on runtime? It's good for usb-over-ip for
   remoting, for various mouse modes, etc.
3. Spice server
   Shared library, in the same address space of qemu (like vnc server).
   Very sophisticated peace of code.


The bit I've been trying to understand is whether the Spice server 
interacts directly with a guest or not.  I assume I'd be able to gather 
that from the VDI interfaces but the server's been down since this morning.



So #1 shouldn't run into any opposition.
We can discuss why #2 is good, the layering separation between 
guest/host seems good idea to me.
As for #3, this is a library. If we have #2, one can even use a 
separate address space for sanity reasons. From my experience with 
spice (through all Red Hat QA), 99.9% of failures originated in qemu..


Where #3 lives is purely a function of what level of integration it 
needs with qemu.  There may be advantages to having it external to 
qemu.  I actually think we should move the VNC server out of qemu...


Dan Berrange and I have been talking about being able to move VNC server 
into a central process such that all of the VMs can have a single VNC 
port that can be connected to.  This greatly simplifies the firewalling 
logic that an administrator has to deal with.   That's a problem I've 
already had to deal with for our management tools.  We use a private 
network for management and we bridge the VNC traffic into the customers 
network so they can see the VGA session.  But since that traffic can be 
a large range of ports and we have to tunnel the traffic through a 
central server to get into the customer network, it's very difficult to 
setup without opening up a mess of ports.  I think we're currently 
opening a few thousand just for VNC.


For VNC, to make this efficient we just need a shared memory transport 
that we can use locally.  I doubt the added latency will matter as long 
as we're not copying data.


Of course, Spice is a different thing altogether.  I have no idea 
whether it makes sense for Spice like it would for VNC.  But I'd like to 
understand if the option is available.


Regards,

Anthony Liguori

Re: [Qemu-devel] Re: Spice project is now open

[Andrea Arcangeli]

On Sat, Dec 12, 2009 at 11:40:21AM -0600, Anthony Liguori wrote:
> If Spice can crash a guest, that indicates to me that Spice is 

That's not what I meant, anything in qemu address space can crash a
guest not just spice, even qcow2 could crash a guest, you just need to
*vaddr_in_guest_physical_space = 0 through a corrupted pointer
(corrupted pointers are very rare, gcc is very pedantic, there are
tools to trap those but they historically happened a few times in the
kernel), but when I said it I didn't in mind crashing just the guest,
I meant corrupting qemu memory itself through a different corrupted
vaddr, but it is the same risk, you could flip a bit in a buffer
header holding ext4 metadata in the guest physical address space or
flip a bit in qcow2 cluster bitmap, it doesn't make a difference both
could result in fs corruption in an extremely unlikely scenario (and
that extremely unlikely scenario is the only one where the microkernel
design would eventually payoff, where you get the graphics and mouse
hosed, but the guest sill is reachable through the network). I simply
meant spice should live in the same address space where the other
virtio drivers are living for the same reasons (performance), it's no
different. Izik already answered the other part.

Thanks,
Andrea

[Qemu-devel] Re: irq latency and tcg

[Paul Brook]

> According to comment in exec-all.h:
> /* Deterministic execution requires that IO only be performed on the last
>instruction of a TB so that interrupts take effect immediately.  */
> 
> Sparc generator must then violate this assumption. Is the assumption
> valid also when not using icount and should the check be enabled for
> all cases, not just icount?

Not really.  With -icount we're trying to achieve deterministic behavior[1]. 
When icount is disabled a few extra instructions interrupt latency is the 
least of your problems.

I guess with in-core peripherals you may be able to accurately predict 
interrupt response. However for the vast majority of cases I wouldn't be 
surprised if real hardware has a few cycles latency anyway.

Paul

[1] Even with -icount, qemu is still a long way from being cycle accurate. The 
goal is to give reproducible and consistent results. Actual realtime 
characteristics are still likely to be very different from real hardware.

Paul

[Qemu-devel] Re: [PATCH 3/3] Workaround --whole-archive on Solaris

[Andreas Färber]

Am 12.12.2009 um 21:57 schrieb Juan Quintela:


Andreas Färber  wrote:

From: Andreas Färber 

On OpenSolaris, neither --whole-archive nor -z allextract
appear to work as expected, causing runtime errors. For example:

qemu: could not open disk image [...]

Fix this by extracting archives and linking their object files  
individually.


libqemu_common.a contains object files from different subdirectories,
leading to name clashes, e.g., nbd.o vs. block/nbd.o.

Archive a renamed copy of the affected files instead, this avoids
duplicating %.c -> %.o compilation rules. Two dashes are used for  
the copy

to avoid name clashes between, e.g., block-qcow.c and block/qcow.c.

Contain this behavior to Solaris to avoid speed regressions on Linux.


I just wonder.  If we are:
a- linking all archives (that is the whole point)
b- some OS's need to unpack the library due to broken ld (or whatever)

why don't we do the right thing?


Maybe because, if we are honest, we have lengthy discussions about  
sticking to ISO/ANSI/POSIX malloc behavior when it affects customers  
on The OS, but silently ignore some "fringe" OS breaking after  
choosing a convenient but non-standard GCC mechanism? ;)



just put the objects in some directory, and not create the library in
the 1st place?  It is a static library, not a dynamic one, and we want
everything in the 1st place.


The trick is knowing which "everything" we want today!


I think that this is a saner approach that having two ways (well
currently several ways) of linking all archives.

What do you people think?


Certainly I would prefer having one shared linking mechanism.

The three separate Makefiles (Makefile, Makefile.hw, Makefile.target)  
that govern which objects are to be compiled pose the problem.
In the end, we need some mechanism to get the right set of objects  
into Makefile.target. Previous attempts were

(i) writing object file paths to a file (me not satisfied), or
(ii) printing them from within make (Avi objected), and now
(iii) extracting them from archives (Juan objected for Linux).

Juan, being our Makefile inventor, what about
(iv) moving the assembling of some of the obj-y variables to a shared  
file included by all three Makefiles?
Would that work? If we had, e.g., common-obj-y and libhw{32,64}-obj-y  
accessible in Makefile.target, we could use them for both dependency  
modelling and linking.


Regards,
Andreas

Re: [Qemu-devel] Re: Spice project is now open

[Dor Laor]

On 12/12/2009 09:48 PM, Izik Eidus wrote:

On Sat, 12 Dec 2009 13:26:30 -0600
Anthony Liguori  wrote:


Izik Eidus wrote:

On Sat, 12 Dec 2009 11:40:21 -0600
Anthony Liguori  wrote:



FWIW, I don't see any reason why Spice couldn't be made to be
separate from guest emulation.  I think it would just require the
right interfacing in qemu.  I think that's purely an implementation
detail.



The QXL device is one of the core compoments of spice..., how can
you separate it from the guest visible state? (it is pci device)



How does live migration work then?  Do you have to query libspice for
it's state?  Does it return an opaque blob?  How can it integrate
with VMState since libspice doesn't have any knowledge of something
like VMState?


QXL transfer the device states by itself using qemu migration
mechanisem.

The spice server just need that the pci memory (and the qxl ram/rom
state) will be migrate. (From the point of view of guest visible state)

All this guest visible states are transfered by the qxl device using
qemu.


In addition, the src spice server notifies the client on the migration 
execution and at the end of the migration it commands it to switch to 
the destination. It even passes a one time password session key.


Does vnc has that?

If you're interested of having a basic vnc mode, it will be much more 
easier, cleaner and faster to do the opposite, like Mark suggested -

Add a basic vnc mode to spice.
That said, it shouldn't be a merge criteria, let's start with qxl and 
vdi, and than the spice library.






Regards,

Anthony Liguori

Re: [Qemu-devel] Re: Spice project is now open

[Dor Laor]

On 12/12/2009 07:40 PM, Anthony Liguori wrote:

If Spice can crash a guest, that indicates to me that Spice is
maintaining guest visible state.  That is difficult architecturally
because if we want to do something like introduce a secure sandbox for
running guest visible emulation, libspice would have to be part of that
sandbox which would seem to be difficult.

The VNC server cannot crash a guest by comparison.


That's not accurate:
https://bugzilla.redhat.com/show_bug.cgi?id=505641 -  (CVE-2009-3616) 
CVE-2009-3616 Remote VNC client can cause any QEMU VNC server to crash 
with a double-free


and again: https://bugzilla.redhat.com/show_bug.cgi?id=495646  -  Get 
segfault when changing vnc password



Why vnc server code should be protected and spice server not?
In addition, like Izik said, the qxl device/driver pair is a must. QXL 
is a great addition even in 'old' vnc mode since it supports lots of 
goodies. In addition for caching it also allows s3 state (qxl d3) for 
the OS, unlike Cirrus.


More VNC bugs that we run into:

https://bugzilla.redhat.com/show_bug.cgi?id=507880 -  qemu hangs during 
VNC connection from RHEVM
https://bugzilla.redhat.com/show_bug.cgi?id=490344 -  QEMU: Cannot VNC 
to a VM if a VNC is already opened to it
https://bugzilla.redhat.com/show_bug.cgi?id=497524 -  QEMU: Early BIOS 
error message cannot be seen after reboot in VNC
https://bugzilla.redhat.com/show_bug.cgi?id=501263 -  KVM: VNC screen is 
sometimes corrupted (at boot?)



If we'll break spice to components we have the following (and I'm not a 
spice expert):

1. QXL device/driver pair
   Is anyone debate we should have it in qemu?
   We should attach it SDL and vnc backend too anyway.
2. VDI (Virtual Desktop Interface)
   http://www.spice-space.org/vdi.html
   It's an abstraction layer for graphics/keyboard/mouse/sound
   /usb/serial.
   We need it anyway regardless of spice. What is our user like to
   switch from vnc to SDL on runtime? It's good for usb-over-ip for
   remoting, for various mouse modes, etc.
3. Spice server
   Shared library, in the same address space of qemu (like vnc server).
   Very sophisticated peace of code.
4. Spice client - independent.

So #1 shouldn't run into any opposition.
We can discuss why #2 is good, the layering separation between 
guest/host seems good idea to me.
As for #3, this is a library. If we have #2, one can even use a separate 
address space for sanity reasons. From my experience with spice (through 
all Red Hat QA), 99.9% of failures originated in qemu..


HTH,
Dor




FWIW, I don't see any reason why Spice couldn't be made to be separate
from guest emulation.  I think it would just require the right
interfacing in qemu.  I think that's purely an implementation detail.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: Spice and legacy VGA drivers

[Dave Airlie]

On Sun, Dec 13, 2009 at 5:28 AM, Anthony Liguori  wrote:
> Izik Eidus wrote:
>>
>> That specific area in spice will be changed very soon due to new
>> requiments that the offscreens will add.
>> Windows direct draw allow modifying offscreen (or even primary)
>> surfaces using a pointer giving to the user, this mean we can`t know
>> what parts of the surface was changed... (In some modes the primary
>> screen can be changed without we know about this)
>>
>> We already thought about few algorithems we might want to add to spice
>> to better address this "changed without notifications surfaces", But it
>> is still not in a state I can confirm in what direction we will go in
>> the end (We still need to test most of the cases to know what fit us
>> best)
>>
>
> Okay, I'm interested in hearing more about this as it develops.  I think
> good support for legacy modes is an important requirement.
>
> For instance, I very often interact with VMs in text console mode.  In cloud
> deployments, it's pretty common to have minimal appliances that don't have a
> full X session.

We should develop a KMS stack for QXL like VMware have done for SVGA,

This would mean getting a fb console in the guests and you can use fb's
dirty support. Getting out of VGA ASAP is a kernel graphics driver goal going
forward.

Also re:cairo, nearly ever app on my desktop uses it via gtk.
Now how many properitary apps exist that don't is an open
question, but anyone using QT or GTK will be using X render for lots of
drawing right now.

I'm not really sure how VNC works at the non-screen scraping level so I suppose
I should investigate, I've never seen VNC as useful fit for doing 3D rendering,
but I suppose it could be extended.

Dave.

[Qemu-devel] [FOR 0.12 PATCH] sparc implement AFX for SS-5

[Artyom Tarasenko]

Implement a stub for the AFX register on SparcStation-5.
This stub is needed for running the original SS-5 OBP 
instead of OpenBIOS (which allows to boot Solaris 2.5.1
and Solaris 2.6 kernels).

---
Signed-off-by: Artyom Tarasenko 
---
diff --git a/hw/sun4m.c b/hw/sun4m.c
index 5b3e0fd..7db00b8 100644
--- a/hw/sun4m.c
+++ b/hw/sun4m.c
@@ -95,7 +95,7 @@ struct sun4m_hwdef {
 target_phys_addr_t iommu_base, slavio_base;
 target_phys_addr_t intctl_base, counter_base, nvram_base, ms_kb_base;
 target_phys_addr_t serial_base, fd_base;
-target_phys_addr_t idreg_base, dma_base, esp_base, le_base;
+target_phys_addr_t afx_base, idreg_base, dma_base, esp_base, le_base;
 target_phys_addr_t tcx_base, cs_base, apc_base, aux1_base, aux2_base;
 target_phys_addr_t ecc_base;
 uint32_t ecc_version;
@@ -600,6 +600,41 @@ static void idreg_register_devices(void)
 
 device_init(idreg_register_devices);
 
+/* SS-5 TCX AFX register */
+static void afx_init(target_phys_addr_t addr)
+{
+DeviceState *dev;
+SysBusDevice *s;
+
+dev = qdev_create(NULL, "tcx_afx");
+qdev_init_nofail(dev);
+s = sysbus_from_qdev(dev);
+
+sysbus_mmio_map(s, 0, addr);
+}
+
+static int afx_init1(SysBusDevice *dev)
+{
+ram_addr_t afx_offset;
+
+afx_offset = qemu_ram_alloc(4);
+sysbus_init_mmio(dev, 4, afx_offset | IO_MEM_RAM);
+return 0;
+}
+
+static SysBusDeviceInfo afx_info = {
+.init = afx_init1,
+.qdev.name  = "tcx_afx",
+.qdev.size  = sizeof(SysBusDevice),
+};
+
+static void afx_register_devices(void)
+{
+sysbus_register_withprop(&afx_info);
+}
+
+device_init(afx_register_devices);
+
 /* Boot PROM (OpenBIOS) */
 static void prom_init(target_phys_addr_t addr, const char *bios_name)
 {
@@ -795,6 +830,10 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef, 
ram_addr_t RAM_size,
 idreg_init(hwdef->idreg_base);
 }
 
+if (hwdef->afx_base) {
+afx_init(hwdef->afx_base);
+}
+
 iommu = iommu_init(hwdef->iommu_base, hwdef->iommu_version,
slavio_irq[30]);
 
@@ -920,6 +959,7 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
 .esp_base = 0x7880,
 .le_base  = 0x78c0,
 .apc_base = 0x6a00,
+.afx_base = 0x6e00,
 .aux1_base= 0x7190,
 .aux2_base= 0x7191,
 .nvram_machine_id = 0x80,

[Qemu-devel] [FOR 0.12 PATCH] fdc/sparc don't hang on detection under OBP

[Artyom Tarasenko]

Stepping through the SS-5's OBP initialization routines
it looks like reading fdc main status register should
clear the fd interrupt.
The patch doesn't fix problems with fdc on sparc platform,
it only fixes fdc detection.
---
Signed-off-by: Artyom Tarasenko 
---
diff --git a/hw/fdc.c b/hw/fdc.c
index e875291..11ea439 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -960,6 +960,12 @@ static uint32_t fdctrl_read_main_status (fdctrl_t *fdctrl)
 fdctrl->dsr &= ~FD_DSR_PWRDOWN;
 fdctrl->dor |= FD_DOR_nRESET;
 
+/* Sparc mutation */
+if (fdctrl->sun4m) {
+retval |= FD_MSR_DIO;
+fdctrl_reset_irq(fdctrl);
+};
+
 FLOPPY_DPRINTF("main status register: 0x%02x\n", retval);
 
 return retval;

[Qemu-devel] Call for participation to the "Alt-OS" devroom at FOSDEM

[François Revol]

Hi,
I'm sending this call here too, I think it'd be interesting to see a
talk about how QEMU is used in various FOSS OS projets for testing,
debugging...
At least in Haiku many developers use it in such ways.
Also, it's interesting to hear about porting efforts of QEMU itself to
unusual OSes. Other subject could be the difficulties of supporting
weird OSes without compromising emulation speed.

François.
-

During the previous edition of the Free and Open Source Software
Developer's European Meeting (FOSDEM) , several
alternative FOSS Operating System projects
(Haiku , ReactOS )
shared booths, but there were discussions about going beyond presenting
each projects on its own, and instead seek cooperation. Recently, at
the Google Summer of Code mentor summit, other OS projects gathered and
formed the Rosetta OS group  to
work on driver sharing.

This year, the FOSDEM (in Brussels, 6-7th February 2010) will host the
"Alt-OS" devroom on sunday from 9:00 to 17:00, organized by members of
the Rosetta OS project.

This devroom is meant as a place for Free and OpenSource Alternative
Operating System projects to share ideas and work on topics like:
 * distinguishing design and features,
 * device drivers and how to share them,
 * sharing code for internal components,
 * internal usage of other FOSS projects to build upon,
 * application portability,
 * interoperability,
  * file formats,
  * extended attributes...

We are interested to hear about your OS projects, how they are
designed, and what they could eventually share for other projects'
benefit.
In addition to all FOSS OS projects, any application project that is
seeking new target platforms is invited. Featured projects will include
participants from the Rosetta OS project which charter 

matches our devroom goal.

As time allows, we are also interested in transversal subjects in
cooperation with other devrooms. As an example, possible topics could
include:
 * unusual package management with the Crossdistro room,
 * standardization of GUI elements and behavior with the Crossdesktop
devroom,
 * scalability with the Embedded devroom,
 * ways in which BSD drivers were reused in your project,
 * concerns about porting Java,
 * Gallium3D port progress reports...

The format of the talks can vary, from 45min large speech to 15 min
general project presentation, or hand-on hacking session.

= Proposals =

Proposals should be sent to François Revol by mail: re...@free.fr

Your proposal should include:
 * duration (in 15 minute blocks -- please stick with that granularity,
as it will make the schedule somewhat easier to follow for visitors),
 * activity title (please try to be descriptive, there are ~250 talks
at FOSDEM during the week-end ;)),
 * a short abstract (1-2 paragraphs),
 * a longer description if appropriate,
 * optionally a list of links to the project website or similar
 * for each speaker:
  * the speaker's real name,
  * a short overview of her bio in a couple of lines,
  * optionally also a longer bio,
  * optionally a picture (please send it to us as 128x128 PNG),
  * optionally links to her website, blog, ...

Plain-text format is preferred by the FOSDEM team, it makes their life
easier, something like:

--
John Doe
john@example.org

John is currently working as a freelancer and spends most of his free
time contributing to various opensource projects, most prominently on
libjohndoe.

John currently lives in England with his wife, 2 kids and a bunch of
kitten. He loves spending his time walking around in the woods, and
of course kitten. He has a masters degree in kitten science, which
helps him a lot with coding.

blog: http://johndoe.example.org/blog/
attached: john_doe.png
--

= Deadline =

The deadline for submissions is 2009-12-25, please try to stick to it.
Acceptance notification on 2009-12-31.

= Organization =

The room provided by the FOSDEM team has:
 * room number AW1.105 with 48 seats,
 * a video projector with VGA cable,
 * wireless internet.
We will try to provide a wifi router with ethernet ports for
demonstrations since we know many projects do not have functional wifi
drivers yet.
We will also try to provide a laptop to load your slides on if you
can't use your own machine.

It is advised to see with your project supporting associations for
possible reimbursement of travel and hosting cost, since the FOSDEM
team cannot help there. Attendance is free however.
Also remember to check other devroom calls as well as the call for
lightning talks , for
subjects that might not fit our topics of interest.

= Projected schedule =


 9:00   Welcome (15min)
 9:15   "Rosetta OS" project
morning project presentations, design...
afternoon   more projects, workshops...
16:45   Closing (15min)

[Qemu-devel] Re: [PATCH 16/17] usb-uhci: symbolic names for pci registers

[Michael S. Tsirkin]

On Sat, Dec 12, 2009 at 04:41:07PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin"  wrote:
> > No functional changes. I verified that the generated binary
> > does not change.
> 
> s/uhci/ohci/ in subject :)

Ugh. Right. Good catch.

> > Signed-off-by: Michael S. Tsirkin 
> > ---
> >  hw/usb-ohci.c |6 --
> >  1 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/usb-ohci.c b/hw/usb-ohci.c
> > index 7ab3a98..deab7f3 100644
> > --- a/hw/usb-ohci.c
> > +++ b/hw/usb-ohci.c
> > @@ -1721,14 +1721,16 @@ static int usb_ohci_initfn_pci(struct PCIDevice 
> > *dev)
> >  pci_config_set_vendor_id(ohci->pci_dev.config, PCI_VENDOR_ID_APPLE);
> >  pci_config_set_device_id(ohci->pci_dev.config,
> >   PCI_DEVICE_ID_APPLE_IPID_USB);
> > -ohci->pci_dev.config[0x09] = 0x10; /* OHCI */
> > +ohci->pci_dev.config[PCI_CLASS_PROG] = 0x10; /* OHCI */
> >  pci_config_set_class(ohci->pci_dev.config, PCI_CLASS_SERIAL_USB);
> > -ohci->pci_dev.config[0x3d] = 0x01; /* interrupt pin 1 */
> > +/* TODO: RST# value should be 0. */
> > +ohci->pci_dev.config[PCI_INTERRUPT_PIN] = 0x01; /* interrupt pin 1 */
> >  
> >  usb_ohci_init(&ohci->state, &dev->qdev, num_ports,
> >ohci->pci_dev.devfn, ohci->pci_dev.irq[0],
> >OHCI_TYPE_PCI, ohci->pci_dev.name, 0);
> >  
> > +/* TODO: avoid cast below by using dev */
> >  pci_register_bar((struct PCIDevice *)ohci, 0, 256,
> > PCI_BASE_ADDRESS_SPACE_MEMORY, ohci_mapfunc);
> >  return 0;

Re: [Qemu-devel] Re: Spice and legacy VGA drivers

[Izik Eidus]

On Sat, 12 Dec 2009 13:28:18 -0600
Anthony Liguori  wrote:

> Izik Eidus wrote:
> > That specific area in spice will be changed very soon due to new
> > requiments that the offscreens will add.
> > Windows direct draw allow modifying offscreen (or even primary)
> > surfaces using a pointer giving to the user, this mean we can`t know
> > what parts of the surface was changed... (In some modes the primary
> > screen can be changed without we know about this)
> >
> > We already thought about few algorithems we might want to add to
> > spice to better address this "changed without notifications
> > surfaces", But it is still not in a state I can confirm in what
> > direction we will go in the end (We still need to test most of the
> > cases to know what fit us best)
> >   
> 
> Okay, I'm interested in hearing more about this as it develops.  I
> think good support for legacy modes is an important requirement.
> 
> For instance, I very often interact with VMs in text console mode.
> In cloud deployments, it's pretty common to have minimal appliances
> that don't have a full X session.

Sure, this exactly why we still dont sure what kind of algorithem we
will use... , we are searching for something that wont deprived any
usage (Such as text console mode, or "modified by pointer surface")

Thanks.


> 
> Regards,
> 
> Anthony Liguori
> 

Re: [Qemu-devel] Re: Spice project is now open

[Izik Eidus]

On Sat, 12 Dec 2009 13:26:30 -0600
Anthony Liguori  wrote:

> Izik Eidus wrote:
> > On Sat, 12 Dec 2009 11:40:21 -0600
> > Anthony Liguori  wrote:
> >
> >   
> >> FWIW, I don't see any reason why Spice couldn't be made to be
> >> separate from guest emulation.  I think it would just require the
> >> right interfacing in qemu.  I think that's purely an implementation
> >> detail.
> >> 
> >
> > The QXL device is one of the core compoments of spice..., how can
> > you separate it from the guest visible state? (it is pci device)
> >   
> 
> How does live migration work then?  Do you have to query libspice for 
> it's state?  Does it return an opaque blob?  How can it integrate
> with VMState since libspice doesn't have any knowledge of something
> like VMState?

QXL transfer the device states by itself using qemu migration
mechanisem.

The spice server just need that the pci memory (and the qxl ram/rom
state) will be migrate. (From the point of view of guest visible state)

All this guest visible states are transfered by the qxl device using
qemu.

> 
> Regards,
> 
> Anthony Liguori
> 

[Qemu-devel] Re: [PATCH] eepro100: Restructure code (new function tx_command)

[Stefan Weil]

Michael S. Tsirkin schrieb:
> On Mon, Nov 30, 2009 at 06:05:31PM +0100, Stefan Weil wrote:
>> Michael S. Tsirkin schrieb:
>>> On Thu, Nov 19, 2009 at 09:54:46PM +0100, Stefan Weil wrote:
 Handling of transmit commands is rather complex,
 so about 80 lines of code were moved from function
 action_command to the new function tx_command.

 The two new values "tx" and "cb_address" in the
 eepro100 status structure made this possible without
 passing too many parameters.

 In addition, the moved code was cleaned a little bit:
 old comments marked with //~ were removed, C++ style
 comments were replaced by C style comments, C++ like
 variable declarations after code were reordered.

 Simplified mode is still broken. Nor did I fix
 endianess issues. Both problems will be fixed in
 additional patches (which need this one).

 Signed-off-by: Stefan Weil 
 ---
 hw/eepro100.c | 192
 +
 1 files changed, 98 insertions(+), 94 deletions(-)

 diff --git a/hw/eepro100.c b/hw/eepro100.c
 index 4210d8a..7093af8 100644
 --- a/hw/eepro100.c
 +++ b/hw/eepro100.c
 @@ -213,6 +213,10 @@ typedef struct {
 uint32_t ru_offset; /* RU address offset */
 uint32_t statsaddr; /* pointer to eepro100_stats_t */

 + /* Temporary data. */
 + eepro100_tx_t tx;
 + uint32_t cb_address;
 +
>>> That's pretty evil, as it makes routines non-reentrant.
>>> How bad is it to pass 2 additional arguments around?
>>> If not, maybe define struct tx_command and put necessary stuff there,
>>> then pass pointer to that?
>> Yes, I know that it makes routines non-reentrant, or
>> to be more exact: it makes routines non-reentrant
>> for the same device instance. Different device instances
>> are reentrant because each instance maintains its
>> own status.
>>
>> No, it's not evil.
>
> "Temporary data" comment is very evil.
> We not only don't want to document code,
> we document this fact.
>
>> The state machine of the real hardware
>> is not expected to be used in a reentrant way. The same
>> applies to the emulated hardware.
>
> That code does not appear currently structured as a state machine.
>
>> Do you expect reentrant calls of transmit or receive
>> functions for one device instance?
>>
>> Regards,
>> Stefan
>
> Datastructures should make sense. This one does not seem to make sense.
> What's the benefit here? Why is it good to pass less
> parameters to functions?

Hello Michael,

I don't think that "very evil" is a good way to describe code someone
has written.
But maybe there is a misunderstanding caused because you and I are not
native
english speakers.

Antony, perhaps a better comment for the two temporary values would be
"Temporary data used to pass status information between functions, don't
save it."
Feel free to change this comment. Michael, maybe you have a better
suggestion?

Both values will be used in more functions with patches to come,
sometimes also as output parameter. So adding a new status structure for
temporary status values or even passing simple data types
would make the code less comprehensible.

Kind regards,
Stefan

Re: [Qemu-devel] Re: Spice and legacy VGA drivers

[Anthony Liguori]

Izik Eidus wrote:

That specific area in spice will be changed very soon due to new
requiments that the offscreens will add.
Windows direct draw allow modifying offscreen (or even primary)
surfaces using a pointer giving to the user, this mean we can`t know
what parts of the surface was changed... (In some modes the primary
screen can be changed without we know about this)

We already thought about few algorithems we might want to add to spice
to better address this "changed without notifications surfaces", But it
is still not in a state I can confirm in what direction we will go in
the end (We still need to test most of the cases to know what fit us
best)
  


Okay, I'm interested in hearing more about this as it develops.  I think 
good support for legacy modes is an important requirement.


For instance, I very often interact with VMs in text console mode.  In 
cloud deployments, it's pretty common to have minimal appliances that 
don't have a full X session.


Regards,

Anthony Liguori

Re: [Qemu-devel] Re: Spice project is now open

[Anthony Liguori]

Izik Eidus wrote:

On Sat, 12 Dec 2009 11:40:21 -0600
Anthony Liguori  wrote:

  

FWIW, I don't see any reason why Spice couldn't be made to be
separate from guest emulation.  I think it would just require the
right interfacing in qemu.  I think that's purely an implementation
detail.



The QXL device is one of the core compoments of spice..., how can you
separate it from the guest visible state? (it is pci device)
  


How does live migration work then?  Do you have to query libspice for 
it's state?  Does it return an opaque blob?  How can it integrate with 
VMState since libspice doesn't have any knowledge of something like VMState?


Regards,

Anthony Liguori

[Qemu-devel] [FOR 0.12 PATCH] scsi-disk: Inquiry with allocation length of CDB < 36 (v3)

[Artyom Tarasenko]

According to the SCSI-2 specification,
http://ldkelley.com/SCSI2/SCSI2/SCSI2/SCSI2-08.html#8.2.5 ,
"if the allocation length of the command descriptor block (CDB) is too
small to transfer all of the parameters, the additional length shall
not be adjusted to reflect the truncation."
The 36 mandatory bytes of response are written to outbuf, and then
only the length requested in CDB is transferred.
---
Signed-off-by: Artyom Tarasenko 
---
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 2e7a57b..495ba35 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -5,6 +5,12 @@
  * Based on code by Fabrice Bellard
  *
  * Written by Paul Brook
+ * Modifications:
+ *  2009-Dec-12 Artyom Tarasenko : implemented stamdard inquiry for the case
+ * when the allocation length of CDB is smaller
+ * than 36.
+ *  2009-Oct-13 Artyom Tarasenko : implemented the block descriptor in the 
+ * MODE SENSE response.
  *
  * This code is licenced under the LGPL.
  *
@@ -406,11 +412,6 @@ static int scsi_disk_emulate_inquiry(SCSIRequest *req, 
uint8_t *outbuf)
 return -1;
 }
 
-if (req->cmd.xfer < 36) {
-BADF("Error: Inquiry (STANDARD) buffer size %zd "
- "is less than 36 (TODO: only 5 required)\n", req->cmd.xfer);
-}
-
 buflen = req->cmd.xfer;
 if (buflen > SCSI_MAX_INQUIRY_LEN)
 buflen = SCSI_MAX_INQUIRY_LEN;
@@ -436,7 +437,15 @@ static int scsi_disk_emulate_inquiry(SCSIRequest *req, 
uint8_t *outbuf)
Some later commands are also implemented. */
 outbuf[2] = 3;
 outbuf[3] = 2; /* Format 2 */
-outbuf[4] = buflen - 5; /* Additional Length = (Len - 1) - 4 */
+
+if (len > 36) {
+outbuf[4] = len - 5; /* Additional Length = (Len - 1) - 4 */
+} else {
+/* If the allocation length of CDB is too small,
+   the additional length is not adjusted */
+outbuf[4] = 36 - 5;
+}
+
 /* Sync data transfer and TCQ.  */
 outbuf[7] = 0x10 | (req->bus->tcq ? 0x02 : 0);
 return buflen;

[Qemu-devel] [PATCH 3/3] Workaround --whole-archive on Solaris

[Andreas Färber]

From: Andreas Färber 

On OpenSolaris, neither --whole-archive nor -z allextract
appear to work as expected, causing runtime errors. For example:

qemu: could not open disk image [...]

Fix this by extracting archives and linking their object files individually.

libqemu_common.a contains object files from different subdirectories,
leading to name clashes, e.g., nbd.o vs. block/nbd.o.

Archive a renamed copy of the affected files instead, this avoids
duplicating %.c -> %.o compilation rules. Two dashes are used for the copy
to avoid name clashes between, e.g., block-qcow.c and block/qcow.c.

Contain this behavior to Solaris to avoid speed regressions on Linux.

Signed-off-by: Andreas Färber 
Cc: Palle Lyckegaard 
Cc: Ben Taylor 
---
 Makefile  |   14 ++
 rules.mak |4 
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index a662d96..cb57c61 100644
--- a/Makefile
+++ b/Makefile
@@ -102,7 +102,14 @@ block-nested-$(CONFIG_WIN32) += raw-win32.o
 block-nested-$(CONFIG_POSIX) += raw-posix.o
 block-nested-$(CONFIG_CURL) += curl.o
 
+ifneq ($(CONFIG_SOLARIS),y)
 block-obj-y +=  $(addprefix block/, $(block-nested-y))
+else
+block-obj-y +=  $(addprefix block--, $(block-nested-y))
+
+block--%.o: block/%.o
+   $(call quiet-command,cp $< $@,"  CP$(TARGET_DIR)$@")
+endif
 
 net-obj-y = net.o
 net-nested-y = queue.o checksum.o util.o
@@ -116,7 +123,14 @@ net-nested-$(CONFIG_SOLARIS) += tap-solaris.o
 net-nested-$(CONFIG_AIX) += tap-aix.o
 net-nested-$(CONFIG_SLIRP) += slirp.o
 net-nested-$(CONFIG_VDE) += vde.o
+ifneq ($(CONFIG_SOLARIS),y)
 net-obj-y += $(addprefix net/, $(net-nested-y))
+else
+net-obj-y += $(addprefix net--, $(net-nested-y))
+
+net--%.o: net/%.o
+   $(call quiet-command,cp $< $@,"  CP$(TARGET_DIR)$@")
+endif
 
 ##
 # libqemu_common.a: Target independent part of system emulation. The
diff --git a/rules.mak b/rules.mak
index 5d9f684..d0e3a2d 100644
--- a/rules.mak
+++ b/rules.mak
@@ -23,7 +23,11 @@ QEMU_DGFLAGS += -MMD -MP -MT $@
 %.o: %.m
$(call quiet-command,$(CC) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) -c 
-o $@ $<,"  OBJC  $(TARGET_DIR)$@")
 
+ifeq ($(CONFIG_SOLARIS),y)
+LINK = $(call quiet-command,{ rm -rf .tmpobjs;mkdir .tmpobjs$(foreach 
arlib,$(ARLIBS),;(mkdir .tmpobjs/$(notdir $(arlib));cd .tmpobjs/$(notdir 
$(arlib)) && ar x ../../$(arlib)));$(CC) $(QEMU_CFLAGS) $(CFLAGS) $(LDFLAGS) -o 
$@ $(1) $(foreach arlib,$(ARLIBS),$(foreach obj,$(shell $(AR) t 
$(arlib)),.tmpobjs/$(notdir $(arlib))/$(obj))) $(LIBS);},"  LINK  
$(TARGET_DIR)$@")
+else
 LINK = $(call quiet-command,$(CC) $(QEMU_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ 
$(1) $(ARLIBS_BEGIN) $(ARLIBS) $(ARLIBS_END) $(LIBS),"  LINK  $(TARGET_DIR)$@")
+endif
 
 %$(EXESUF): %.o
$(call LINK,$^)
-- 
1.6.5.3

[Qemu-devel] [PATCH 2/3] Silence softfloat warnings on OpenSolaris

[Andreas Färber]

From: Andreas Färber 

Don't define C99 math functions on OpenSolaris (Solaris 11),
which still ships GCC 3.4.3. This fixes redefinition warnings.

Spotted by Palle Lyckegaard.

Signed-off-by: Andreas Färber 
Cc: Palle Lyckegaard 
Cc: Ben Taylor 
---
 fpu/softfloat-native.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fpu/softfloat-native.h b/fpu/softfloat-native.h
index 35670c8..fe737b3 100644
--- a/fpu/softfloat-native.h
+++ b/fpu/softfloat-native.h
@@ -22,7 +22,7 @@
  */
 #if defined(CONFIG_SOLARIS) && \
((CONFIG_SOLARIS_VERSION <= 9 ) || \
-   ((CONFIG_SOLARIS_VERSION >= 10) && (__GNUC__ < 4))) \
+   ((CONFIG_SOLARIS_VERSION == 10) && (__GNUC__ < 4))) \
 || (defined(__OpenBSD__) && (OpenBSD < 200811))
 /*
  * C99 7.12.3 classification macros
-- 
1.6.5.3

[Qemu-devel] Build fixes for OpenSolaris x86 hosts

[Andreas Färber]

Hello,

This series fixes compilation issues on OpenSolaris hosts.

These patches apply equally to x86 and sparc hosts, but sparc requires
addition fixes.

I have therefore taken the freedom to prepare this x86-only series as
intermediate step, including bits extracted from Palle's
work-in-progress sparc patch.

Further, I present a patch for the long-standing --whole-archive issue,
which takes into account the review comments received so far.

Regards,

Andreas

[Qemu-devel] [PATCH 1/3] tap: Compilation fix for Solaris

[Andreas Färber]

From: Andreas Färber 

Avoid an unresolved symbol error for TFR,
which is defined in sysemu.h.

Based on patch by Palle Lyckegaard.

Signed-off-by: Andreas Färber 
Cc: Palle Lyckegaard 
Cc: Ben Taylor 
---
 net/tap-solaris.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/net/tap-solaris.c b/net/tap-solaris.c
index e14fe36..0b42861 100644
--- a/net/tap-solaris.c
+++ b/net/tap-solaris.c
@@ -23,6 +23,7 @@
  */
 
 #include "net/tap.h"
+#include "sysemu.h"
 
 #include 
 #include 
-- 
1.6.5.3

Re: [Qemu-devel] Qemu terminating with SIGABRT

[David S. Ahern]

Thanks for the responses. I had forgotten that SIGABRT==abort() which
means I have to get the core file to get to the root cause. To date the
only information I have is a shell exit status of 134 which from the
bash man pages means it died due to SIGABRT.

David Ahern


On 12/12/2009 01:52 AM, Stefan Weil wrote:
> David S. Ahern schrieb:
>> I realize this is a rather generic question, but what are typical
>> reasons Qemu would be killed by a SIGABRT? I am seeing this on a
>> somewhat regular (though not repeatable on demand) basis. I do not have
>> a core file, though I hope to capture one if I can get it repeat again.
>>
>> Thanks,
>>   
> 
> Look for "abort" in QEMU's code to see the possible reasons.
> 
> In many cases, the reason will be printed to stderr before
> aborting. Did you call QEMU from a console and get some
> output there? Or maybe the stderr output went into a file?
> 
> Run "ulimit -c unlimited" before you run QEMU, then a
> core file will be written automatically on SIGABRT.
> 

Re: [Qemu-devel] [FOR 0.12 PATCH] qdev: Replace device names containing whitespace

[Markus Armbruster]

Blue Swirl  writes:

> On Wed, Dec 9, 2009 at 11:43 AM, Markus Armbruster  wrote:
>> Ian Molton  writes:
>>
>>> Markus Armbruster wrote:
>>>
 The place for verbose device names is DeviceInfo member desc.  The
 name should be short & sweet.
>>>
>>> Agreed, however...
>>>
>>> Why do these (maybe others) get caps in their names? they dont look
>>> right to me, compared to the others with nice names like usb-serial,
>>> piix-ide, or cirrus-vga.
>>>
 -    sysbus_register_dev("Uni-north main", sizeof(UNINState),
 +    sysbus_register_dev("Uni-north-main", sizeof(UNINState),
                          pci_unin_main_init_device);
      pci_qdev_register(&unin_main_pci_host_info);
 -    sysbus_register_dev("DEC 21154", sizeof(UNINState),
 +    sysbus_register_dev("DEC-21154", sizeof(UNINState),
                          pci_dec_21154_init_device);
      pci_qdev_register(&dec_21154_pci_host_info);
 -    sysbus_register_dev("Uni-north AGP", sizeof(UNINState),
 +    sysbus_register_dev("Uni-north-AGP", sizeof(UNINState),
                          pci_unin_agp_init_device);
      pci_qdev_register(&unin_agp_pci_host_info);
 -    sysbus_register_dev("Uni-north internal", sizeof(UNINState),
 +    sysbus_register_dev("Uni-north-internal", sizeof(UNINState),
                          pci_unin_internal_init_device);
      pci_qdev_register(&unin_internal_pci_host_info);
  }
>>
>> I can downcase them.  Blue Swirl, any objections?
>>
>
> I'd prefer the same names that are used by the device tree, like uni-n
> and uni-north-agp. Though the bridge is name poorly, just
> "pci-bridge".
>
> For example:
> http://penguinppc.org/historical/dev-trees-html/imac_400_1.html

If I read that document correctly, we have

old qdev name   device tree name
Uni-north main  uni-n
Uni-north AGP   uni-north-agp
Uni-north internal  pci
DEC 21154   pci-bridge

Do you want me to respin my patch?  If yes, the best way to make me do
exactly what you want is to tell me exactly what you want.  In this
case, tell me the names you want.

Re: [Qemu-devel] Re: Spice project is now open

[Izik Eidus]

On Sat, 12 Dec 2009 11:40:21 -0600
Anthony Liguori  wrote:

> FWIW, I don't see any reason why Spice couldn't be made to be
> separate from guest emulation.  I think it would just require the
> right interfacing in qemu.  I think that's purely an implementation
> detail.

The QXL device is one of the core compoments of spice..., how can you
separate it from the guest visible state? (it is pci device)

> 
> Regards,
> 
> Anthony Liguori
> 
> 

Re: [Qemu-devel] loader.c / disas.h compile issue at 7029a83bd6f71c6fe748220eb481f2afff3ab33f

[Andreas Färber]

Am 12.12.2009 um 16:22 schrieb Andreas Färber:


I'm getting this on OpenSolaris/amd64:

CClibhw64/loader.o
In file included from /export/home/andreas/QEMU/qemu/loader.c:25:
/export/home/andreas/QEMU/qemu/disas.h:25: error: syntax error  
before "target_phys_addr_t"

[...]


After bisecting this back to Blue's original commit moving loader.c  
around, back on HEAD, after a couple of make distclean, make defconfig  
and what not, the issue has magically disappeared...


Andreas

Re: [Qemu-devel] Re: Spice and legacy VGA drivers

[Izik Eidus]

On Sat, 12 Dec 2009 11:35:24 -0600
Anthony Liguori  wrote:

> Izik Eidus wrote:
> > What you mean? how can it compress it? or what method?
> >
> > When there is no driver installed, we use compression that based on
> > LZ...
> >   
> 
> Okay, that's what I was asking.  I'm curious because during guest 
> installation, I assume that even if you're using QXL, you are still 
> stuck in VESA mode.


Correct.

> 
> I'm curious if LZ on it's own is significantly different than some of 
> the vnc encodings.  Both ZRLE and Tight have some pre-encoding 
> techniques that introduce a palette and in the case of Tight, also 
> support efficient gradient encoding.  The idea is that you end up
> with much more compressable data this way.
> 
> It's the sort of thing I think would be interesting to measure.  I
> think being able to use VNC style encodings could also be interesting
> for Spice in order to improve this "legacy mode" use-case.


That specific area in spice will be changed very soon due to new
requiments that the offscreens will add.
Windows direct draw allow modifying offscreen (or even primary)
surfaces using a pointer giving to the user, this mean we can`t know
what parts of the surface was changed... (In some modes the primary
screen can be changed without we know about this)

We already thought about few algorithems we might want to add to spice
to better address this "changed without notifications surfaces", But it
is still not in a state I can confirm in what direction we will go in
the end (We still need to test most of the cases to know what fit us
best)

Thanks.

> 
> Regards,
> 
> Anthony Liguori
> 
> 

Re: [Qemu-devel] Re: Spice project is now open

[Anthony Liguori]

Andrea Arcangeli wrote:

On Sat, Dec 12, 2009 at 09:03:26AM -0600, Anthony Liguori wrote:
  
Spice has been closed source for a long time.  For those that have been 
involved with Spice development, I'm sure you understand very well why 
it's so wonderful, but for the rest of us, Spice didn't exist until 
yesterday so it's going to take a little bit for us to all understand 
what actually about it makes it special.



I personally wasn't involved but I've seen it running with video
fullscreen and I don't know the comparison with rdesktop as I never
used it but I know the comparsion with vnc too well ;). It has to get
even faster and avoid decoding the compressed stream on the server.
  


I can run video full screen with VNC on my local lan.  In fact, that's 
the benchmark I use to do perf measurements with gtk-vnc.


I'm not saying that VNC handles video as well as Spice, I can pretty 
much guarantee that it doesn't :-)


If spice really needs to be able to evolve on it's own, what would it 
take for spice to be implementable from an external process?  What level 
of interaction does it need with qemu?  As long as we can prevent any 
device state from escaping from qemu, I'd be very interested in a model 
where spice lived entirely in a separate address space.



Funny thing is I think it's already in a separate process! ;) (you
know it wasn't open source until recently so...), but now that you
mention it, I think it should be changed to not be in a separate
process...

Linux is monolithic, KVM is the monolithic way (xen is the microkernel
slow way), I think you don't need to worry about sharing spice libs in
the same address space. We want to make it as fast as feasible on the
server side. A separate address space forces tlb flushes, mm switches
and screw performance and spice is all about performance. We've
already a pipe to connect server and client, we should try to avoid
having two pipes as much as possible and have a single exit to qemu
spice ring and send directly to spice client with virtio instead of
sending to separate process that eventually sends to remote spice
client.

Like 99% of microkernel designs they're very wasteful, what good it
does that the network is still up and running when you lost access to
your harddisk because the sata driver crashed? Or to have access to
sata disk but network driver crashed and you can't reach the system
anymore. Yeah there are corner cases where they can be useful but
those won't use linux kernel or monolitich kvm design in the first
place and they will run dogslow and they'll demonstrate math
correctness all software running on the bare metal with math which
means you can't patch the software anymore until math people
recomputes. We're not in that environment (luckily).

In this case keeping it separate means the desktop remains reachable
through network but virtual graphics card, virtual mouse and stuff
crashed, if somebody uses qlx that means the VM has to be rebooted
anyway.


If Spice can crash a guest, that indicates to me that Spice is 
maintaining guest visible state.  That is difficult architecturally 
because if we want to do something like introduce a secure sandbox for 
running guest visible emulation, libspice would have to be part of that 
sandbox which would seem to be difficult.


The VNC server cannot crash a guest by comparison.

FWIW, I don't see any reason why Spice couldn't be made to be separate 
from guest emulation.  I think it would just require the right 
interfacing in qemu.  I think that's purely an implementation detail.


Regards,

Anthony Liguori

[Qemu-devel] Re: Spice and legacy VGA drivers

[Anthony Liguori]

Izik Eidus wrote:

What you mean? how can it compress it? or what method?

When there is no driver installed, we use compression that based on
LZ...
  


Okay, that's what I was asking.  I'm curious because during guest 
installation, I assume that even if you're using QXL, you are still 
stuck in VESA mode.


I'm curious if LZ on it's own is significantly different than some of 
the vnc encodings.  Both ZRLE and Tight have some pre-encoding 
techniques that introduce a palette and in the case of Tight, also 
support efficient gradient encoding.  The idea is that you end up with 
much more compressable data this way.


It's the sort of thing I think would be interesting to measure.  I think 
being able to use VNC style encodings could also be interesting for 
Spice in order to improve this "legacy mode" use-case.


Regards,

Anthony Liguori

[Qemu-devel] Re: Spice and legacy VGA drivers

[Izik Eidus]

On Sat, 12 Dec 2009 11:19:19 -0600
Anthony Liguori  wrote:

> Izik Eidus wrote:
> > On Sat, 12 Dec 2009 09:25:00 -0600
> > Anthony Liguori  wrote:
> >
> >   
> >> How does this work?
> >>
> >> Does Spice only work with QXL or can it also work with Cirrus and 
> >> std-vga?  Does it degrade into basically a framebuffer based
> >> protocol? How does it encode the bitmap data in this mode?
> >> 
> >
> > It work with std-vga
> > It send bitmaps using the dirty bit from kvm/qemu
> >   
> 
> How does it compress the bitmaps?

What you mean? how can it compress it? or what method?

When there is no driver installed, we use compression that based on
LZ...
How does it compress it?, it just send it to the spice server as
"Draw bitmap" command and the spice server send it to the client.

> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] Re: Spice project is now open

[Anthony Liguori]

Avi Kivity wrote:

On 12/12/2009 05:11 PM, Anthony Liguori wrote:


I have no idea how SPICE performs now, but there's definitely 
nothing in a modern X Windows desktop that it cannot deal with.  The 
only negative point it might have compared to Windows is IMO the 
rendering of text.


I think the question I was raising was not whether Spice could handle 
X, but that given the things you can do with X, is all of Spice 
really needed.  IOW, would we get 99% of the way there with Xv 
accelerated overlays and Xrender based compositing for VNC?


Suppose only 1% of spice is needed to support X. Given that we wish to 
support Windows well, does it matter?


I understand X better than I understand Windows so it's easier for me to 
understand things as they relate to X.


My original question was how much better is Spice support for Windows 
than it is for X.  If Spice is really designed for Windows and does 
really well for it, that's great.  I'm just trying to understand what 
it's good for and what it's not good for.


Regards,

Anthony Liguori

[Qemu-devel] Re: Spice and legacy VGA drivers

[Anthony Liguori]

Izik Eidus wrote:

On Sat, 12 Dec 2009 09:25:00 -0600
Anthony Liguori  wrote:

  

How does this work?

Does Spice only work with QXL or can it also work with Cirrus and 
std-vga?  Does it degrade into basically a framebuffer based

protocol? How does it encode the bitmap data in this mode?



It work with std-vga
It send bitmaps using the dirty bit from kvm/qemu
  


How does it compress the bitmaps?

Regards,

Anthony Liguori

Re: [Qemu-devel] X support for QXL and SPICE

[Soeren Sandmann]

Anthony Liguori  writes:

> Soeren Sandmann wrote:
> > Hi,
> >
> > Here is an overview of what the current QXL driver does and does not
> > do.  The parts of X rendering that are currently being used by cairo
> > and Qt are:
> >
> > - Most of XRender - Image compositing
> > - Glyphs
> >
> 
> Does anything use Xrender for drawing glyphs these days?

Yes, essentially everything on a desktop uses Xrender for glyphs.

The way glyphs work in XRender is basically like this:

- The client stores a bunch of glyphs in the X server. The
  data structure is called a GlyphSet

- Whenever it wants to draw text, it sends a string of indices
  into this a GlyphSet along with coordinates.

Adding support for this to SPICE amounts to offscreen pixmaps along
with a compact way of representing text.

> Certainly, with a compositing window manager, nothing is getting
> rendered by X...

With a compositing manager, all windows are redirected to offscreen
pixmaps, and the compositing manager will then use either OpenGL or
XRender to composite all those pixmaps together whenever one of them
changes.

Rendering to these offscreen pixmaps is still done by X in the same
way I described before:

- Render to temporary offscreen pixmap (T)

- Copy pixmap T to window W, where W is redirected to another
  pixmap, which is not T.

So X is still rendering, even when there is a compositing manager.

> > The X driver for the QXL device is not yet very sophisticated. What it
> > does is basically this:
> >
> > - It keeps a separate memory framebuffer uptodate using
> >   software
> >
> > - Solid fills and CopyArea requests are turned into SPICE
> >   commands.
> >
> > - The cursor is drawn using cursor commands
> >
> > - For other things, bitmaps are sent across the wire
> > - It uses the hashing feature of SPICE to only send
> >   hashcodes for those bitmaps if it can get away with
> >   it.
> >
> > Even this simple support provides a better user experience than VNC
> > because scrolling is accelerated and doesn't result in a huge bitmap
> > getting sent across the wire.
> 
> Scrolling is accelerated in VNC.  In the Cirrus adapter, both X and
> Windows use a video-to-video bitblt, we use this to create a VNC
> CopyRect which makes scrolling and Window movement smooth.

The solid fill acceleration also makes a difference because windows
usually have a solid background, so when they are expose (for example
by someone dragging one window over another), their background gets
filled by the X server.

The bitmap hashing also made a fairly noticable difference for
animations where the same few images get sent again and
again. Eventually, many of these cases are better handled with
offscreen pixmaps, but there likely are applications drawing the image
over and over withing putting it into a pixmap.

> > However, as things stand right now, there is not much point in adding
> > this support, because X applications essentially always work like
> > this:
> >
> > - render to offscreen pixmap
> > - copy pixmap to screen
> >
> > There is not yet support for offscreen pixmaps in SPICE, so at the
> > moment, solid fill and CopyArea are the two main things that actually
> > make a difference.
> >
> 
> Okay, that's in line with what my expectations were.  So what's the
> future of Spice for X?  Anything clever or is Windows the only target
> right now?

I'd say that offscreen pixmaps is the biggest missing feature at the
moment as far as performance improvements go.

There are some other things that would be interesting to do:

- Really good RandR support

  The QXL driver already has rudimentary RandR support - ie., basic
  mode switching on the fly, which is reflected on the client side.

  But newer versions of RandR are much more capable: a graphics
  adapter can report when screens are plugged in and what their
  capabilities are and so on. It would make sense to capture this
  information on the client side and expose it through the QXL device.


- Video support

  The QXL device tries to detect when a piece of the screen is really
  a video, but we can do better by implementing the Xv extension (or
  whatever ends up being the future of video playback on Linux). It
  may also make sense to add support for "decoding" Theora or other
  video codecs to QXL, and then tunnel compressed video to the client.


Soren

Re: [Qemu-devel] Re: Spice project is now open

[Avi Kivity]

On 12/12/2009 05:11 PM, Anthony Liguori wrote:


I have no idea how SPICE performs now, but there's definitely nothing 
in a modern X Windows desktop that it cannot deal with.  The only 
negative point it might have compared to Windows is IMO the rendering 
of text.


I think the question I was raising was not whether Spice could handle 
X, but that given the things you can do with X, is all of Spice really 
needed.  IOW, would we get 99% of the way there with Xv accelerated 
overlays and Xrender based compositing for VNC?


Suppose only 1% of spice is needed to support X. Given that we wish to 
support Windows well, does it matter?


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

Re: [Qemu-devel] Re: Spice project is now open

[Andrea Arcangeli]

On Sat, Dec 12, 2009 at 09:03:26AM -0600, Anthony Liguori wrote:
> Spice has been closed source for a long time.  For those that have been 
> involved with Spice development, I'm sure you understand very well why 
> it's so wonderful, but for the rest of us, Spice didn't exist until 
> yesterday so it's going to take a little bit for us to all understand 
> what actually about it makes it special.

I personally wasn't involved but I've seen it running with video
fullscreen and I don't know the comparison with rdesktop as I never
used it but I know the comparsion with vnc too well ;). It has to get
even faster and avoid decoding the compressed stream on the server.

> project?  You complain about VNC's extensibility, but so far, we have no 
> idea whether it's even possible to extend Spice.  Given the interactions 
> so far, I'm a little concerned about how well we can influence the protocol.

Well this is open source, so you know, anybody can change it, fork it,
takeover it, simply. And it's in the interest of everyone to help in
converging on the best SPICE protocol.

> If spice really needs to be able to evolve on it's own, what would it 
> take for spice to be implementable from an external process?  What level 
> of interaction does it need with qemu?  As long as we can prevent any 
> device state from escaping from qemu, I'd be very interested in a model 
> where spice lived entirely in a separate address space.

Funny thing is I think it's already in a separate process! ;) (you
know it wasn't open source until recently so...), but now that you
mention it, I think it should be changed to not be in a separate
process...

Linux is monolithic, KVM is the monolithic way (xen is the microkernel
slow way), I think you don't need to worry about sharing spice libs in
the same address space. We want to make it as fast as feasible on the
server side. A separate address space forces tlb flushes, mm switches
and screw performance and spice is all about performance. We've
already a pipe to connect server and client, we should try to avoid
having two pipes as much as possible and have a single exit to qemu
spice ring and send directly to spice client with virtio instead of
sending to separate process that eventually sends to remote spice
client.

Like 99% of microkernel designs they're very wasteful, what good it
does that the network is still up and running when you lost access to
your harddisk because the sata driver crashed? Or to have access to
sata disk but network driver crashed and you can't reach the system
anymore. Yeah there are corner cases where they can be useful but
those won't use linux kernel or monolitich kvm design in the first
place and they will run dogslow and they'll demonstrate math
correctness all software running on the bare metal with math which
means you can't patch the software anymore until math people
recomputes. We're not in that environment (luckily).

In this case keeping it separate means the desktop remains reachable
through network but virtual graphics card, virtual mouse and stuff
crashed, if somebody uses qlx that means the VM has to be rebooted
anyway. Ok, it won't risk to create disk corruption but in practice
the slowdown it creates it's not worth paying compared to the minor
risk that you really end up corrupting a bit in qcow2 cluster bitmap
in a way that doesn't crash the VM but silently corrupts data. If
something if I had to pay slowdown for higher reliability of disk I/O
it would be much better to move qcow2 and the I/O stack to its own
address space so it's protected from all the rest too... plus qcow2 is
a lot less performance critical than network graphics! Plus there's
valgrind and all that userland stuff to trap memory corruption, orders
of magnitude easier to debug than kernel random corruption (that over
time we fix too and so we keep run at max speed).

Having the thing modular at runtime not only at ./configure time
(loadable dynamically into qemu address space) OTOH is great idea, so
you can disable the module and verify the crashes go away without
having to rebuild.

Re: [Qemu-devel] X support for QXL and SPICE

[Izik Eidus]

On Sat, 12 Dec 2009 16:43:43 +0100
Alexander Graf  wrote:
> 
> 
> I'm always having a hard time understanding why VNC is slow. I've
> seriously always been wondering. And I'm still puzzled as to why RDP
> is so much superior performance-wise. After all, it basically only
> implements framebuffer updates too.

Not really, RDP does have commands in its protocol.
The latest RDP 7 is even more advance in that but lack the abilaty to
enjoy it when not using "same codecs / dx" support.

> 
> So now you bring in SPICE to that equation. I don't know _why_ SPICE
> is faster. I know that it is and I hear all those awesome great
> features. But I still don't have a feeling on which part of it really
> is the performance booster. As with the example above, I would never
> have guessed that doing synchronous updates is the performance
> killer. I'm still trying to figure out what is going wrong in VNC :-).
> 
> So don't take this as an offense. It's about learning from you guys.
> You're the ones that measured what makes things fast - and we want to
> know! Even if we're not building code on it, but using SPICE, it'd
> still be very valuable to know why exactly it is performing better.
> And best case also by how much each single feature saves us.


From my point of view, Effective commands transfer, Smart Depth tree
usage, Effective Cache, (the soon to be merged offscreens), Effective
Compression, and Effective Video streaming, this what need to have for
making things fast...

But It is not that easy as it sound, beacuse spice is really not just
about sending simple "draw_line command".

it is system that was desgiened to send commands from day one, and to
be used by kvm to reduce host cpu usage, The QXL driver, the QXL
Device, the Spice server, The spice Client, all of this peice of
software togather bring spice into what it is.

(As you saw above, you said it yourself, in the middle of making such
 system there are alot of performence questions, some times the answers
 are not absolute, And I sure VNC beat spice in some cases, But this is
 the whole point, allowing the user to choce what ever protocol he
 want)

Thanks.

> 
> 
> Alex
> 
> PS: Let me explain my background on those questions:
> 
> I'm stuck with VNC for SUSE Studio for now. While I can't make
> fundamental changes to the protocol, I can easily modify the guest
> and I can also easily modify the VNC viewer to add a few new
> commands. If I can get a throughput reduction of 50% by using 2 out
> of 10 features SPICE has as VNC protocol extensions, I'd gladly
> implement them. That'd just make user experience on our side a lot
> better. If that means using QXL inside the guest, so be it :-).
> 

[Qemu-devel] Re: [PATCH 00/17] pci: switch a ton of drivers to symbolic names

[Juan Quintela]

"Michael S. Tsirkin"  wrote:
> The recent e1000 bug made the important of using
> symbolic macros for pci config access clear for me.
> So I started going over drivers and converting
> to symbolic constants instead of hard-coded ones.
> I did a large part until I run out of steam.
> Maybe some brave soul will take up converting
> the rest of them, or maybe I will: note that
> when converting bridges one should be careful
> to use bridge macros where appropriate.

Nice patchset.  And makes things way clear.

Acked-by: Juan Quintela

Re: [Qemu-devel] X support for QXL and SPICE

[Alexander Graf]

On 12.12.2009, at 16:29, Izik Eidus wrote:

> On Sat, 12 Dec 2009 09:13:51 -0600
> Anthony Liguori  wrote:
> 
>> Izik Eidus wrote:
>>> On Fri, 11 Dec 2009 21:31:34 -0600
>>> Anthony Liguori  wrote:
>>> 
 Okay, that's in line with what my expectations were.  So what's
 the future of Spice for X?  Anything clever or is Windows the only
 target right now?
 
>>> 
>>> Offscreen pixmaps, Xrender, opengl 3d commands, Video extention.
>>> 
>>> I dont understand what you want here?
>>> 
>> 
>> To understand what makes Spice special.
> 
> 
> Spice is interesting beacuse unlike the great VNC protocol it already
> have what it take to make VDI possible to the user.
> 
> If you think all the above features are pointless and if you think that
> Windows graphic systems (90% of the world wide desktops users) is not
> important, I really dont know what to tell you.
> 
> It is easy to say about everything "We can implment it in VNC..." yes.
> and I can write my own new operation system and tell everyone "Haa,
> right now i dont have it, but it is easy to implement"...
> 
> It is naive to think that software is all about features..., In this
> case Linux / Freebsd are the same thing..., ohh wait they are diffrent
> no?.
> 
> Wait, I think Google, Yahoo and Bing, does`nt they all have the same
> features, How come ppl still prefer to use Google in that case?
> 
> VNC is much older than spice, but still why it didnt get all this SPICE
> protocol goodies? why? (I mean it is so easy to add this into VNC...)

I think you're getting the wrong message. Let me tell you something about my 
work on virtio-fb.

I did 2 versions. The first one was completely ring and message based. I used 
the virtio ring topology to send framebuffer updates along to the hypervisor, 
basically resembling the linux fb callback interface.

While that worked, it was _horribly_ slow. I didn't know why. Until I found out 
that all of this transferring happens synchronously! So on every linuxfb 
function call we basically got a hypervisor exit, resulting in a lot of 
overhead. Not to speak of all the vmalloc magic I had to do.

If I had known before that this is a bottleneck, I would have designed the 
protocol differently. In fact, I did for v2 - and ended up having only a single 
real command in my awesome protocol: "mark dirty". So I ended up basically 
reimplementing the same framebuffer based interface we use in qemu already. Oh 
great.

If anybody would have been around to tell me that what I'm doing is a bad idea 
because he went through it before, or if I had simply known before, I wouldn't 
have made those mistakes. It's all about knowledge.


Another example.


I'm always having a hard time understanding why VNC is slow. I've seriously 
always been wondering. And I'm still puzzled as to why RDP is so much superior 
performance-wise. After all, it basically only implements framebuffer updates 
too.

So now you bring in SPICE to that equation. I don't know _why_ SPICE is faster. 
I know that it is and I hear all those awesome great features. But I still 
don't have a feeling on which part of it really is the performance booster. As 
with the example above, I would never have guessed that doing synchronous 
updates is the performance killer. I'm still trying to figure out what is going 
wrong in VNC :-).

So don't take this as an offense. It's about learning from you guys. You're the 
ones that measured what makes things fast - and we want to know! Even if we're 
not building code on it, but using SPICE, it'd still be very valuable to know 
why exactly it is performing better. And best case also by how much each single 
feature saves us.


Alex

PS: Let me explain my background on those questions:

I'm stuck with VNC for SUSE Studio for now. While I can't make fundamental 
changes to the protocol, I can easily modify the guest and I can also easily 
modify the VNC viewer to add a few new commands. If I can get a throughput 
reduction of 50% by using 2 out of 10 features SPICE has as VNC protocol 
extensions, I'd gladly implement them. That'd just make user experience on our 
side a lot better. If that means using QXL inside the guest, so be it :-).

[Qemu-devel] Re: Spice and legacy VGA drivers

[Izik Eidus]

On Sat, 12 Dec 2009 09:25:00 -0600
Anthony Liguori  wrote:

> How does this work?
> 
> Does Spice only work with QXL or can it also work with Cirrus and 
> std-vga?  Does it degrade into basically a framebuffer based
> protocol? How does it encode the bitmap data in this mode?

It work with std-vga
It send bitmaps using the dirty bit from kvm/qemu

> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] Re: approaches to 3D virtualisation

[Carl-Daniel Hailfinger]

On 12.12.2009 13:08, Juan Quintela wrote:
> - vmware_vga.  Lets say that the way that it embeds an vga is
>   _interesting_ to say the less.  Also the vga can be compiled out, but
>   not bios/os on earth will boot without its support.
>   

The coreboot developers can boot Linux on all VIA chipsets without VGA
support (no VGA ROM, no VGA interface) and X works just fine. Note that
this works on pretty much every 2.6.x Linux kernel and X with the
Unichrome driver.

Regards,
Carl-Daniel

-- 
Developer quote of the month: 
"We are juggling too many chainsaws and flaming arrows and tigers."

Re: [Qemu-devel] X support for QXL and SPICE

[Izik Eidus]

On Sat, 12 Dec 2009 09:13:51 -0600
Anthony Liguori  wrote:

> Izik Eidus wrote:
> > On Fri, 11 Dec 2009 21:31:34 -0600
> > Anthony Liguori  wrote:
> >   
> >> Okay, that's in line with what my expectations were.  So what's
> >> the future of Spice for X?  Anything clever or is Windows the only
> >> target right now?
> >> 
> >
> > Offscreen pixmaps, Xrender, opengl 3d commands, Video extention.
> >
> > I dont understand what you want here?
> >   
> 
> To understand what makes Spice special.


Spice is interesting beacuse unlike the great VNC protocol it already
have what it take to make VDI possible to the user.

If you think all the above features are pointless and if you think that
Windows graphic systems (90% of the world wide desktops users) is not
important, I really dont know what to tell you.

It is easy to say about everything "We can implment it in VNC..." yes.
and I can write my own new operation system and tell everyone "Haa,
right now i dont have it, but it is easy to implement"...

It is naive to think that software is all about features..., In this
case Linux / Freebsd are the same thing..., ohh wait they are diffrent
no?.

Wait, I think Google, Yahoo and Bing, does`nt they all have the same
features, How come ppl still prefer to use Google in that case?

VNC is much older than spice, but still why it didnt get all this SPICE
protocol goodies? why? (I mean it is so easy to add this into VNC...)

> 
> > Spice is not responsible for how X work the fact that X doesnt have
> > many things that windows have - doesnt mean it is bad spice DOES
> > have them...
> >   
> 
> Don't confuse trying to understand Spice with attempts to poke holes
> or criticize Spice.  There is very little information about what
> makes Spice interesting.

There is a complete protocol paper that expline the whole protocol,
There is me answering you to any question that you ask,
There is the whole source open, what more do you need?

> 
> Regards,
> 
> Anthony Liguori
> 

[Qemu-devel] Spice and legacy VGA drivers

[Anthony Liguori]

How does this work?

Does Spice only work with QXL or can it also work with Cirrus and 
std-vga?  Does it degrade into basically a framebuffer based protocol?  
How does it encode the bitmap data in this mode?


Regards,

Anthony Liguori

Re: [Qemu-devel] Re: approaches to 3D virtualisation

[Anthony Liguori]

Juan Quintela wrote:

Dave Airlie  wrote:
  

Current existing solutions in the area:
a) VMware virtual graphics adapter - based on DX9, has an open
KMS/Gallium3D driver stack recently released by vmware, has certified
Windows drivers and has a documented vGPU interface (it could be
documented a lot better)


http://vmware-svga.svn.sourceforge.net/viewvc/vmware-svga/trunk/doc/gpu-wiov.pdf?revision=1

is a good whitepaper on the different 3D virtualisation approaches and why
vmware picked what they did also.

Dave.



I have zero clue of 3D, but for the qemu part, vmware_vga is the "nicer"
driver.
  


I like the design of the vmware_vga driver but it has one critical 
flaw.  The Windows drivers has a EULA that prohibits their use outside 
of VMware.


Without reasonably licensed Windows drivers, I don't think it's viable.

I'm hoping QXL can fill this niche.

Regards,

Anthony Liguori

[Qemu-devel] loader.c / disas.h compile issue at 7029a83bd6f71c6fe748220eb481f2afff3ab33f

[Andreas Färber]

Hello,

I'm getting this on OpenSolaris/amd64:

 CClibhw64/loader.o
In file included from /export/home/andreas/QEMU/qemu/loader.c:25:
/export/home/andreas/QEMU/qemu/disas.h:25: error: syntax error before 
"target_phys_addr_t"

[...]

Anyone have an idea what's going wrong here? It didn't surface on OSX or 
Linux, and it must be recent.


Thanks,

Andreas

Re: [Qemu-devel] Re: [PATCH] eepro100: Restructure code (new function tx_command)

[Anthony Liguori]

Stefan Weil wrote:

Stefan Weil schrieb:
  

Handling of transmit commands is rather complex,
so about 80 lines of code were moved from function
action_command to the new function tx_command.

The two new values "tx" and "cb_address" in the
eepro100 status structure made this possible without
passing too many parameters.

In addition, the moved code was cleaned a little bit:
old comments marked with //~ were removed, C++ style
comments were replaced by C style comments, C++ like
variable declarations after code were reordered.

Simplified mode is still broken. Nor did I fix
endianess issues. Both problems will be fixed in
additional patches (which need this one).

Signed-off-by: Stefan Weil 
---
hw/eepro100.c | 192
+
1 files changed, 98 insertions(+), 94 deletions(-)



This patch is still missing in QEMU master.
Because of other patches (which were sent later!), a rebase is needed again
(it was rebased 3 times now). Only the line with qemu_send_packet changed.

Please apply the rebased patch if there are no really important
reasons against it (there are none), hopefully without waiting several
weeks again.
It is needed for very important bug fixes (multicast, simple transmit mode).
  


Michael had given the patch some feedback that I think is valuable.  I 
haven't seen a response to his feedback nor have I seen a resubmit 
incorporating the feedback.


Storing intermediate state of a function as global state (instead of on 
the stack) is odd.  Even if there's a great justification (I don't think 
there is), such a thing is sufficiently unusual that it deserves a 
better comment.


BTW, part of the trouble your having is you're sending one patch that 
does too many things.  If you submitted a series that contained code 
cleanups, and then code motion, the first patches would have been no 
brainers to commit while the code motion would have been treated 
separately making rebasing less painful.


Regards,

Anthony Liguori

Re: [Qemu-devel] X support for QXL and SPICE

[Anthony Liguori]

Izik Eidus wrote:

On Fri, 11 Dec 2009 21:31:34 -0600
Anthony Liguori  wrote:
  
Okay, that's in line with what my expectations were.  So what's the 
future of Spice for X?  Anything clever or is Windows the only target 
right now?



Offscreen pixmaps, Xrender, opengl 3d commands, Video extention.

I dont understand what you want here?
  


To understand what makes Spice special.


Spice is not responsible for how X work the fact that X doesnt have
many things that windows have - doesnt mean it is bad spice DOES have
them...
  


Don't confuse trying to understand Spice with attempts to poke holes or 
criticize Spice.  There is very little information about what makes 
Spice interesting.


Regards,

Anthony Liguori

Re: [Qemu-devel] Re: Spice project is now open

[Anthony Liguori]

Paolo Bonzini wrote:

On 12/12/2009 04:34 AM, Anthony Liguori wrote:

Firefox uses that extensively, for example to render tiled backgrounds
(though probably GTK user interface elements can do so less
successfully).


Yes, but this is just a single application.  The point is that these
things are not as widely standardized on X as they are on Windows.


They are standardized (Xrender) and there are high-level de facto 
standard APIs (Cairo or the Qt equivalent).


Cairo is pretty new and not widely used by applications yet.  But even 
Xrender is very limited compared to all of the things that GDI 
supports.  If it's just a matter of offloading Xrender, you could 
implement compositing in VNC fairly easily.




Regarding compositing, this is done via OpenGL so even though it is 
true that nothing goes through X calls, it is also true that 
everything does go though a high-level API which can be sent on the 
wire (cfr. AIGLX).


Right, but 3D is a different topic.  Spice doesn't address this today.

Actually, compositing might really be where a protocol like SPICE 
shines, since it does not generate nearly as many expose events, and 
since you do not have to resend occluded contents on the wire any time 
someone raises a window.


It's a trade off.  If you're sending each windows contents verses 
sending the visible screen, you're incurring an upfront cost assuming 
interaction will be improved.  This is something that I'd really like to 
see perf data on because.


I have no idea how SPICE performs now, but there's definitely nothing 
in a modern X Windows desktop that it cannot deal with.  The only 
negative point it might have compared to Windows is IMO the rendering 
of text.


I think the question I was raising was not whether Spice could handle X, 
but that given the things you can do with X, is all of Spice really 
needed.  IOW, would we get 99% of the way there with Xv accelerated 
overlays and Xrender based compositing for VNC?


BTW, can someone split out these VDI patches and get them on the list?  
Maybe at least an ETA of when that will happen.  I think it would make 
this whole discussion a lot more fruitful if we had more context..


Regards,

Anthony Liguori

Re: [Qemu-devel] Re: Spice project is now open

[Anthony Liguori]

Andrea Arcangeli wrote:

About the discussion of improving VNC, this code has to change and
move so fast (you can see already requests from Alexander to split the
features to allow remote usb from remote qlx, it's expectable code to
change for the better to support more obscure features than 99% of
userbase cares about as it goes open), it's huge, it's unreasonable to
pretend to make official modifications to VNC protocol every time we
do a small change to the protocol to please Alexander or anybody other
reasonable wishes of the day, even vnc could eventually reach
equivalent speedup (which is debatable too). Going the vnc route and
official feature requests to extend the protocol is a dead hand IMHO,
all you can argue is spice or something else separate from vnc.
  


What I really want is a high quality paper comparing Spice to other 
options (like VNC) with performance graphs demonstrating why it's so 
much better.  A paper isn't really necessary but what I'd like to see is 
that level of detailed comparison.


Spice has been closed source for a long time.  For those that have been 
involved with Spice development, I'm sure you understand very well why 
it's so wonderful, but for the rest of us, Spice didn't exist until 
yesterday so it's going to take a little bit for us to all understand 
what actually about it makes it special.


And with respect to the spice protocol, what's the model around making 
changes to the specification?  Is it just submit a patch to the spice 
project?  You complain about VNC's extensibility, but so far, we have no 
idea whether it's even possible to extend Spice.  Given the interactions 
so far, I'm a little concerned about how well we can influence the protocol.


If spice really needs to be able to evolve on it's own, what would it 
take for spice to be implementable from an external process?  What level 
of interaction does it need with qemu?  As long as we can prevent any 
device state from escaping from qemu, I'd be very interested in a model 
where spice lived entirely in a separate address space.


Regards,

Anthony Liguori

Re: [Qemu-devel] Re: Spice project is now open

[Andrea Arcangeli]

Hi everyone,

On Fri, Dec 11, 2009 at 09:44:02PM -0600, Anthony Liguori wrote:
> A typical scenario is someone develops a closed source plugin, but does 
> not distribute it with the original piece of software thinking that they 
> aren't creating a derived work because there's no combination.

Creation of derived work of a GPL'd program isn't defined like
this. You can ask confirmation to IBM lawyers. Even ignoring the
explicit allow Linus gave (initially for already existing x86 drivers
coming from other proprietary OS that had more drivers than linux at
the time), it was meant for software written for other OS and ported
over to be dynamic linked into the kernel, so clearly not creating a
derivative work as the binary existed already for other OS.

This has been abused, and later EXPORT_MODULE_GPL was added
too... Even if anybody can remove the _GPL tag with any GPL'd patch,
without necessarily creating a derivative work or breaking the GPL by
removing that _GPL suffix. However if your module only works after you
remove a couple of _GPL suffixes that rings an huge bell that you are
breaking the GPL and everyone will look if that really is a derivative
work or not.

> GCC is not the best example since it's support for plugins are 
> relatively new.  It's bad for users.  They start using a plugin for one 
> version and they really like it, they want to update to a new version of 
> the base program and now their plugin no longer works.  The plugin has 
> gone unmaintained and now they have to choose between the plugin and 
> updating the base program.

If plugin is dead and unmaintained I guess it wasn't so useful after
all... besides it's all GPL so he can maintain it himself.

Libs APIs also are upgraded and they stop building and you got to
upgrade the program too in order to use the new lib. It doesn't matter
if this is called a plugin, static or dynamic lib, in raw terms it's
just a function that changed its arguments, how the function .text is
loaded into the address space is technicality.

> I don't think the kernel is an example of it working smoothly.  It's a 
> constant source of frustration for users and people are constantly doing 
> ugly things wrt licensing.

There are lots of less stable GPL'd module drivers too, it's not just
nvidia, so what? Besides the tainting flag that avoids some of the
time waste of the few abuses of the interface, CONFIG_MODULE=y is
clearly a net win and removing pluggable modules would be insanity. In
life few things are black and white and 100% improvements, but when
the benefit greatly exceeds the downsides, it's fairly silly to use
the few downsides as an argument to reject it. It'd be like refusing
to catch a plane because it could crash in the middle of the ocean.

In a previous email you said:

--
Historically, we have not supported multiple display mechanisms
favoring making one mechanism as good as it can be.

Supporting both Spice and VNC would go against this policy.  It's not
--

There's no such thing as a policy in open source, this is not a
committee, code rulez in GPL'd world, everything else is irrelevant.


About the discussion of improving VNC, this code has to change and
move so fast (you can see already requests from Alexander to split the
features to allow remote usb from remote qlx, it's expectable code to
change for the better to support more obscure features than 99% of
userbase cares about as it goes open), it's huge, it's unreasonable to
pretend to make official modifications to VNC protocol every time we
do a small change to the protocol to please Alexander or anybody other
reasonable wishes of the day, even vnc could eventually reach
equivalent speedup (which is debatable too). Going the vnc route and
official feature requests to extend the protocol is a dead hand IMHO,
all you can argue is spice or something else separate from vnc.

Likely the spice protocol should be left free to float for a while so
all graphics people can put their hands on it and improve it. Open
sourcing it is going to inevitably improve spice protocol. There is no
hardware involvement, no lock-in, no lack of specs, this is an area
where open source can shine against proprietary world. But policies,
licenses and in general political arguments must be left void and
irrelevant and we must stick to technical discussions about code.

Once things settled down and protocol is stable it is very reasonable
to expect a VNC export to enable/disable so legacy vnc clients can
still be used on qlx guest even if they will lose most of the
benefits. But worrying and discussing it now is too early. It would be
like pretending to provide a git-svn importer before git was actually
usable...

Overall, it's awesome SPICE has been finally released Open Source,
even if in only in tarball form so far.  I hope splitting the tarball
in patches is also feasible... ;) and it will be done, but clearly
it's a clumsy work and so I guess it will take a bit of time so
there's no particular reason 

[Qemu-devel] [PATCH] eepro100: Restructure code (new function tx_command)

[Stefan Weil]

Handling of transmit commands is rather complex,
so about 80 lines of code were moved from function
action_command to the new function tx_command.

The two new values "tx" and "cb_address" in the
eepro100 status structure made this possible without
passing too many parameters.

In addition, the moved code was cleaned a little bit:
old comments marked with //~ were removed, C++ style
comments were replaced by C style comments, C++ like
variable declarations after code were reordered.

Simplified mode is still broken. Nor did I fix
endianess issues. Both problems will be fixed in
additional patches (which need this one).

Signed-off-by: Stefan Weil 
---
 hw/eepro100.c |  192 +
 1 files changed, 98 insertions(+), 94 deletions(-)

diff --git a/hw/eepro100.c b/hw/eepro100.c
index 2a9e3b5..5635f61 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -213,6 +213,10 @@ typedef struct {
 uint32_t ru_offset; /* RU address offset */
 uint32_t statsaddr; /* pointer to eepro100_stats_t */
 
+/* Temporary data. */
+eepro100_tx_t tx;
+uint32_t cb_address;
+
 /* Statistical counters. Also used for wake-up packet (i82559). */
 eepro100_stats_t statistics;
 
@@ -748,17 +752,100 @@ static void dump_statistics(EEPRO100State * s)
 //~ missing("CU dump statistical counters");
 }
 
+static void tx_command(EEPRO100State *s)
+{
+uint32_t tbd_array = le32_to_cpu(s->tx.tx_desc_addr);
+uint16_t tcb_bytes = (le16_to_cpu(s->tx.tcb_bytes) & 0x3fff);
+/* Sends larger than MAX_ETH_FRAME_SIZE are allowed, up to 2600 bytes. */
+uint8_t buf[2600];
+uint16_t size = 0;
+uint32_t tbd_address = s->cb_address + 0x10;
+TRACE(RXTX, logout
+("transmit, TBD array address 0x%08x, TCB byte count 0x%04x, TBD count 
%u\n",
+ tbd_array, tcb_bytes, s->tx.tbd_count));
+
+if (tcb_bytes > 2600) {
+logout("TCB byte count too large, using 2600\n");
+tcb_bytes = 2600;
+}
+if (!((tcb_bytes > 0) || (tbd_array != 0x))) {
+logout
+("illegal values of TBD array address and TCB byte count!\n");
+}
+assert(tcb_bytes <= sizeof(buf));
+while (size < tcb_bytes) {
+uint32_t tx_buffer_address = ldl_phys(tbd_address);
+uint16_t tx_buffer_size = lduw_phys(tbd_address + 4);
+//~ uint16_t tx_buffer_el = lduw_phys(tbd_address + 6);
+tbd_address += 8;
+TRACE(RXTX, logout
+("TBD (simplified mode): buffer address 0x%08x, size 0x%04x\n",
+ tx_buffer_address, tx_buffer_size));
+tx_buffer_size = MIN(tx_buffer_size, sizeof(buf) - size);
+cpu_physical_memory_read(tx_buffer_address, &buf[size],
+ tx_buffer_size);
+size += tx_buffer_size;
+}
+if (tbd_array == 0x) {
+/* Simplified mode. Was already handled by code above. */
+} else {
+/* Flexible mode. */
+uint8_t tbd_count = 0;
+if (s->has_extended_tcb_support && !(s->configuration[6] & BIT(4))) {
+/* Extended Flexible TCB. */
+for (; tbd_count < 2; tbd_count++) {
+uint32_t tx_buffer_address = ldl_phys(tbd_address);
+uint16_t tx_buffer_size = lduw_phys(tbd_address + 4);
+uint16_t tx_buffer_el = lduw_phys(tbd_address + 6);
+tbd_address += 8;
+TRACE(RXTX, logout
+("TBD (extended flexible mode): buffer address 0x%08x, 
size 0x%04x\n",
+ tx_buffer_address, tx_buffer_size));
+tx_buffer_size = MIN(tx_buffer_size, sizeof(buf) - size);
+cpu_physical_memory_read(tx_buffer_address, &buf[size],
+ tx_buffer_size);
+size += tx_buffer_size;
+if (tx_buffer_el & 1) {
+break;
+}
+}
+}
+tbd_address = tbd_array;
+for (; tbd_count < s->tx.tbd_count; tbd_count++) {
+uint32_t tx_buffer_address = ldl_phys(tbd_address);
+uint16_t tx_buffer_size = lduw_phys(tbd_address + 4);
+uint16_t tx_buffer_el = lduw_phys(tbd_address + 6);
+tbd_address += 8;
+TRACE(RXTX, logout
+("TBD (flexible mode): buffer address 0x%08x, size 0x%04x\n",
+ tx_buffer_address, tx_buffer_size));
+tx_buffer_size = MIN(tx_buffer_size, sizeof(buf) - size);
+cpu_physical_memory_read(tx_buffer_address, &buf[size],
+ tx_buffer_size);
+size += tx_buffer_size;
+if (tx_buffer_el & 1) {
+break;
+}
+}
+}
+TRACE(RXTX, logout("%p sending frame, len=%d,%s\n", s, size, nic_dump(buf, 
size)));
+qemu_send_packet(&s->nic->nc, buf, size);
+s->statistics.tx_good_frames++;
+/* Transmit with bad 

[Qemu-devel] Re: [PATCH] eepro100: Restructure code (new function tx_command)

[Stefan Weil]

Stefan Weil schrieb:
> Handling of transmit commands is rather complex,
> so about 80 lines of code were moved from function
> action_command to the new function tx_command.
>
> The two new values "tx" and "cb_address" in the
> eepro100 status structure made this possible without
> passing too many parameters.
>
> In addition, the moved code was cleaned a little bit:
> old comments marked with //~ were removed, C++ style
> comments were replaced by C style comments, C++ like
> variable declarations after code were reordered.
>
> Simplified mode is still broken. Nor did I fix
> endianess issues. Both problems will be fixed in
> additional patches (which need this one).
>
> Signed-off-by: Stefan Weil 
> ---
> hw/eepro100.c | 192
> +
> 1 files changed, 98 insertions(+), 94 deletions(-)

This patch is still missing in QEMU master.
Because of other patches (which were sent later!), a rebase is needed again
(it was rebased 3 times now). Only the line with qemu_send_packet changed.

Please apply the rebased patch if there are no really important
reasons against it (there are none), hopefully without waiting several
weeks again.
It is needed for very important bug fixes (multicast, simple transmit mode).

Regards
Stefan Weil

Re: [Qemu-devel] about porting qemu to alpha platform

[Andreas Färber]

Hello,

Am 05.12.2009 um 16:23 schrieb identifier scorpio:

I'm trying to port qemu to alpha platform, and my working  
environment is

an alpha xp1000 workstation (21264) that is running debian 5.



diff -urN qemu-0.10.0/cpu-all.h qemu-0.10.0.alpha/cpu-all.h
--- qemu-0.10.0/cpu-all.h2009-03-04 14:54:45.0 -0800
+++ qemu-0.10.0.alpha/cpu-all.h2009-10-25 23:13:53.0 -0700


While I don't know much about alpha architecture, I notice that you  
seem to be working against version 0.10.
You should consider forward-porting your work to git master branch, to  
assure that your patches apply cleanly and that you are copying from  
the latest TCG code.


Andreas

Re: [Qemu-devel] Bug in Sparc64/IDE Code

[Igor Kovalenko]

On Sat, Dec 12, 2009 at 3:18 PM, Igor Kovalenko
 wrote:
> On Sat, Dec 12, 2009 at 1:12 PM, Blue Swirl  wrote:
>> On Fri, Dec 11, 2009 at 10:16 PM, Nick Couchman  
>> wrote:
>>> In working to try to get Sparc64 system emulation developed, we seem to 
>>> have run into an issue with the IDE code in Qemu.  The OpenBIOS folks have 
>>> been working quite a few issues with the OpenBIOS code that need to be 
>>> resolved in order to boot 64-bit Solaris kernels correctly, but the most 
>>> recent issue indicates that the IDE code for the Sparc64 emulator is 
>>> reading from and writing to the wrong memory locations.  The end result is 
>>> the following output when trying to boot off an ISO image in Qemu:
>>
>>> bmdma_cmd_writeb: 0x0054
>>> bmdma: writeb 0x701 : 0xd7
>>> bmdma: writeb 0x702 : 0x79
>>> bmdma: writeb 0x703 : 0xfe
>>> bmdma_addr_writew: 0xddef
>>> bmdma_addr_writew: 0xb12b
>>> bmdma_cmd_writeb: 0x00da
>>> bmdma: writeb 0x709 : 0x95
>>> Segmentation fault
>>
>> I can't reproduce this with milaX 0.3.1, QEMU git HEAD and OpenBIOS
>> svn r644. The bug could be that the BMDMA address may need BE to LE
>> conversion, or OpenBIOS could just clobber BMDMA registers with
>> garbage (the DMA address candidates 0xddefb12b and 0xb12bddef do not
>> look valid).
>>
>> Another possibility is that the PCI host bridge should have an IOMMU
>> which is not implemented yet, but I doubt we are at that stage.
>>
>> Could you run QEMU in a GDB session and send the backtrace from the segfault?
>>
>
> There seems to be an issue with pci_from_bm cast: bm->unit is not
> assigned anywhere
> in the code so it is zero for second unit, and pci_from_bm returns
> wrong address.
> Crash happens writing to address mapped for second unit.

This appears to be a regression in cmd646. After removal of pci_dev from
BMDMAState structure we cannot do much to work around this issue.

The problem here is that we cannot rely on bm->unit value since it is getting
changed while dma operations are in progress, f.e. it is set to -1 on
dma cancel.
Thus we cannot get to pci_dev from BMDMAState passed to i/o read/write
callbacks.

Juan, can you please take a look at this issue?

-- 
Kind regards,
Igor V. Kovalenko

Re: [Qemu-devel] Adding support for Mac OS X ppc64 host

[malc]

On Fri, 11 Dec 2009, Andreas F?rber wrote:

> 
> Am 06.12.2009 um 07:37 schrieb malc:
> 
> > will try system-ppc later..
> 
> I've tried Debian 4.0r4a ppc netinst CD on Linux/ppc64 and spotted different
> but similar deviations:
> 
> ppc64 qemu-system-ppc segfaults after "returning from prom_init".

Weird things going on there, it fails (but only semi-reliably!) inside
helper_lsw it appears that while argument passed to it is correct the
memory reference (inside ldl) uses sign extended version of the address.

I'm a bit stumped...

> ppc64 qemu-system-ppc64 boots the default "install" option fine.
> 
> amd64 qemu-system-ppc does not exhibit this crash.
> amd64 qemu-system-ppc64 boots okay, too.
> 
> Andreas

-- 
mailto:av1...@comtv.ru

Re: [Qemu-devel] Adding support for Mac OS X ppc64 host

[malc]

On Sat, 12 Dec 2009, Andreas F?rber wrote:

> 
> Am 06.12.2009 um 07:37 schrieb malc:
> 
> > On Sun, 6 Dec 2009, Andreas F?rber wrote:
> > 
> > > 
> > > Am 06.12.2009 um 06:14 schrieb malc:
> > > 
> > > > On Sun, 6 Dec 2009, Andreas Faerber wrote:
> > > > 
> > > > > qemu-system-sparc64 works on ppc64 while it didn't on ppc!
> > > > 
> > > > Does it work on linux ppc64? If so
> > > 
> > > Haven't had a chance to test on other ppc[64] platforms yet.
> > > 
> > > > how exactly did you test that
> > > > (so that i can try to debug it here)
> > > 
> > > $ /Users/andreas/QEMU/latest64/bin/qemu-system-sparc64 -boot d -cdrom
> > > /Users/andreas/QEMU/sol-10-u3-ga-sparc-dvd.iso
> > > $ /Users/andreas/QEMU/latest64/bin/qemu-system-sparc64 -boot d -cdrom
> > > /Users/andreas/QEMU/debian-40r3-sparc-CD-1.iso
> > > 
> > > All these (also MilaX, in case you don't have Solaris 10 around) are
> > > expected
> > > to enter OpenBIOS and result in OpenBIOS errors but not in QEMU crashes or
> > > hangs.
> > > On Linux add -nographic.
> > > 
> > 
> > I was only able to find debian-40r3-sparc-netinst.iso here on ppc/linux
> > it boots (i think):
> > 
> > 
> > boot: expert
> > Allocated 8 Megs of memory at 0x4000 for kernel
> > Loaded kernel version 2.6.18
> > Loading initial ramdisk (3882238 bytes at 0xC0 phys, 0x40C0 virt)...
> > -
> > Remapping the kernel... done.
> > Booting Linux...
> > 
> > And it sits there while i'm losing patience..
> > 
> > Can you retry with netinst, if it behaves like CD-1 in your case the
> > problem is most likely confined to OSX, otherwise i would have to search
> > for CD-1 better.
> 
> I tried with 4.0r8 businesscard: Such a hang I could reproduce on Linux/ppc
> and Linux/ppc64 and OSX/ppc64 and Linux/amd64 only when running with
> qemu-system-sparc64, but not with qemu-system-sparc.

So the problem is in no way limited to ppc, good to know.
 
> Also, on Linux/ppc64, qemu and qemu-system-x86_64 render Haiku nightly image
> r34558 x86gcc2 unusable (desktop garbled, no cursor), while on Linux/ppc and
> OSX/ppc64 (r34514) and Linux/amd64 it works okay.

That's vga/display issue (have you tried -vga std ?, FranГois REVOL 
mentioned that it works with one of those and doesn't work with others)

-- 
mailto:av1...@comtv.ru

Re: [Qemu-devel] Bug in Sparc64/IDE Code

[Igor Kovalenko]

On Sat, Dec 12, 2009 at 1:12 PM, Blue Swirl  wrote:
> On Fri, Dec 11, 2009 at 10:16 PM, Nick Couchman  
> wrote:
>> In working to try to get Sparc64 system emulation developed, we seem to have 
>> run into an issue with the IDE code in Qemu.  The OpenBIOS folks have been 
>> working quite a few issues with the OpenBIOS code that need to be resolved 
>> in order to boot 64-bit Solaris kernels correctly, but the most recent issue 
>> indicates that the IDE code for the Sparc64 emulator is reading from and 
>> writing to the wrong memory locations.  The end result is the following 
>> output when trying to boot off an ISO image in Qemu:
>
>> bmdma_cmd_writeb: 0x0054
>> bmdma: writeb 0x701 : 0xd7
>> bmdma: writeb 0x702 : 0x79
>> bmdma: writeb 0x703 : 0xfe
>> bmdma_addr_writew: 0xddef
>> bmdma_addr_writew: 0xb12b
>> bmdma_cmd_writeb: 0x00da
>> bmdma: writeb 0x709 : 0x95
>> Segmentation fault
>
> I can't reproduce this with milaX 0.3.1, QEMU git HEAD and OpenBIOS
> svn r644. The bug could be that the BMDMA address may need BE to LE
> conversion, or OpenBIOS could just clobber BMDMA registers with
> garbage (the DMA address candidates 0xddefb12b and 0xb12bddef do not
> look valid).
>
> Another possibility is that the PCI host bridge should have an IOMMU
> which is not implemented yet, but I doubt we are at that stage.
>
> Could you run QEMU in a GDB session and send the backtrace from the segfault?
>

There seems to be an issue with pci_from_bm cast: bm->unit is not
assigned anywhere
in the code so it is zero for second unit, and pci_from_bm returns
wrong address.
Crash happens writing to address mapped for second unit.

-- 
Kind regards,
Igor V. Kovalenko

[Qemu-devel] Re: approaches to 3D virtualisation

[Juan Quintela]

Dave Airlie  wrote:
>>>
>>> Current existing solutions in the area:
>>> a) VMware virtual graphics adapter - based on DX9, has an open
>>> KMS/Gallium3D driver stack recently released by vmware, has certified
>>> Windows drivers and has a documented vGPU interface (it could be
>>> documented a lot better)
>
> http://vmware-svga.svn.sourceforge.net/viewvc/vmware-svga/trunk/doc/gpu-wiov.pdf?revision=1
>
> is a good whitepaper on the different 3D virtualisation approaches and why
> vmware picked what they did also.
>
> Dave.

I have zero clue of 3D, but for the qemu part, vmware_vga is the "nicer"
driver.

On the size department:

(virtio-2*)$ wc -l vga.c cirrus_vga.c vmware_vga.c
  2380 vga.c
  3235 cirrus_vga.c
  1211 vmware_vga.c

(notice that part of vga.c is used by both vwmare_vga and cirrus_vga).

On the features, vmware_vga has a nice feature: xrandr already works
(i.e. you can have any modern resolution that you like), cirrus and
vga_std have much less options here.

vmware_vga also has Xvideo (or something) that improves video support.

once telling that, the 3 drivers need a big cleanup.

- vga.c -> VBE is optional (#ifdef'd) but you can't compile it out.

- cirrus_vga -> uses all vga.c code minus the vbe code.  Replicates
  several big functions (switch) for only changing a couple of lines
  there.

- vmware_vga.  Lets say that the way that it embeds an vga is
  _interesting_ to say the less.  Also the vga can be compiled out, but
  not bios/os on earth will boot without its support.

I did some cleanups of the three drivers some months ago, but they need
much more care.  I didn't follow due to time constraints and my zero
knowledge of graphics (hardware/software/...).

Later, Juan.

Re: [Qemu-devel] Bug in Sparc64/IDE Code

[Blue Swirl]

On Fri, Dec 11, 2009 at 10:16 PM, Nick Couchman  wrote:
> In working to try to get Sparc64 system emulation developed, we seem to have 
> run into an issue with the IDE code in Qemu.  The OpenBIOS folks have been 
> working quite a few issues with the OpenBIOS code that need to be resolved in 
> order to boot 64-bit Solaris kernels correctly, but the most recent issue 
> indicates that the IDE code for the Sparc64 emulator is reading from and 
> writing to the wrong memory locations.  The end result is the following 
> output when trying to boot off an ISO image in Qemu:

> bmdma_cmd_writeb: 0x0054
> bmdma: writeb 0x701 : 0xd7
> bmdma: writeb 0x702 : 0x79
> bmdma: writeb 0x703 : 0xfe
> bmdma_addr_writew: 0xddef
> bmdma_addr_writew: 0xb12b
> bmdma_cmd_writeb: 0x00da
> bmdma: writeb 0x709 : 0x95
> Segmentation fault

I can't reproduce this with milaX 0.3.1, QEMU git HEAD and OpenBIOS
svn r644. The bug could be that the BMDMA address may need BE to LE
conversion, or OpenBIOS could just clobber BMDMA registers with
garbage (the DMA address candidates 0xddefb12b and 0xb12bddef do not
look valid).

Another possibility is that the PCI host bridge should have an IOMMU
which is not implemented yet, but I doubt we are at that stage.

Could you run QEMU in a GDB session and send the backtrace from the segfault?

[Qemu-devel] Re: approaches to 3D virtualisation

[Dave Airlie]

>>
>> Current existing solutions in the area:
>> a) VMware virtual graphics adapter - based on DX9, has an open
>> KMS/Gallium3D driver stack recently released by vmware, has certified
>> Windows drivers and has a documented vGPU interface (it could be
>> documented a lot better)

http://vmware-svga.svn.sourceforge.net/viewvc/vmware-svga/trunk/doc/gpu-wiov.pdf?revision=1

is a good whitepaper on the different 3D virtualisation approaches and why
vmware picked what they did also.

Dave.

[Qemu-devel] Re: Spice project is now open

[Paolo Bonzini]

On 12/12/2009 04:34 AM, Anthony Liguori wrote:

Firefox uses that extensively, for example to render tiled backgrounds
(though probably GTK user interface elements can do so less
successfully).


Yes, but this is just a single application.  The point is that these
things are not as widely standardized on X as they are on Windows.


They are standardized (Xrender) and there are high-level de facto 
standard APIs (Cairo or the Qt equivalent).


If glyphs are rendered with Xrender it means that the shapes must be 
somehow transferred to the X server (and hence with SPICE-like protocols 
to the SPICE client), unlike with X fonts.  However these shapes will be 
grayscale (cheap) and the complicated compositing with the background 
will be all done via XRender (i.e. on the SPICE client too).


Regarding compositing, this is done via OpenGL so even though it is true 
that nothing goes through X calls, it is also true that everything does 
go though a high-level API which can be sent on the wire (cfr. AIGLX).


Actually, compositing might really be where a protocol like SPICE 
shines, since it does not generate nearly as many expose events, and 
since you do not have to resend occluded contents on the wire any time 
someone raises a window.


I have no idea how SPICE performs now, but there's definitely nothing in 
a modern X Windows desktop that it cannot deal with.  The only negative 
point it might have compared to Windows is IMO the rendering of text.


Paolo

[Qemu-devel] Re: [PATCH] sparc32 fix carry flag handling (Solaris bootblk fix)

[Blue Swirl]

On Thu, Dec 10, 2009 at 8:27 PM, Artyom Tarasenko
 wrote:
> 2009/11/13 Blue Swirl :
>> On Fri, Nov 13, 2009 at 4:28 PM, Artyom Tarasenko
>>  wrote:
> Could you describe the steps how to boot Solaris with OBP? I'm sure
> there are a lot of people who'd like to test if their favorite Sparc
> Solaris programs work on QEMU.
>>>
>>> Gathered things for which I currently have hacks here:
>>> http://tyom.blogspot.com/2009/11/things-missing-in-vanilla-qemu.html
>>>
>>> Actually for OBP itself it's just two (SS-5) or three (SS-20) things:
>>>
>>> - Floppy. Instead of fixing it, I broke it completely, so OBP doesn't
>>> try to initialize it and hang. Actually it maybe not the fdc itself,
>>> but the irq handling. There are OBP tests which may help to understand
>>> what is currently going wrong. I didn't need it, does the fdc actually
>>> work under linux/netbsd/OpenBIOS?
>>
>> Not at least Linux, IIRC Linux floppy driver is broken. FDC is wired a
>> bit differently from PC setup. We don't need it, but getting OBP just
>> to accept it would be nice.
>>
>>> - [SparcStation-5] 0x6e00 AFX. OBP tries to access it and fails
>>> with "unassigned address exception". Is only present in the SS-5's
>>> TCX. The required address space is just one byte long. IMHO makes no
>>> sense to create a special stub device for it. Can we push it into the
>>> TCX?
>>
>> I'd put it to sun4m.c, there is similar device (idreg) already.
>
> Ok, I made one patch for fdc.c (it turned out that for SS5-only fix, a
> very small change is needed), and a small afx patch for sun4m.c .
> Shall I post them marked "for 0.12" or shall we do it in 0.13 ?

Depends on the patches.

Re: [Qemu-devel] [FOR 0.12 PATCH] qdev: Replace device names containing whitespace

[Blue Swirl]

On Wed, Dec 9, 2009 at 11:43 AM, Markus Armbruster  wrote:
> Ian Molton  writes:
>
>> Markus Armbruster wrote:
>>
>>> The place for verbose device names is DeviceInfo member desc.  The
>>> name should be short & sweet.
>>
>> Agreed, however...
>>
>> Why do these (maybe others) get caps in their names? they dont look
>> right to me, compared to the others with nice names like usb-serial,
>> piix-ide, or cirrus-vga.
>>
>>> -    sysbus_register_dev("Uni-north main", sizeof(UNINState),
>>> +    sysbus_register_dev("Uni-north-main", sizeof(UNINState),
>>>                          pci_unin_main_init_device);
>>>      pci_qdev_register(&unin_main_pci_host_info);
>>> -    sysbus_register_dev("DEC 21154", sizeof(UNINState),
>>> +    sysbus_register_dev("DEC-21154", sizeof(UNINState),
>>>                          pci_dec_21154_init_device);
>>>      pci_qdev_register(&dec_21154_pci_host_info);
>>> -    sysbus_register_dev("Uni-north AGP", sizeof(UNINState),
>>> +    sysbus_register_dev("Uni-north-AGP", sizeof(UNINState),
>>>                          pci_unin_agp_init_device);
>>>      pci_qdev_register(&unin_agp_pci_host_info);
>>> -    sysbus_register_dev("Uni-north internal", sizeof(UNINState),
>>> +    sysbus_register_dev("Uni-north-internal", sizeof(UNINState),
>>>                          pci_unin_internal_init_device);
>>>      pci_qdev_register(&unin_internal_pci_host_info);
>>>  }
>
> I can downcase them.  Blue Swirl, any objections?
>

I'd prefer the same names that are used by the device tree, like uni-n
and uni-north-agp. Though the bridge is name poorly, just
"pci-bridge".

For example:
http://penguinppc.org/historical/dev-trees-html/imac_400_1.html

Re: [Qemu-devel] Qemu terminating with SIGABRT

[Stefan Weil]

David S. Ahern schrieb:
> I realize this is a rather generic question, but what are typical
> reasons Qemu would be killed by a SIGABRT? I am seeing this on a
> somewhat regular (though not repeatable on demand) basis. I do not have
> a core file, though I hope to capture one if I can get it repeat again.
>
> Thanks,
>   

Look for "abort" in QEMU's code to see the possible reasons.

In many cases, the reason will be printed to stderr before
aborting. Did you call QEMU from a console and get some
output there? Or maybe the stderr output went into a file?

Run "ulimit -c unlimited" before you run QEMU, then a
core file will be written automatically on SIGABRT.

[Qemu-devel] Re: irq latency and tcg

[Blue Swirl]

On Wed, Dec 9, 2009 at 2:30 PM, Artyom Tarasenko
 wrote:
> 2009/12/7 Blue Swirl :
>> On Mon, Dec 7, 2009 at 3:30 PM, Artyom Tarasenko
>>  wrote:
>>> Can it be that qemu (-system-sparc in my case, but I guess it's more
>>> or less similar on all platforms) reacts to irqs slower than a real
>>> hardware due to tcg optimizations?
>>>
>>> I see one test pattern which fails on qemu:
>>>
>>> 
>>> nop * N
>>> 
>>>
>>> What I observe is that the proper interrupt does take a place, but
>>> after the check, so no-one expects it anymore.
>>> Is there a way to reduce the interrupt latency? Or maybe there is a
>>> good substitute to a nop*N, so that irq would definitely get through
>>> in the mean time?
>>
>> On Sparc, nops do not generate any code at all.
>
> But "qemu: fatal: Raised interrupt while not in I/O function" is still
> a bug, right?

According to comment in exec-all.h:
/* Deterministic execution requires that IO only be performed on the last
   instruction of a TB so that interrupts take effect immediately.  */

Sparc generator must then violate this assumption. Is the assumption
valid also when not using icount and should the check be enabled for
all cases, not just icount?

[Qemu-devel] Re: Qemu terminating with SIGABRT

[Avi Kivity]

On 12/11/2009 07:08 PM, David S. Ahern wrote:

I realize this is a rather generic question, but what are typical
reasons Qemu would be killed by a SIGABRT? I am seeing this on a
somewhat regular (though not repeatable on demand) basis. I do not have
a core file, though I hope to capture one if I can get it repeat again.
   


There's pretty much nothing we can do without a core.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.