[Qemu-devel] win2k, acpi usb
G'day all,
I just attempted a clean Win2k-SP4 install with CVS from today..
Just a couple of gotchas I noticed..
Windows has a couple of install stages the first of which is the old blue screen text mode
format/copy stage which will not work with -kernel-kqemu. So I boot and do that stage with no
-kernel-kqemu. When it asks me to reboot the computer I stop qemu and restart the process with
-kernel-kqemu and it chugs along nicely. (This one is a known issue, not a problem and I simply
included it for those joining us late)
1. Doing the install with -usb -usbdevice tablet had the win2k install getting stuck in the
hardware detection screen. (No problem, once I figured it out I just install without that option and
let it detect it later)
2. Windows would install, however during the first real boot it would blue screen and complain about
incomplete ACPI support required to run windows. (No problem, installed clean with -no-acpi and we
are good to go). Once it's installed with -no-acpi then you don't need to specify it again as
windows won't try and detect/use it anyway.
In addition, I've had to massage a version of the -no-tsc patch I found floating about, as my new
Pentium-M laptop has a 4 stage speedstep and the timer was going haywire using the tsc. (Patch
attached). What are the chances of getting something like this included sometime in the future. I
can't be the only person who runs this on a speedstep capable machine with broken tsc behaviour.
Brad
--
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. -- Douglas Adams
? qemu-notsc.patch
Index: vl.c
===
RCS file: /cvsroot/qemu/qemu/vl.c,v
retrieving revision 1.196
diff -u -r1.196 vl.c
--- vl.c 26 Jun 2006 21:00:51 - 1.196
+++ vl.c 28 Jun 2006 04:48:43 -
@@ -129,6 +129,10 @@
int vm_running;
int rtc_utc = 1;
int cirrus_vga_enabled = 1;
+#ifdef __i386__
+static int notsc = 0;
+extern int64_t get_clock(void);
+#endif
#ifdef TARGET_SPARC
int graphic_width = 1024;
int graphic_height = 768;
@@ -523,6 +527,9 @@
return ti.QuadPart;
#else
int64_t val;
+if (notsc) {
+ return get_clock()12;
+}
asm volatile (rdtsc : =A (val));
return val;
#endif
@@ -657,6 +664,7 @@
usec = get_clock() - usec;
ticks = cpu_get_real_ticks() - ticks;
ticks_per_sec = (ticks * 100LL + (usec 1)) / usec;
+//printf(ticks_per_sec=%lld\n,ticks_per_sec);
}
#endif /* !_WIN32 */
@@ -5142,6 +5150,9 @@
#ifdef USE_CODE_COPY
-no-code-copy disable code copy acceleration\n
#endif
+#ifdef __i386__
+ -no-tsc disable tsc as clock source\n
+#endif
#ifdef TARGET_I386
-std-vgasimulate a standard VGA card with VESA Bochs Extensions\n
(default is CL-GD5446 PCI VGA)\n
@@ -5208,6 +5219,7 @@
QEMU_OPTION_hdachs,
QEMU_OPTION_L,
QEMU_OPTION_no_code_copy,
+QEMU_OPTION_no_tsc,
QEMU_OPTION_k,
QEMU_OPTION_localtime,
QEMU_OPTION_cirrusvga,
@@ -5283,6 +5295,10 @@
{ no-kqemu, 0, QEMU_OPTION_no_kqemu },
{ kernel-kqemu, 0, QEMU_OPTION_kernel_kqemu },
#endif
+#ifdef __i386__
+{ no-tsc, 0, QEMU_OPTION_no_tsc },
+#endif
+
#if defined(TARGET_PPC) || defined(TARGET_SPARC)
{ g, 1, QEMU_OPTION_g },
#endif
@@ -5929,7 +5945,12 @@
case QEMU_OPTION_no_acpi:
acpi_enabled = 0;
break;
-}
+#ifdef __i386__
+case QEMU_OPTION_no_tsc:
+notsc = 1;
+break;
+#endif
+ }
}
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Simulated devices of Qemu?
Hi all, Qemu can simulate ARM processor with Integrator/CP board and the devices below: Two PL011 UARTs, SMC 91c111 Ethernet adapter 1. Generally, how Qemu simulates these devices? It means on Qemu's code or these devices will be simulated automaticly by "portable dynamic translation" mechanism of Qemu? 2. Is Qemu's window (when I execute it on Windows) the screen device simulated by Qemu or it's only the window application on Windows? 3. How Qemu simulates PL011 UART? 4. How I must do if I want to develop (add) a device simulated on Qemu Thanks. Tieu Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail Beta.___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Sparc64 host support update: i386-user builds
I got the i386-user to build by moving the troublesome SSE ops to helper (only for Sparc32/64, no effect at least to x86 host). The emulator crashes when executing the first TB, code generation and register use could be suspected. The patch makes ops_sse.h more confusing to read. Any comments? The remaining target specific problem with PPC FPU ops could be solved by changing PPC to soft float. Would that be OK? _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ sparc64_host.diff.bz2 Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] add serial port mux for debug monitor support
There are two patches attached to show the logical progress of the code
and in the case that one is not accepted the work is more easily broken
down.
The serial_mux_driver.patch must be applied first. It adds a generic
mux support for the I/O drivers internal to vl.c. The main purpose is
to use it for switching on the monitor. Basically it allows more than
one driver to register an fd_read and fd_can_read routine. Of course
the mux support is generic and could easily be used for other sorts of
I/O. This patch also adds the new options:
-echr ascii_value -- Allow you to use a different control character
other than Control-a
-serial mon:device_string -- Multiplex the device_string with the
monitor functionality
The second patch fully abstracts the monitor so that the monitor can be
used on more than one serial port at the same time as well as having a
separate dedicated monitor. I also removed the stdio splitting from the
stdio driver. The mux driver can be used to replace any functionality
that I missed.
signed-off-by: [EMAIL PROTECTED]
Jason.
Index: qemu/vl.c
===
--- qemu.orig/vl.c
+++ qemu/vl.c
@@ -1124,9 +1124,11 @@ void qemu_chr_add_read_handler(CharDrive
s-chr_add_read_handler(s, fd_can_read, fd_read, opaque);
}
-void qemu_chr_add_event_handler(CharDriverState *s, IOEventHandler *chr_event)
+void qemu_chr_add_event_handler(CharDriverState *s, IOEventHandler *chr_event,
+void *event_opaque)
{
s-chr_event = chr_event;
+s-event_opaque = event_opaque;
}
static int null_chr_write(CharDriverState *chr, const uint8_t *buf, int len)
@@ -1152,6 +1154,166 @@ CharDriverState *qemu_chr_open_null(void
return chr;
}
+#define MAX_MUX 2
+/* MUX driver for serial I/O splitting */
+typedef struct {
+IOCanRWHandler *fd_can_read[MAX_MUX];
+IOReadHandler *fd_read[MAX_MUX];
+void *ext_opaque[MAX_MUX];
+CharDriverState *drv;
+int idx;
+int mux_cnt;
+int term_got_escape;
+int max_size;
+} MuxDriver;
+
+
+static int mux_chr_write(CharDriverState *chr, const uint8_t *buf, int len)
+{
+MuxDriver *d = chr-opaque;
+len = d-drv-chr_write(d-drv, buf, len);
+return len;
+}
+
+static char *mux_help[] = {
+% hprint this help\n\r,
+% xexit emulator\n\r,
+% ssave disk data back to file (if -snapshot)\n\r,
+% bsend break (magic sysrq)\n\r,
+% cswitch between console and monitor\n\r,
+% % sends %\n\r,
+NULL
+};
+
+static int term_escape_char = 0x01; /* ctrl-a is used for escape */
+static void mux_print_help(CharDriverState *chr)
+{
+int i, j;
+char ebuf[15] = Escape-Char;
+char cbuf[50] = \n\r;
+
+if (term_escape_char 0 term_escape_char 26) {
+sprintf(cbuf,\n\r);
+sprintf(ebuf,C-%c, term_escape_char - 1 + 'a');
+} else {
+sprintf(cbuf,\n\rEscape-Char set to Ascii: 0x%02x\n\r\n\r,
term_escape_char);
+}
+chr-chr_write(chr, cbuf, strlen(cbuf));
+for (i = 0; mux_help[i] != NULL; i++) {
+for (j=0; mux_help[i][j] != '\0'; j++) {
+if (mux_help[i][j] == '%')
+chr-chr_write(chr, ebuf, strlen(ebuf));
+else
+chr-chr_write(chr, mux_help[i][j], 1);
+}
+}
+}
+
+static int mux_proc_byte(CharDriverState *chr, MuxDriver *d, int ch)
+{
+if (d-term_got_escape) {
+d-term_got_escape = 0;
+if (ch == term_escape_char)
+goto send_char;
+switch(ch) {
+case '?':
+case 'h':
+mux_print_help(chr);
+break;
+case 'x':
+exit(0);
+break;
+case 's':
+{
+int i;
+for (i = 0; i MAX_DISKS; i++) {
+if (bs_table[i])
+bdrv_commit(bs_table[i]);
+}
+}
+break;
+case 'b':
+if (chr-chr_event)
+chr-chr_event(chr-event_opaque, CHR_EVENT_BREAK);
+break;
+case 'c':
+/* Switch to the next registered device */
+d-idx++;
+if (d-idx = d-mux_cnt)
+d-idx = 0;
+break;
+}
+} else if (ch == term_escape_char) {
+d-term_got_escape = 1;
+} else {
+send_char:
+return 1;
+}
+return 0;
+}
+
+static int mux_chr_fd_can_read(void *opaque)
+{
+CharDriverState *chr = opaque;
+MuxDriver *d = chr-opaque;
+return d-fd_can_read[d-idx](d-ext_opaque[d-idx]);
+}
+
+static void mux_chr_fd_read(void *opaque, const uint8_t *buf, int size)
+{
+CharDriverState *chr = opaque;
+MuxDriver *d = chr-opaque;
+int i;
+for(i = 0; i size; i++)
+if (mux_proc_byte(chr, d, buf[i]))
+d-fd_read[d-idx](d-ext_opaque[d-idx], buf[i], 1);
+}
+
+static void
[Qemu-devel] qemu with kqemu freezes when more than one qemu is running
Hi, qemu-0.8.1_1 with kqemu-kmod-1.3.0.p9 on FreeBSD 6.1-RELEASE i386 freezes after less than one hour runtime when more than one qemu is running. If only one qemu is running everything works fine. When more than one qemu runs none of them can use kqemu without freezing after a short time. The frozen qemu can get killed only by a kill -9. The same happened with kqemu-kmod-1.3.0.p7. The processor is an AMD Athlon 64, but I use the i386 release of FreeBSD. The problem was also confirmed by somebody else: http://qemu.dad-answers.com/viewtopic.php?t=1726sid=66fb41f3f20e19862aed3ae2fbfe97e9 Please help me. -- Bye Frank ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw rtl8139.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 06/07/01 21:41:18 Modified files: hw : rtl8139.c Log message: disable unimplemented C+ mode (aka windows xp 64 fix) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/rtl8139.c?cvsroot=qemur1=1.1r2=1.2 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
Hi Luca, On Thu, 22 Jun 2006, Luca Barbato wrote: Fabrice Bellard wrote: Concerning the QEMU GUI, my mind slightly evolved since my last posts on the topic: I think that a wxWidgets GUI would be the best as it is reasonnably portable and because it uses the native GUIs. wx is nasty at best. I'd be interested to know why you dislike it. I actually find it very nice to code in wx, much easier than GTK or MFC or raw Win32 API. I do hope that Fabrice will not mind the wx GUI being written in C++, as I don't know Python, which seems to be the most popular scripting language binding for wx. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson at qwirx.com - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
