Re: [Qemu-devel] [RFC] IRQ acknowledge on MIPS
Hi all, Some news on that point. After a discussion with Paul Brook, Thiemo Seufer and Ralf Baechle on IRC yesterday, we got convinced that the current IRQ handling is not correct. The hardware interrupt is currently deasserted by the CPU itself (in cpu-exec.c). It should be deasserted by the interrupt controller (the i8259a in our case), so that pending interrupts are not missed. This is wrong for MIPS, but also for x86_64 and PowerPC. ARM is correctly implemented though. Then after playing with the current code, I am sure we are missing a simple interrupt controller for the MIPS CPU. It supports 6 hardware interrupts (IP2 to IP7) and we are using two of them in the current emulation: one for the i8259a and the other for the timer. In both case the current code assert and deassert a CPU_INTERRUPT_HARD. The interrupt controller should assert and deassert the CPU_INTERRUPT_HARD upon the contents of the CP0 cause and CP0 status (ie mask) registers. Currently we are totally ignoring that interrupts can be masked and leave this task to the operating system. I will try to write the missing code this night. Bye, Aurelien -- .''`. 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] [RFC] IRQ acknowledge on MIPS
On Tue, 23 Jan 2007, Aurelien Jarno wrote: > There is currently a bug concerning the IRQ acknowlege on the MIPS > system emulation. It concerns both the QEMU and Malta boards, though it > is only detectable with a 2.4 kernel and thus on the Malta board. The > symptom is a storm of "We got a spurious interrupt from PIIX4." > > This is due to the kernel requesting the interrupt number from the > i8259A where no interrupt is waiting. In such a case the i8259A answers > by an IRQ 7. > > When an hardware interrupt occurs, the i8259A memorizes the interrupt > and sends it to the MIPS CPU. This is done via the pic_irq_request() > function. The result is that the bit 10 of the CP0 Cause register is > set to one (interrupt 2). But when the interrupt is finished, the i8259a > registers IRR and ISR are cleared, but not the CP0 Cause register. The > CPU always thinks there is an interrupt to serve, which is wrong. I can confirm this issue. For our (custom) OS I worked around this by manualy clearing CP0 Cause (even though I think I shouldn't be allowed to do that since CP0:IP[7-2] are read-only, but that's another story... ;-) > Does anyone has an idea of a sane implementation for that? It seems > only the MIPS platform has to clear a register of the CPU when an > interrupt is finished. What about passing another hook to pic_init which, if set, would be called when no more interrupts are pending? Would that be too specific this problem to be an acceptable solution? Regards, Marius -- Marius Groeger <[EMAIL PROTECTED]> SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: DMA timeouts running a FreeBSD guest with last CVS snapshot
On Mon, Jan 22, 2007 at 11:55:11AM +0100, Aurelien Jarno wrote: > Carlo Marcelo Arenas Belon a écrit : > > > > The following patch moves the initialization of bm->cur_addr to match > > FreeBSD behavior while being also compatible with all other guests > > the following snippet kept the initialization of bm->cur_addr inside the ide_dma_start function as a failback as that is where it conceptually belongs. that is not needed though, as the initialization of bm->addr and also bm->cur_addr is now done when the address for DMA is send to the emulated PIIX. > > Index: hw/ide.c > > === > > RCS file: /sources/qemu/qemu/hw/ide.c,v > > retrieving revision 1.51 > > diff -u -r1.51 ide.c > > --- hw/ide.c20 Jan 2007 01:12:17 - 1.51 > > +++ hw/ide.c22 Jan 2007 09:50:20 - > > @@ -2230,10 +2230,11 @@ > > return; > > bm->ide_if = s; > > bm->dma_cb = dma_cb; > > -bm->cur_addr = bm->addr; > > bm->cur_prd_last = 0; > > bm->cur_prd_addr = 0; > > bm->cur_prd_len = 0; > > +if (bm->cur_addr != bm->addr) > > +bm->cur_addr = bm->addr; > > Why using a condition here? This will probably be slower than doing > bm->cur_addr = bm->addr and the result is the same. as I mentioned before, this initialization is not even needed, but I kept it as a way to keep the original logic that used this function to setup all initial values for the DMA. in retrospective though I can see why it was a bad idea and confusing, so I'd prepared version 2 of the patch that removes this and eliminates your concern as well. thanks, Carlo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH V2] DMA timeouts running a FreeBSD guest
Greetings,
the following patch moves the initialization for bm->cur_addr from the
ide_dma_start function to bmdma_addr_writel, so that it is set in sync
with the call to set the destination address for DMA (bm->addr) and to
avoid timeouts in guests that set this address after they have called
the READ_DMA command (FreeBSD).
the final package has been tested with the following guests :
FreeBSD 6.2 (amd64 and i386)
FreeBSD 5.3 (i386)
Fedora Core 6 (i386)
Gentoo Linux 2006.1 (i386)
NexentaOS Alpha 6 (amd64)
OpenSolaris Nevada b55b (amd64)
OpenBSD 4.0 (amd64 and i386)
Windows 2000 (i386)
Carlo
Index: hw/ide.c
===
RCS file: /sources/qemu/qemu/hw/ide.c,v
retrieving revision 1.51
diff -u -r1.51 ide.c
--- hw/ide.c20 Jan 2007 01:12:17 - 1.51
+++ hw/ide.c23 Jan 2007 09:58:44 -
@@ -2230,7 +2230,6 @@
return;
bm->ide_if = s;
bm->dma_cb = dma_cb;
-bm->cur_addr = bm->addr;
bm->cur_prd_last = 0;
bm->cur_prd_addr = 0;
bm->cur_prd_len = 0;
@@ -2363,6 +2362,7 @@
printf("%s: 0x%08x\n", __func__, val);
#endif
bm->addr = val & ~3;
+bm->cur_addr = bm->addr;
}
static void bmdma_map(PCIDevice *pci_dev, int region_num,
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [RFC] IRQ acknowledge on MIPS
"Aurelien Jarno" <[EMAIL PROTECTED]> wrote: Then after playing with the current code, I am sure we are missing a simple interrupt controller for the MIPS CPU. It supports 6 hardware interrupts (IP2 to IP7) and we are using two of them in the current emulation: one for the i8259a and the other for the timer. In both case the current code assert and deassert a CPU_INTERRUPT_HARD. The Galileo GT64xxx chip contains an interrupt controller too (for DMA cycle indication, built-in Timers e.t.c.). All this interrupt controllers are daisy-chained: i8259(as part of the PIIX + PCI), GT64xxx and MIPS internal. P.S. It should be good to have a well-defined modular IRQ routing architecture in the Qemu. Moreover, modern ix86 LAPIC/APIC interrupt controller even more complicated. -- -=AV=- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [RFC] IRQ acknowledge on MIPS
> It should be good to have a well-defined modular IRQ routing
> architecture in the Qemu.
We've got most of one for the ARM targets (see hw/arm_pic.h). This file
contains both the target independent bits and the ARM specific bits for
emulating the CPU IRQ/FIQ pins.
Annother possibility to abstract this to use a single interrupt line object
rather than an {object,index} pair. This simplifies code that that raises
interrupts, at the expense of some complication in the code to create
interrupt controllers.
Paul
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] fix i386-softmmu with newer kernel headers
hi with newer kernel-headers, i get the following compile error: gcc-3.3 -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I.. -I/var/tmp/fst/src/qemu-0.8.2/target-i386 -I/var/tmp/fst/src/qemu-0.8.2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/var/tmp/fst/src/qemu-0.8.2/fpu -DHAS_AUDIO -I/var/tmp/fst/src/qemu-0.8.2/slirp -c -o usb-linux.o /var/tmp/fst/src/qemu-0.8.2/usb-linux.c /var/tmp/fst/src/qemu-0.8.2/usb-linux.c:29:28: linux/compiler.h: No such file or directory make[1]: *** [usb-linux.o] Error 1 make[1]: Leaving directory `/var/tmp/fst/src/qemu-0.8.2/i386-softmmu' make: *** [subdir-i386-softmmu] Error 2 is this a known issue? a trivial patch is here: http://darcs.frugalware.org/repos/frugalware-current/source/xapps-extra/qemu/qemu-0.8.2-include.diff i'm not sure about what would require that inclusion. i mean in case i would know, of course i would send some #ifndef FOO #include #endif patch :) thanks, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fix i386-softmmu with newer kernel headers
Hi, On Tue, 23 Jan 2007, VMiklos wrote: > /var/tmp/fst/src/qemu-0.8.2/usb-linux.c:29:28: linux/compiler.h: No > such file or directory > make[1]: *** [usb-linux.o] Error 1 > make[1]: Leaving directory `/var/tmp/fst/src/qemu-0.8.2/i386-softmmu' > make: *** [subdir-i386-softmmu] Error 2 > > is this a known issue? Yes: http://search.gmane.org/?query=linux%2Fcompiler.h&group=gmane.comp.emulators.qemu Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fix i386-softmmu with newer kernel headers
On Tue, 2007-01-23 at 17:03 +0100, VMiklos wrote: > hi > > with newer kernel-headers, i get the following compile error: > gcc-3.3 -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. > -I.. -I/var/tmp/fst/src/qemu-0.8.2/target-i386 > -I/var/tmp/fst/src/qemu-0.8.2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE_SOURCE -I/var/tmp/fst/src/qemu-0.8.2/fpu -DHAS_AUDIO > -I/var/tmp/fst/src/qemu-0.8.2/slirp -c -o usb-linux.o > /var/tmp/fst/src/qemu-0.8.2/usb-linux.c > /var/tmp/fst/src/qemu-0.8.2/usb-linux.c:29:28: linux/compiler.h: No > such file or directory > make[1]: *** [usb-linux.o] Error 1 > make[1]: Leaving directory `/var/tmp/fst/src/qemu-0.8.2/i386-softmmu' > make: *** [subdir-i386-softmmu] Error 2 > > is this a known issue? > > a trivial patch is here: remove the #include statement in usb-linux.c. Compile. Done. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [RFC] IRQ acknowledge on MIPS
Alexander Voropay a écrit : > "Aurelien Jarno" <[EMAIL PROTECTED]> wrote: > >> Then after playing with the current code, I am sure we are missing a >> simple interrupt controller for the MIPS CPU. It supports 6 hardware >> interrupts (IP2 to IP7) and we are using two of them in the current >> emulation: one for the i8259a and the other for the timer. In both case >> the current code assert and deassert a CPU_INTERRUPT_HARD. > > The Galileo GT64xxx chip contains an interrupt controller too (for DMA > cycle indication, built-in Timers e.t.c.). All this interrupt controllers are > daisy-chained: i8259(as part of the PIIX + PCI), GT64xxx and MIPS internal. > Yes, but this controller is not used on the Malta board. -- .''`. 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] Reworking MIPS interrupts handling
Hi all,
Please find below a patch to fix the IRQ issue on the MIPS platform. I
have tested it on both 2.4 and 2.6 kernel and it works fine.
Here are a few comments on the patch to understand how it works.
- The CPU hardware interrupt (CPU_INTERRUPT_HARD) is not deasserted by
the CPU anymore, but rather by the interrupt controller. I think it
should be the case for other targets too, but I don't want to change
the code of other targets without some more tests, that's why I use a
condition in the i8259.c file.
- The gt64120 now uses pic_read_irq() instead of pic_intack_read() so
that the interrupt state of the i8259 is recomputed and propagated if
needed.
- I changed the way the CPU hardware interrupt (CPU_INTERRUPT_HARD) is
asserted. It appears that the MIPS CPU can have more than one
interrupt, 6 hardware and 2 software interrupt. The
cpu_mips_update_irq() subroutine computes the state of the hardware
interrupt and issue and harware interrupt, deassert it or do nothing
in function of the mode of the CPU, the CP0 cause register (status
of the interrupt lines) and the CP0 status register (interrupt masks).
- The software interrupt are now handled using... a hardware interrupt.
From our point of view, hardware and software interrupts are actually
the same, they use the same vector, they use the same registers, the
only difference is that the bit in the CP0 cause register is set to
one by software instead of hardware.
Bye,
Aurelien
--- hw/mips_int.c 2007-01-18 20:37:29.623079789 +0100
+++ hw/mips_int.c 2007-01-23 18:47:42.0 +0100
@@ -0,0 +1,31 @@
+#include "vl.h"
+
+/* Raise IRQ to CPU if necessary. It must be called every time the active
+ IRQ may change. */
+void cpu_mips_update_irq(CPUState *env)
+{
+if ((env->CP0_Status & env->CP0_Cause & 0xff00) &&
+(env->CP0_Status & 0x0001) &&
+!(env->hflags & MIPS_HFLAG_EXL) &&
+!(env->hflags & MIPS_HFLAG_ERL) &&
+!(env->hflags & MIPS_HFLAG_DM)) {
+if (! (env->interrupt_request & CPU_INTERRUPT_HARD)) {
+cpu_interrupt(env, CPU_INTERRUPT_HARD);
+}
+} else {
+cpu_reset_interrupt(env, CPU_INTERRUPT_HARD);
+}
+}
+
+void cpu_mips_irq_request(void *opaque, int irq, int level)
+{
+CPUState *env = first_cpu;
+
+if (level) {
+env->CP0_Cause |= (irq & 0xff00);
+} else {
+env->CP0_Cause &= ~(irq & 0xff00);
+}
+cpu_mips_update_irq(env);
+}
+
Index: Makefile.target
===
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.140
diff -u -d -p -r1.140 Makefile.target
--- Makefile.target 21 Jan 2007 22:40:04 - 1.140
+++ Makefile.target 23 Jan 2007 18:14:39 -
@@ -376,7 +376,7 @@ VL_OBJS+= grackle_pci.o prep_pci.o unin_
CPPFLAGS += -DHAS_AUDIO
endif
ifeq ($(TARGET_ARCH), mips)
-VL_OBJS+= mips_r4k.o mips_malta.o mips_timer.o dma.o vga.o serial.o i8254.o
i8259.o
+VL_OBJS+= mips_r4k.o mips_malta.o mips_timer.o mips_int.o dma.o vga.o serial.o
i8254.o i8259.o
VL_OBJS+= ide.o gt64xxx.o pckbd.o ps2.o fdc.o mc146818rtc.o usb-uhci.o acpi.o
VL_OBJS+= piix_pci.o parallel.o mixeng.o cirrus_vga.o $(SOUND_HW) $(AUDIODRV)
DEFINES += -DHAS_AUDIO
Index: cpu-exec.c
===
RCS file: /sources/qemu/qemu/cpu-exec.c,v
retrieving revision 1.88
diff -u -d -p -r1.88 cpu-exec.c
--- cpu-exec.c 7 Dec 2006 18:28:42 - 1.88
+++ cpu-exec.c 23 Jan 2007 18:14:40 -
@@ -535,7 +535,6 @@ int cpu_exec(CPUState *env1)
env->exception_index = EXCP_EXT_INTERRUPT;
env->error_code = 0;
do_interrupt(env);
-env->interrupt_request &= ~CPU_INTERRUPT_HARD;
#if defined(__sparc__) && !defined(HOST_SOLARIS)
tmp_T0 = 0;
#else
Index: vl.h
===
RCS file: /sources/qemu/qemu/vl.h,v
retrieving revision 1.175
diff -u -d -p -r1.175 vl.h
--- vl.h21 Jan 2007 16:47:01 - 1.175
+++ vl.h23 Jan 2007 18:14:44 -
@@ -1067,6 +1067,9 @@ extern QEMUMachine mips_machine;
/* mips_malta.c */
extern QEMUMachine mips_malta_machine;
+/* mips_int */
+extern void cpu_mips_irq_request(void *opaque, int irq, int level);
+
/* mips_timer.c */
extern void cpu_mips_clock_init(CPUState *);
extern void cpu_mips_irqctrl_init (void);
Index: hw/gt64xxx.c
===
RCS file: /sources/qemu/qemu/hw/gt64xxx.c,v
retrieving revision 1.2
diff -u -d -p -r1.2 gt64xxx.c
--- hw/gt64xxx.c17 Jan 2007 23:35:01 - 1.2
+++ hw/gt64xxx.c23 Jan 2007 18:14:45 -
@@ -1,7 +1,7 @@
/*
* QEMU GT64120 PCI host
*
- * Copyright (c) 2006 Aurelien Jarno
+ * Copyright (c) 2006, 2007 Aurelien Jarno
*
* Permission is hereby
Re: [Qemu-devel] [PATCH] Reworking MIPS interrupts handling
On Tue, Jan 23, 2007 at 07:42:20PM +0100, Aurelien Jarno wrote:
> Hi all,
>
> Please find below a patch to fix the IRQ issue on the MIPS platform. I
> have tested it on both 2.4 and 2.6 kernel and it works fine.
>
Here is an updated patch including the comments from Paul Brook via IRC.
Thanks Paul for the review.
--- hw/mips_int.c 2007-01-18 20:37:29.623079789 +0100
+++ hw/mips_int.c 2007-01-23 20:55:13.0 +0100
@@ -0,0 +1,39 @@
+#include "vl.h"
+#include "cpu.h"
+
+/* Raise IRQ to CPU if necessary. It must be called every time the active
+ IRQ may change */
+void cpu_mips_update_irq(CPUState *env)
+{
+if ((env->CP0_Status & env->CP0_Cause & CP0Ca_IP_mask) &&
+(env->CP0_Status & (1 << CP0St_IE)) &&
+!(env->hflags & MIPS_HFLAG_EXL) &&
+ !(env->hflags & MIPS_HFLAG_ERL) &&
+ !(env->hflags & MIPS_HFLAG_DM)) {
+if (! (env->interrupt_request & CPU_INTERRUPT_HARD)) {
+cpu_interrupt(env, CPU_INTERRUPT_HARD);
+ }
+} else {
+cpu_reset_interrupt(env, CPU_INTERRUPT_HARD);
+}
+}
+
+void cpu_mips_irq_request(void *opaque, int irq, int level)
+{
+CPUState *env = first_cpu;
+
+uint32_t mask;
+
+if (irq >= 16)
+return;
+
+mask = 1 << (irq + CP0Ca_IP);
+
+if (level) {
+env->CP0_Cause |= mask;
+} else {
+env->CP0_Cause &= ~mask;
+}
+cpu_mips_update_irq(env);
+}
+
? hw/mips_int.c
Index: Makefile.target
===
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.140
diff -u -d -p -r1.140 Makefile.target
--- Makefile.target 21 Jan 2007 22:40:04 - 1.140
+++ Makefile.target 23 Jan 2007 19:57:09 -
@@ -376,7 +376,7 @@ VL_OBJS+= grackle_pci.o prep_pci.o unin_
CPPFLAGS += -DHAS_AUDIO
endif
ifeq ($(TARGET_ARCH), mips)
-VL_OBJS+= mips_r4k.o mips_malta.o mips_timer.o dma.o vga.o serial.o i8254.o
i8259.o
+VL_OBJS+= mips_r4k.o mips_malta.o mips_timer.o mips_int.o dma.o vga.o serial.o
i8254.o i8259.o
VL_OBJS+= ide.o gt64xxx.o pckbd.o ps2.o fdc.o mc146818rtc.o usb-uhci.o acpi.o
VL_OBJS+= piix_pci.o parallel.o mixeng.o cirrus_vga.o $(SOUND_HW) $(AUDIODRV)
DEFINES += -DHAS_AUDIO
Index: cpu-exec.c
===
RCS file: /sources/qemu/qemu/cpu-exec.c,v
retrieving revision 1.88
diff -u -d -p -r1.88 cpu-exec.c
--- cpu-exec.c 7 Dec 2006 18:28:42 - 1.88
+++ cpu-exec.c 23 Jan 2007 19:57:10 -
@@ -535,7 +535,6 @@ int cpu_exec(CPUState *env1)
env->exception_index = EXCP_EXT_INTERRUPT;
env->error_code = 0;
do_interrupt(env);
-env->interrupt_request &= ~CPU_INTERRUPT_HARD;
#if defined(__sparc__) && !defined(HOST_SOLARIS)
tmp_T0 = 0;
#else
Index: vl.h
===
RCS file: /sources/qemu/qemu/vl.h,v
retrieving revision 1.175
diff -u -d -p -r1.175 vl.h
--- vl.h21 Jan 2007 16:47:01 - 1.175
+++ vl.h23 Jan 2007 19:57:10 -
@@ -1067,6 +1067,9 @@ extern QEMUMachine mips_machine;
/* mips_malta.c */
extern QEMUMachine mips_malta_machine;
+/* mips_int */
+extern void cpu_mips_irq_request(void *opaque, int irq, int level);
+
/* mips_timer.c */
extern void cpu_mips_clock_init(CPUState *);
extern void cpu_mips_irqctrl_init (void);
Index: hw/gt64xxx.c
===
RCS file: /sources/qemu/qemu/hw/gt64xxx.c,v
retrieving revision 1.2
diff -u -d -p -r1.2 gt64xxx.c
--- hw/gt64xxx.c17 Jan 2007 23:35:01 - 1.2
+++ hw/gt64xxx.c23 Jan 2007 19:57:10 -
@@ -1,7 +1,7 @@
/*
* QEMU GT64120 PCI host
*
- * Copyright (c) 2006 Aurelien Jarno
+ * Copyright (c) 2006,2007 Aurelien Jarno
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to
deal
@@ -433,7 +436,8 @@ static uint32_t gt64120_readl (void *opa
val = s->regs[saddr];
break;
case GT_PCI0_IACK:
- val = pic_intack_read(isa_pic);
+/* Read the IRQ number */
+val = pic_read_irq(isa_pic);
break;
/* SDRAM Parameters */
Index: hw/i8259.c
===
RCS file: /sources/qemu/qemu/hw/i8259.c,v
retrieving revision 1.19
diff -u -d -p -r1.19 i8259.c
--- hw/i8259.c 25 Jun 2006 18:15:31 - 1.19
+++ hw/i8259.c 23 Jan 2007 19:57:10 -
@@ -161,6 +161,13 @@ void pic_update_irq(PicState2 *s)
#endif
s->irq_request(s->irq_request_opaque, 1);
}
+
+/* all targets should do this rather than acking the IRQ in the cpu */
+#if defined(TARGET_MIPS)
+else {
+s->irq_request(s->irq_request_opaque, 0);
+}
+#endif
}
#ifdef DEBUG_IRQ_LATENCY
Index: hw/mips_malta.c
Re: [Qemu-devel] [RFC] IRQ acknowledge on MIPS
Paul Brook wrote:
It should be good to have a well-defined modular IRQ routing
architecture in the Qemu.
We've got most of one for the ARM targets (see hw/arm_pic.h). This file
contains both the target independent bits and the ARM specific bits for
emulating the CPU IRQ/FIQ pins.
Annother possibility to abstract this to use a single interrupt line object
rather than an {object,index} pair. This simplifies code that that raises
interrupts, at the expense of some complication in the code to create
interrupt controllers.
I prefer to have a new type 'QEMUBoolSignal' which can be used for any
boolean signal. A function could be called to change its level and
several clients could set a callback ("listener") to be informed that
its level changes.
Regards,
Fabrice.
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Reworking MIPS interrupts handling
Good. I prefer this implementation to the current one! Fabrice. Aurelien Jarno wrote: On Tue, Jan 23, 2007 at 07:42:20PM +0100, Aurelien Jarno wrote: Hi all, Please find below a patch to fix the IRQ issue on the MIPS platform. I have tested it on both 2.4 and 2.6 kernel and it works fine. Here is an updated patch including the comments from Paul Brook via IRC. Thanks Paul for the review. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] PIIX4 SMBus host, EEPROM device emulation
The attached patch adds SMBus host support to the emulated PIIX4 power
management device (acpi.c), and adds an emulated serial EEPROM device
accessible via the SMBus interface.
I tried to follow the Intel 82371AB spec for the SMBus support; the
interface should be generic enough to implement a variety of
SMBus-compliant devices.
The EEPROM device can use a file for persistent storage
(smbus_eeprom.bin in the BIOS directory). If this file does not exist,
a temporary buffer is used instead.
I tested the devices with Linux using the i2c-piix4 host driver and
the eeprom chip driver. I have no idea what will happen on other OSes.
Comments and suggestions welcome.
--Ed
Index: qemu-0.8.2/hw/acpi.c
===
--- qemu-0.8.2.orig/hw/acpi.c
+++ qemu-0.8.2/hw/acpi.c
@@ -27,6 +27,7 @@
#define PM_IO_BASE0xb000
#define SMI_CMD_IO_ADDR 0xb040
#define ACPI_DBG_IO_ADDR 0xb044
+#define SMB_IO_BASE 0xb100
typedef struct PIIX4PMState {
PCIDevice dev;
@@ -35,6 +36,15 @@ typedef struct PIIX4PMState {
uint16_t pmcntrl;
QEMUTimer *tmr_timer;
int64_t tmr_overflow_time;
+SMBusDevice *smb_dev[128];
+uint8_t smb_stat;
+uint8_t smb_ctl;
+uint8_t smb_cmd;
+uint8_t smb_addr;
+uint8_t smb_data0;
+uint8_t smb_data1;
+uint8_t smb_data[32];
+uint8_t smb_index;
} PIIX4PMState;
#define RTC_EN (1 << 10)
@@ -46,8 +56,6 @@ typedef struct PIIX4PMState {
#define SUS_EN (1 << 13)
-/* Note: only used for ACPI bios init. Could be deleted when ACPI init
- is integrated in Bochs BIOS */
static PIIX4PMState *piix4_pm_state;
static uint32_t get_pmtmr(PIIX4PMState *s)
@@ -218,13 +226,163 @@ static void acpi_dbg_writel(void *opaque
#endif
}
+static void smb_transaction(PIIX4PMState *s)
+{
+uint8_t prot = (s->smb_ctl >> 2) & 0x07;
+uint8_t read = s->smb_addr & 0x01;
+uint8_t cmd = s->smb_cmd;
+uint8_t addr = s->smb_addr >> 1;
+SMBusDevice *dev = s->smb_dev[addr];
+
+#ifdef DEBUG
+printf("SMBus trans addr=0x%02x prot=0x%02x\n", addr, prot);
+#endif
+if (!dev) goto error;
+
+switch(prot) {
+case 0x0:
+if (!dev->quick_cmd) goto error;
+(*dev->quick_cmd)(dev, read);
+break;
+case 0x1:
+if (read) {
+if (!dev->receive_byte) goto error;
+s->smb_data0 = (*dev->receive_byte)(dev);
+}
+else {
+if (!dev->send_byte) goto error;
+(*dev->send_byte)(dev, cmd);
+}
+break;
+case 0x2:
+if (read) {
+if (!dev->read_byte) goto error;
+s->smb_data0 = (*dev->read_byte)(dev, cmd);
+}
+else {
+if (!dev->write_byte) goto error;
+(*dev->write_byte)(dev, cmd, s->smb_data0);
+}
+break;
+case 0x3:
+if (read) {
+uint16_t val;
+if (!dev->read_word) goto error;
+val = (*dev->read_word)(dev, cmd);
+s->smb_data0 = val;
+s->smb_data1 = val >> 8;
+}
+else {
+if (!dev->write_word) goto error;
+(*dev->write_word)(dev, cmd, (s->smb_data1 << 8) | s->smb_data0);
+}
+break;
+case 0x5:
+if (read) {
+if (!dev->read_block) goto error;
+s->smb_data0 = (*dev->read_block)(dev, cmd, s->smb_data);
+}
+else {
+if (!dev->write_block) goto error;
+(*dev->write_block)(dev, cmd, s->smb_data0, s->smb_data);
+}
+break;
+default:
+goto error;
+}
+return;
+
+ error:
+s->smb_stat |= 0x04;
+}
+
+static void smb_ioport_writeb(void *opaque, uint32_t addr, uint32_t val)
+{
+PIIX4PMState *s = opaque;
+addr &= 0x3f;
+#ifdef DEBUG
+printf("SMB writeb port=0x%04x val=0x%02x\n", addr, val);
+#endif
+switch(addr) {
+case 0x00: /* SMBHSTSTS */
+s->smb_stat = 0;
+s->smb_index = 0;
+break;
+case 0x02: /* SMBHSTCNT */
+s->smb_ctl = val;
+if (val & 0x40)
+smb_transaction(s);
+break;
+case 0x03: /* SMBHSTCMD */
+s->smb_cmd = val;
+break;
+case 0x04: /* SMBHSTADD */
+s->smb_addr = val;
+break;
+case 0x05: /* SMBHSTDAT0 */
+s->smb_data0 = val;
+break;
+case 0x06: /* SMBHSTDAT1 */
+s->smb_data1 = val;
+break;
+case 0x07: /* SMBBLKDAT */
+s->smb_data[s->smb_index++] = val;
+if (s->smb_index > 31)
+s->smb_index = 0;
+break;
+default:
+break;
+}
+}
+
+static uint32_t smb_ioport_readb(void *opaque, uint32_t addr)
+{
+PIIX4PMState *s = opaque;
+uint32_t val;
+
+addr &= 0x3f;
+switch(addr) {
+case 0x00: /* SMBHSTSTS */
+val = s->smb_stat;
+break;
+case 0x02: /* SMBHSTCNT */
+s->smb_index = 0;
+val = s->smb_ctl & 0x1f;
+break;
+
Re: [Qemu-devel] [PATCH] PIIX4 SMBus host, EEPROM device emulation
Ed Swierk wrote: The attached patch adds SMBus host support to the emulated PIIX4 power management device (acpi.c), and adds an emulated serial EEPROM device accessible via the SMBus interface. I tried to follow the Intel 82371AB spec for the SMBus support; the interface should be generic enough to implement a variety of SMBus-compliant devices. The EEPROM device can use a file for persistent storage (smbus_eeprom.bin in the BIOS directory). If this file does not exist, a temporary buffer is used instead. I tested the devices with Linux using the i2c-piix4 host driver and the eeprom chip driver. I have no idea what will happen on other OSes. Comments and suggestions welcome. > [...] OK, but avoid using mmap() in the device code. Moreover, files in the BIOS directory are not writable. Regards, Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] PIIX4 SMBus host, EEPROM device emulation
On 1/23/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote: OK, but avoid using mmap() in the device code. Moreover, files in the BIOS directory are not writable. OK. Would it be better to do the following: - add a command-line option -seeprom that sets the file to use as backing store for the smbus_eeprom device - in main(), open and mmap the file if the -seeprom option is specified, otherwise allocate a temporary buffer - add a seeprom buffer argument to each machine's init(), ignored except for pc --Ed ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-mips cpu.h op.c op_helper.c transla...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/01/23 22:45:22 Modified files: target-mips: cpu.h op.c op_helper.c translate.c Log message: Implementing dmfc/dmtc. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemu&r1=1.17&r2=1.18 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemu&r1=1.19&r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemu&r1=1.26&r2=1.27 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.30&r2=1.31 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] PIIX4 SMBus host, EEPROM device emulation
Here's a revised patch with the mmap stuff removed. I'll refine the
persistence support, but in the meantime the EEPROM device is usable
even if it forgets its contents when qemu exits.
--Ed
Index: qemu-0.8.2/hw/acpi.c
===
--- qemu-0.8.2.orig/hw/acpi.c
+++ qemu-0.8.2/hw/acpi.c
@@ -27,6 +27,7 @@
#define PM_IO_BASE0xb000
#define SMI_CMD_IO_ADDR 0xb040
#define ACPI_DBG_IO_ADDR 0xb044
+#define SMB_IO_BASE 0xb100
typedef struct PIIX4PMState {
PCIDevice dev;
@@ -35,6 +36,15 @@ typedef struct PIIX4PMState {
uint16_t pmcntrl;
QEMUTimer *tmr_timer;
int64_t tmr_overflow_time;
+SMBusDevice *smb_dev[128];
+uint8_t smb_stat;
+uint8_t smb_ctl;
+uint8_t smb_cmd;
+uint8_t smb_addr;
+uint8_t smb_data0;
+uint8_t smb_data1;
+uint8_t smb_data[32];
+uint8_t smb_index;
} PIIX4PMState;
#define RTC_EN (1 << 10)
@@ -46,8 +56,6 @@ typedef struct PIIX4PMState {
#define SUS_EN (1 << 13)
-/* Note: only used for ACPI bios init. Could be deleted when ACPI init
- is integrated in Bochs BIOS */
static PIIX4PMState *piix4_pm_state;
static uint32_t get_pmtmr(PIIX4PMState *s)
@@ -218,13 +226,163 @@ static void acpi_dbg_writel(void *opaque
#endif
}
+static void smb_transaction(PIIX4PMState *s)
+{
+uint8_t prot = (s->smb_ctl >> 2) & 0x07;
+uint8_t read = s->smb_addr & 0x01;
+uint8_t cmd = s->smb_cmd;
+uint8_t addr = s->smb_addr >> 1;
+SMBusDevice *dev = s->smb_dev[addr];
+
+#ifdef DEBUG
+printf("SMBus trans addr=0x%02x prot=0x%02x\n", addr, prot);
+#endif
+if (!dev) goto error;
+
+switch(prot) {
+case 0x0:
+if (!dev->quick_cmd) goto error;
+(*dev->quick_cmd)(dev, read);
+break;
+case 0x1:
+if (read) {
+if (!dev->receive_byte) goto error;
+s->smb_data0 = (*dev->receive_byte)(dev);
+}
+else {
+if (!dev->send_byte) goto error;
+(*dev->send_byte)(dev, cmd);
+}
+break;
+case 0x2:
+if (read) {
+if (!dev->read_byte) goto error;
+s->smb_data0 = (*dev->read_byte)(dev, cmd);
+}
+else {
+if (!dev->write_byte) goto error;
+(*dev->write_byte)(dev, cmd, s->smb_data0);
+}
+break;
+case 0x3:
+if (read) {
+uint16_t val;
+if (!dev->read_word) goto error;
+val = (*dev->read_word)(dev, cmd);
+s->smb_data0 = val;
+s->smb_data1 = val >> 8;
+}
+else {
+if (!dev->write_word) goto error;
+(*dev->write_word)(dev, cmd, (s->smb_data1 << 8) | s->smb_data0);
+}
+break;
+case 0x5:
+if (read) {
+if (!dev->read_block) goto error;
+s->smb_data0 = (*dev->read_block)(dev, cmd, s->smb_data);
+}
+else {
+if (!dev->write_block) goto error;
+(*dev->write_block)(dev, cmd, s->smb_data0, s->smb_data);
+}
+break;
+default:
+goto error;
+}
+return;
+
+ error:
+s->smb_stat |= 0x04;
+}
+
+static void smb_ioport_writeb(void *opaque, uint32_t addr, uint32_t val)
+{
+PIIX4PMState *s = opaque;
+addr &= 0x3f;
+#ifdef DEBUG
+printf("SMB writeb port=0x%04x val=0x%02x\n", addr, val);
+#endif
+switch(addr) {
+case 0x00: /* SMBHSTSTS */
+s->smb_stat = 0;
+s->smb_index = 0;
+break;
+case 0x02: /* SMBHSTCNT */
+s->smb_ctl = val;
+if (val & 0x40)
+smb_transaction(s);
+break;
+case 0x03: /* SMBHSTCMD */
+s->smb_cmd = val;
+break;
+case 0x04: /* SMBHSTADD */
+s->smb_addr = val;
+break;
+case 0x05: /* SMBHSTDAT0 */
+s->smb_data0 = val;
+break;
+case 0x06: /* SMBHSTDAT1 */
+s->smb_data1 = val;
+break;
+case 0x07: /* SMBBLKDAT */
+s->smb_data[s->smb_index++] = val;
+if (s->smb_index > 31)
+s->smb_index = 0;
+break;
+default:
+break;
+}
+}
+
+static uint32_t smb_ioport_readb(void *opaque, uint32_t addr)
+{
+PIIX4PMState *s = opaque;
+uint32_t val;
+
+addr &= 0x3f;
+switch(addr) {
+case 0x00: /* SMBHSTSTS */
+val = s->smb_stat;
+break;
+case 0x02: /* SMBHSTCNT */
+s->smb_index = 0;
+val = s->smb_ctl & 0x1f;
+break;
+case 0x03: /* SMBHSTCMD */
+val = s->smb_cmd;
+break;
+case 0x04: /* SMBHSTADD */
+val = s->smb_addr;
+break;
+case 0x05: /* SMBHSTDAT0 */
+val = s->smb_data0;
+break;
+case 0x06: /* SMBHSTDAT1 */
+val = s->smb_data1;
+break;
+case 0x07: /* SMBBLKDAT */
+val = s->smb_data[s->smb_index++];
+if (s->smb_index > 31)
+s->smb_index = 0;
+break;
+default:
+v
[Qemu-devel] qemu/hw ide.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/01/24 01:12:42 Modified files: hw : ide.c Log message: Fix DMA timeouts on FreeBSD, by Carlo Marcelo Arenas Belon. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ide.c?cvsroot=qemu&r1=1.51&r2=1.52 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu Makefile.target cpu-exec.c vl.h hw/gt64xxx...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/01/24 01:47:51 Modified files: . : Makefile.target cpu-exec.c vl.h hw : gt64xxx.c i8259.c mips_malta.c mips_r4k.c mips_timer.c target-mips: cpu.h exec.h op.c op_helper.c Added files: hw : mips_int.c Log message: Reworking MIPS interrupt handling, by Aurelien Jarno. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.140&r2=1.141 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemu&r1=1.88&r2=1.89 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.175&r2=1.176 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/gt64xxx.c?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/i8259.c?cvsroot=qemu&r1=1.19&r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemu&r1=1.4&r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemu&r1=1.31&r2=1.32 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_timer.c?cvsroot=qemu&r1=1.1&r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_int.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemu&r1=1.18&r2=1.19 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/exec.h?cvsroot=qemu&r1=1.15&r2=1.16 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemu&r1=1.20&r2=1.21 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemu&r1=1.27&r2=1.28 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] PIIX4 SMBus host, EEPROM device emulation
Windows 2000 boots and PC Wizard 2007 displays the following information under the Mainboard category: > SMBus/i2c Bus : Yes >> General Information Device : 82371AB/EB/MB PIIX4/E/M Power Management Controller Revision : 0 Frequency : 16 KHz Address : 0xB100 >> Device Capabilities (PCI) I/O Access : Yes Memory Access : Yes Bus Master Capable : Yes Special Cycle Recognition : No Memory Write & Invalidate : No VGA Palette Snoop : No Parity Error Response : No Cycle Wait : No System Error Line : No Fast Back-to-Back : No Detects Parity Errors : No User Defined Format : No PCI 66Mhz Bus Support : No New Capability List : No which hopefully means the patch doesn't break anything. --Ed ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
