[Qemu-devel] [PATCH] hw/pxa2xx_dma.c
The following patch fixes the problem that DMA transfers are not performed when
the DCSR_STOPINTR bit is set.
--
Thorsten
Index: hw/pxa2xx_dma.c
===
RCS file: /sources/qemu/qemu/hw/pxa2xx_dma.c,v
retrieving revision 1.5
diff -u -r1.5 pxa2xx_dma.c
--- hw/pxa2xx_dma.c 11 Nov 2007 19:47:58 - 1.5
+++ hw/pxa2xx_dma.c 15 Nov 2007 09:28:22 -
@@ -186,7 +186,8 @@
s-running = 1;
for (c = 0; c s-channels; c ++) {
ch = s-chan[c];
-
+
+ch-state = ~DCSR_STOPINTR;
while ((ch-state DCSR_RUN) !(ch-state DCSR_STOPINTR)) {
/* Test for pending requests */
if ((ch-cmd (DCMD_FLOWSRC | DCMD_FLOWTRG)) !ch-request)
[Qemu-devel] [PATCH] Gumstix board support
Hi. The following patch adds support for Gumstix connex boards. A working flash
image (after unpacking) is
http://omnibus.uni-freiburg.de/~zitteret/files/qemu/flash.bz2
Comments?
--
Thorsten
Index: Makefile.target
===
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.223
diff -u -r1.223 Makefile.target
--- Makefile.target 11 Nov 2007 14:26:46 - 1.223
+++ Makefile.target 15 Nov 2007 09:28:21 -
@@ -499,6 +499,7 @@
VL_OBJS+= arm-semi.o
VL_OBJS+= pxa2xx.o pxa2xx_pic.o pxa2xx_gpio.o pxa2xx_timer.o pxa2xx_dma.o
VL_OBJS+= pxa2xx_lcd.o pxa2xx_mmci.o pxa2xx_pcmcia.o max111x.o max7310.o
+VL_OBJS+= pflash_cfi01.o gumstix.o
VL_OBJS+= spitz.o ads7846.o ide.o serial.o nand.o ecc.o wm8750.o
VL_OBJS+= omap.o omap_lcdc.o omap1_clk.o omap_mmc.o omap_i2c.o
VL_OBJS+= palm.o tsc210x.o
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.361
diff -u -r1.361 vl.c
--- vl.c11 Nov 2007 20:14:28 - 1.361
+++ vl.c15 Nov 2007 09:28:22 -
@@ -7435,6 +7435,7 @@
qemu_register_machine(palmte_machine);
qemu_register_machine(lm3s811evb_machine);
qemu_register_machine(lm3s6965evb_machine);
+qemu_register_machine(connex_machine);
#elif defined(TARGET_SH4)
qemu_register_machine(shix_machine);
qemu_register_machine(r2d_machine);
@@ -8260,7 +8261,8 @@
if (!linux_boot net_boot == 0
hd_filename[0] == '\0'
(cdrom_index = 0 hd_filename[cdrom_index] == '\0')
-fd_filename[0] == '\0')
+fd_filename[0] == '\0'
+pflash_filename[0] == '\0')
help(1);
/* boot to floppy or the default cd if no hard disk defined yet */
Index: vl.h
===
RCS file: /sources/qemu/qemu/vl.h,v
retrieving revision 1.295
diff -u -r1.295 vl.h
--- vl.h11 Nov 2007 17:56:38 - 1.295
+++ vl.h15 Nov 2007 09:28:22 -
@@ -1254,6 +1254,9 @@
extern QEMUMachine borzoipda_machine;
extern QEMUMachine terrierpda_machine;
+/* gumstix.c */
+extern QEMUMachine connex_machine;
+
/* palm.c */
extern QEMUMachine palmte_machine;
Index: hw/gumstix.c
===
RCS file: hw/gumstix.c
diff -N hw/gumstix.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ hw/gumstix.c15 Nov 2007 09:28:22 -
@@ -0,0 +1,73 @@
+/*
+ * Gumstix Platforms
+ *
+ * Copyright (c) 2007 by Thorsten Zitterell [EMAIL PROTECTED]
+ *
+ * Code based on spitz platform by Andrzej Zaborowski [EMAIL PROTECTED]
+ *
+ * This code is licensed under the GNU GPL v2.
+ */
+
+#include vl.h
+
+static void connex_smc_irq(void *opaque, int line, int level)
+{
+ /* Interrupt line of NIC is connected to GPIO line 36 */
+struct pxa2xx_state_s *cpu = (struct pxa2xx_state_s *) opaque;
+pxa2xx_gpio_set(cpu-gpio, 36, level);
+}
+
+/* Board init. */
+enum gumstix_model_e { connex };
+
+static void gumstix_common_init(int ram_size, int vga_ram_size,
+DisplayState *ds, const char *kernel_filename,
+const char *kernel_cmdline, const char *initrd_filename,
+const char *cpu_model, enum gumstix_model_e model)
+{
+ struct pxa2xx_state_s *cpu;
+
+ uint32_t gumstix_rom = 0x0200;
+ uint32_t gumstix_ram = 0x0800;
+
+ if (ram_size (gumstix_ram + gumstix_rom + PXA2XX_INTERNAL_SIZE)) {
+ fprintf(stderr, This platform requires %i bytes of memory\n,
+ gumstix_ram + gumstix_rom +
PXA2XX_INTERNAL_SIZE);
+ exit(1);
+ }
+
+ cpu = pxa255_init(gumstix_ram, ds);
+
+ if (pflash_table[0] == NULL) {
+ fprintf(stderr, A flash image must be given with the 'pflash'
parameter\n);
+ exit(1);
+ }
+
+ if (!pflash_register(0x, gumstix_ram + PXA2XX_INTERNAL_SIZE,
pflash_table[0], 128*1024, 128, 2, 0, 0, 0, 0)) {
+ fprintf(stderr, qemu: Error register flash memory.\n);
+ exit(1);
+ }
+
+ cpu-env-regs[15] = 0x;
+
+ qemu_irq *irq = qemu_allocate_irqs(connex_smc_irq, cpu, 1);
+ smc91c111_init(nd_table[0], 0x04000300, *irq);
+}
+
+static void connex_init(int ram_size, int vga_ram_size,
+const char *boot_device, DisplayState *ds,
+const char **fd_filename, int snapshot,
+const char *kernel_filename, const char *kernel_cmdline,
+const char *initrd_filename, const char *cpu_model)
+{
+gumstix_common_init(ram_size, vga_ram_size, ds, kernel_filename,
+kernel_cmdline, initrd_filename, cpu_model, connex);
+}
+
+
+
+QEMUMachine connex_machine = {
+connex,
+Gumstix Connex (PXA255),
+connex_init,
+};
Index: hw/pflash_cfi01.c
Re: [Qemu-devel] Help needed! dyngen: Unsupported ELF class
On Thursday 15 November 2007, test test wrote: -- -- dyngen: Unsupported ELF class make[1]: *** [op.h] Error 1 -- -- What's the problem? Please help! For better analysis of the problem, I put the result of configure as below: WARNING: gcc looks like gcc 4.x Looking for gcc 3.x Found gcc-3.3 [...] host CPU x86_64 Is it possible that your gcc-3.3 is an i386 compiler? If so, edit config-host.mak and replace ARCH=x86_64 with ARCH=i386, then rebuild. CU Uli -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
[Qemu-devel] qemu/winME/98
Is it possible to get networking to work with ME/98 as guest ? No network device shows up in this case as in XP which works fine. Command I use; qemu -hda Win98.img -net nic,model=rtl8139 -net user
RE: [Qemu-devel] USB Asynchronous I/O
I believe you can do it similar to the way I did for isochronous transfers in usb-linux.c. Remember that using SUBMITURB and REAPURBNDELAY ioctls, you need to add another signal and signal handler for the async bulk, and there might be some issues in the ohci/uhci because they currently assume only isochronous transfers are async. A minute ago I tried to implement the bulk transfers using SUBMITURB and REAPURB (which blocks until response) but it seems to hang qemu upon connecting a disk-on-key. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Salil Bijur Sent: Wednesday, November 14, 2007 11:49 PM To: qemu-devel@nongnu.org Subject: [Qemu-devel] USB Asynchronous I/O Hello, I've been testing Bluetooth-USB in QEMU for an arm-based processor with a Linux guest. When a bluetooth dongle is added, there is a continuous sending of bulk and interrupt packets synchronously (using the USBDEVFS_BULK ioctl) making qemu extremely slow and unusable. I wanted to know if it is a good idea to send these bulk and interrupt transfers asynchronously using the SUBMITURB and REAPURBNDELAY ioctls in a way similar as isochronous transfers in usb-linux.c. Is there any reason why only isochronous packets are being sent asynchronously when the same can be done for other types? Thanks, Salil
[Qemu-devel] Guest OS kernel panic when using '-kernel-kqemu'
I'm currently running into a problem when running recent Linux kernels as a guest under QEMU with KQEMU kernel acceleration. My problem is that early in the boot process the guest kernel panics, the host OS appears to be unaffected. The panic can be different depending on the guest Linux distribution/kernel but the panic is repeatable and consistent. In all cases, removing the '-kernel-kqemu' flag and only making use of userspace acceleration appears to solve the problem. Using both the QEMU monitor and the linux lsmod reference count I have verified that KQEMU is being used by QEMU. For reference, the host OS is a Gentoo 2007.0 x86 system with the Gentoo Linux kernel 2.6.23-r1, QEMU 0.9.0 and KQEMU 1.3.0_pre11; greater detail can be found in the Gentoo bug report[1]. I have also noticed this on other Gentoo based systems as well. I am able to reproduce this on a regular basis using the Fedora 8 install DVD and the following command line: # qemu -m 256 -kernel-kqemu -cdrom Fedora-8-i386-DVD.iso -boot d f8.img However, using a sample image[2] and the following command line I do not see any problems: # qemu -m 256 -kernel-kqemu linux-0.2.img Any assistance or pointers to a solution would be greatly appreciated. If there is anything I can do to help track down the problem further please let me know. Thanks, -Paul [1] http://bugs.gentoo.org/show_bug.cgi?id=199151 [2] http://fabrice.bellard.free.fr/qemu/linux-0.2.img.bz2
Re: [Qemu-devel] qemu/winME/98
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is it possible to get networking to work with ME/98 as guest ? No network device shows up in this case as in XP which works fine. Command I use; qemu -hda Win98.img -net nic,model=rtl8139 -net user maybe because you have to download the rtl8139 driver from realtek for Win98. Had to do the same thing for Win98SE. Since there's no networking you can use vvfat or a floppy image to let the win98 instance see the file. Ben
Re: [Qemu-devel] qemu/winME/98
Thanks Ben I understand. For some silly and flawed reason I assumed that it was an emulation driver from qemu recognized by windows. Reason for my assumption happened, since I cannot delete the RTL driver in WinXP and assumed it was somehow tied to qemu. Obviously I am wrong. Thanks for the clarification. Ben Taylor wrote: "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: Is it possible to get networking to work with ME/98 as guest ? No network device shows up in this case as in XP which works fine. Command I use; qemu -hda Win98.img -net nic,model=rtl8139 -net user maybe because you have to download the rtl8139 driver from realtek for Win98. Had to do the same thing for Win98SE. Since there's no networking you can use vvfat or a floppy image to let the win98 instance see the file. Ben
[Qemu-devel] qemu/linux-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/15 15:27:03 Modified files: linux-user : main.c Log message: x86_64 fixes CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.151r2=1.152
[Qemu-devel] qemu/linux-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/15 15:37:50 Modified files: linux-user : main.c Log message: force correct ppc64 cpu CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.152r2=1.153
[Qemu-devel] win98se guest regression
I have a couple of win98se guests that I keep around for testing and upgrade tests and the like. The current CVS code has no problem booting these images, but the first time I do anything (like read the cdrom, or change directories in windows explorer), the guest just hangs. This seems like a regression. This happens on both iso images and real cdrom's. I realize that Win98 is a bit old at this point, but it's so lightweight compared to Win2K and WinXP, and it's been a good test for several years. Anyone have an idea or seen this behavior? Thanks, Ben
[Qemu-devel] Guest OS kernel panic when using '-kernel-kqemu'
I'm currently running into a problem when running recent Linux kernels as a guest under QEMU with KQEMU kernel acceleration. My problem is that early in the boot process the guest kernel panics, the host OS appears to be unaffected. The panic can be different depending on the guest Linux distribution/kernel but the panic is repeatable and consistent. In all cases, removing the '-kernel-kqemu' flag and only making use of userspace acceleration appears to solve the problem. Using both the QEMU monitor and the linux lsmod reference count I have verified that KQEMU is being used by QEMU. For reference, the host OS is a Gentoo 2007.0 x86 system with the Gentoo Linux kernel 2.6.23-r1, QEMU 0.9.0 and KQEMU 1.3.0_pre11; greater detail can be found in the Gentoo bug report[1]. I have also noticed this on other Gentoo based systems as well. I am able to reproduce this on a regular basis using the Fedora 8 install DVD and the following command line: # qemu -m 256 -kernel-kqemu -cdrom Fedora-8-i386-DVD.iso -boot d f8.img However, using a sample image[2] and the following command line I do not see any problems: # qemu -m 256 -kernel-kqemu linux-0.2.img Any assistance or pointers to a solution would be greatly appreciated. If there is anything I can do to help track down the problem further please let me know. Thanks, -Paul [1] http://bugs.gentoo.org/show_bug.cgi?id=199151 [2] http://fabrice.bellard.free.fr/qemu/linux-0.2.img.bz2
Re: [Qemu-devel] [PATCH] add iommu version to sparc32
On 11/13/07, Robert Reif [EMAIL PROTECTED] wrote: Add iommu version to sparc32. Also reset iommu after initialization. Should the version be tied to CPU model instead of machine type? At least for Turbosparc this seems to be the case. Older CPUs may have separate chips for IU and IOMMU. Otherwise the patch looks good, thanks.
Re: [Qemu-devel] [PATCH] sparc32 asi cleanups and debug printf
On 11/10/07, Robert Reif [EMAIL PROTECTED] wrote: Blue Swirl wrote: DPRINTF_ASI would be nice. Here is a revised patch: Thanks. The patch didn't apply completely. I noticed that there are some too long lines, they should be wrapped. Module reset register should be in a different patch. Cache ASIs are implemented, they just do nothing, so the debug text should only apply to the store buffer (but not Ross I-cache flush?) and breakpoint ASIs. This by the way highlights that there should be a mechanism to register CPU specific ASIs and their handlers so that these ASI conflicts can be resolved. Because on Sparc32 we know the ASI at translation time, the handler can be selected then to get a small speedup.
[Qemu-devel] qemu vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 07/11/15 19:04:09 Modified files: . : vl.c Log message: Init dumb display if no others available. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.361r2=1.362
Re: [Qemu-devel] Alpha build failure: dyngen picking out a nameless symbol
On 11/14/07, Shaddy Baddah [EMAIL PROTECTED] wrote:
Hi,
I am building qemu from CVS, on a sun4u machine. I have used the
following configure command to ensure a sun4m userland build:
../qemu/configure --prefix=/opt/qemu-cvs --sparc_cpu=v8
I get the following message confirming the use of GCC 3:
Looking for gcc 3.x
Found gcc-3.4
Eventually, I get the error I have included at the base of this email. I
have attached the op.h generated. As you will be able to see from the
line below, a nameless symbol is being referenced (after the ):
op.h:24:*(uint32_t *)(gen_code_ptr + 0) = ((*(uint32_t
*)(gen_code_ptr + 0)) ~0x3f) | long)() + 0) 10) 0x3f);
^
I've followed the dyngen code as best as I can, and AFAICT that code is
right. The symbol referenced is nameless in the ELF symbol table.
The problem is in op_reset_FT0. Source is like this:
void OPPROTO glue(op_reset_FT, REG) (void)
{
glue(FT, REG) = 0;
RETURN();
}
The code generated for op_reset_FT0 is like this:
.section.rodata.cst8,aM,@progbits,8
.align 8
.LLC0:
.long 0
.long 0
.section.text
.align 4
.global op_reset_FT0
.type op_reset_FT0, #function
.proc 020
op_reset_FT0:
.LLFB152:
.loc 1 30 0
!#PROLOGUE# 0
!#PROLOGUE# 1
.loc 1 31 0
sethi %hi(.LLC0), %g1
ldd [%g1+%lo(.LLC0)], %f8
std %f8, [%g6+1176]
.loc 1 32 0
nop
retl
nop
.LLFE152:
.size op_reset_FT0, .-op_reset_FT0
So gcc puts the zero constant to .rodata.cst8 and generates code to
load the zero value from this location. This method is not supported
by dyngen for Sparc, but ARM uses similar method for all (?)
constants.
SV: [Qemu-devel] qemu Changelog Makefile.target cpu-exec.c qemu-...
This seems great! But does this mean that QEMU has support for a subset of the ARM11 cores? Also, I'm curious about ARMs position to this. I know that there has been a licence clause that prohibits you from modelling ARM v6 CPU if you download the ARMARM for v6 on their homepage. Is this solution based on information derived from other sources than the ARMARM or have ARM changed their opinion? /Best regards Tobbe -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Paul Brook Skickat: den 11 november 2007 01:05 Till: qemu-devel@nongnu.org Ämne: [Qemu-devel] qemu Changelog Makefile.target cpu-exec.c qemu-... CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 07/11/11 00:04:50 Modified files: . : Changelog Makefile.target cpu-exec.c qemu-doc.texi vl.c vl.h fpu: softfloat-native.h softfloat.c softfloat.h hw : arm_boot.c arm_gic.c arm_sysctl.c integratorcp.c pl011.c pxa2xx.c realview.c versatilepb.c target-arm : cpu.h exec.h helper.c op.c op_helper.c op_mem.h translate.c Added files: hw : armv7m.c armv7m_nvic.c mpcore.c pl022.c pl061.c realview_gic.c ssd0303.c ssd0323.c stellaris.c target-arm : op_addsub.h op_neon.h Log message: ARMv7 support. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Changelog?cvsroot=qemur1=1.146r2= 1.147 http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.2 19r2=1.220 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemur1=1.122r2 =1.123 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.164 r2=1.165 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.357r2=1.358 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.292r2=1.293 http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat-native.h?cvsroot=qemu r1=1.11r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat.c?cvsroot=qemur1=1.6 r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat.h?cvsroot=qemur1=1.8 r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm_boot.c?cvsroot=qemur1=1.9r 2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm_gic.c?cvsroot=qemur1=1.7r2 =1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm_sysctl.c?cvsroot=qemur1=1.4 r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/integratorcp.c?cvsroot=qemur1=1 .23r2=1.24 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl011.c?cvsroot=qemur1=1.8r2=1 .9 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx.c?cvsroot=qemur1=1.19r2 =1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview.c?cvsroot=qemur1=1.13; r2=1.14 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/versatilepb.c?cvsroot=qemur1=1. 19r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/armv7m.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/armv7m_nvic.c?cvsroot=qemurev=1 .1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mpcore.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl022.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl061.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview_gic.c?cvsroot=qemurev= 1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ssd0303.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ssd0323.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/stellaris.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/cpu.h?cvsroot=qemur1=1. 37r2=1.38 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/exec.h?cvsroot=qemur1=1 .14r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/helper.c?cvsroot=qemur1 =1.25r2=1.26 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/op.c?cvsroot=qemur1=1.2 7r2=1.28 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/op_helper.c?cvsroot=qemu r1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/op_mem.h?cvsroot=qemur1 =1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/translate.c?cvsroot=qemu r1=1.57r2=1.58 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/op_addsub.h?cvsroot=qemu rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/op_neon.h?cvsroot=qemur ev=1.1
Re: [Qemu-devel] [PATCH] add iommu version to sparc32
Add iommu version to sparc32. Also reset iommu after initialization. Should the version be tied to CPU model instead of machine type? At least for Turbosparc this seems to be the case. On SMP systems the IOMMU is on the system board in a separate ASIC. On single CPU systems the IOMMU is integrated into the CPU. Without checking the FEH, the SS 5 was the only single CPU system that shipped with more than one family of CPUs (MicroSparc II and TurboSparc and they do have different IOMMU versions). That could be special cased. Unfortunately QEMU will allow you to specify unrealistic systems. We should probably add allowable CPU types to specific machine types to catch this.
Re: [Qemu-devel] Alpha build failure: dyngen picking out a nameless symbol
So gcc puts the zero constant to .rodata.cst8 and generates code to load the zero value from this location. This method is not supported by dyngen for Sparc, but ARM uses similar method for all (?) constants. Not quite. ARM puts constant pools inline with the code, not in rodata. This is a fairly fundamental property of the arm architecture. Unlike most other risc architectures arm does not really have any other mechanism for loading addresses/large values. Dyngen has a nontrivial amount of special code to handle this. Paul
[Qemu-devel] RFC: fix for random Qemu crashes
Some may have experienced of having some Qemu builds crashing, apparently at random places, but in a reproducable way. I found one reason for this crashes: it appears that with the growth of the op.c file, there may be cases where we could reach the inlining limits of gcc. In such a case, gcc would not inline some declared inline function but would emit a call and provide a separate function. Unfortunately, this is not acceptable in op.o context as it will slowdown the emulation and because the call is likely to break the specific compilation rules (ie reserved registers) used while compiling op.o I found some workaround to avoid this behavior and I'd like to get opinions about it. The first idea is to change all occurences of 'inline' with 'always_inline' in all headers included in op.c. It then appeared to me that always_inline is not globally declared and that the definition is duplicated in vl.h and exec-all.h. But it's not declared in darwin-user/qemu.h and linux-user/qemu.h, which is not consistent with the declaration in vl.h. Further investigations showed me that the osdep.h header is the one that is actually included everywhere. Even if those are more compiler than OS dependent, I decided to move the definitions for glue, tostring, likely, unlikely, always_inline and REGPARM to this header so they can be globally used. I also changed the include orders in darwin-user/qemu.h to be sure this header will be included first. This patch is attached in common_defs.diff. Giving this patch, I've been able to replace all occurence of 'inline' with 'always_inline' in all headers included from op.c (given the generated .d file). Some would say I'd better add a #define inline always_inline somewhere. I personnally dislike this solution as this kind of macro as it tends to expand recursivally (always_inline definition contains the inline word) and this may lead to compilation warnings or errors in some context; one could do tests using the linux kernel headers to get convinced that it can happen. Then, I choosed to replace 'inline' by 'always_inline', which is more invasive but have less risks of side effects. The diff is attached in always_inline.diff. The last thing that helps solve the problem is to change the inlining limits of gcc, at least to compile the op.o file.Unfortunatelly, there is no way to disable those limits (I checked in the source code), then I put them to an arbitrary high level. I also added the -funit-at-a-time switch, as this kind of optimisation would not be relevant in op.o context. The diff is attached in gcc_inline_limits.diff. Please comment. -- J. Mayer [EMAIL PROTECTED] Never organized Index: exec-all.h === RCS file: /sources/qemu/qemu/exec-all.h,v retrieving revision 1.70 diff -u -d -d -p -r1.70 exec-all.h --- exec-all.h 4 Nov 2007 02:24:57 - 1.70 +++ exec-all.h 15 Nov 2007 22:58:45 - @@ -21,36 +21,6 @@ /* allow to see translation results - the slowdown should be negligible, so we leave it */ #define DEBUG_DISAS -#ifndef glue -#define xglue(x, y) x ## y -#define glue(x, y) xglue(x, y) -#define stringify(s) tostring(s) -#define tostring(s) #s -#endif - -#ifndef likely -#if __GNUC__ 3 -#define __builtin_expect(x, n) (x) -#endif - -#define likely(x) __builtin_expect(!!(x), 1) -#define unlikely(x) __builtin_expect(!!(x), 0) -#endif - -#ifndef always_inline -#if (__GNUC__ 3) || defined(__APPLE__) -#define always_inline inline -#else -#define always_inline __attribute__ (( always_inline )) inline -#endif -#endif - -#ifdef __i386__ -#define REGPARM(n) __attribute((regparm(n))) -#else -#define REGPARM(n) -#endif - /* is_jmp field values */ #define DISAS_NEXT0 /* next instruction can be analyzed */ #define DISAS_JUMP1 /* only pc was modified dynamically */ Index: osdep.h === RCS file: /sources/qemu/qemu/osdep.h,v retrieving revision 1.10 diff -u -d -d -p -r1.10 osdep.h --- osdep.h 7 Jun 2007 23:09:47 - 1.10 +++ osdep.h 15 Nov 2007 22:58:45 - @@ -3,6 +3,43 @@ #include stdarg.h +#ifndef glue +#define xglue(x, y) x ## y +#define glue(x, y) xglue(x, y) +#define stringify(s) tostring(s) +#define tostring(s) #s +#endif + +#ifndef likely +#if __GNUC__ 3 +#define __builtin_expect(x, n) (x) +#endif + +#define likely(x) __builtin_expect(!!(x), 1) +#define unlikely(x) __builtin_expect(!!(x), 0) +#endif + +#ifndef MIN +#define MIN(a, b) (((a) (b)) ? (a) : (b)) +#endif +#ifndef MAX +#define MAX(a, b) (((a) (b)) ? (a) : (b)) +#endif + +#ifndef always_inline +#if (__GNUC__ 3) || defined(__APPLE__) +#define always_inline inline +#else +#define always_inline __attribute__ (( always_inline )) inline +#endif +#endif + +#ifdef __i386__ +#define REGPARM(n) __attribute((regparm(n))) +#else +#define REGPARM(n) +#endif + #define qemu_printf printf void *qemu_malloc(size_t size); Index: vl.h
Re: [Qemu-devel] [RFC][PATCH] fix sparc32 mxcc 64 bit read word order
This patch fixes the word order for 64 bit reads of the mxcc registers.
Index: target-sparc/op_helper.c
===
RCS file: /sources/qemu/qemu/target-sparc/op_helper.c,v
retrieving revision 1.52
diff -p -u -r1.52 op_helper.c
--- target-sparc/op_helper.c11 Nov 2007 19:46:09 - 1.52
+++ target-sparc/op_helper.c15 Nov 2007 23:04:48 -
@@ -196,8 +196,8 @@ void helper_ld_asi(int asi, int size, in
switch (T0) {
case 0x01c00a00: /* MXCC control register */
if (size == 8) {
-ret = env-mxccregs[3];
-T0 = env-mxccregs[3] 32;
+ret = env-mxccregs[3] 32;
+T0 = env-mxccregs[3];
} else
DPRINTF_MXCC(%08x: unimplemented access size: %d\n, T0,
size);
break;
@@ -209,8 +209,8 @@ void helper_ld_asi(int asi, int size, in
break;
case 0x01c00f00: /* MBus port address register */
if (size == 8) {
-ret = env-mxccregs[7];
-T0 = env-mxccregs[7] 32;
+ret = env-mxccregs[7] 32;
+T0 = env-mxccregs[7];
} else
DPRINTF_MXCC(%08x: unimplemented access size: %d\n, T0,
size);
break;
[Qemu-devel] [PATCH] sparc32 fix MXCC error bit clearing
Fix MXCC error register bit clearing.
Index: target-sparc/op_helper.c
===
RCS file: /sources/qemu/qemu/target-sparc/op_helper.c,v
retrieving revision 1.52
diff -p -u -r1.52 op_helper.c
--- target-sparc/op_helper.c11 Nov 2007 19:46:09 - 1.52
+++ target-sparc/op_helper.c15 Nov 2007 23:28:12 -
@@ -438,13 +446,11 @@ void helper_st_asi(int asi, int size)
DPRINTF_MXCC(%08x: unimplemented access size: %d\n, T0,
size);
break;
case 0x01c00e00: /* MXCC error register */
+// writing a 1 bit clears the error
if (size == 8)
-env-mxccregs[6] = ((uint64_t)T1 32) | T2;
+env-mxccregs[6] = ~(((uint64_t)T1 32) | T2);
else
DPRINTF_MXCC(%08x: unimplemented access size: %d\n, T0,
size);
-if (env-mxccregs[6] == 0xULL) {
-// this is probably a reset
-}
break;
case 0x01c00f00: /* MBus port address register */
if (size == 8)
[Qemu-devel] [PATCH] sparc32 add new MXCC register
Add new MXCC register.
Index: target-sparc/op_helper.c
===
RCS file: /sources/qemu/qemu/target-sparc/op_helper.c,v
retrieving revision 1.52
diff -r1.52 op_helper.c
209a210,217
case 0x01c00c00: /* Module reset register */
if (size == 8) {
ret = env-mxccregs[5] 32;
T0 = env-mxccregs[5];
// should we do something here?
} else
DPRINTF_MXCC(%08x: unimplemented access size: %d\n, T0,
size);
break;
Re: [Qemu-devel] RFC: fix for random Qemu crashes
Hi, On 16/11/2007, J. Mayer [EMAIL PROTECTED] wrote: Some may have experienced of having some Qemu builds crashing, apparently at random places, but in a reproducable way. I found one reason for this crashes: it appears that with the growth of the op.c file, there may be cases where we could reach the inlining limits of gcc. In such a case, gcc would not inline some declared inline function but would emit a call and provide a separate function. Unfortunately, this is not acceptable in op.o context as it will slowdown the emulation and because the call is likely to break the specific compilation rules (ie reserved registers) used while compiling op.o I found some workaround to avoid this behavior and I'd like to get opinions about it. The first idea is to change all occurences of 'inline' with 'always_inline' in all headers included in op.c. It then appeared to me that always_inline is not globally declared and that the definition is duplicated in vl.h and exec-all.h. But it's not declared in darwin-user/qemu.h and linux-user/qemu.h, which is not consistent with the declaration in vl.h. Further investigations showed me that the osdep.h header is the one that is actually included everywhere. Even if those are more compiler than OS dependent, I decided to move the definitions for glue, tostring, likely, unlikely, always_inline and REGPARM to this header so they can be globally used. I also changed the include orders in darwin-user/qemu.h to be sure this header will be included first. This patch is attached in common_defs.diff. I had also noticed that glue and tostring definitions were present in three places in qemu and it seemed wrong to me, so I'm in favour of this patch. I can't say much about the other patches. After armv6/armv7 support was merged on Sunday, I had a consistent segfaults in the generated code and I tracked it down to cpsr_write function not being inlined properly because it grew in size. Changing the inline to always_inline helped but we decided to instead move the function to target-arm/helper.c. I don't know which approach is better, the performance hit shouldn't be notable (in case of ARM cpsr). Giving this patch, I've been able to replace all occurence of 'inline' with 'always_inline' in all headers included from op.c (given the generated .d file). Some would say I'd better add a #define inline always_inline somewhere. I personnally dislike this solution as this kind of macro as it tends to expand recursivally (always_inline definition contains the inline word) and this may lead to compilation warnings or errors in some context; one could do tests using the linux kernel headers to get convinced that it can happen. Then, I choosed to replace 'inline' by 'always_inline', which is more invasive but have less risks of side effects. The diff is attached in always_inline.diff. The last thing that helps solve the problem is to change the inlining limits of gcc, at least to compile the op.o file.Unfortunatelly, there is no way to disable those limits (I checked in the source code), then I put them to an arbitrary high level. I also added the -funit-at-a-time switch, as this kind of optimisation would not be relevant in op.o context. The diff is attached in gcc_inline_limits.diff. Please comment. -- J. Mayer [EMAIL PROTECTED] Never organized Regards
[Qemu-devel] [PATCH] sparc32 remove unnecessary 0xffffffff
Remove unnecessary masking of lower word with 0x. Index: target-sparc/op_helper.c === RCS file: /sources/qemu/qemu/target-sparc/op_helper.c,v retrieving revision 1.52 diff -p -u -r1.52 op_helper.c --- target-sparc/op_helper.c11 Nov 2007 19:46:09 - 1.52 +++ target-sparc/op_helper.c15 Nov 2007 23:10:36 - @@ -263,7 +263,7 @@ void helper_ld_asi(int asi, int size, in case 8: tmp = ldq_code(T0 ~7); ret = tmp 32; -T0 = tmp 0x; +T0 = tmp; break; } break; @@ -282,7 +282,7 @@ void helper_ld_asi(int asi, int size, in case 8: tmp = ldq_user(T0 ~7); ret = tmp 32; -T0 = tmp 0x; +T0 = tmp; break; } break; @@ -301,7 +301,7 @@ void helper_ld_asi(int asi, int size, in case 8: tmp = ldq_kernel(T0 ~7); ret = tmp 32; -T0 = tmp 0x; +T0 = tmp; break; } break; @@ -325,7 +325,7 @@ void helper_ld_asi(int asi, int size, in case 8: tmp = ldq_phys(T0 ~7); ret = tmp 32; -T0 = tmp 0x; +T0 = tmp; break; } break; @@ -349,7 +349,7 @@ void helper_ld_asi(int asi, int size, in tmp = ldq_phys((target_phys_addr_t)(T0 ~7) | ((target_phys_addr_t)(asi 0xf) 32)); ret = tmp 32; -T0 = tmp 0x; +T0 = tmp; break; } break;
[Qemu-devel] Hardware virtualization with QEMU
From the slackbook WIKI; http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:qemu; I quote below which relates to my questions: My questions are as follows: 1) I know -hdc and -cdrom cannot be called at the same time, but i have no luck getting an image to be mounted with -hdb or -hdd. The same image I can successfully mount with -cdrom cannot be mounted with either -hdb or -hdd, What's up there. I could not figure out from the manuals if these should just be dd'ed images a directory or iso? 2) Are floppy images restricted to exactly 1.44MB created with dd? I cannot mount anything with the floppy switches either which is probably a size constraint I dont meet. 3) Since USB is seemingly working, what would the command be to activate the usb driver ? -usb Intel SB82371or -usb SB82371 ? 4) What is the attainable USB speed? Full USB-1 ? 5) Are the serial and parallel ports running at native speed without delays? --- Emulated hardware and supported Guest OS-es The QEMU Virtual Machine emulates a set of hardware components that is independent of the real hardware on which it is running. Since Slackware runs on x86 architecture, I will limit myself to a list of emulated hardware available to Slack (other emulated architectures may have other hardware peripherals available to the Guest OS). * IDE-Controller supporting up to 4 drives (the drives are disk images on the host computer * IDE CDROM device (in the form of a CD ISO image, or a real CDROM device) * Floppy disk controller supporting up to 2 drives (floppy disk images) * Graphics card (either a Cirrus Logic GD5446 PCI, or VGA-VESA) * PS/2 Mouse * Ethernet network card (Realtek RTL8139 PCI or NE2000 PCI) * A serial port (COM 1) * A parallel port (LPT 1) * Soundcard (Soundblaster 16 and/or ES1370) * A USB-UHCI host controller (the Intel SB82371) The list of Operating Systems that run inside QEMU is quite long. Here is an unofficial list of supported Guest OS-es. I have run various Linuxes (for x68 and x86_64) and Windows 98/2000/XP inside QEMU. -
Re: [Qemu-devel] Hardware virtualization with QEMU
I soved (3) with this qemu -hda WinXP_Home.img -kernel-kqemu -usb -usbdevice host:04b4:8613 -net nic,model=rtl8139 -net user I can see the device and the intel hubs are running. Amazing, it is the first VM I see that even tries to address USB except for VMWARE. The remainder of the questions are still open. [EMAIL PROTECTED] wrote: From the slackbook WIKI; http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:qemu; I quote below which relates to my questions: My questions are as follows: 1) I know -hdc and -cdrom cannot be called at the same time, but i have no luck getting an image to be mounted with -hdb or -hdd. The same image I can successfully mount with -cdrom cannot be mounted with either -hdb or -hdd, What's up there. I could not figure out from the manuals if these should just be dd'ed images a directory or iso? 2) Are floppy images restricted to exactly 1.44MB created with dd? I cannot mount anything with the floppy switches either which is probably a size constraint I dont meet. 3) Since USB is seemingly working, what would the command be to activate the usb driver ? -usb Intel SB82371or -usb SB82371 ? 4) What is the attainable USB speed? Full USB-1 ? 5) Are the serial and parallel ports running at native speed without delays?
Re: [Qemu-devel] Re: [PATCH] tget/tput deprecation
On Wed, 2007-11-14 at 09:03 -0700, Thayne Harbaugh wrote:
This patch deprecates tget/tput and replaces them with get_user() and
put_user() which perform proper locking. It also checks return codes
(in most places) and fails with EFAULT where appropriate.
This version doesn't depend on 44_target_posix_types.patch.
Index: qemu/linux-user/elfload.c
===
--- qemu.orig/linux-user/elfload.c 2007-11-15 14:04:26.0 -0700
+++ qemu/linux-user/elfload.c 2007-11-15 21:21:19.0 -0700
@@ -179,8 +179,9 @@
regs-ARM_cpsr |= CPSR_T;
regs-ARM_pc = infop-entry 0xfffe;
regs-ARM_sp = infop-start_stack;
-regs-ARM_r2 = tgetl(stack + 8); /* envp */
-regs-ARM_r1 = tgetl(stack + 4); /* envp */
+/* FIXME - what to for failure of get_user()? */
+get_user_ual(regs-ARM_r2, stack + 8); /* envp */
+get_user_ual(regs-ARM_r1, stack + 4); /* envp */
/* XXX: it seems that r0 is zeroed after ! */
regs-ARM_r0 = 0;
/* For uClinux PIC binaries. */
@@ -341,7 +342,8 @@
* but this is what the ABI wants and is needed to allow
* execution of PPC BSD programs.
*/
-_regs-gpr[3] = tgetl(pos);
+/* FIXME - what to for failure of get_user()? */
+get_user_ual(_regs-gpr[3], pos);
pos += sizeof(abi_ulong);
_regs-gpr[4] = pos;
for (tmp = 1; tmp != 0; pos += sizeof(abi_ulong))
@@ -733,7 +735,8 @@
if (nbyte) {
nbyte = qemu_host_page_size - nbyte;
do {
- tput8(elf_bss, 0);
+/* FIXME - what to do if put_user() fails? */
+ put_user_u8(0, elf_bss);
elf_bss++;
} while (--nbyte);
}
@@ -782,17 +785,11 @@
/* This is correct because Linux defines
* elf_addr_t as Elf32_Off / Elf64_Off
*/
-#if ELF_CLASS == ELFCLASS32
-#define NEW_AUX_ENT(id, val) do { \
-sp -= n; tput32(sp, val); \
-sp -= n; tput32(sp, id); \
+#define NEW_AUX_ENT(id, val) do { \
+sp -= n; put_user_ual(val, sp); \
+sp -= n; put_user_ual(id, sp); \
} while(0)
-#else
-#define NEW_AUX_ENT(id, val) do { \
-sp -= n; tput64(sp, val); \
-sp -= n; tput64(sp, id); \
- } while(0)
-#endif
+
NEW_AUX_ENT (AT_NULL, 0);
/* There must be exactly DLINFO_ITEMS entries here. */
Index: qemu/linux-user/flatload.c
===
--- qemu.orig/linux-user/flatload.c 2007-11-15 14:04:26.0 -0700
+++ qemu/linux-user/flatload.c 2007-11-15 21:22:59.0 -0700
@@ -598,14 +598,16 @@
rp = datapos;
while (1) {
abi_ulong addr;
-addr = tgetl(rp);
+if (get_user_ual(addr, rp))
+return -EFAULT;
if (addr == -1)
break;
if (addr) {
addr = calc_reloc(addr, libinfo, id, 0);
if (addr == RELOC_FAILED)
return -ENOEXEC;
-tputl(rp, addr);
+if (put_user_ual(addr, rp))
+return -EFAULT;
}
rp += sizeof(abi_ulong);
}
@@ -629,14 +631,16 @@
/* Get the address of the pointer to be
relocated (of course, the address has to be
relocated first). */
-relval = tgetl(reloc + i * sizeof (abi_ulong));
+if (get_user_ual(relval, reloc + i * sizeof(abi_ulong)))
+return -EFAULT;
addr = flat_get_relocate_addr(relval);
rp = calc_reloc(addr, libinfo, id, 1);
if (rp == RELOC_FAILED)
return -ENOEXEC;
/* Get the pointer's value. */
-addr = tgetl(rp);
+if (get_user_ual(addr, rp))
+return -EFAULT;
if (addr != 0) {
/*
* Do the relocation. PIC relocs in the data section are
@@ -652,13 +656,15 @@
return -ENOEXEC;
/* Write back the relocated pointer. */
-tputl(rp, addr);
+if (put_user_ual(addr, rp))
+return -EFAULT;
}
}
} else {
for (i = 0; i relocs; i++) {
abi_ulong relval;
-relval = tgetl(reloc + i * sizeof (abi_ulong));
+if (get_user_ual(relval, reloc + i * sizeof(abi_ulong)))
+return -EFAULT;
old_reloc(libinfo[0], relval);
}
}
@@ -744,9 +750,12 @@
p = libinfo[i].start_data;
for (j=0; jMAX_SHARED_LIBS; j++) {
p -= 4;
-tput32(p, libinfo[j].loaded
- ? libinfo[j].start_data
- : UNLOADED_LIB);
+/* FIXME - handle put_user() failures */
+if (put_user_ual(libinfo[j].loaded
+
Re: [Qemu-devel] win98se guest regression
Ben Taylor [EMAIL PROTECTED] wrote: I have a couple of win98se guests that I keep around for testing and upgrade tests and the like. The current CVS code has no problem booting these images, but the first time I do anything (like read the cdrom, or change directories in windows explorer), the guest just hangs. This seems like a regression. This happens on both iso images and real cdrom's. I have tracked down the regression to ide.c V1.66. I have a build from 9/16/07, and replaced V1.64, V1.65 and V1.66 of ide.c only in this build. After building all three versions, the last vesion with ide.c V.166 causes Win98SE when I click on MyComputer to hang, and can only be killed by using the process manager. Previous instances of ide.c compiled, and the explorer brings up all the devices. Filip - you have any ideas on this? Thanks, Ben
