[Qemu-devel] exporting console over Xforwarding

2007-03-13 Thread Patrick Ale

Morning all,

Does Qemu support the forwarding of the VGA console over X11/SSH?

For some obscure reason I dont get it to work while all my other
remote X stuff does work.


Thanks,

Patrick


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


[Qemu-devel] PATCH: allow Sparc hosts to run arm/mips/sparc-softmmu

2007-03-13 Thread Ben Taylor

This patch fixes crashes when testing with arm-test-0.2.tar.gz and 
mips-test-0.2.tar.gz.
Without the patch, both arm-test and mips-test segfault when trying to boot.

The original patch was authored by Martin Bochnig.

--- qemu/cpu-exec.c.ORIG	2007-03-13 09:46:51.940624000 -0400
+++ qemu/cpu-exec.c	2007-03-13 09:33:34.130534000 -0400
@@ -738,7 +744,10 @@
 #else
 gen_func();
 #endif
+/* sparc hosts don't seem to like this method very much */
+#if !(defined(__sparc__)  !defined(TARGET_I386)  !defined(TARGET_X86_64)  !defined(TARGET_PPC))
 env-current_tb = NULL;
+#endif
 /* reset soft MMU for next block (it can currently
only be set by a memory fault) */
 #if defined(TARGET_I386)  !defined(CONFIG_SOFTMMU)
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] SSE 'maxps' instruction bug?

2007-03-13 Thread Julian Seward

 QEMU and Core 2 Duo disagree on the handling of NaNs it seems.

 http://courses.ece.uiuc.edu/ece390/books/labmanual/inst-ref-simd.html
 - this implies that MAXPS should leave the NaNs alone, no idea how
 normative that is though (and no IA32 manual at hand)

Having looked at an IA32 manual I'd say the inst-ref-simd.html
description agrees with it, so the Core 2 behaviour is what 
qemu should do.

J




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


Re: [Qemu-devel] PATCH: allow Sparc hosts to run arm/mips/sparc-softmmu

2007-03-13 Thread Ben Taylor

 Paul Brook [EMAIL PROTECTED] wrote: 
 On Tuesday 13 March 2007 14:01, Ben Taylor wrote:
  This patch fixes crashes when testing with arm-test-0.2.tar.gz and
  mips-test-0.2.tar.gz. Without the patch, both arm-test and mips-test
  segfault when trying to boot.
 
 I don't believe this is correct. You're going to have to come up with a 
 fairly 
 convincing argument to get a patch like this accepted.
 don't seem to like this very much is not a useful comment.

Yeah, so the comment is not very useful.  I copied it from the author.
I'll see if he can actually explain why this patch is important.

However, it's very wax-on, wax-off kind of thing.  Without the patch, arm-test
and mips-test crash.  With the patch, I can run both tests.

Ben


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


Re: [Qemu-devel] PATCH: allow Sparc hosts to run arm/mips/sparc-softmmu

2007-03-13 Thread Paul Brook
 However, it's very wax-on, wax-off kind of thing.  Without the patch,
 arm-test and mips-test crash.  With the patch, I can run both tests.

As I've said before it's not sufficient to say that a patch fixes a bug, you 
have to explain *what* bug you are fixing, *how* it fixes the bug, and *why* 
it's the correct way to fix it. In order to review the patch I need to be 
able to follow your logic for creating the patch. If you don't understand the 
patch you should not be submitting it.

In this specific case:

* What: qemu crashes is not a particularly useful description of the failure 
mode. I want to know how (eg. segfault, abort, infinite loop, does wrong 
thing) it crashes, which bit of code it's executing when it crashes, and how 
it got to that point.

* How: I'm also not convinced your #ifdef does what you think it does, though 
It's somewhat unclear what you're trying to achieve. I'm guessing you 
intended to disable the code on sparc hosted arm+mips targets 

* Why: I randomly changed things until it started working is not a valid 
justification for a change. Why doesn't this failure occur on other hosts? 
Why only arm and mips targets?

Paul


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


AW: [Qemu-devel] exporting console over Xforwarding

