[Qemu-devel] Unified device model
Hi I have been following the discussion about some more dynamic way to configure and define a simulation set-up for Qemu. If You want to attract others than hard core developers, I think that an unified device model is something to aim for. With a generic device model I think you open up a sea of possibilities for Qemu. There are for sure conflicting interests among the users (and potential users) of Qemu (not to talk about the developers), ranging from those who are satisfied with a monolith acting as some well defined machine, to those that want to runt different configurations on every launch. Take beyond that,there might as well be a need for some users to test configurations that is unimaginable be the developers, as well as running a network of interconnected machines in a deterministic way. But I hope that there is a common denominator that all can agree on, some minimal changes that are required to satisfy a larger community of both users and developers. I acknowledge that fact that Fabrice calls the shots, but I only want to emphasize a few points that I think are required to be solved for Qemu to really lift off. What is the smallest set of requirements on a device model that Qemu developers can embrace? Few questions comes to my mind * Is it a framework that requires the models to be open source, or is a truly dynamic one with DLL files with well defined interfaces something to strive for? I strongly believe that a dynamic model is a prerequisite to enable sharing of devices, open source or not. * Scripting languages, what about those? Can we agree upon some language to use for configurations definitions, like Haskel, M, Tcl, XML or elisp? A scripting language makes it fairly easy for an inexperienced user to create and alters configurations, those configurations can also describe well defined state for a machine. Think, in terms of not booting windowz every time you need it for some obscure task. * What about interface definition languages (IDL)? By using an IDL it is possible to auto generate proxies for different requirements, like wrappers for devices developed for Bochs, Mame and so on, as well as remove the not so important important part on how to interconnect components (the technical aspects). * All this comes with a performance penalty, is that acceptable? As soon as you add any kind of dynamic device model, you more or less have to remove all global variables and most of the global functions. Fellow developers, what do you say? And most importantly, what do You, Fabrice say, is the above something that Qemu can evolve into? BR Pete ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] SPARC iommu mapping
Then I tried to track down this problem with gdb and strace. But unfortunately, both are segfaulting, too. This makes debugging somewhat harder... Now, I'll try to analyze the core files of the crashing programs to get an idea what's going wrong. Or do you have any idea? What's the difference between bash compared to other shells? I don't know, I noticed the same problem earlier. I think it's something related to fork or clone. There is some problem with CDROM access, the files on CD look corrupt, whereas the same image used as hdb works perfectly. Strange. I started qemu with -cdrom /dev/cdrom and could see all contents without a problem. What exactly did you try? This command fails when installing kernel and modules: qemu-system-sparc -kernel vmlinux-2.6.11+tcx -cdrom debian-30r4-sparc-binary-1.iso -hda hd -initrd debian-30r4-sparc.initrd -nographic -append 'cdrom ramdisk_size=16384 devfs=mount rw root=/dev/rd/0' There was a problem installing the Drivers from /instmnt/dists/woody/main/disks-sparc/current/sun4cdm/drivers.tgz and some errors in background. Replace -cdrom with -hdb and the installer has no problems until installing libc6. OK, have a look at the attached patch. Much better, though a few spaces are still missing. _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] gdbstub.c fix for SIGINT
Attached is a patch to add the case for interrupting the gdbstub and
sending the correct signal to gdb.
The gdb serial protocol states that if you interrupt the stub with a
control-c in gdb that it should stop with S02 (SIGINT) to indicate
that it was interrupted. I also added the tlb flush so that
breakpoints can be written in correctly. I found that if I ran a
pentium qemu instance and broke in with gdb and planted a breakpoint at
do_fork() that it was not immediately hit due to the lack of the
flush. With the patch, it reliably stops all the time now when a
breakpoint is planted after interrupting the stub.
Thanks,
Jason.
Index: Changelog
===
RCS file: /sources/qemu/qemu/Changelog,v
retrieving revision 1.111
diff -u -r1.111 Changelog
--- Changelog 12 Apr 2006 21:09:31 - 1.111
+++ Changelog 17 Apr 2006 13:05:57 -
@@ -2,6 +2,7 @@
- USB tablet support (Brad Campbell, Anthony Liguori)
- win32 host serial support (Kazu)
+ - Fix SIGINT handler for gdbstub
version 0.8.0:
Index: gdbstub.c
===
RCS file: /sources/qemu/qemu/gdbstub.c,v
retrieving revision 1.34
diff -u -r1.34 gdbstub.c
--- gdbstub.c 5 Dec 2005 19:55:19 - 1.34
+++ gdbstub.c 17 Apr 2006 13:05:57 -
@@ -654,6 +654,9 @@
if (reason == EXCP_DEBUG) {
tb_flush(s-env);
ret = SIGTRAP;
+} else if (reason == EXCP_INTERRUPT) {
+tb_flush(s-env);
+ret = SIGINT;
}
else
ret = 0;
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu Makefile Makefile.target configure
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook [EMAIL PROTECTED] 06/04/17 13:57:12 Modified files: . : Makefile Makefile.target configure Log message: Allow user to specify install utility. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.diff?tr1=1.95tr2=1.96r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.target.diff?tr1=1.96tr2=1.97r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/configure.diff?tr1=1.91tr2=1.92r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] enh req: Allow ATAPI CD-ROM to be attached other than sec/master
Jim,
thanks for the patch, it seems to work great. However, I'm attaching an
updated version that fixes the following [minor] problems:
1. qemu was not correctly aborting [with help] if no arguments/disk
images were specified
2. using the method qemu [options] disk-image no longer worked...
you had to specify -hda explicitly.
1 and 2 are fixed in this patch that I attached. It's also diff'ed
against today's CVS, so it applies without fuzz or hunks.
Like I said, these fixes are minor more than anything else - otherwise
the patch works great for me so far. I've been able to do a Windows XP
install with 2 CDROM images attached. That's the extent of my testing
so far, but I don't see any reason why there would be any problems
otherwise.
Regards,
Leo Reiter
Jim C. Brown wrote:
On Fri, Apr 14, 2006 at 02:41:12PM -0400, Jim C. Brown wrote:
Attached is a patch that does just that.
The default -cdrom still works, but you can also use -cdrom-a, -cdrom-b,
-cdrom-c, and -cdrom-d to specify if the cdrom should be plugged in place over
hda, hdb, hdc, or hdd respectively.
Also includes a few tests to make sure you don't clobber a hard disk with a
cdrom, or use the same -hdX or -cdrom-X option multiple times.
--
Leonardo E. Reiter
Vice President of Product Development, CTO
Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com
Index: vl.c
===
RCS file: /cvsroot/qemu/qemu/vl.c,v
retrieving revision 1.171
diff -a -u -r1.171 vl.c
--- vl.c16 Apr 2006 11:06:58 - 1.171
+++ vl.c17 Apr 2006 16:22:45 -
@@ -4572,6 +4572,7 @@
-hda/-hdb file use 'file' as IDE hard disk 0/1 image\n
-hdc/-hdd file use 'file' as IDE hard disk 2/3 image\n
-cdrom file use 'file' as IDE cdrom image (cdrom is ide1
master)\n
+ -cdrom-[n] file use 'file' as IDE cdrom image (n is a, b, c, or
d)\n
-boot [a|c|d] boot on floppy (a), hard disk (c) or CD-ROM (d)\n
-snapshot write to temporary files instead of disk image
files\n
-m megs set virtual RAM size to megs MB [default=%d]\n
@@ -4700,6 +4701,10 @@
QEMU_OPTION_hdc,
QEMU_OPTION_hdd,
QEMU_OPTION_cdrom,
+QEMU_OPTION_cdrom_a,
+QEMU_OPTION_cdrom_b,
+QEMU_OPTION_cdrom_c,
+QEMU_OPTION_cdrom_d,
QEMU_OPTION_boot,
QEMU_OPTION_snapshot,
QEMU_OPTION_m,
@@ -4761,6 +4766,10 @@
{ hdc, HAS_ARG, QEMU_OPTION_hdc },
{ hdd, HAS_ARG, QEMU_OPTION_hdd },
{ cdrom, HAS_ARG, QEMU_OPTION_cdrom },
+{ cdrom-a, HAS_ARG, QEMU_OPTION_cdrom_a },
+{ cdrom-b, HAS_ARG, QEMU_OPTION_cdrom_b },
+{ cdrom-c, HAS_ARG, QEMU_OPTION_cdrom_c },
+{ cdrom-d, HAS_ARG, QEMU_OPTION_cdrom_d },
{ boot, HAS_ARG, QEMU_OPTION_boot },
{ snapshot, 0, QEMU_OPTION_snapshot },
{ m, HAS_ARG, QEMU_OPTION_m },
@@ -5004,6 +5013,7 @@
int snapshot, linux_boot;
const char *initrd_filename;
const char *hd_filename[MAX_DISKS], *fd_filename[MAX_FD];
+int hd_is_cdrom[MAX_DISKS];
const char *kernel_filename, *kernel_cmdline;
DisplayState *ds = display_state;
int cyls, heads, secs, translation;
@@ -5034,7 +5044,10 @@
for(i = 0; i MAX_FD; i++)
fd_filename[i] = NULL;
for(i = 0; i MAX_DISKS; i++)
+{
hd_filename[i] = NULL;
+hd_is_cdrom[i] = 0;
+}
ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
vga_ram_size = VGA_RAM_SIZE;
bios_size = BIOS_SIZE;
@@ -5046,11 +5059,7 @@
nographic = 0;
kernel_filename = NULL;
kernel_cmdline = ;
-#ifdef TARGET_PPC
-cdrom_index = 1;
-#else
-cdrom_index = 2;
-#endif
+cdrom_index = -1; //disable by default
cyls = heads = secs = 0;
translation = BIOS_ATA_TRANSLATION_AUTO;
pstrcpy(monitor_device, sizeof(monitor_device), vc);
@@ -5129,9 +5138,12 @@
{
int hd_index;
hd_index = popt-index - QEMU_OPTION_hda;
+if (hd_filename[hd_index] != NULL) {
+fprintf(stderr, qemu: can't share multiple disks\n);
+exit(1);
+}
hd_filename[hd_index] = optarg;
-if (hd_index == cdrom_index)
-cdrom_index = -1;
+hd_is_cdrom[hd_index] = 0;
}
break;
case QEMU_OPTION_snapshot:
@@ -5185,9 +5197,26 @@
kernel_cmdline = optarg;
break;
case QEMU_OPTION_cdrom:
-if (cdrom_index = 0) {
-hd_filename[cdrom_index] = optarg;
+case QEMU_OPTION_cdrom_a:
+case QEMU_OPTION_cdrom_b:
+case QEMU_OPTION_cdrom_c:
+case QEMU_OPTION_cdrom_d:
+ if (popt-index ==
Re: [Qemu-devel] enh req: Allow ATAPI CD-ROM to be attached other than sec/master
Sorry, I should add that my patch also adds a simple help line for the new options. Again, minor stuff ;) Regards, Leo Reiter Leonardo E. Reiter wrote: Jim, thanks for the patch, it seems to work great. However, I'm attaching an updated version that fixes the following [minor] problems: 1. qemu was not correctly aborting [with help] if no arguments/disk images were specified 2. using the method qemu [options] disk-image no longer worked... you had to specify -hda explicitly. 1 and 2 are fixed in this patch that I attached. It's also diff'ed against today's CVS, so it applies without fuzz or hunks. -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing from Desktop to Data Center 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] Reactos SVN + Kqemu fails
Reactos 0.3.0 SVN + kqemu fails as guest O.S. It fails in both systems, Linux host and Windows Host. Without kqemu the reactos 0.3.0 SVN runs with less bugs. In VMWARE host, this bug not apear. I Send a screenshot of failure. _ Dale rienda suelta a tu tiempo libre. Mil ideas para exprimir tu ocio con MSN Entretenimiento. http://entretenimiento.msn.es/ reactos.png Description: PNG image ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Reactos SVN + Kqemu fails
This bug has been around for a while. On 4/17/06, Víctor Córcoles López [EMAIL PROTECTED] wrote: Reactos 0.3.0 SVN + kqemu fails as guest O.S. It fails in both systems, Linux host and Windows Host. Without kqemu the reactos 0.3.0 SVN runs with less bugs. In VMWARE host, this bug not apear. I Send a screenshot of failure. _ Dale rienda suelta a tu tiempo libre. Mil ideas para exprimir tu ocio con MSN Entretenimiento. http://entretenimiento.msn.es/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- ReactOS is a hub, follow the spokes and you'll immediately find absolutely everything you need to know about Windows. ReactOS is not just software, it's people. kjk_hyperion ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Reactos SVN + Kqemu fails
I just made a fix for this problem and I will publish the corresponding new kqemu version ASAP. This fix also enables to launch plan9. Fabrice. Víctor Córcoles López wrote: Reactos 0.3.0 SVN + kqemu fails as guest O.S. It fails in both systems, Linux host and Windows Host. Without kqemu the reactos 0.3.0 SVN runs with less bugs. In VMWARE host, this bug not apear. I Send a screenshot of failure. _ Dale rienda suelta a tu tiempo libre. Mil ideas para exprimir tu ocio con MSN Entretenimiento. http://entretenimiento.msn.es/ ___ 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] Reactos SVN + Kqemu fails
On Mon, Apr 17, 2006 at 11:56:51PM +0200, Fabrice Bellard wrote: I just made a fix for this problem and I will publish the corresponding new kqemu version ASAP. This fix also enables to launch plan9. Did you also look at the linux 2.6.16.5 -kernel-kqemu problem I just posted about? Curious, :) Juergen ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
