RE: [Qemu-devel] Bus number and address changes after usb_add?
On Thu, 2006-12-07 at 14:43 +0800, Yu, Xiaoyang wrote: > Thanks a lot! So we need to use "usb_del bus.addr" to remove the device from > the guest. So I must get the bus.addr information for the device first. But I > cannot do so by just add code into usb_device_add() function, because the > bus.addr will change after that. Is there a place in QEMU source code > suitable for logging the bus.addr information? The usb code could use some improvement in regards to tracking the devices internally in qemu. If you scan this list there was an attempt at adding devices to a tree for tracking them, but that code was seemingly rushed so it had numerous bugs. You can find the thread with the proposal here: http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00489.html ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] Bus number and address changes after usb_add?
Thanks a lot! So we need to use "usb_del bus.addr" to remove the device from the guest. So I must get the bus.addr information for the device first. But I cannot do so by just add code into usb_device_add() function, because the bus.addr will change after that. Is there a place in QEMU source code suitable for logging the bus.addr information? Thanks Xiaoyang -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lonnie Mendez Sent: 2006年12月7日 14:23 To: qemu-devel@nongnu.org Subject: RE: [Qemu-devel] Bus number and address changes after usb_add? On Thu, 2006-12-07 at 14:11 +0800, Yu, Xiaoyang wrote: > I see. Guest OS will assign the USB device an address later. Is it possible > to store this new address in host OS? Then when the USB device is unplugged, > host OS can send "usb_del" command to QEMU to automatically delete the device. It's possible (on linux host) to register a signal with the kernel that will trigger when the device is disconnected from the host system. From the signal handler the device can then be removed from the guest. See USBDEVFS_DISCSIGNAL ioctl in usbdevice_fs.h. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] Bus number and address changes after usb_add?
On Thu, 2006-12-07 at 14:11 +0800, Yu, Xiaoyang wrote: > I see. Guest OS will assign the USB device an address later. Is it possible > to store this new address in host OS? Then when the USB device is unplugged, > host OS can send "usb_del" command to QEMU to automatically delete the device. It's possible (on linux host) to register a signal with the kernel that will trigger when the device is disconnected from the host system. From the signal handler the device can then be removed from the guest. See USBDEVFS_DISCSIGNAL ioctl in usbdevice_fs.h. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] Bus number and address changes after usb_add?
I see. Guest OS will assign the USB device an address later. Is it possible to store this new address in host OS? Then when the USB device is unplugged, host OS can send "usb_del" command to QEMU to automatically delete the device. Thanks! Xiaoyang -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lonnie Mendez Sent: 2006年12月7日 12:25 To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] Bus number and address changes after usb_add? On Thu, 2006-12-07 at 12:18 +0800, Yu, Xiaoyang wrote: > After add a USB device by “usb_add”, I can view it by “info usb”. It > shows the bus number and address. > > > > As shown in vl.c, it seems that usb_info() is called when issue “info > usb”, and usb_device_add() is called when issue “usb_add”. > > > > But if I add call to usb_info() in the end of usb_device_add(), it > always show the bus number and address as “0.0”, which can be > different from the output of “usb_add”. > > So it seems like the bus number and address of a USB device changed > some time after “usb_add”. Does anyone know why it changes? Thanks in > advance! The address you see with the monitor command "info usb" is the address all usb devices start out with when connected to the guest. The guest os will later assign the device an address on bus 0 (the uhci controller on the i386 system target) after it does things like fetch the device descriptor, configuration, etc. iirc linux will first assign a device an address unlike windows which queries for the configuration information before an address is assigned. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Bus number and address changes after usb_add?
On Thu, 2006-12-07 at 12:18 +0800, Yu, Xiaoyang wrote: > After add a USB device by “usb_add”, I can view it by “info usb”. It > shows the bus number and address. > > > > As shown in vl.c, it seems that usb_info() is called when issue “info > usb”, and usb_device_add() is called when issue “usb_add”. > > > > But if I add call to usb_info() in the end of usb_device_add(), it > always show the bus number and address as “0.0”, which can be > different from the output of “usb_add”. > > So it seems like the bus number and address of a USB device changed > some time after “usb_add”. Does anyone know why it changes? Thanks in > advance! The address you see with the monitor command "info usb" is the address all usb devices start out with when connected to the guest. The guest os will later assign the device an address on bus 0 (the uhci controller on the i386 system target) after it does things like fetch the device descriptor, configuration, etc. iirc linux will first assign a device an address unlike windows which queries for the configuration information before an address is assigned. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Recall: Bus number and address changes after usb_add?
Yu, Xiaoyang would like to recall the message, "Bus number and address changes after usb_add?". ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Bus number and address changes after usb_add?
After add a USB device by "usb_add", I can view it by "info usb". It shows the bus number and address. As shown in vl.c, it seems that usb_info() is called when issue "info usb", and usb_device_add() is called when issue "usb_add". But if I add call to usb_info() in the end of usb_device_add(), it always show the bus number and address as "0.0", which can be different from the output of "info usb". So it seems like the bus number and address of a USB device changed some time after "usb_add". Does anyone know why it changes? Thanks in advance! Thanks Xiaoyang ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Bus number and address changes after usb_add?
After add a USB device by "usb_add", I can view it by "info usb". It shows the bus number and address. As shown in vl.c, it seems that usb_info() is called when issue "info usb", and usb_device_add() is called when issue "usb_add". But if I add call to usb_info() in the end of usb_device_add(), it always show the bus number and address as "0.0", which can be different from the output of "usb_add". So it seems like the bus number and address of a USB device changed some time after "usb_add". Does anyone know why it changes? Thanks in advance! Thanks Xiaoyang ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-mips translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 06/12/07 00:30:19 Modified files: target-mips: translate.c Log message: Simplify mask construction. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.23&r2=1.24 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add more devices to MIPS system emulation
Thiemo Seufer a écrit : > Aurelien Jarno wrote: > [snip] >> Index: hw/mips_r4k.c >> === >> RCS file: /sources/qemu/qemu/hw/mips_r4k.c,v >> retrieving revision 1.23 >> diff -u -d -p -r1.23 mips_r4k.c >> --- hw/mips_r4k.c6 Dec 2006 21:38:37 - 1.23 >> +++ hw/mips_r4k.c6 Dec 2006 22:02:39 - >> @@ -10,7 +10,8 @@ >> #include "vl.h" >> >> #define BIOS_FILENAME "mips_bios.bin" >> -//#define BIOS_FILENAME "system.bin" >> +#define LINUX_BOOT_FILENAME "linux_boot.bin" >> + > > I figure this hunk is erraneous. > Well it was in your original patch... But I can remove it. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add more devices to MIPS system emulation
Aurelien Jarno wrote: [snip] > Index: hw/mips_r4k.c > === > RCS file: /sources/qemu/qemu/hw/mips_r4k.c,v > retrieving revision 1.23 > diff -u -d -p -r1.23 mips_r4k.c > --- hw/mips_r4k.c 6 Dec 2006 21:38:37 - 1.23 > +++ hw/mips_r4k.c 6 Dec 2006 22:02:39 - > @@ -10,7 +10,8 @@ > #include "vl.h" > > #define BIOS_FILENAME "mips_bios.bin" > -//#define BIOS_FILENAME "system.bin" > +#define LINUX_BOOT_FILENAME "linux_boot.bin" > + I figure this hunk is erraneous. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-mips translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 06/12/06 23:12:49 Modified files: target-mips: translate.c Log message: Update copyright notice. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.22&r2=1.23 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Add more devices to MIPS system emulation
Hello all,
This patch, initially posted by Thiemo Seufer, adds more devices to the
MIPS system emulation, most importantly a RTC emulation which e.g. keeps
timestamps on a linux filesystem sane.
I have only modified it to use the patch I posted on the mailing list a
few minutes ago.
Aurelien
Index: Makefile.target
===
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.133
diff -u -d -p -r1.133 Makefile.target
--- Makefile.target 6 Dec 2006 21:38:37 - 1.133
+++ Makefile.target 6 Dec 2006 22:02:39 -
@@ -358,7 +358,7 @@ DEFINES += -DHAS_AUDIO
endif
ifeq ($(TARGET_ARCH), mips)
VL_OBJS+= mips_r4k.o mips_timer.o dma.o vga.o serial.o i8254.o i8259.o ide.o
-#VL_OBJS+= #pckbd.o fdc.o m48t59.o
+VL_OBJS+= mc146818rtc.o #pckbd.o fdc.o m48t59.o
endif
ifeq ($(TARGET_BASE_ARCH), sparc)
ifeq ($(TARGET_ARCH), sparc64)
Index: hw/mips_r4k.c
===
RCS file: /sources/qemu/qemu/hw/mips_r4k.c,v
retrieving revision 1.23
diff -u -d -p -r1.23 mips_r4k.c
--- hw/mips_r4k.c 6 Dec 2006 21:38:37 - 1.23
+++ hw/mips_r4k.c 6 Dec 2006 22:02:39 -
@@ -10,7 +10,8 @@
#include "vl.h"
#define BIOS_FILENAME "mips_bios.bin"
-//#define BIOS_FILENAME "system.bin"
+#define LINUX_BOOT_FILENAME "linux_boot.bin"
+
#define KERNEL_LOAD_ADDR 0x8001
#define INITRD_LOAD_ADDR 0x8080
@@ -135,6 +136,7 @@ void mips_r4k_init (int ram_size, int vg
unsigned long bios_offset;
int ret;
CPUState *env;
+static RTCState *rtc_state;
int i;
env = cpu_init();
@@ -179,12 +181,15 @@ void mips_r4k_init (int ram_size, int vg
cpu_mips_clock_init(env);
cpu_mips_irqctrl_init();
+rtc_state = rtc_init(0x70, 8);
+
/* Register 64 KB of ISA IO space at 0x1400 */
isa_mmio_init(0x1400, 0x0001);
isa_mem_base = 0x1000;
isa_pic = pic_init(pic_irq_request, env);
pit = pit_init(0x40, 0);
+
serial_init(&pic_set_irq_new, isa_pic, 0x3f8, 4, serial_hds[0]);
isa_vga_init(ds, phys_ram_base + ram_size, ram_size,
vga_ram_size);
@@ -202,6 +207,9 @@ void mips_r4k_init (int ram_size, int vg
for(i = 0; i < 2; i++)
isa_ide_init(ide_iobase[i], ide_iobase2[i], ide_irq[i],
bs_table[2 * i], bs_table[2 * i + 1]);
+
+kbd_init();
+DMA_init(1);
}
QEMUMachine mips_machine = {
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Move RTC date/time initialisation to hw/mc146818rtc.c
Hello all,
This patch moves the initialisation of the RTC date/time from hw/pc.c
into hw/mc146818rtc.c, to avoid duplication of code. I guess all
platforms using this RTC chip will want to setup at least the date and
time.
Aurelien
Index: hw/mc146818rtc.c
===
RCS file: /sources/qemu/qemu/hw/mc146818rtc.c,v
retrieving revision 1.6
diff -u -d -p -r1.6 mc146818rtc.c
--- hw/mc146818rtc.c3 Jun 2004 12:51:19 - 1.6
+++ hw/mc146818rtc.c6 Dec 2006 22:20:44 -
@@ -380,6 +380,29 @@ void rtc_set_date(RTCState *s, const str
rtc_copy_date(s);
}
+/* PC cmos mappings */
+#define REG_IBM_CENTURY_BYTE0x32
+#define REG_IBM_PS2_CENTURY_BYTE0x37
+
+void rtc_set_date_from_host(RTCState *s)
+{
+time_t ti;
+struct tm *tm;
+int val;
+
+/* set the CMOS date */
+time(&ti);
+if (rtc_utc)
+tm = gmtime(&ti);
+else
+tm = localtime(&ti);
+rtc_set_date(s, tm);
+
+val = to_bcd(s, (tm->tm_year / 100) + 19);
+rtc_set_memory(s, REG_IBM_CENTURY_BYTE, val);
+rtc_set_memory(s, REG_IBM_PS2_CENTURY_BYTE, val);
+}
+
static void rtc_save(QEMUFile *f, void *opaque)
{
RTCState *s = opaque;
@@ -444,6 +467,8 @@ RTCState *rtc_init(int base, int irq)
s->cmos_data[RTC_REG_C] = 0x00;
s->cmos_data[RTC_REG_D] = 0x80;
+rtc_set_date_from_host(s);
+
s->periodic_timer = qemu_new_timer(vm_clock,
rtc_periodic_timer, s);
s->second_timer = qemu_new_timer(vm_clock,
Index: hw/pc.c
===
RCS file: /sources/qemu/qemu/hw/pc.c,v
retrieving revision 1.62
diff -u -d -p -r1.62 pc.c
--- hw/pc.c 24 Sep 2006 18:48:00 - 1.62
+++ hw/pc.c 6 Dec 2006 22:20:44 -
@@ -111,14 +111,6 @@ static void pic_irq_request(void *opaque
/* PC cmos mappings */
#define REG_EQUIPMENT_BYTE 0x14
-#define REG_IBM_CENTURY_BYTE0x32
-#define REG_IBM_PS2_CENTURY_BYTE0x37
-
-
-static inline int to_bcd(RTCState *s, int a)
-{
-return ((a / 10) << 4) | (a % 10);
-}
static int cmos_get_fd_drive_type(int fd0)
{
@@ -171,18 +163,6 @@ static void cmos_init(int ram_size, int
struct tm *tm;
int i;
-/* set the CMOS date */
-time(&ti);
-if (rtc_utc)
-tm = gmtime(&ti);
-else
-tm = localtime(&ti);
-rtc_set_date(s, tm);
-
-val = to_bcd(s, (tm->tm_year / 100) + 19);
-rtc_set_memory(s, REG_IBM_CENTURY_BYTE, val);
-rtc_set_memory(s, REG_IBM_PS2_CENTURY_BYTE, val);
-
/* various important CMOS locations needed by PC/Bochs bios */
/* memory size */
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu Makefile.target vl.h hw/mips_r4k.c hw/mips...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 06/12/06 21:38:37 Modified files: . : Makefile.target vl.h hw : mips_r4k.c Added files: hw : mips_timer.c Log message: Move the MIPS CPU timer in a seperate file, by Alec Voropay. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.132&r2=1.133 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.154&r2=1.155 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemu&r1=1.22&r2=1.23 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_timer.c?cvsroot=qemu&rev=1.1 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-mips cpu.h exec.h helper.c mips-def...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 06/12/06 20:17:30 Modified files: target-mips: cpu.h exec.h helper.c mips-defs.h op.c op_helper.c translate.c Log message: Add MIPS32R2 instructions, and generally straighten out the instruction decoding. This is also the first percent towards MIPS64 support. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemu&r1=1.12&r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/exec.h?cvsroot=qemu&r1=1.11&r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/helper.c?cvsroot=qemu&r1=1.16&r2=1.17 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/mips-defs.h?cvsroot=qemu&r1=1.4&r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemu&r1=1.14&r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemu&r1=1.19&r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.21&r2=1.22 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-mips exec.h op.c op_helper.c transl...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 06/12/06 18:19:33 Modified files: target-mips: exec.h op.c op_helper.c translate.c Log message: Dynamically translate MIPS mtc0 instructions. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/exec.h?cvsroot=qemu&r1=1.10&r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemu&r1=1.13&r2=1.14 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemu&r1=1.18&r2=1.19 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.20&r2=1.21 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-mips exec.h op.c op_helper.c transl...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 06/12/06 17:59:07 Modified files: target-mips: exec.h op.c op_helper.c translate.c Log message: Dynamically translate MIPS mfc0 instructions. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/exec.h?cvsroot=qemu&r1=1.9&r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemu&r1=1.12&r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemu&r1=1.17&r2=1.18 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.19&r2=1.20 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu hw/mips_r4k.c target-mips/cpu.h target-mip...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 06/12/06 17:48:53 Modified files: hw : mips_r4k.c target-mips: cpu.h translate.c Log message: Halt/reboot support for Linux, by Daniel Jacobowitz. This is a band-aid until we emulate real MIPS hardware with real firmware. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemu&r1=1.21&r2=1.22 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemu&r1=1.11&r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.18&r2=1.19 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-mips cpu.h exec.h helper.c mips-def...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 06/12/06 17:42:40 Modified files: target-mips: cpu.h exec.h helper.c mips-defs.h op_helper.c translate.c Log message: MIPS TLB performance improvements, by Daniel Jacobowitz. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemu&r1=1.10&r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/exec.h?cvsroot=qemu&r1=1.8&r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/helper.c?cvsroot=qemu&r1=1.15&r2=1.16 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/mips-defs.h?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemu&r1=1.16&r2=1.17 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.17&r2=1.18 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] a strange segmentation fault
Paul, Thank you! I didn't know it, as nobody told me. :) Heng Paul Brook wrote: helper_test(T0); //my own function if (T0) GOTO_LABEL_PARAM(1); FORCE_RET(); ops that use GOTO_LABEL_PARM or EXIT_TB must not have a stack frame. Paul ___ 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] a strange segmentation fault
> helper_test(T0); //my own function > if (T0) > GOTO_LABEL_PARAM(1); > FORCE_RET(); ops that use GOTO_LABEL_PARM or EXIT_TB must not have a stack frame. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] a strange segmentation fault
Hi QEMU developers,
I'm running into a strange problem when I add some my own stuff in QEMU.
If I add a function call in the following position, QEMU will crash
immediately after execution.
In target-i386/op.c:
void OPPROTO op_jnz_T0_label(void)
{
helper_test(T0); //my own function
if (T0)
GOTO_LABEL_PARAM(1);
FORCE_RET();
}
I define this function in target-i386/helper.c:
int helper_test(int t0)
{
return 100+t0;
}
I try it on the two versions: 0.8.2 and 0.8.0. The problem appears no
matter what kqemu option (-kernel-kqemu -no-kqmeu, or none) is used and
what guest os (linux or winxp) is to launch.
I got the following message from gdb:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212991808 (LWP 28612)]
0x0001 in ?? ()
(gdb) bt
#0 0x0001 in ?? ()
#1 0x080bac6c in cpu_x86_exec (env1=0x40)
at /home/hyin/qemu-0.8.2/cpu-exec.c:772
#2 0x08050a62 in main_loop () at /home/hyin/qemu-0.8.2/vl.c:5069
#3 0x08051fe2 in main (argc=3324, argv=0x8)
at /home/hyin/qemu-0.8.2/vl.c:6221
(gdb)
Interestingly, if I change the function helper_test to take no
arguments, the fault will be gone.
Can anybody give any hints of what may cause this fault and how to solve it?
Thanks,
Heng
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-sparc op_helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 06/12/06 15:51:39 Modified files: target-sparc : op_helper.c Log message: sparc-softmmu build fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_helper.c?cvsroot=qemu&r1=1.21&r2=1.22 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Network problem, was Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake
Hi, please do not reply to something completely unrelated. On Wed, 6 Dec 2006, Manish Gajbhiye wrote: > We are faceing one Problem in Qemu guest os winxp . The Qemu hbas been > installed in Linux CentOs 4.4 . Guest os detected the Realtek Lan > Adapter . BUt with is Adpeter we are unable get the IP from Our Dhcp > Server. The network card QEmu detects is a _virtual_ one. And it should already have received an IP by the _virtual_ DHCP in QEmu. The _virtual_ router inside QEmu will act as a masquerading firewall to your QEmu instance, so that network connections to the wide world will seem to originate from your _host_ machine. Hth, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