2007-03-13 Thread Nenad Cimerman
 Does Qemu support the forwarding of the VGA console over X11/SSH?
 For some obscure reason I dont get it to work while all my other
 remote X stuff does work.
 Thanks,
 Patrick

I tried this once in a cygwin bash using this command:

 # Xwin :0.0 -query cclsol01 -fp cclsol01/7100 

But it failed and QEMU showed the following message:
'Error initializing SDL...'

After some research I found the reason to be a problem with the shared
libraries, which were installed for 32- and 64-bit mode of my Solaris x86-64
installation.

I used the following command to track down the missing library:

 # ldd /usr/kernel/drv/amd64/kqemu

With the output of the above command, I was able to set the environment
variable LD_LIBRARY_PATH correctly, to make sure the SDL-libs were found.

HTH

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



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


Re: [Qemu-devel] Updated PATCH: hw/rtl8139.c for Sparc (BigEndian) Hosts

2007-03-13 Thread Igor Kovalenko

On 3/13/07, Ben Taylor [EMAIL PROTECTED] wrote:



Patch 1: qemu-rtl8139-bigend.diff

This fixes the big-endian problem with the hw/rtl8139.c on a Sparc host.




I updated the patch to remove one extra le32 conversion found in
rtl8139_TxAddr_read
which is called from i/o read callback.

--
Kind regards,
Igor V. Kovalenko
--- hw/rtl8139.c.old	2007-03-14 00:55:03.0 +0300
+++ hw/rtl8139.c	2007-03-13 23:57:04.0 +0300
@@ -1194,7 +1194,10 @@
 s-eeprom.contents[1] = 0x10ec;
 s-eeprom.contents[2] = 0x8139;
 #endif
-memcpy(s-eeprom.contents[7], s-macaddr, 6);
+
+s-eeprom.contents[7] = s-macaddr[0] | s-macaddr[1]  8;
+s-eeprom.contents[8] = s-macaddr[2] | s-macaddr[3]  8;
+s-eeprom.contents[9] = s-macaddr[4] | s-macaddr[5]  8;
 
 /* mark all status registers as owned by host */
 for (i = 0; i  4; ++i)
@@ -2457,12 +2460,12 @@
 {
 DEBUG_PRINT((RTL8139: TxAddr write offset=0x%x val=0x%08x\n, txAddrOffset, val));
 
-s-TxAddr[txAddrOffset/4] = le32_to_cpu(val);
+s-TxAddr[txAddrOffset/4] = val;
 }
 
 static uint32_t rtl8139_TxAddr_read(RTL8139State *s, uint32_t txAddrOffset)
 {
-uint32_t ret = cpu_to_le32(s-TxAddr[txAddrOffset/4]);
+uint32_t ret = s-TxAddr[txAddrOffset/4];
 
 DEBUG_PRINT((RTL8139: TxAddr read offset=0x%x val=0x%08x\n, txAddrOffset, ret));
 
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] SSE 'maxps' instruction bug?

2007-03-13 Thread Tim Olson


On Mar 12, 2007, at 11:27 AM, malc wrote:



QEMU and Core 2 Duo disagree on the handling of NaNs it seems.

http://courses.ece.uiuc.edu/ece390/books/labmanual/inst-ref-simd.html
- this implies that MAXPS should leave the NaNs alone, no idea how
normative that is though (and no IA32 manual at hand)


I compiled and ran the code that Julian supplied on an AMD processor 
with SSE, and on qemu-i386  version 0.8.2 built with that system, and 
both agreed with the Intel Core 2 results that Julian supplied.


That means that either qemu changed in this area between v 0.8.2 and 
0.9.0, or that the compiler/host combination used to build the qemu 
binary Julian is running generated bad code for the float compares.


The MAXPS instruction is defined to operate on NaNs in such a way that 
it can be used as a direct replacement for an iterated scalar max 
operation coded in C like:


a = (a  b) ? a : b;

Which is exactly how it is coded in qemu (at least in v0.8.2).  This 
relies upon the fact that the greater-than comparison returns false 
anytime there is an unordered operand (NaN), for either operand -- in 
which case the result is the second argument.


