Re: [Qemu-devel] [PATCH, RFC] Disable implicit self-modifying code support for RISC CPUs
On 11/4/07, Fabrice Bellard [EMAIL PROTECTED] wrote: Blue Swirl wrote: Hi, RISC CPUs don't support self-modifying code unless the affected area is flushed explicitly. This patch disables the extra effort for SMC. The changes in this version would affect all CPUs except x86, but I'd like to see if there are problems with some target, so that the committed change can be limited. Without comments, I'll just disable SMC for Sparc, as there are no problems. So please comment, especially if you want to opt in. For some reason, I can't disable all TB/TLB flushing, for example there was already one line with TARGET_HAS_SMC || 1, but removing the || 1 part causes crashing. Does anyone know why? With the current QEMU architecture, you cannot disable self-modifying code as you did. This is why I did not fully supported the TARGET_HAS_SMC flag. The problem is that the translator make the assumption that the RAM and the TB contents are consistent for example when handling exceptions. Suppressing this assumption is possible but requires more work. I think the conclusion is that we would need some kind of emulator for i-cache for any accurate emulation. And handling the boot loader may need an uncached mode. The performance benefit from disabling SMC is unnoticeable according to my benchmarks. Adding a TB flush to i-cache flushing made things worse. Moreover, SMC is hardly ever used on Sparc. I'll just commit the debug statement fixes and the fix that separates PAGE_READ from PAGE_EXEC for Sparc. Maybe this issue should be documented in qemu-tech.texi, there are also frequently some questions about caches.
[Qemu-devel] qemu exec.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/11/04 07:31:40 Modified files: . : exec.c Log message: Fix debug statements CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemur1=1.110r2=1.111
Re: [Qemu-devel] [PATCH, RFC] Disable implicit self-modifying code support for RISC CPUs
On Sun, 2007-11-04 at 09:12 +0200, Blue Swirl wrote: On 11/4/07, Fabrice Bellard [EMAIL PROTECTED] wrote: Blue Swirl wrote: Hi, RISC CPUs don't support self-modifying code unless the affected area is flushed explicitly. This patch disables the extra effort for SMC. The changes in this version would affect all CPUs except x86, but I'd like to see if there are problems with some target, so that the committed change can be limited. Without comments, I'll just disable SMC for Sparc, as there are no problems. So please comment, especially if you want to opt in. For some reason, I can't disable all TB/TLB flushing, for example there was already one line with TARGET_HAS_SMC || 1, but removing the || 1 part causes crashing. Does anyone know why? With the current QEMU architecture, you cannot disable self-modifying code as you did. This is why I did not fully supported the TARGET_HAS_SMC flag. The problem is that the translator make the assumption that the RAM and the TB contents are consistent for example when handling exceptions. Suppressing this assumption is possible but requires more work. I think the conclusion is that we would need some kind of emulator for i-cache for any accurate emulation. And handling the boot loader may need an uncached mode. The performance benefit from disabling SMC is unnoticeable according to my benchmarks. Adding a TB flush to i-cache flushing made things worse. Moreover, SMC is hardly ever used on Sparc. I'll just commit the debug statement fixes and the fix that separates PAGE_READ from PAGE_EXEC for Sparc. This patch is absolutely not needed. You have to directly call tlb_set_page_exec instead of tlb_set_page if you want to separate PAGE_READ from PAGE_EXEC. #ifdef TARGET_xxx should never occur in generic code and in that specific case, it's the Sparc target code that has to be fixed... Maybe this issue should be documented in qemu-tech.texi, there are also frequently some questions about caches. Yes, some documentation on such tricks can never hurt ! -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)
On Sun, 2007-11-04 at 01:51 +, Paul Brook wrote: If you take a close look, you'll find more variations between Linux ABIs for different CPUs than between all BSD implementations: common syscalls of all BSD flavors do the same thing (and have the same ABI whatever the CPU...). You'll also find very few variations between the syscalls common to BSD Linux because most of those directly map POSIX defined functions. Then, following the given argument, we never should try to share any code between linux-user for different targets, as the Linux ABI and behavior is different for different CPUs... I'd guess that the ones that are all the same are the ones that don't take any real effort to implement in the first place. If you can combine the implementations I'd also expect to be able to do cross emulation. e.g. run *BSD applications on a Linux host. This definitely works for simple cases, even in the extreme case of a windows host - as you say many syscalls map directly onto POSIX functions so there is only ever one implementation. Whether it works well enough for real applications or whole distributions of software I'm not so sure. If you can't do cross emulation I'm sceptical about how much they can be combined. Ooops... I should have been more precise. In my idea, it was BSD-on-Linux I was talking about. Let's say OpenBSD / NetBSD. FreeBSD has some specific tricks that might be difficult to map on Linux (or even other BSD), not even talking of Darwin which is quite impossible to emulate (or if one wants to emulate the IOkit...). The main difficulty of emulating BSD on Linux is the sysctl syscall, the trace facilites and the ioctls. I guess we can forget the ioctls... Most of the other syscalls mappings are quite like mapping one Linux port to another. -- J. Mayer [EMAIL PROTECTED] Never organized
[Qemu-devel] Gcc 4 building error
Hello. I have (GCC) 4.2.1, when i'm tried to build qemu from cvs, i've got such error: Code: make -C i386-softmmu all make[1]: Entering directory `/mnt/work/install/compil/qemu/qemu/i386-softmmu' gcc -Wall -O2 -g -fno-strict-aliasing -fno-reorder-blocks -fno-gcse -fno-tree-ch -fno-optimize-sibling-calls -fno-crossjumping -fno-align-labels -fno-align-jumps -fno-align-functions -fno-section-anchors -mpreferred-stack-boundary=2 -fomit-frame-pointer -I. -I.. -I/mnt/work/install/compil/qemu/qemu/target-i386 -I/mnt/work/install/compil/qemu/qemu -MMD -MP -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/mnt/work/install/compil/qemu/qemu/fpu -I/opt/soft/gnutls-1.7.18/include -DHAS_AUDIO -DHAS_AUDIO_CHOICE -I/mnt/work/install/compil/qemu/qemu/slirp -c -o op.o /mnt/work/install/compil/qemu/qemu/target-i386/op.c /mnt/work/install/compil/qemu/qemu/target-i386/ops_template_mem.h: In function 'op_shlb_user_T0_T1_cc': ../softmmu_header.h:174: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' ../softmmu_header.h:174: error: 'asm' operand has impossible constraints make[1]: *** [op.o] Error 1 make[1]: Leaving directory `/mnt/work/install/compil/qemu/qemu/i386-softmmu' make: *** [subdir-i386-softmmu] Error 2 is this qemu bug, or gcc? is there any patches to avoid it?
Re: [Qemu-devel] [PATCH, RFC] Disable implicit self-modifying code support for RISC CPUs
On 11/4/07, J. Mayer [EMAIL PROTECTED] wrote: On Sun, 2007-11-04 at 09:12 +0200, Blue Swirl wrote: On 11/4/07, Fabrice Bellard [EMAIL PROTECTED] wrote: Blue Swirl wrote: Hi, RISC CPUs don't support self-modifying code unless the affected area is flushed explicitly. This patch disables the extra effort for SMC. The changes in this version would affect all CPUs except x86, but I'd like to see if there are problems with some target, so that the committed change can be limited. Without comments, I'll just disable SMC for Sparc, as there are no problems. So please comment, especially if you want to opt in. For some reason, I can't disable all TB/TLB flushing, for example there was already one line with TARGET_HAS_SMC || 1, but removing the || 1 part causes crashing. Does anyone know why? With the current QEMU architecture, you cannot disable self-modifying code as you did. This is why I did not fully supported the TARGET_HAS_SMC flag. The problem is that the translator make the assumption that the RAM and the TB contents are consistent for example when handling exceptions. Suppressing this assumption is possible but requires more work. I think the conclusion is that we would need some kind of emulator for i-cache for any accurate emulation. And handling the boot loader may need an uncached mode. The performance benefit from disabling SMC is unnoticeable according to my benchmarks. Adding a TB flush to i-cache flushing made things worse. Moreover, SMC is hardly ever used on Sparc. I'll just commit the debug statement fixes and the fix that separates PAGE_READ from PAGE_EXEC for Sparc. This patch is absolutely not needed. You have to directly call tlb_set_page_exec instead of tlb_set_page if you want to separate PAGE_READ from PAGE_EXEC. #ifdef TARGET_xxx should never occur in generic code and in that specific case, it's the Sparc target code that has to be fixed... In fact Sparc code calls only tlb_set_page_exec, never tlb_set_page, so no fix is necessary. This reminds me that there is some TARGET_SPARC conditional code in fdc.c, I'll change those.
Re: [Qemu-devel] How to split vl.h
On 11/1/07, Fabrice Bellard [EMAIL PROTECTED] wrote:
Blue Swirl wrote:
Hi,
With the automatic dependency rule installed, modifying vl.h causes
all files to be recompiled. This is of course the correct action, but
it's a major slowdown for development too.
There must be an option in the Makefile to disable the automatic
dependency check.
How should we split vl.h into smaller pieces? Give each device a
header file, like m48t59? What about other stuff exported from vl.c?
The net result is that you will have dozens of header files with only
one line in them as most devices only export one function.
I have another solution: include all architecture specific files from
the main file. This actually makes the compilation faster and the
resulting binary is smaller (maybe faster). Changing the architecture
specific code needs no changes to vl.h, just a recompile of sun4m.c,
but this is instantaneous on my machine. Automatic dependencies also
handle this case. I guess some may find this style pretty ugly.
Similar approach could be taken with the network adapters, sound
cards, Slirp (for the speed, not vl.h effect) etc. by introducing .c
files that include all the others.
Index: qemu/Makefile.target
===
--- qemu.orig/Makefile.target 2007-11-04 08:17:00.0 +
+++ qemu/Makefile.target 2007-11-04 08:20:41.0 +
@@ -505,9 +505,7 @@
VL_OBJS+= fdc.o mc146818rtc.o serial.o m48t59.o
VL_OBJS+= cirrus_vga.o parallel.o ptimer.o
else
-VL_OBJS+= sun4m.o tcx.o pcnet.o iommu.o m48t59.o slavio_intctl.o
-VL_OBJS+= slavio_timer.o slavio_serial.o slavio_misc.o fdc.o esp.o sparc32_dma.o
-VL_OBJS+= cs4231.o ptimer.o
+VL_OBJS+= sun4m.o
endif
endif
ifeq ($(TARGET_BASE_ARCH), arm)
Index: qemu/hw/cs4231.c
===
--- qemu.orig/hw/cs4231.c 2007-11-04 08:17:00.0 +
+++ qemu/hw/cs4231.c 2007-11-04 08:20:41.0 +
@@ -164,7 +164,7 @@
return 0;
}
-void cs_init(target_phys_addr_t base, int irq, void *intctl)
+static void cs_init(target_phys_addr_t base, int irq, void *intctl)
{
int cs_io_memory;
CSState *s;
Index: qemu/hw/esp.c
===
--- qemu.orig/hw/esp.c 2007-11-04 08:17:00.0 +
+++ qemu/hw/esp.c 2007-11-04 08:20:41.0 +
@@ -551,7 +551,7 @@
return 0;
}
-void esp_scsi_attach(void *opaque, BlockDriverState *bd, int id)
+static void esp_scsi_attach(void *opaque, BlockDriverState *bd, int id)
{
ESPState *s = (ESPState *)opaque;
@@ -574,8 +574,8 @@
s-scsi_dev[id] = scsi_disk_init(bd, 0, esp_command_complete, s);
}
-void *esp_init(BlockDriverState **bd, target_phys_addr_t espaddr,
- void *dma_opaque, qemu_irq irq, qemu_irq *reset)
+static void *esp_init(BlockDriverState **bd, target_phys_addr_t espaddr,
+ void *dma_opaque, qemu_irq irq, qemu_irq *reset)
{
ESPState *s;
int esp_io_memory;
Index: qemu/hw/iommu.c
===
--- qemu.orig/hw/iommu.c 2007-11-04 08:17:00.0 +
+++ qemu/hw/iommu.c 2007-11-04 08:20:41.0 +
@@ -244,8 +244,8 @@
s-regs[IOMMU_AFAR] = addr;
}
-void sparc_iommu_memory_rw(void *opaque, target_phys_addr_t addr,
- uint8_t *buf, int len, int is_write)
+static void sparc_iommu_memory_rw(void *opaque, target_phys_addr_t addr,
+ uint8_t *buf, int len, int is_write)
{
int l;
uint32_t flags;
@@ -311,7 +311,7 @@
s-regs[IOMMU_CTRL] = IOMMU_VERSION;
}
-void *iommu_init(target_phys_addr_t addr)
+static void *iommu_init(target_phys_addr_t addr)
{
IOMMUState *s;
int iommu_io_memory;
Index: qemu/hw/slavio_intctl.c
===
--- qemu.orig/hw/slavio_intctl.c 2007-11-04 08:17:00.0 +
+++ qemu/hw/slavio_intctl.c 2007-11-04 08:20:41.0 +
@@ -201,7 +201,7 @@
slavio_intctlm_mem_writel,
};
-void slavio_pic_info(void *opaque)
+static void slavio_pic_info(void *opaque)
{
SLAVIO_INTCTLState *s = opaque;
int i;
@@ -212,7 +212,7 @@
term_printf(master: pending 0x%08x, disabled 0x%08x\n, s-intregm_pending, s-intregm_disabled);
}
-void slavio_irq_info(void *opaque)
+static void slavio_irq_info(void *opaque)
{
#ifndef DEBUG_IRQ_COUNT
term_printf(irq statistic code not compiled.\n);
@@ -349,10 +349,11 @@
slavio_check_interrupts(s);
}
-void *slavio_intctl_init(target_phys_addr_t addr, target_phys_addr_t addrg,
- const uint32_t *intbit_to_level,
- qemu_irq **irq, qemu_irq **cpu_irq,
- qemu_irq **parent_irq, unsigned int cputimer)
+static void *slavio_intctl_init(target_phys_addr_t addr,
+target_phys_addr_t addrg,
+
[Qemu-devel] qemu/hw grackle_pci.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/11/04 08:49:01 Modified files: hw : grackle_pci.c Log message: Fix grackle (in fact MPC106) PCI host bridge header to avoid confusing firmwares and OSes. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/grackle_pci.c?cvsroot=qemur1=1.7r2=1.8
[Qemu-devel] qemu/hw omap.c omap.h omap1_clk.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/11/04 11:42:11 Modified files: hw : omap.c omap.h omap1_clk.c Log message: Make accesses with wrong width also work as apparently real hardware allows them when the fault is disabled. Fix DMA register writes if target_phys_addr_t is 64-bit. Make more functions static. A timer hack to make PalmOS run in finite time (uses very short timer periods, much shorter than clocksource tick). Re-calculate internal clock rates on start-up. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.c?cvsroot=qemur1=1.16r2=1.17 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.h?cvsroot=qemur1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap1_clk.c?cvsroot=qemur1=1.1r2=1.2
[Qemu-devel] qemu/hw fdc.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/11/04 12:00:18 Modified files: hw : fdc.c Log message: Constification CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/fdc.c?cvsroot=qemur1=1.28r2=1.29
Re: [Qemu-devel] How to split vl.h
I have another solution: include all architecture specific files from the main file. I'd really rather not do this. I doubt it's going to be a win, as now you have to recompile the whole thing every time you change the implementation. At least with vl.h you only have to recompile when you change the interface. Paul
[Qemu-devel] qemu/hw omap.c omap.h omap_i2c.c omap_mmc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/11/04 12:19:22 Modified files: hw : omap.c omap.h omap_i2c.c omap_mmc.c Log message: Add register mappings in DSP space (must be accessible for MPU too). Don't set microwire CSR-busy bit too early. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.c?cvsroot=qemur1=1.17r2=1.18 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.h?cvsroot=qemur1=1.13r2=1.14 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap_i2c.c?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap_mmc.c?cvsroot=qemur1=1.2r2=1.3
[Qemu-devel] [PATCH] sparc32: hw/slavio_misc.c sysctrl register is 32 bits
The sysctrl register is actually 32 bits. Add code to access it as 32 bits.
Index: hw/slavio_misc.c
===
RCS file: /sources/qemu/qemu/hw/slavio_misc.c,v
retrieving revision 1.10
diff -p -u -r1.10 slavio_misc.c
--- hw/slavio_misc.c6 Oct 2007 11:28:21 - 1.10
+++ hw/slavio_misc.c4 Nov 2007 15:21:17 -
@@ -44,10 +44,12 @@ typedef struct MiscState {
qemu_irq irq;
uint8_t config;
uint8_t aux1, aux2;
-uint8_t diag, mctrl, sysctrl;
+uint8_t diag, mctrl;
+uint32_t sysctrl;
} MiscState;
#define MISC_SIZE 1
+#define SYSCTRL_SIZE 4
static void slavio_misc_update_irq(void *opaque)
{
@@ -116,13 +118,6 @@ static void slavio_misc_mem_writeb(void
MISC_DPRINTF(Write modem control %2.2x\n, val 0xff);
s-mctrl = val 0xff;
break;
-case 0x1f0:
-MISC_DPRINTF(Write system control %2.2x\n, val 0xff);
-if (val 1) {
-s-sysctrl = 0x2;
-qemu_system_reset_request();
-}
-break;
case 0xa00:
MISC_DPRINTF(Write power management %2.2x\n, val 0xff);
cpu_interrupt(cpu_single_env, CPU_INTERRUPT_HALT);
@@ -156,10 +151,6 @@ static uint32_t slavio_misc_mem_readb(vo
ret = s-mctrl;
MISC_DPRINTF(Read modem control %2.2x\n, ret);
break;
-case 0x1f0:
-MISC_DPRINTF(Read system control %2.2x\n, ret);
-ret = s-sysctrl;
-break;
case 0xa00:
MISC_DPRINTF(Read power management %2.2x\n, ret);
break;
@@ -178,6 +169,47 @@ static CPUWriteMemoryFunc *slavio_misc_m
slavio_misc_mem_writeb,
slavio_misc_mem_writeb,
};
+
+static uint32_t slavio_misc_mem_readl(void *opaque, target_phys_addr_t addr)
+{
+MiscState *s = opaque;
+uint32_t ret = 0;
+
+switch (addr) {
+case 0x1f0:
+MISC_DPRINTF(Read system control %08x\n, ret);
+ret = s-sysctrl;
+break;
+}
+return ret;
+}
+
+static void slavio_misc_mem_writel(void *opaque, target_phys_addr_t addr,
uint32_t val)
+{
+MiscState *s = opaque;
+
+switch (addr) {
+case 0x1f0:
+MISC_DPRINTF(Write system control %08x\n, val);
+if (val 1) {
+s-sysctrl = 0x2;
+qemu_system_reset_request();
+}
+break;
+}
+}
+
+static CPUReadMemoryFunc *slavio_misc_mem_read32[3] = {
+slavio_misc_mem_readl,
+slavio_misc_mem_readl,
+slavio_misc_mem_readl,
+};
+
+static CPUWriteMemoryFunc *slavio_misc_mem_write32[3] = {
+slavio_misc_mem_writel,
+slavio_misc_mem_writel,
+slavio_misc_mem_writel,
+};
static void slavio_misc_save(QEMUFile *f, void *opaque)
{
@@ -191,7 +223,7 @@ static void slavio_misc_save(QEMUFile *f
qemu_put_8s(f, s-aux2);
qemu_put_8s(f, s-diag);
qemu_put_8s(f, s-mctrl);
-qemu_put_8s(f, s-sysctrl);
+qemu_put_be32s(f, s-sysctrl);
}
static int slavio_misc_load(QEMUFile *f, void *opaque, int version_id)
@@ -208,20 +240,21 @@ static int slavio_misc_load(QEMUFile *f,
qemu_get_8s(f, s-aux2);
qemu_get_8s(f, s-diag);
qemu_get_8s(f, s-mctrl);
-qemu_get_8s(f, s-sysctrl);
+qemu_get_be32s(f, s-sysctrl);
return 0;
}
void *slavio_misc_init(target_phys_addr_t base, target_phys_addr_t power_base,
qemu_irq irq)
{
-int slavio_misc_io_memory;
+int slavio_misc_io_memory, slavio_misc_io_memory32;
MiscState *s;
s = qemu_mallocz(sizeof(MiscState));
if (!s)
return NULL;
+/* 8 bit registers */
slavio_misc_io_memory = cpu_register_io_memory(0, slavio_misc_mem_read,
slavio_misc_mem_write, s);
// Slavio control
cpu_register_physical_memory(base + 0x180, MISC_SIZE,
@@ -238,12 +271,15 @@ void *slavio_misc_init(target_phys_addr_
// Modem control
cpu_register_physical_memory(base + 0x1b0, MISC_SIZE,
slavio_misc_io_memory);
-// System control
-cpu_register_physical_memory(base + 0x1f0, MISC_SIZE,
- slavio_misc_io_memory);
// Power management
cpu_register_physical_memory(power_base, MISC_SIZE, slavio_misc_io_memory);
+/* 32 bit registers */
+slavio_misc_io_memory32 = cpu_register_io_memory(0,
slavio_misc_mem_read32, slavio_misc_mem_write32, s);
+// System control
+cpu_register_physical_memory(base + 0x1f0, SYSCTRL_SIZE,
+ slavio_misc_io_memory32);
+
s-irq = irq;
register_savevm(slavio_misc, base, 1, slavio_misc_save,
slavio_misc_load, s);
Re: [Qemu-devel] [PATCH] sparc32: hw/slavio_misc.c sysctrl register is 32 bits
Please use this version. The previous version didn't mask off the top
address bit.
The sysctrl register is actually 32 bits. Add code to access it as 32
bits.
Index: hw/slavio_misc.c
===
RCS file: /sources/qemu/qemu/hw/slavio_misc.c,v
retrieving revision 1.10
diff -p -u -r1.10 slavio_misc.c
--- hw/slavio_misc.c6 Oct 2007 11:28:21 - 1.10
+++ hw/slavio_misc.c4 Nov 2007 15:29:45 -
@@ -44,10 +44,12 @@ typedef struct MiscState {
qemu_irq irq;
uint8_t config;
uint8_t aux1, aux2;
-uint8_t diag, mctrl, sysctrl;
+uint8_t diag, mctrl;
+uint32_t sysctrl;
} MiscState;
#define MISC_SIZE 1
+#define SYSCTRL_SIZE 4
static void slavio_misc_update_irq(void *opaque)
{
@@ -116,13 +118,6 @@ static void slavio_misc_mem_writeb(void
MISC_DPRINTF(Write modem control %2.2x\n, val 0xff);
s-mctrl = val 0xff;
break;
-case 0x1f0:
-MISC_DPRINTF(Write system control %2.2x\n, val 0xff);
-if (val 1) {
-s-sysctrl = 0x2;
-qemu_system_reset_request();
-}
-break;
case 0xa00:
MISC_DPRINTF(Write power management %2.2x\n, val 0xff);
cpu_interrupt(cpu_single_env, CPU_INTERRUPT_HALT);
@@ -156,10 +151,6 @@ static uint32_t slavio_misc_mem_readb(vo
ret = s-mctrl;
MISC_DPRINTF(Read modem control %2.2x\n, ret);
break;
-case 0x1f0:
-MISC_DPRINTF(Read system control %2.2x\n, ret);
-ret = s-sysctrl;
-break;
case 0xa00:
MISC_DPRINTF(Read power management %2.2x\n, ret);
break;
@@ -178,6 +169,47 @@ static CPUWriteMemoryFunc *slavio_misc_m
slavio_misc_mem_writeb,
slavio_misc_mem_writeb,
};
+
+static uint32_t slavio_misc_mem_readl(void *opaque, target_phys_addr_t addr)
+{
+MiscState *s = opaque;
+uint32_t ret = 0;
+
+switch (addr 0xfff) {
+case 0x1f0:
+MISC_DPRINTF(Read system control %08x\n, ret);
+ret = s-sysctrl;
+break;
+}
+return ret;
+}
+
+static void slavio_misc_mem_writel(void *opaque, target_phys_addr_t addr,
uint32_t val)
+{
+MiscState *s = opaque;
+
+switch (addr 0xfff) {
+case 0x1f0:
+MISC_DPRINTF(Write system control %08x\n, val);
+if (val 1) {
+s-sysctrl = 0x2;
+qemu_system_reset_request();
+}
+break;
+}
+}
+
+static CPUReadMemoryFunc *slavio_misc_mem_read32[3] = {
+slavio_misc_mem_readl,
+slavio_misc_mem_readl,
+slavio_misc_mem_readl,
+};
+
+static CPUWriteMemoryFunc *slavio_misc_mem_write32[3] = {
+slavio_misc_mem_writel,
+slavio_misc_mem_writel,
+slavio_misc_mem_writel,
+};
static void slavio_misc_save(QEMUFile *f, void *opaque)
{
@@ -191,7 +223,7 @@ static void slavio_misc_save(QEMUFile *f
qemu_put_8s(f, s-aux2);
qemu_put_8s(f, s-diag);
qemu_put_8s(f, s-mctrl);
-qemu_put_8s(f, s-sysctrl);
+qemu_put_be32s(f, s-sysctrl);
}
static int slavio_misc_load(QEMUFile *f, void *opaque, int version_id)
@@ -208,20 +240,21 @@ static int slavio_misc_load(QEMUFile *f,
qemu_get_8s(f, s-aux2);
qemu_get_8s(f, s-diag);
qemu_get_8s(f, s-mctrl);
-qemu_get_8s(f, s-sysctrl);
+qemu_get_be32s(f, s-sysctrl);
return 0;
}
void *slavio_misc_init(target_phys_addr_t base, target_phys_addr_t power_base,
qemu_irq irq)
{
-int slavio_misc_io_memory;
+int slavio_misc_io_memory, slavio_misc_io_memory32;
MiscState *s;
s = qemu_mallocz(sizeof(MiscState));
if (!s)
return NULL;
+/* 8 bit registers */
slavio_misc_io_memory = cpu_register_io_memory(0, slavio_misc_mem_read,
slavio_misc_mem_write, s);
// Slavio control
cpu_register_physical_memory(base + 0x180, MISC_SIZE,
@@ -238,12 +271,15 @@ void *slavio_misc_init(target_phys_addr_
// Modem control
cpu_register_physical_memory(base + 0x1b0, MISC_SIZE,
slavio_misc_io_memory);
-// System control
-cpu_register_physical_memory(base + 0x1f0, MISC_SIZE,
- slavio_misc_io_memory);
// Power management
cpu_register_physical_memory(power_base, MISC_SIZE, slavio_misc_io_memory);
+/* 32 bit registers */
+slavio_misc_io_memory32 = cpu_register_io_memory(0,
slavio_misc_mem_read32, slavio_misc_mem_write32, s);
+// System control
+cpu_register_physical_memory(base + 0x1f0, SYSCTRL_SIZE,
+ slavio_misc_io_memory32);
+
s-irq = irq;
register_savevm(slavio_misc, base, 1, slavio_misc_save,
slavio_misc_load, s);
[Qemu-devel] qemu/hw fdc.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/11/04 16:58:08 Modified files: hw : fdc.c Log message: Fix Solaris breakage CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/fdc.c?cvsroot=qemur1=1.29r2=1.30
[Qemu-devel] qemu/hw fdc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/11/04 17:17:09 Modified files: hw : fdc.c Log message: Fix memory corruption: bdrv_read/write API has been changed to take nb_sectors instead of len in bytes but the fdc driver has never been fixed. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/fdc.c?cvsroot=qemur1=1.30r2=1.31
Re: [Qemu-devel] How to split vl.h
On Sun, 2007-11-04 at 12:17 +, Paul Brook wrote: I have another solution: include all architecture specific files from the main file. I'd really rather not do this. I doubt it's going to be a win, as now you have to recompile the whole thing every time you change the implementation. At least with vl.h you only have to recompile when you change the interface. What I feel about this is that adding a hw/hw.h, included in all hw/*.c files would greatly improve the situation: changing vl.h would lead to recompile the core emulator object files, changing hw/hw.h would lead to recompile the hardware library. A first pass to do this could be achieved with a minimal effort, just moving all prototypes and structure definitions that could be moved without having to change vl.c. Then, things could be refined to move some hardware specific stuffs from vl.c to hw subdirectory: for example, the USB or display registration functions could go in a file in hw which would avoid USBDevice or DisplayState to be defined globally. -- J. Mayer [EMAIL PROTECTED] Never organized
[Qemu-devel] qemu/hw slavio_misc.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/11/04 17:27:07 Modified files: hw : slavio_misc.c Log message: Change sysctrl register to 32 bits (original patch by Robert Reif) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/slavio_misc.c?cvsroot=qemur1=1.10r2=1.11
Re: [Qemu-devel] [PATCH] sparc32: hw/slavio_misc.c sysctrl register is 32 bits
On 11/4/07, Robert Reif [EMAIL PROTECTED] wrote: Please use this version. The previous version didn't mask off the top address bit. The sysctrl register is actually 32 bits. Add code to access it as 32 bits. Thanks. I made some changes to avoid updating the savevm format version.
Re: [Qemu-devel] How to split vl.h
On Sunday 04 November 2007, J. Mayer wrote: On Sun, 2007-11-04 at 12:17 +, Paul Brook wrote: I have another solution: include all architecture specific files from the main file. I'd really rather not do this. I doubt it's going to be a win, as now you have to recompile the whole thing every time you change the implementation. At least with vl.h you only have to recompile when you change the interface. What I feel about this is that adding a hw/hw.h, included in all hw/*.c files would greatly improve the situation: changing vl.h would lead to recompile the core emulator object files, changing hw/hw.h would lead to recompile the hardware library. Well, most of the core emulator doesn't depend on vl.h anyway. It's just the device emulation and host disk/display code. I not sure a single hw/hw.h file will give any benefit because there's a fair amount of interfacing between the target devices emulation and the host side interaction code. i.e. there's not much that's only used inside hw/. hw/ is about as big as most of the rest of qemu put together, so splitting that is probably going to get the biggest wins. How about dividing things up by category? e.g. Have header files for all of (in no particular order): - Things includes by everything - The block IO layer. - The character IO layer - Network IO layer. - Display interface. - Generic Device infrastructure (memory mapping, IRQs, etc). Maybe subdivide for common busses like scsi/usb/pci/i2c. - Prototypes for device emulation init routines. Each file can then include whichever categories it needs. Paul
Re: [Qemu-devel] How to split vl.h
Blue Swirl wrote: On 11/1/07, Fabrice Bellard [EMAIL PROTECTED] wrote: Blue Swirl wrote: Hi, With the automatic dependency rule installed, modifying vl.h causes all files to be recompiled. This is of course the correct action, but it's a major slowdown for development too. There must be an option in the Makefile to disable the automatic dependency check. How should we split vl.h into smaller pieces? Give each device a header file, like m48t59? What about other stuff exported from vl.c? The net result is that you will have dozens of header files with only one line in them as most devices only export one function. I have another solution: include all architecture specific files from the main file. This actually makes the compilation faster and the resulting binary is smaller (maybe faster). I it a solution? You always end up with the worst case of recompiling everything now. Changing the architecture specific code needs no changes to vl.h, just a recompile of sun4m.c, but this is instantaneous on my machine. Automatic dependencies also handle this case. I guess some may find this style pretty ugly. It is ugly. You basically re-invented gcc's -combine option but without avoiding the namespace problem of a single file scope. Thiemo
[Qemu-devel] qemu does not wait for gdb
Hello I'm trying to connect gdb to qemu and it seems not to work correctly. I mean it does not wait for gdb to connect. I perform the following command to do that: qemu -s -kernel arch/i386/boot/bzImage -hda root-2.4.20.img -append root=/dev/hda It just runs like this option hasn't been specified. No error message is displayed. I use qemu.0.9.0 under linux. Do You know what can be wrong. PS: sorry for posting to development mailing list but I cannot subscribe to Qemu for Linux. I receive the Hacking attempt message when clicking the register button. Where can I report problem with subscription ? Thank You for help __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [Qemu-devel] qemu does not wait for gdb
Pawel K wrote: Hello I'm trying to connect gdb to qemu and it seems not to work correctly. I mean it does not wait for gdb to connect. I perform the following command to do that: qemu -s -kernel arch/i386/boot/bzImage -hda root-2.4.20.img -append root=/dev/hda It just runs like this option hasn't been specified. No error message is displayed. You need to add an uppercase -S as well if you want it to wait for gdb. Thiemo
Re: [Qemu-devel] How to split vl.h
On Sun, 2007-11-04 at 17:54 +, Paul Brook wrote: On Sunday 04 November 2007, J. Mayer wrote: On Sun, 2007-11-04 at 12:17 +, Paul Brook wrote: I have another solution: include all architecture specific files from the main file. I'd really rather not do this. I doubt it's going to be a win, as now you have to recompile the whole thing every time you change the implementation. At least with vl.h you only have to recompile when you change the interface. What I feel about this is that adding a hw/hw.h, included in all hw/*.c files would greatly improve the situation: changing vl.h would lead to recompile the core emulator object files, changing hw/hw.h would lead to recompile the hardware library. Well, most of the core emulator doesn't depend on vl.h anyway. It's just the device emulation and host disk/display code. I not sure a single hw/hw.h file will give any benefit because there's a fair amount of interfacing between the target devices emulation and the host side interaction code. i.e. there's not much that's only used inside hw/. hw/ is about as big as most of the rest of qemu put together, so splitting that is probably going to get the biggest wins. hw library contains a lot of code but is not all is compiled for all targets. How about dividing things up by category? e.g. Have header files for all of (in no particular order): - Things includes by everything - The block IO layer. - The character IO layer - Network IO layer. - Display interface. - Generic Device infrastructure (memory mapping, IRQs, etc). Maybe subdivide for common busses like scsi/usb/pci/i2c. - Prototypes for device emulation init routines. Each file can then include whichever categories it needs. Yes, it could be a great solution. Mine was just the quick and less effort proposal ! It seems you also should have headers for target specific declarations. This would avoid recompiling all targets when working on devices specific to only one or a few of them. -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] How to split vl.h
I not sure a single hw/hw.h file will give any benefit because there's a fair amount of interfacing between the target devices emulation and the host side interaction code. i.e. there's not much that's only used inside hw/. hw/ is about as big as most of the rest of qemu put together, so splitting that is probably going to get the biggest wins. hw library contains a lot of code but is not all is compiled for all targets. *shrug*. When I'm developing I generally only build the target I'm interested in anyway. If I'm doing a verification build before committing I'll build from scratch anyway. I've been bitten by faulty dependency checking (automatic or otherwise) often enough that I don't trust it for anything important. Paul
[Qemu-devel] qemu vl.h hw/omap.c hw/omap.h hw/omap1_clk.c hw...
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/11/04 22:53:50 Modified files: . : vl.h hw : omap.c omap.h omap1_clk.c palm.c tsc210x.c Log message: Zeroing ITR shouldn't ack irq zero. Fix PWT PWL clocks, fix user refcounting for clocks, add 'hsab_ck' and 'usb_w2fc_ck'. Fix TCMI register addresses. Implement OMAP McBSP controller and connection to I2S-compatible CODECs. Add audio support for TSC2102 as an I2S CODEC. Connect TSC2102 I2S interface to CPU's McBSP1 interface in the Palm Tungsten|E. Correct '' instead of '' typos. Implement GPIO PIN_CONTROL register (not in OMAP310 TRM, from OMAP1510). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.286r2=1.287 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.c?cvsroot=qemur1=1.18r2=1.19 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.h?cvsroot=qemur1=1.14r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap1_clk.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/palm.c?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/tsc210x.c?cvsroot=qemur1=1.2r2=1.3
Re: [Qemu-devel] How to split vl.h
Paul Brook wrote: I not sure a single hw/hw.h file will give any benefit because there's a fair amount of interfacing between the target devices emulation and the host side interaction code. i.e. there's not much that's only used inside hw/. hw/ is about as big as most of the rest of qemu put together, so splitting that is probably going to get the biggest wins. hw library contains a lot of code but is not all is compiled for all targets. *shrug*. When I'm developing I generally only build the target I'm interested in anyway. If I'm doing a verification build before committing I'll build from scratch anyway. I've been bitten by faulty dependency checking (automatic or otherwise) often enough that I don't trust it for anything important. Dependency checking appears to work well now. Thiemo
[Qemu-devel] sparc hflags support?
I'm looking at adding more complete support for different sparc32 CPUs, MMUs, cache controllers and systems. Each CPU/MMU/cache controller combination is slightly different and requires its own unique state. For example the two CPUs currently supported save the boot mode in different bits in the MMU control register: 0x2000 for the SuperSparc and 0x4000 for the TurboSparc. Others bits will need to be saved in the MMU and cache controllers as better hardware emulation is added. It looks like other architectures handle this by computing hflags in the target directories but sparc determines the flags value to save in common code. Are there plans to add hflags support to sparc? I'm willing work on it but I don't have the experience yet to tackle a job like this without help.
Re: [Qemu-devel] sparc hflags support?
On Sunday 04 November 2007, Robert Reif wrote: I'm looking at adding more complete support for different sparc32 CPUs, MMUs, cache controllers and systems. Each CPU/MMU/cache controller combination is slightly different and requires its own unique state. For example the two CPUs currently supported save the boot mode in different bits in the MMU control register: 0x2000 for the SuperSparc and 0x4000 for the TurboSparc. Others bits will need to be saved in the MMU and cache controllers as better hardware emulation is added. If it's something that only changes rarely (e.g. when switching from early boot to a real OS environment) you can just do a tb flush. Does mmu/cache mode actually effect the instruction semantics? Paul
Re: [Qemu-devel] Gcc 4 building error
Its known bug of gcc4. you should compile on gcc 3. Please check the following qemu FAQ. http://calamari.reverse-dns.net:980/cgi-bin/moin.cgi/FrequentlyAskedQuestions#head-1dd86241b11d36963df140c9f6ab46ef402d4244 Thanks Atsushi SAKAI Alexander [EMAIL PROTECTED] wrote: Hello. I have (GCC) 4.2.1, when i'm tried to build qemu from cvs, i've got such error: Code: make -C i386-softmmu all make[1]: Entering directory `/mnt/work/install/compil/qemu/qemu/i386-softmmu' gcc -Wall -O2 -g -fno-strict-aliasing -fno-reorder-blocks -fno-gcse -fno-tree-ch -fno-optimize-sibling-calls -fno-crossjumping -fno-align-labels -fno-align-jumps -fno-align-functions -fno-section-anchors -mpreferred-stack-boundary=2 -fomit-frame-pointer -I. -I.. -I/mnt/work/install/compil/qemu/qemu/target-i386 -I/mnt/work/install/compil/qemu/qemu -MMD -MP -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/mnt/work/install/compil/qemu/qemu/fpu -I/opt/soft/gnutls-1.7.18/include -DHAS_AUDIO -DHAS_AUDIO_CHOICE -I/mnt/work/install/compil/qemu/qemu/slirp -c -o op.o /mnt/work/install/compil/qemu/qemu/target-i386/op.c /mnt/work/install/compil/qemu/qemu/target-i386/ops_template_mem.h: In function 'op_shlb_user_T0_T1_cc': ../softmmu_header.h:174: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' ../softmmu_header.h:174: error: 'asm' operand has impossible constraints make[1]: *** [op.o] Error 1 make[1]: Leaving directory `/mnt/work/install/compil/qemu/qemu/i386-softmmu' make: *** [subdir-i386-softmmu] Error 2 is this qemu bug, or gcc? is there any patches to avoid it?
[Qemu-devel] qemu/hw fdc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/11/05 03:11:37 Modified files: hw : fdc.c Log message: No functional changes: remove dead code and fix indentation wrapping lines. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/fdc.c?cvsroot=qemur1=1.31r2=1.32
