[Qemu-devel] PATCH: Support for multi-file raw images
Hello.
Attached is a C file (and small patch) to add support for multi-file raw
images to QEMU. The rationale (for me at least) is as follows:
I use rsync to backup my home directory. The act of starting up QEMU
changes a 20GB file on my drive. This causes 20GB of extra copying next
time I do backups. If I could split the drive image into smaller parts
(maybe 2048 10MB files) then the amount of extra copying is drastically
reduced (since only a few of these files are modified).
There are definitely other reasons that this may be useful.
It works as follows:
1) Create a bunch of files of equal size with names of the form
harddriveXX
where XX is a hex number starting from 00 going to whatever.
NB: you can have any number of XXs from 0 (ie: basically a single-file
image) to 6 (ie: up to 16 million parts).
2) Run qemu multi:harddrive000
QEMU will detect the multi-part image, do a sanity check to ensure all
the parts are there, of the same size, and accessible and then start
using the device as the harddrive (this consists of calling 'stat' and
'access' on each file).
Some notes:
o I've tested only on Linux. I'm positive the code is not portable
to other systems. Feedback about this, please.
o Included is optional support for limiting the number of open fds.
Cache eviction is done using a least-recently-opened policy
(efficiently implemented using a ring buffer).
o The code makes use of the euidaccess() syscall which is Linux-only.
BSD has eaccess() to do the same thing. Both of these calls are
approximately equal to POSIX access() except that the euid of the
process is considered instead of the real uid. The call is used
to determine if the device should be marked 'read_only' by checking
for write access to the files comprising the device. If access()
is used and QEMU is installed setuid/gid to give the user access to
a drive image then the result of using access() will be that the
drive is incorrectly flagged read-only.
o If the files comprising the device are deleted (for example) while
QEMU is running then this is quite bad. Currently this will result
in read/write requests returning -1. Maybe it makes sense to panic
and cause QEMU to exit.
o All comments welcome.
Cheers.
/*
* Block driver for multiple-file raw images.
* Copyright © 2006 Ryan Lortie [EMAIL PROTECTED]
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public
* License along with this program; if not, write to the
* Free Software Foundation, Inc., 59 Temple Place - Suite 330,
* Boston, MA 02111-1307, USA.
*/
#include vl.h
#include block_int.h
/* The maximum number of fds to use. */
#define LIMIT_FDS 15
#ifdef LIMIT_FDS
#define RING_BUFFER_SIZE LIMIT_FDS
struct _RingBuffer
{
int buffer[RING_BUFFER_SIZE+1];
int head;
int tail;
};
typedef struct _RingBuffer RingBuffer;
static RingBuffer *
ring_buffer_new (void)
{
RingBuffer *ring;
ring = qemu_mallocz (sizeof (RingBuffer));
return ring;
}
static int
ring_buffer_get (RingBuffer *ring)
{
int value;
if (ring-head == ring-tail)
return -1;
value = ring-buffer[ring-head];
ring-head = (ring-head + 1) % (RING_BUFFER_SIZE + 1);
return value;
}
static int
ring_buffer_put (RingBuffer *ring, int value)
{
int new_tail;
new_tail = (ring-tail + 1) % (RING_BUFFER_SIZE + 1);
if (ring-head == new_tail)
return -1;
ring-buffer[ring-tail] = value;
ring-tail = new_tail;
return 0;
}
#endif
struct _MultiStatus
{
char *level;
int *fds;
char *filename;
int fnlength;
char pattern[5];
int64_t filesize;
int n_files;
int read_only;
};
typedef struct _MultiStatus MultiStatus;
typedef ssize_t (*disk_operation) (int, const uint8_t *, ssize_t);
static int
multi_status_fill (MultiStatus *status, const char *filename)
{
struct stat statbuf;
int zeros = 0;
int i;
if (!strstart(filename, multi:, NULL))
return -1;
filename += 6;
for (i = 0; filename[i]; i++)
if (filename[i] == '0')
zeros++;
else
zeros = 0;
if (zeros 6)
zeros = 6;
status-fnlength = strlen (filename);
status-filename = qemu_malloc (status-fnlength + 1);
status-fnlength -= zeros;
strcpy (status-filename, filename);
if (zeros == 0)
status-pattern[status-fnlength] = '\0';
else
sprintf (status-pattern, %%0%ux, zeros);
status-n_files = 1 (4 * zeros);
status-read_only = 0;
for (i = 0; i status-n_files; i++)
{
sprintf
Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
Paul Brook wrote: On Wednesday 10 May 2006 23:05, Fabrice Bellard wrote: In order to stop the release of incomplete BGR patches, I am implementing a more complete patch. I am just adding depth = 32 with BGR instead of RGB. If other pixel formats are wanted, you should signal it now. I don't have any paticular favourite pixel formats, but qemu now has [at least] 3 different sets of low-level pixel conversion routines (vga, tcx and pl110). If you're feeling really enthusiastic it would be nice if they could be unified :-) It's one of the things I've been meaning to look at when I've nothing better to do, but haven't got round to yet.. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Just curious... Are you using an OpenGL directdraw surface for the graphics emulation in Qemu? If not, then consider the benefits: 1. It is much faster than any native graphics 2D/3D primitives like Windows GDI 2: It gives full control over things like window or fullscreen mode in any (almost) resolution and color depth. 3. It is operating system independent. 4. It handles things like RGB, BGR, 24bit, 15bit, 16bit, 8bit, alpha channel etc in hardware, all you have to do is select the pixelformat you like to use for the buffer and OpenGL does the rest - lightning fast, minimum CPU-load. My suggestion would be to write a frontend similar to VMware's for Qemu in Lazarus. Why Lazarus? 1. The fantastic GLscene is available for Lazarus making OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/ 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and directly compileable for most operating systems without need for modifications. Hope someone likes the idea, otherwise I will have to do it myself if I can find some spare time. Dan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PATCH: Solaris/Sparc patch against yesterdays' BGR CVS update
Fabrice Bellard [EMAIL PROTECTED] wrote:
In order to stop the release of incomplete BGR patches, I am
implementing a more complete patch. I am just adding depth = 32 with BGR
instead of RGB. If other pixel formats are wanted, you should signal it now.
Fabrice - nice job. The patch works fine. I munged something up when
I was redoing my patches for Solaris sparc so I mistakenly reported a
problem with the patch. I redid them and figured out what I did wrong,
and have validated DSL and Win98SE.
I'm still seeing color munging when using vnc and this patch, but I did
not expect this patch to fix that problem.
Enclosed is the latest version of the qemu solaris/sparc patch, applied
against yesterday's CVS (post BGR update).
Bendiff -ruN qemu-presol-sparc/Makefile qemu/Makefile
--- qemu-presol-sparc/Makefile 2006-04-30 19:54:18.0 -0400
+++ qemu/Makefile 2006-05-11 08:39:01.93155 -0400
@@ -4,6 +4,9 @@
ifdef CONFIG_DARWIN
CFLAGS+= -mdynamic-no-pic
endif
+ifeq ($(ARCH),sparc)
+CFLAGS+=-mcpu=ultrasparc
+endif
LDFLAGS=-g
LIBS=
DEFINES+=-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
diff -ruN qemu-presol-sparc/Makefile.target qemu/Makefile.target
--- qemu-presol-sparc/Makefile.target 2006-05-03 18:02:44.0 -0400
+++ qemu/Makefile.target 2006-05-11 08:39:06.248166000 -0400
@@ -102,6 +102,11 @@
endif
ifeq ($(ARCH),sparc)
+ifeq ($(CONFIG_SOLARIS),yes)
+CFLAGS+=-mcpu=ultrasparc -m32 -ffixed-g2 -ffixed-g3
+LDFLAGS+=-m32
+OP_CFLAGS=$(CFLAGS) -fno-delayed-branch -fno-omit-frame-pointer -ffixed-i0
+else
CFLAGS+=-m32 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6
LDFLAGS+=-m32
OP_CFLAGS=$(CFLAGS) -fno-delayed-branch -ffixed-i0
@@ -109,6 +114,7 @@
# -static is used to avoid g1/g3 usage by the dynamic linker
LDFLAGS+=-Wl,-T,$(SRC_PATH)/sparc.ld -static
endif
+endif
ifeq ($(ARCH),sparc64)
CFLAGS+=-m64 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6
diff -ruN qemu-presol-sparc/cpu-exec.c qemu/cpu-exec.c
--- qemu-presol-sparc/cpu-exec.c 2006-04-27 17:05:14.0 -0400
+++ qemu/cpu-exec.c 2006-05-11 08:39:41.49382 -0400
@@ -253,7 +253,7 @@
uint32_t *saved_regwptr;
#endif
#endif
-#ifdef __sparc__
+#if defined(__sparc__) !defined(HOST_SOLARIS)
int saved_i7, tmp_T0;
#endif
int ret, interrupt_request;
@@ -323,7 +323,7 @@
#if defined(reg_T2)
saved_T2 = T2;
#endif
-#ifdef __sparc__
+#if defined(__sparc__) !defined(HOST_SOLARIS)
/* we also save i7 because longjmp may not restore it */
asm volatile (mov %%i7, %0 : =r (saved_i7));
#endif
@@ -447,7 +447,7 @@
T0 = 0; /* force lookup of first TB */
for(;;) {
-#ifdef __sparc__
+#if defined(__sparc__) !defined(HOST_SOLARIS)
/* g1 can be modified by some libc? functions */
tmp_T0 = T0;
#endif
@@ -467,7 +467,7 @@
do_interrupt(intno, 0, 0, 0, 1);
/* ensure that no TB jump will be modified as
the program flow was changed */
-#ifdef __sparc__
+#if defined(__sparc__) !defined(HOST_SOLARIS)
tmp_T0 = 0;
#else
T0 = 0;
@@ -486,7 +486,7 @@
env-error_code = 0;
do_interrupt(env);
env-interrupt_request = ~CPU_INTERRUPT_HARD;
-#ifdef __sparc__
+#if defined(__sparc__) !defined(HOST_SOLARIS)
tmp_T0 = 0;
#else
T0 = 0;
@@ -497,7 +497,7 @@
env-error_code = 0;
do_interrupt(env);
env-interrupt_request = ~CPU_INTERRUPT_TIMER;
-#ifdef __sparc__
+#if defined(__sparc__) !defined(HOST_SOLARIS)
tmp_T0 = 0;
#else
T0 = 0;
@@ -516,7 +516,7 @@
env-error_code = 0;
do_interrupt(env);
env-interrupt_request = ~CPU_INTERRUPT_HARD;
-#ifdef __sparc__
+#if defined(__sparc__) !defined(HOST_SOLARIS)
tmp_T0 = 0;
#else
T0 = 0;
@@ -534,7 +534,7 @@
env-interrupt_request = ~CPU_INTERRUPT_HARD;
do_interrupt(env-interrupt_index);
env-interrupt_index = 0;
-#ifdef __sparc__
+#if defined(__sparc__) !defined(HOST_SOLARIS)
tmp_T0 = 0;
#else
T0 = 0;
@@ -565,7 +565,7 @@
env-interrupt_request = ~CPU_INTERRUPT_EXITTB;
/* ensure that no TB jump will be modified as
the program flow was changed */
-#ifdef __sparc__
+#if defined(__sparc__) !defined(HOST_SOLARIS)
tmp_T0 = 0;
#else
T0 = 0;
@@ -633,7 +633,7 @@
lookup_symbol(tb-pc));
}
#endif
-#ifdef __sparc__
+#if defined(__sparc__) !defined(HOST_SOLARIS)
Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
Am Donnerstag, 11. Mai 2006 15:04 schrieb Dan Sandberg: Are you using an OpenGL directdraw surface for the graphics emulation in Qemu? Qemu is using SDL, as this is a very portable library/framework. I'm not sure, if SDL uses DirectX on Win32, but I'd rather think it does not. Of course one might want to check this and maybe have a look at the SDL mail lists, if DirectX was discussed there. My suggestion would be to write a frontend similar to VMware's for Qemu in Lazarus. Why Lazarus? 1. The fantastic GLscene is available for Lazarus making OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/ 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and directly compileable for most operating systems without need for modifications. There already are a few projects for external qemu GUIs, but for an internal GUI it would have to be done in SDL, too, as to not introduce further dependencies. Please keep in mind that qemu is ported to many platforms and therefor the code would have to be very portable anyways. If you're keen on doing a GUI in Lazarus, feel free to do so, but have a look at the ml archive and some existing GUIs first. With regards, Jan Simons ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
Dan Sandberg wrote: Paul Brook wrote: On Wednesday 10 May 2006 23:05, Fabrice Bellard wrote: In order to stop the release of incomplete BGR patches, I am implementing a more complete patch. I am just adding depth = 32 with BGR instead of RGB. If other pixel formats are wanted, you should signal it now. I don't have any paticular favourite pixel formats, but qemu now has [at least] 3 different sets of low-level pixel conversion routines (vga, tcx and pl110). If you're feeling really enthusiastic it would be nice if they could be unified :-) It's one of the things I've been meaning to look at when I've nothing better to do, but haven't got round to yet.. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Hi, some comments on your suggestions: Just curious... Are you using an OpenGL directdraw surface for the graphics emulation in Qemu? If not, then consider the benefits: 1. It is much faster than any native graphics 2D/3D primitives like Windows GDI Not sure how much faster it is on Windows; currently Qemu uses plain SDL for drawing which probably uses DirectDraw under Windows. However, AFAIK under Linux SDL is not hardware accelerated in most cases, while OpenGL could give hardware acceleration. 2: It gives full control over things like window or fullscreen mode in any (almost) resolution and color depth. AFAIK the windowing/fullscreen stuff is not done by OpenGL itself, but by some external library; SDL offers this functionality, GLUT is another possibility, and apparently the GlScene lib you mentioned does this as well. 3. It is operating system independent. 4. It handles things like RGB, BGR, 24bit, 15bit, 16bit, 8bit, alpha channel etc in hardware, all you have to do is select the pixelformat you like to use for the buffer and OpenGL does the rest - lightning fast, minimum CPU-load. Basically, that sounds like a good idea to me. My suggestion would be to write a frontend similar to VMware's for Qemu in Lazarus. Why Lazarus? 1. The fantastic GLscene is available for Lazarus making OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/ 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and directly compileable for most operating systems without need for modifications. Hope someone likes the idea, otherwise I will have to do it myself if I can find some spare time. Dan Before you start working on this, I have some suggestions as well: Is the drawing part really a performance bottleneck? And will this really be improved by changing the drawing functions, or wouldn't a better graphics card emulation give much more improvements? What does a profiler say about this? I seem to recall that in most cases, SDL doesn't slow down performance in Qemu. It might be interesting to see how much the new RGB-BGR conversions costs, though. Another thing that I think is important is that not all computers have OpenGL acceleration. And at least on Linux, software OpenGL rendering is quite slow, so a port to OpenGL would probably be a huge drawback for some people. If OpenGL is really worth the trouble, one could add OpenGL rendering so that people can still use the old way of drawing if no hardware acceleration is available. A GUI frontend would be quite nice, I think. So far several people have submitted (quite useful) patches for this, but nothing more has happened in that direction. Not sure what is required for a GUI that will be integrated into Qemu finally... Thanks, Oliver ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
On Thu, May 11, 2006 at 04:57:23PM +0200, Jan Marten Simons wrote: Am Donnerstag, 11. Mai 2006 15:04 schrieb Dan Sandberg: Are you using an OpenGL directdraw surface for the graphics emulation in Qemu? Qemu is using SDL, as this is a very portable library/framework. I'm not sure, if SDL uses DirectX on Win32, but I'd rather think it does not. Of course one might want to check this and maybe have a look at the SDL mail lists, if DirectX was discussed there. He is askinng about OpenGL, not DirectX. Dunno if it is the default, but iirc SDL supports OpenGL on Windows. My suggestion would be to write a frontend similar to VMware's for Qemu in Lazarus. Why Lazarus? 1. The fantastic GLscene is available for Lazarus making OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/ 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and directly compileable for most operating systems without need for modifications. SDL has support for OpenGL builtin, so qemu should be able to use that with only a few modifications. There already are a few projects for external qemu GUIs, but for an internal GUI it would have to be done in SDL, too, as to not introduce further dependencies. No one has tried to make an SDL Gui for qemu. SDL guis tend to be ugly in general. There is a well supported GUI for OS X called Q, and there are 2 versions of qemu that use a GTK GUI internally. Please keep in mind that qemu is ported to many platforms and therefor the code would have to be very portable anyways. Supporting something that runs (or can run) on top of X would catch most of the platforms that qemu runs on, the only ones I can think of that would need their own stuff would be Windows and OS X (well OS X has an X server but users prefer a native GUI there). If you're keen on doing a GUI in Lazarus, feel free to do so, but have a look at the ml archive and some existing GUIs first. With regards, Jan Simons ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] -smb switch and national character support
With the default settings, using -smb switch causes the national characters in shared files' names to display incorrectly. I've put together a simple patch (attached for reference only) that addresses this issue. As this feature looks useful for me, I thought it would be nice to include such functionality in qemu. The idea is simple - using -smb-dos-charset and -smb-unix-charset switches to archieve the desired goal. Example usage: qemu -smb-dos-charset cp852 -smb-unix-charset iso8859-2 Also, another switch, named for example -smb-read-only, would be useful. As the number of options is growing, it might be better to introduce another form: -qemu-options dos-charset=cp852,read-only,... Or, making a more general approach: -smb directory[,options] As it is with -net and other switches. However, the charset settings should be put in the [global] section. We can introduce another switch or use a simple and nice hack: -smb global,charset=cp852,... Also, this form of -smb switch would allow to inject _any_ strings into the smb.conf file, making it far more flexible. As always, comments are welcome before I start to work on the code - I don't want to make a patch that would be rejected. Kosma diff -urp qemu-0.7.2/vl.c qemu-0.7.2-pl/vl.c --- qemu-0.7.2/vl.c 2005-09-04 19:11:31.0 +0200 +++ qemu-0.7.2-pl/vl.c 2006-01-17 00:08:50.0 +0100 @@ -1605,6 +1605,9 @@ void net_slirp_smb(const char *exported_ log file=%s/log.smbd\n smb passwd file=%s/smbpasswd\n security = share\n + dos charset=CP852\n + unix charset=ISO8859-2\n + display charset=ISO8859-2\n [qemu]\n path=%s\n read only=no\n ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
Dan Sandberg wrote: Just curious... Are you using an OpenGL directdraw surface for the graphics emulation in Qemu? If not, then consider the benefits: 1. It is much faster than any native graphics 2D/3D primitives like Windows GDI 2: It gives full control over things like window or fullscreen mode in any (almost) resolution and color depth. 3. It is operating system independent. 4. It handles things like RGB, BGR, 24bit, 15bit, 16bit, 8bit, alpha channel etc in hardware, all you have to do is select the pixelformat you like to use for the buffer and OpenGL does the rest - lightning fast, minimum CPU-load. My own feeling is that a smarter thing to do is to pass the VGA ops to another program to actually do the rendering. I think a GUI that used VNC to interact with QEmu would be a very good start. localhost VNC performance seems good enough to me that this should be a reasonable approach. Hardware scaling would, perhaps, be a useful feature of using OpenGL. Unfortunately, OpenGL is not available enough widely to make this practical in my mind. I'd rather devote the same effort to fast software scaling (via SIMD instructions). Regards, Anthony Liguori My suggestion would be to write a frontend similar to VMware's for Qemu in Lazarus. Why Lazarus? 1. The fantastic GLscene is available for Lazarus making OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/ 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and directly compileable for most operating systems without need for modifications. Hope someone likes the idea, otherwise I will have to do it myself if I can find some spare time. Dan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu-0.8.1 and Solaris-10
I was able to compile the qemu-cvs code with Taylor's patches applied. I did not see a qemu executable? Is it the same as qemu/aprc-softmmu/qemu-system-sparc? When I try to use it it keeps complaining that it can't load:: /usr/local/share/qemu/proll.elf: No such file or directory qemu: could not load prom '/usr/local/share/qemu/proll.bin' I know I have not installed it in /usr/local as I do not have the privileges but should this file be somewhere in the qemu/* (where it was compiled)? -ishwar ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw mips_r4k.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/05/11 21:15:08 Modified files: hw : mips_r4k.c Log message: mips bios loading fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/mips_r4k.c.diff?tr1=1.16tr2=1.17r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
Dan Sandberg wrote: Just curious... Are you using an OpenGL directdraw surface for the graphics emulation in Qemu? If not, then consider the benefits: 1. It is much faster than any native graphics 2D/3D primitives like Windows GDI 2: It gives full control over things like window or fullscreen mode in any (almost) resolution and color depth. 3. It is operating system independent. 4. It handles things like RGB, BGR, 24bit, 15bit, 16bit, 8bit, alpha channel etc in hardware, all you have to do is select the pixelformat you like to use for the buffer and OpenGL does the rest - lightning fast, minimum CPU-load. [...] I am not sure the bottleneck is in the rendering itself and the single primitive that QEMU uses (display a rectangle of bitmap) is accelerated by every graphic card since many years. But you are free to modify the SDL library to include OpenGL rendering if it is not already done :-) Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu/hw mips_r4k.c
Fabrice Bellard wrote: CVSROOT: /sources/qemu Module name: qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/05/11 21:15:08 Modified files: hw : mips_r4k.c Log message: mips bios loading fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/mips_r4k.c.diff?tr1=1.16tr2=1.17r1=textr2=text Why is this correct? I would have expected moving parts of the initialisation in front of the file loads would be the right fix. (Those parts which aren't supposed to be done by the BIOS.) Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw vga_template.h
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/05/11 21:54:44 Modified files: hw : vga_template.h Log message: BGR_FORMAT fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/vga_template.h.diff?tr1=1.12tr2=1.13r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] patch for ne2000.c
OK for (2).
For (1) It would be good to find the exact behaviour of the NE2000 card.
Maybe ENISR_RX remain set as long are there are packets in the buffer ?
Otherwise your fix is a workaround to correct a bug in the OS driver...
Fabrice.
Han, Zhu wrote:
Any comments for this patch?
Best Regards,
hanzhu
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Han, Zhu
Sent: 2006年5月9日 12:27
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] patch for ne2000.c
Hi, All!
I'm a developer working on xen project! It's well known that xen has
adopted a lot of codes and features from QEMU, especially the Device
Mode Part!
I fix a bug for ne2000 device emulation code in XEN and I expect it to
be a potential bug for QEMU, either! Because you are all device mode
experts, I submit this patch to you at first in order to ask you to
review my patch.
Several notes:
1) Because XEN use event driven mechanism in the main_loop(), irq may be
missed due to the rather high speed and large file! For example, the
ne2000_receive will filled up with the buffer and set up the ENISR_RX
signal, however, the driver could ack and clear the ENISR_RX signal due
to it could only handle a certain amount of packets once in it's
interrupt handling routine! The consequence for this specific steps is
the netcard buffer is full but it never resend the ENISR_RX signal, at
the last, the netcard will be halted! This problem could be rather rare
for QEMU. Anyway, it's a potential bug.
2) Many of the ne2000 spec said we should set boundary register should
be set to indicate the last receive buffer page the host has read, and
the driver in linux follows this guideline. So, we boundary == index,
the buffer for the netcard is full and we can't write any packets into
this buffer. This minor fix could prevent the ne2000 emulated card from
overflow and destroying the previous received packet page! This problem
could also be rare for QEMU since it could happen only under extreme
circumstance!
Any feedbacks and comments will be appreciated!
--- qemu-snapshot-2006-05-07_23\hw\ne2000.c Mon May 08 16:13:49 2006
+++ ./ne2000.cMon May 08 16:57:33 2006
@@ -159,9 +159,19 @@
}
}
+static int ne2000_buffer_full(NE2000State *s);
static void ne2000_update_irq(NE2000State *s)
{
int isr;
+
+if(ne2000_buffer_full(s)
+ !(s-isr ENISR_RX)){
+ /* The freeing space is not enough, tell the ne2k driver
+ * to fetch these packets!
+ */
+s-isr |= ENISR_RX;
+}
+
isr = (s-isr s-imr) 0x7f;
#if defined(DEBUG_NE2000)
printf(NE2000: Set IRQ line %d to %d (%02x %02x)\n,
@@ -206,7 +216,10 @@
index = s-curpag 8;
boundary = s-boundary 8;
-if (index boundary)
+if (index = boundary)
+ /* when index == boundary, we should assume
+ * the buffer is full instead of empty!
+ */
avail = boundary - index;
else
avail = (s-stop - s-start) - (index - boundary);
Best Regards,
hanzhu
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu/hw mips_r4k.c
Thiemo Seufer wrote: Fabrice Bellard wrote: CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/05/11 21:15:08 Modified files: hw : mips_r4k.c Log message: mips bios loading fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/mips_r4k.c.diff?tr1=1.16tr2=1.17r1=textr2=text Why is this correct? I would have expected moving parts of the initialisation in front of the file loads would be the right fix. (Those parts which aren't supposed to be done by the BIOS.) The bug I fixed was that the BIOS could not be used without specifying -kernel x. Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] [PATCH]Fix for minor video corruption under Windows
Fabrice- Well, I've been assuming that the Windows driver doesn't call the BIOS to do a video mode switch (that seems like a silly thing to do and without sources I hate having to guess at things) but this is Windows so I guess it's possible. If you've got a BIOS patch I'd love to try it out when you're ready. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale [EMAIL PROTECTED] Ph: (303)440-1368 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Fabrice Bellard Sent: Thursday, May 11, 2006 4:48 PM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] [PATCH]Fix for minor video corruption under Windows Hi, I think the proper fix must be done in the BIOS (set VRAM to 0xFF at cirrus mode init). I made a patch for that but I must test it a little more. Fabrice. Dugger, Donald D wrote: Leo- Yeah, I started there but it turns out there are multiple reasons why that is the wrong place to fix things: 1) `hw/vga.c' only knows about resolution changes, the bug also appears if you change the pixel size, e.g. 24 bpp to 16 bpp. 2) Technically, because of the lazy screen update, your change would be too late. To improve performance the vga code is only called periodically, not after every VRAM change. It is theoretically possible for the target to change video mode, assume VRAM got reset, do a bitblt from non-visible VRAM to visible VRAM and then have the `hw/vga.c' code get called, overwriting the changes done to visible VRAM. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale [EMAIL PROTECTED] Ph: (303)440-1368 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Leonardo E. Reiter Sent: Tuesday, May 09, 2006 2:29 PM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] [PATCH]Fix for minor video corruption under Windows Donald... thanks... I actually posted a patch to fix this sometime ago, but your patch seems more thorough and probably more correct. Just FYI, I attached my patch again. I will test your patch as well. Thanks again, Leo Reiter Donald D. Dugger wrote: If you change the video resolution while running a Windows XP image such that it uses fewer bytes of VRAM (either by using fewer bytes per pixel or by lowering the resolution) then some window backgrounds will become corrupted. This happens because the Windows XP Cirrus Logic driver assumes that VRAM is initialized to 0xff whenever the video mode switches between VGA and SVGA. This patch fixes this problem by resetting VRAM whenever a VGA/SVGA mode switch occurs. Signed-off-by: [EMAIL PROTECTED] -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing that means Business Main: +1 512 339 7979 Fax: +1 512 532 6501 http://www.win4lin.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
On Fri, May 05, 2006 at 09:06:20AM -0500, Anthony Liguori wrote: Ben Taylor wrote: I'm seeing quite a few bugs on Qemu 0.8.1 with the vnc feature 1) Sparc based system comes up in distored colors (foreground of a Damn Small linux iso comes up in yellow, instead of white) This is a know problem. qemu doesn't give any indication that the guest is storing pixels in big endian mode. A proper fix is on my TODO list. 2) When it bounces from the initial syslinux text to the grahpical screen, it leaves the text in the top left corner not cleared. (to the boot: at the bottom) Yeah, I've noticed something similar myself. It's on the TODO list (see vnc.c). 3) screen autoresize is not working. 2 examples with DSL. a) initial screen is 80x25, but qemu comes up in 80x24 and stays there and I can't see boot: prompt at the bottom. b) when it goes into graphical mode, it's not resizing so I'm missing some portion of the screen TightVNC doesn't support the desktop resize encoding. Try RealVNC. I am running the current CVS code and seeing endian color problems with a x86 machine running qemu and a PPC linux machine running xrealvncviewer. This is the debian xvncviewer package version 3.3.7-7. Also, how does one get to the qemu console with the vnc? The vnc server also seems to occasionally send invalid vnc packets, and the screen resize does not seem to work. Included is a log of starting up and exiting because a bad message.. The bad message problem occurs with Chicken of the VNC on MacOS X as well. VNC viewer version 3.3.7 - built Sep 25 2004 21:02:46 Copyright (C) 2002-2003 RealVNC Ltd. Copyright (C) 1994-2000 ATT Laboratories Cambridge. See http://www.realvnc.com for information on VNC. VNC server supports protocol version 3.3 (viewer 3.3) No authentication needed Desktop name QEMU Connected to VNC server, using protocol version 3.3 VNC server default format: 32 bits per pixel. Least significant byte first in each pixel. True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0 Using default colormap and visual, TrueColor, depth 24. Got 256 exact BGR233 colours out of 256 Using BGR233 pixel format: 8 bits per pixel. True colour: max red 7 green 7 blue 3, shift red 0 green 3 blue 6 Throughput 2 kbit/s - changing to Hextile Throughput 2 kbit/s - changing from 8bit Using viewer's native pixel format: 32 bits per pixel. Most significant byte first in each pixel. True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0 Rect too large: 69x1 at (705, 577) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