-- Tim Olson



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


[Qemu-devel] [PATCH] Reducing X communication bandwidth, take 2

2007-03-13 Thread Julian Seward

Here is a somewhat revised version of a patch I first made nearly
three years ago.  The original thread is 

http://lists.gnu.org/archive/html/qemu-devel/2004-07/msg00263.html

The patch makes QEMU's graphics emulation much more usable over remote
X connections, by reducing the amount of data sent to the X server.
This is particularly noticeable for small display updates, most
importantly mouse cursor movements, which become faster and so 
generally make the guest's GUI more pleasant to use.

Compared to the original patch, this one:

- is relative to 0.9.0

- handle screen-format-BytesPerPixel values of both 2 and 4,
  so handles most guest depths - I tested 8, 16, 24bpp.

- has unrolled comparison/copy loops for the depth 2 case.  Most
  of the comparisons are short (= 64 bytes) so I don't see much
  point in taking the overhead of a call to memcmp/memcpy.

- most importantly, is optional and disabled by default, so that
  default performance is unchanged.  To use it you need the new
  -remote-x11 flag (perhaps -low-bandwidth-x11 would be a better 
  name).

It still uses a shadow frame buffer.  Fabrice mentioned this is not
necessary

 http://lists.gnu.org/archive/html/qemu-devel/2004-07/msg00279.html

but I can't see how to get rid of it and still check for redundant
updates in NxN pixel blocks (N=32 by default).  The point of checking
NxN squares is that mouse pointer pixmaps are square and so the most
common display updates - mouse pointer movements - are often reduced
to transmission of a single 32x32 block using this strategy.

The shadow framebuffer is only allocated when -remote-x11 is present,
so the patch has no effect on default memory use.

I measured the bandwidth saving roughly by resuming a vm snapshot
containing a web browser showing a page with a lot of links.  I moved
the pointer slowly over the links (so they change colour) and scrolled
up and down a bit; about 1/2 minute of activity in total.  I tried to do
the same with and without -remote-x11.  Without -remote-x11, 163Mbyte
was transmitted to the X server; with it, 20.6Mbyte was, about an 8:1
reduction.

J


diff -u -r Orig/qemu-0.9.0/sdl.c qemu-0.9.0/sdl.c
--- Orig/qemu-0.9.0/sdl.c   2007-02-05 23:01:54.0 +
+++ qemu-0.9.0/sdl.c2007-03-13 22:16:40.0 +
@@ -29,6 +29,8 @@
 #include signal.h
 #endif
 
+#include assert.h
+
 static SDL_Surface *screen;
 static int gui_grab; /* if true, all keyboard/mouse events are grabbed */
 static int last_vm_running;
@@ -44,17 +46,232 @@
 static SDL_Cursor *sdl_cursor_hidden;
 static int absolute_enabled = 0;
 
