[Qemu-devel] exporting console over Xforwarding
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
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?
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
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
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
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
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?
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
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?
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
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