[Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/06/28 07:28:22 Modified files: pc-bios: README openbios-sparc32 openbios-sparc64 Log message: Update Sparc32 and Sparc64 OpenBIOS image to SVN revision 157. Changes: r150: Try to fix system reset for SMP and SS-10 cases r151: Fix obp_dumb_memalloc r152: Fix mapping more than 2G memory r153: Get a real memory allocator for Sparc, based on PPC ofmem r154: Update totavail when memory is allocated by dumb memory allocator r155: Fix pop_fstr_copy memory leaks - console one prevented Debian 3.1r1 from installing in console=prom mode - fixing this also needed the real malloc/free r156: Hack for building on CIFS directory r157: Allow boot start PC to be different from virtual location (boot mode) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/README?cvsroot=qemur1=1.14r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc32?cvsroot=qemurev=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc64?cvsroot=qemurev=1.3
Re: [Qemu-devel] qemu vl.c
Hello, Am 25.06.2007 um 13:48 schrieb Thiemo Seufer: CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/25 11:48:07 Modified files: . : vl.c Log message: Enable serial (tty) support on Solaris host, by Marion Hakanson. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c? cvsroot=qemur1=1.313r2=1.314 Unfortunately this has introduced a regression on Mac OS X: qemu_chr_open_tty is being used although not defined. Andreas
Re: [Qemu-devel] qemu/target-mips op_helper.c
floatX_to_intY should already do the rounding according to the current rounding direction. Fabrice. Thiemo Seufer wrote: Fabrice Bellard wrote: IMHO, calling floatX_round_to_int before floatX_to_intY is not useful... I don't understand. floatX_round_to_int does round/ceil/floor but keeps the floating point representation. floatX_to_intY converts the adjusted value to integer representation. Doing this in two steps may have its own problems like spurious inexact signalling, but at least the calculated values appear to be correct. Thiemo
Re: [Qemu-devel] qemu vl.c
Am 25.06.2007 um 13:48 schrieb Thiemo Seufer: CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/25 11:48:07 Modified files: . : vl.c Log message: Enable serial (tty) support on Solaris host, by Marion Hakanson. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c? cvsroot=qemur1=1.313r2=1.314 Unfortunately this has introduced a regression on Mac OS X: qemu_chr_open_tty is being used although not defined. Attached is a possible patch. Andreas vl.c_tty.diff Description: Binary data
Re: [Qemu-devel] sparc guest
Am 27.06.2007 um 22:43 schrieb Blue Swirl: On 6/27/07, Nigel Horne [EMAIL PROTECTED] wrote: Thiemo Seufer wrote: Blue Swirl wrote: On 6/25/07, Thiemo Seufer [EMAIL PROTECTED] wrote: Nigel Horne wrote: Good news, sparc emulation with -nographic no longer core dumps. The bad news, networking still fails: FYI, I see a transmit error for ne2k_isa on mips r4k. Maybe that's related. On my test cases the network is still fine. What was the setup again? What I see is apparently not triggered by a change in Qemu. An older 2.6.16 kernel works with current Qemu, but 2.6.21 breaks networking. 2.6.16 and 2.6.21 are not involved here. My host is running 2.6.20, the guest is running 2.6.8. I just updated guest from Debian 3.1r1 to 4.0. After reboot net still works fine (4Mbytes/s), though the kernel is still 2.4.29. I tried installing a 2.6 series kernel but something went wrong with the ram disk creation. Host is 2.6.18. My guest is using 4.0's 2.6.18 and it does not work for me (host OS X v10.4.10). I also sometimes get this: ... Starting Hardware abstraction layer: hald floppy driver state --- now=4294959146 last interrupt=4294937998 diff=21148 last called handler=f0120824 timeout_message=lock fdc last output bytes: 13 80 4294937998 0 80 4294937998 1a 80 4294937998 0 80 4294937998 12 80 4294937998 0 80 4294937998 14 80 4294937998 18 80 4294937998 8 80 4294937998 12 80 4294958847 0 80 4294958847 13 80 4294958847 0 80 4294958847 1a 80 4294958847 0 80 4294958847 3 80 4294958847 c1 80 4294958847 11 80 4294958847 7 80 4294958847 0 80 4294958847 last result at 4294937998 last redo_fd_request at 4294958843 status=80 fdc_busy=1 do_floppy=f01205ac cont=f01dd0f8 current_req= command_status=-1 floppy0: floppy timeout called . Starting DHCP D-Bus daemon: dhcdbd. ... So maybe it's a more general problem with interrupt handling? Lance complains about timeouts, too, and so did DHCP during installation. Andreas
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
Hi, On Thu, 28 Jun 2007, Blue Swirl wrote: Update Sparc32 and Sparc64 OpenBIOS image to SVN revision 157. Since when is QEmu tracked with Subversion? Thanks, Dscho
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
On 6/28/07, Johannes Schindelin [EMAIL PROTECTED] wrote: Hi, On Thu, 28 Jun 2007, Blue Swirl wrote: Update Sparc32 and Sparc64 OpenBIOS image to SVN revision 157. Since when is QEmu tracked with Subversion? OpenBIOS SVN, not QEMU.
[Qemu-devel] qemu vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/28 14:05:38 Modified files: . : vl.c Log message: Fix segfault when printing the help text, spotted by Stefan Weil. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.314r2=1.315
[Qemu-devel] qemu/target-mips op_helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/28 14:07:06 Modified files: target-mips: op_helper.c Log message: Simplify round/ceil/floor implementation, spotted by Fabrice Bellard. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemur1=1.55r2=1.56
Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...
Hi, On Thu, 28 Jun 2007, Blue Swirl wrote: On 6/28/07, Johannes Schindelin [EMAIL PROTECTED] wrote: On Thu, 28 Jun 2007, Blue Swirl wrote: Update Sparc32 and Sparc64 OpenBIOS image to SVN revision 157. Since when is QEmu tracked with Subversion? OpenBIOS SVN, not QEMU. Ah, thanks. Ciao, Dscho
[Qemu-devel] [PATCH] ARM (Thumb) read from R15
Hi!
QEMU does not set the Thumb bit when reading from R15 in Thumb mode.
Here's the fix:
Index: target-arm/translate.c
===
RCS file: /sources/qemu/qemu/target-arm/translate.c,v
retrieving revision 1.53
diff -u -r1.53 translate.c
--- target-arm/translate.c 11 Jun 2007 18:59:35 - 1.53
+++ target-arm/translate.c 28 Jun 2007 14:29:15 -
@@ -307,7 +307,7 @@
if (reg == 15) {
/* normaly, since we updated PC, we need only to add one insn */
if (s-thumb)
-val = (long)s-pc + 2;
+val = (long)s-pc + 3;
else
val = (long)s-pc + 4;
gen_op_movl_TN_im[t](val);
CU
Uli
--
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
Re: [Qemu-devel] [PATCH] starting qemu vnc session on a pre-allocated port
Gilad Ben-Yossef wrote: It also implies that the daemon will be running for the entire lifetime of the VM. No. In fact, running an extra daemon for the entire life time of the VM is exactly what I'm trying to avoid (one of the things, anyway). Now I see why you think the unix domain socket option solves the problem already. Our use case is actully a little different. Let me explain: The machine running qemu has a web based interface to start VMs. A user asks for a new VM to start by browsing to a URL. The CGI implmenting that URL will start a new qemu instance, send to the user web browser an HTML page with a JAVA VNC viewer embedded and terminate. Passing an fd is still the wrong solution due to the problems with save/restore/migrate. It may be interesting to have something like -vnc tcp://0.0.0.0:5900-6000 to let QEMU try to find an unused port in the given range. Combined with -daemonize and having the monitor on a Unix socket, you could: 1) create a vm with qemu -vnc tcp://0.0.0.0:5900-6000 -monitor unix:/path/to/socket -daemonize 2) *wait* for qemu to finish running and daemonize properly 3) connect to /path/to/socket and issue a 'info vnc' command to discover which port it's actually using 4) render that port with your HTML. The nice thing about this is that it not only continues to work with save/restore/migrate, it's smart enough to allocate a new port to ensure that you always tend to succeed. Choosing :3 might be okay on machine A, but there's no guarantee that it's okay on machine B so you have to allow QEMU to try and find a new port after restore/migrate. I prefer this syntax over Xen's -vncunused since you can restrict the allocated ports to a particular region. Regards, Anthony Liguori Here is the problem: the HTML page needs to have the port number for the JAVA VNC viewer to connect to embedded in it. Of course, the CGI can pick a free port and ask qemu to start the VNC server on it, but it means CGI needs to maintain a list of free/used port ranges in some shared data structue, track the qemu instance to know when it is termianted and the port is free again and of course, hope that not non related proccess will snatch a port in the port range and generally duplicate the ifnormation the operating system already has on free/in use ports. In our suggested solution, our CGI simply opens a listening socket on an ethermal port, letting the OS do the allocation, hands the file descriptor to qemu to use and *terminates* (after sending the HTML page). No long running daemons. Having a daemon sit around just to shove the data from the Unix domain socket to the TCP socket and back and needing to track it and all really puts an ugly dent on the whole idea and, more important - I think what we are doing is a rather general concept, certainly not unique to us (just look at qemudo, only of course, they got it wrong... :-) Hope this explains things a little better. Since VM's are meant to run for very long periods of time, this is quite limiting. By utilizing a domain socket, you gain the ability to record on disk the state of the daemon and then restart. The layer of redirection also allows you to let your uses change the VNC server properties while the VM is running (so you change the listening vnc display from localhost:3 to :22 without restarting the VM). All the above are really nice to have, but nit with the cost of extra management overhead, as explained above. Also, our VM life time is typically 15 minutes long... :-) Plus, live migration has no hope of working if you're passing file descriptors on the command line as they're meaningless once you've migrated. That, I have no answer for. What do you do with the Unix domain socket? open it by path/filename on the new machines? Gilad
Re: [Qemu-devel] sparc guest
I found the problem, it wasn't related to Debian's 2.6 kernel after all, but pcnet just didn't work on a 32-bit host. I'm committing a fix. On 6/28/07, Andreas Färber [EMAIL PROTECTED] wrote: So maybe it's a more general problem with interrupt handling? Lance complains about timeouts, too, and so did DHCP during installation. I think floppy driver on Sparc Linux is broken.
[Qemu-devel] qemu/hw pcnet.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/06/28 15:28:18 Modified files: hw : pcnet.c Log message: Fix Lance on 32-bit hosts CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pcnet.c?cvsroot=qemur1=1.14r2=1.15
Re: [Qemu-devel] [PATCH] ARM (Thumb) read from R15
On Thursday 28 June 2007 16:31, Ulrich Hecht wrote: QEMU does not set the Thumb bit when reading from R15 in Thumb mode. Here's the fix: Maybe not; this seems to break some cases ... :( CU Uli -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
Re: [Qemu-devel] [PATCH] ARM (Thumb) read from R15
On Thursday 28 June 2007 17:30, Ulrich Hecht wrote:
On Thursday 28 June 2007 16:31, Ulrich Hecht wrote:
QEMU does not set the Thumb bit when reading from R15 in Thumb mode.
Here's the fix:
Maybe not; this seems to break some cases ... :(
This works in all my cases, although I am not sure if it is correct:
Index: target-arm/translate.c
===
RCS file: /sources/qemu/qemu/target-arm/translate.c,v
retrieving revision 1.53
diff -u -r1.53 translate.c
--- target-arm/translate.c 11 Jun 2007 18:59:35 - 1.53
+++ target-arm/translate.c 28 Jun 2007 15:48:59 -
@@ -307,7 +307,7 @@
if (reg == 15) {
/* normaly, since we updated PC, we need only to add one insn */
if (s-thumb)
-val = (long)s-pc + 2;
+val = (long)s-pc + 3;
else
val = (long)s-pc + 4;
gen_op_movl_TN_im[t](val);
@@ -3062,7 +3062,10 @@
gen_op_movl_T1_im(val);
gen_movl_reg_T1(s, 14);
}
-gen_movl_T0_reg(s, rm);
+if (rm == 15)
+ gen_op_movl_T0_im(s-pc + 2);
+else
+ gen_movl_T0_reg(s, rm);
gen_bx(s);
break;
}
CU
Uli
--
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
[Qemu-devel] Problem with triggering interrupts
Hello
I'm trying to implement the “system_powerdown” command for i386/x86_64.
After way too much time, I've now to hope for someone else being able to
help me, I just don't get it anymore. Due to the available
infrastructure, I decided to use an ACPI power button event. You can
find my current patches for qemu and the bochs BIOS below.
The code itself sets the interrupt, but unfortunately, it never reaches
the system inside qemu. For tests, I tried setting sci_level = 1, and
suddenly, it gets received and shuts down the system. Does anyone know
what I'm doing wrong here?
Thanks a lot,
Michael
---
diff -u -b -B -r1.254 vl.h
--- vl.h25 Jun 2007 10:57:10 - 1.254
+++ vl.h28 Jun 2007 19:56:45 -
@@ -136,11 +136,12 @@
void qemu_system_reset_request(void);
void qemu_system_shutdown_request(void);
void qemu_system_powerdown_request(void);
-#if !defined(TARGET_SPARC)
+#if defined(TARGET_I386) || defined(TARGET_X86_64) || \
+defined(TARGET_SPARC)
+void qemu_system_powerdown(void);
+#else
// Please implement a power failure function to signal the OS
#define qemu_system_powerdown() do{}while(0)
-#else
-void qemu_system_powerdown(void);
#endif
void main_loop_wait(int timeout);
Index: hw/acpi.c
===
RCS file: /sources/qemu/qemu/hw/acpi.c,v
retrieving revision 1.12
diff -u -b -B -r1.12 acpi.c
--- hw/acpi.c 28 May 2007 21:01:02 - 1.12
+++ hw/acpi.c 28 Jun 2007 19:56:45 -
@@ -98,6 +98,26 @@
}
}
+#if defined(TARGET_I386) || defined(TARGET_X86_64)
+static PIIX4PMState *powerdown_piix4 = NULL;
+
+void qemu_system_powerdown(void)
+{
+PIIX4PMState *s;
+
+if (powerdown_piix4 == NULL) {
+return;
+}
+
+s = powerdown_piix4;
+
+if (s-pmen PWRBTN_EN) {
+s-pmsts |= PWRBTN_EN;
+pm_update_sci(s);
+}
+}
+#endif
+
static void pm_tmr_timer(void *opaque)
{
PIIX4PMState *s = opaque;
@@ -495,5 +515,12 @@
register_savevm(piix4_pm, 0, 1, pm_save, pm_load, s);
s-smbus = i2c_init_bus();
+
+#if defined(TARGET_I386) || defined(TARGET_X86_64)
+if (powerdown_piix4 == NULL) {
+powerdown_piix4 = s;
+}
+#endif
+
return s-smbus;
}
diff -rpu bochs-20070617.orig/bios/rombios32.c bochs-20070617/bios/rombios32.c
--- bochs-20070617.orig/bios/rombios32.c2007-06-17 09:37:11.0
+0200
+++ bochs-20070617/bios/rombios32.c 2007-06-28 21:59:18.0 +0200
@@ -861,6 +861,11 @@ static void mptable_init(void)
int ioapic_id, i, len;
int mp_config_table_size;
+#ifdef BX_QEMU
+if (smp_cpus = 1)
+return;
+#endif
+
#ifdef BX_USE_EBDA_TABLES
mp_config_table = (uint8_t *)(ram_size - ACPI_DATA_SIZE -
MPTABLE_MAX_SIZE);
#else
@@ -1285,6 +1290,7 @@ void acpi_bios_init(void)
rsdp-checksum = acpi_checksum((void *)rsdp, 20);
/* RSDT */
+memset(rsdt, 0, sizeof(*rsdt));
rsdt-table_offset_entry[0] = cpu_to_le32(fadt_addr);
rsdt-table_offset_entry[1] = cpu_to_le32(madt_addr);
acpi_build_table_header((struct acpi_table_header *)rsdt,
@@ -1310,7 +1316,7 @@ void acpi_bios_init(void)
fadt-plvl3_lat = cpu_to_le16(50);
fadt-plvl3_lat = cpu_to_le16(50);
/* WBINVD + PROC_C1 + PWR_BUTTON + SLP_BUTTON + FIX_RTC */
-fadt-flags = cpu_to_le32((1 0) | (1 2) | (1 4) | (1 5) | (1
6));
+fadt-flags = cpu_to_le32((1 0) | (1 2) | (0 4) | (1 5) | (1
6));
acpi_build_table_header((struct acpi_table_header *)fadt, FACP,
sizeof(*fadt));
diff -rpu bochs-20070617.orig/bios/rombios.h bochs-20070617/bios/rombios.h
--- bochs-20070617.orig/bios/rombios.h 2007-02-20 10:36:55.0 +0100
+++ bochs-20070617/bios/rombios.h 2007-06-17 21:59:46.0 +0200
@@ -19,7 +19,7 @@
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
/* define it to include QEMU specific code */
-//#define BX_QEMU
+#define BX_QEMU
#ifndef LEGACY
# define BX_ROMBIOS32 1
Re: [Qemu-devel] sparc guest
Am 28.06.2007 um 17:26 schrieb Blue Swirl: I found the problem, it wasn't related to Debian's 2.6 kernel after all, but pcnet just didn't work on a 32-bit host. I'm committing a fix. Big thanks for fixing this! Works now. :-) Andreas
Re: [Qemu-devel] rtl8139 not working with VISTA 32bit
This is a tested step by step enable the network and audio under vista32 on Xen. 1. Download latest Vista driver for the RTL8139 series cards from the Realtek site. There is one dated 2007/4/26, version 6.103. I used this file. 2. Install the files, follow setup. If your Vista crashed, please go to the Save Mode and remove the network driver. 3. Copy C:\Program Files\Realtek\VISTA_8139\WINVISTA\NetrtOEM.inf to a folder called 'Temp' on your Vista desktop. 4. Find a Server 2003 machine, and copy C:\Windows\system32\drivers \rtl8139.sys (I Using ISO file under Linux) to the same Temp folder on your Vista desktop. 5. Rename rtl8139.sys to rtnicxp.sys 6. Open Device Manager, Click Update Driver. 7. Browse my computer for drive software 8. Let me pick from a list of drivers on my computer --- This is key. 9. Click Have Disk, and navigate to the NetrtOEM.inf in the temp folder on your desktop 10. If you get an error about the driver not being digitally signed, that's good, you are installing the right driver. 10. Now the network can work now. 11. After the network is enabled, update the audio driver using the method Searching automatically for the updated driver software. 2007/6/27, Adnan Misherfi [EMAIL PROTECTED]: I have posted/read other posts regarding rtl8139 in qemu not working with VISTA 32bit. Does any one know if there is a fix for this one? I have tried to debug this, but not sure what is VISTA 32bit driver is expecting. Qemu writes rx buffers to guest memory, but it looks like they are ignored by the guest rtl8139 driver. Any Ideas of what is going on? Regards Adnan