+/* Mechanism to reduce the total amount of data transmitted to the X
+   server, often quite dramatically.  Keep a shadow copy of video
+   memory in alt_pixels, and when asked to update a rectangle, use
+   the shadow copy to establish areas which are the same, and so do
+   not need updating.
+*/
+
+static void* alt_pixels = NULL;
+
+#define THRESH 32
+
+/* Return 1 if the area [x .. x+w-1, y .. y+w-1] is different from
+   the old version and so needs updating. */
+static int cmpArea_16bit ( int x, int y, int w, int h )
+{
+   inti, j;
+  unsigned intsll;
+  unsigned short* p1base = (unsigned short*)screen-pixels;
+  unsigned short* p2base = (unsigned short*)alt_pixels;
+  assert(screen-format-BytesPerPixel == 2);
+  if (w == 0 || h == 0)
+ return 0;
+  assert(w  0  h  0);
+  sll = ((unsigned int)screen-pitch)  1;
+  for (j = y; j  y+h; j++) {
+unsigned short* p1p =  p1base[j * sll + x];
+unsigned short* p2p =  p2base[j * sll + x];
+for (i = 0; i  w-5; i += 5) {
+  if (p1p[i+0] != p2p[i+0]) return 1;
+  if (p1p[i+1] != p2p[i+1]) return 1;
+  if (p1p[i+2] != p2p[i+2]) return 1;
+  if (p1p[i+3] != p2p[i+3]) return 1;
+  if (p1p[i+4] != p2p[i+4]) return 1;
+}
+for (/*fixup*/; i  w; i++) {
+  if (p1p[i+0] != p2p[i+0]) return 1;
+}
+  }
+  return 0;
+}
+static void copyArea_16bit ( int x, int y, int w, int h )
+{
+   inti, j;
+  unsigned intsll;
+  unsigned short* p1base = (unsigned short*)screen-pixels;
+  unsigned short* p2base = (unsigned short*)alt_pixels;
+  assert(screen-format-BytesPerPixel == 2);
+  sll = ((unsigned int)screen-pitch)  1;
+  if (w == 0 || h == 0)
+ return;
+  assert(w  0  h  0);
+  for (j = y; j  y+h; j++) {
+unsigned short* p1p =  p1base[j * sll + x];
+unsigned short* p2p =  p2base[j * sll + x];
+for (i = 0; i  w-5; i += 5) {
+  p2p[i+0] = p1p[i+0];
+  p2p[i+1] = p1p[i+1];
+  p2p[i+2] = p1p[i+2];
+  p2p[i+3] = p1p[i+3];
+  p2p[i+4] = p1p[i+4];
+}
+for (/*fixup*/; i  w; i++) {
+  p2p[i+0] = p1p[i+0];
+}
+  }
+}
+
+static int cmpArea_32bit ( int x, int y, int w, int h )
+{
+  int   i, j;
+  unsigned int  sll;
+  unsigned int* p1base = (unsigned int*)screen-pixels;
+  unsigned int* p2base = (unsigned int*)alt_pixels;
+  assert(screen-format-BytesPerPixel == 4);
+  sll = ((unsigned int)screen-pitch)  

Re: [Qemu-devel] SSE 'maxps' instruction bug?

2007-03-13 Thread Julian Seward

 0.9.0, or that the compiler/host combination used to build the qemu
 binary Julian is running generated bad code for the float compares.

I used gcc 3.4.6 bootstrapped as normal ('make bootstrap; make install')
on a 64-bit machine.  If it is qemu generating bad code due to variations
in gcc behaviour, that's another argument in favour of scrapping the gcc 
3.X based backend and using a self contained, handwritten insn selector
and register allocator.

J


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


Re: [Qemu-devel] [PATCH] Reducing X communication bandwidth, take 2

2007-03-13 Thread Mark Williamson
  Here is a somewhat revised version of a patch I first made nearly
  three years ago.  The original thread is

 The idea here is quite similar to what the VNC server does now.

 If this is desirable for SDL too, then perhaps we should find a way to
 fold this into common code?

 Although, is there a compelling reason to use SDL over X instead of VNC?

I sometimes do this sort of thing because it Just Works with no manual 
configuring of port forwarding etc.  I don't necessarily like to do it for 
extended usage but it is very convenient.

Cheers,
Mark

 Regards,

 Anthony Liguori

  http://lists.gnu.org/archive/html/qemu-devel/2004-07/msg00263.html
 
  The patch makes QEMU's graphics emulation much more usable over remote
  X connections, by reducing the amount of data sent to the X server.
  This is particularly noticeable for small display updates, most
  importantly mouse cursor movements, which become faster and so
  generally make the guest's GUI more pleasant to use.
 
  Compared to the original patch, this one:
 
  - is relative to 0.9.0
 
  - handle screen-format-BytesPerPixel values of both 2 and 4,
so handles most guest depths - I tested 8, 16, 24bpp.
 
  - has unrolled comparison/copy loops for the depth 2 case.  Most
of the comparisons are short (= 64 bytes) so I don't see much
point in taking the overhead of a call to memcmp/memcpy.
 
  - most importantly, is optional and disabled by default, so that
default performance is unchanged.  To use it you need the new
-remote-x11 flag (perhaps -low-bandwidth-x11 would be a better
name).
 
  It still uses a shadow frame buffer.  Fabrice mentioned this is not
  necessary
 
   http://lists.gnu.org/archive/html/qemu-devel/2004-07/msg00279.html
 
  but I can't see how to get rid of it and still check for redundant
  updates in NxN pixel blocks (N=32 by default).  The point of checking
  NxN squares is that mouse pointer pixmaps are square and so the most
  common display updates - mouse pointer movements - are often reduced
  to transmission of a single 32x32 block using this strategy.
 
  The shadow framebuffer is only allocated when -remote-x11 is present,
  so the patch has no effect on default memory use.
 
  I measured the bandwidth saving roughly by resuming a vm snapshot
  containing a web browser showing a page with a lot of links.  I moved
  the pointer slowly over the links (so they change colour) and scrolled
  up and down a bit; about 1/2 minute of activity in total.  I tried to do
  the same with and without -remote-x11.  Without -remote-x11, 163Mbyte
  was transmitted to the X server; with it, 20.6Mbyte was, about an 8:1
  reduction.
 
  J
 
 
  diff -u -r Orig/qemu-0.9.0/sdl.c qemu-0.9.0/sdl.c
  --- Orig/qemu-0.9.0/sdl.c   2007-02-05 23:01:54.0 +
  +++ qemu-0.9.0/sdl.c2007-03-13 22:16:40.0 +
  @@ -29,6 +29,8 @@
   #include signal.h
   #endif
 
  +#include assert.h
  +
   static SDL_Surface *screen;
   static int gui_grab; /* if true, all keyboard/mouse events are grabbed
  */ static int last_vm_running;
  @@ -44,17 +46,232 @@
   static SDL_Cursor *sdl_cursor_hidden;
   static int absolute_enabled = 0;
 
  +/* Mechanism to reduce the total amount of data transmitted to the X
  +   server, often quite dramatically.  Keep a shadow copy of video
  +   memory in alt_pixels, and when asked to update a rectangle, use
  +   the shadow copy to establish areas which are the same, and so do
  +   not need updating.
  +*/
  +
  +static void* alt_pixels = NULL;
  +
  +#define THRESH 32
  +
  +/* Return 1 if the area [x .. x+w-1, y .. y+w-1] is different from
  +   the old version and so needs updating. */
  +static int cmpArea_16bit ( int x, int y, int w, int h )
  +{
  +   inti, j;
  +  unsigned intsll;
  +  unsigned short* p1base = (unsigned short*)screen-pixels;
  +  unsigned short* p2base = (unsigned short*)alt_pixels;
  +  assert(screen-format-BytesPerPixel == 2);
  +  if (w == 0 || h == 0)
  + return 0;
  +  assert(w  0  h  0);
  +  sll = ((unsigned int)screen-pitch)  1;
  +  for (j = y; j  y+h; j++) {
  +unsigned short* p1p =  p1base[j * sll + x];
  +unsigned short* p2p =  p2base[j * sll + x];
  +for (i = 0; i  w-5; i += 5) {
  +  if (p1p[i+0] != p2p[i+0]) return 1;
  +  if (p1p[i+1] != p2p[i+1]) return 1;
  +  if (p1p[i+2] != p2p[i+2]) return 1;
  +  if (p1p[i+3] != p2p[i+3]) return 1;
  +  if (p1p[i+4] != p2p[i+4]) return 1;
  +}
  +for (/*fixup*/; i  w; i++) {
  +  if (p1p[i+0] != p2p[i+0]) return 1;
  +}
  +  }
  +  return 0;
  +}
  +static void copyArea_16bit ( int x, int y, int w, int h )
  +{
  +   inti, j;
  +  unsigned intsll;
  +  unsigned short* p1base = (unsigned short*)screen-pixels;
  +  unsigned short* p2base = (unsigned short*)alt_pixels;
  +  assert(screen-format-BytesPerPixel == 2);
  +  sll = ((unsigned int)screen-pitch)  1;
  +  if (w == 0 || h == 0)
  + return;
  +  assert(w  0  h