Re: [Qemu-devel] [PATCH] Add gcc 4.0 support
Out of curiosity, wouldn't it be better to specifically request that feature of gcc, with one of its myriad options, rather than forcing a rather large optimization sweep? I'm sure that -O2 is good generally, but using it as a kludge to get at one of the many things that it enables seems like a not-so-great-idea. Its like buying a restaurant so that you can get a chef's stove. Please feel free to ignore me completely if you like, this is just my $0.02. :-) JP On 28 Mar 2006, at 06:09, Thiemo Seufer wrote: +# We require -O2 to avoid the stack setup prologue in EXIT_TB -- "Faith: Belief without evidence in what is told by one who speaks without knowledge, of things without parallel." - A.B. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu version 1.3.0pre5
Ed Swierk wrote: On 3/28/06, Jens Axboe <[EMAIL PROTECTED]> wrote: monitor/mwait feature present. using mwait in idle threads. [snip] invalid operand: [#1] Modules linked in: CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010246 (2.6.14-1.1656_FC4) EIP is at mwait_idle+0x2f/0x41 I don't think qemu supports PNI, which includes the monitor/mwait additions. I wonder why Linux detects that. You can probably get around it for now by either passing idle=poll as a boot parameter, or compile your kernel for plain i586 for instance. It seems that with -kernel-kqemu, the guest kernel is seeing the CPUID of the host machine rather than the one normally generated by qemu. The workarounds you suggest do work--thanks for your help. However, ideally kqemu would trap the CPUID instruction and mask the feature bits for unsupported CPU features. The problem is that it is not possible to trap on the CPUID instruction :-( So the only possible patch is to support PNI in QEMU. For monitor/mwait for example, doing nops should suffice... Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu vl.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/28 20:20:38 Modified files: . : vl.c Log message: Use 3-argument open call when creating file. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.165&tr2=1.166&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu version 1.3.0pre5
On 3/28/06, Jens Axboe <[EMAIL PROTECTED]> wrote: > > monitor/mwait feature present. > > using mwait in idle threads. > > [snip] > > > invalid operand: [#1] > > Modules linked in: > > CPU:0 > > EIP:0060:[]Not tainted VLI > > EFLAGS: 00010246 (2.6.14-1.1656_FC4) > > EIP is at mwait_idle+0x2f/0x41 > > I don't think qemu supports PNI, which includes the monitor/mwait > additions. I wonder why Linux detects that. You can probably get around > it for now by either passing idle=poll as a boot parameter, or compile > your kernel for plain i586 for instance. It seems that with -kernel-kqemu, the guest kernel is seeing the CPUID of the host machine rather than the one normally generated by qemu. The workarounds you suggest do work--thanks for your help. However, ideally kqemu would trap the CPUID instruction and mask the feature bits for unsupported CPU features. --Ed ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu version 1.3.0pre5
On Tue, Mar 28 2006, Ed Swierk wrote: > I'm still getting a kernel panic running a Linux guest kernel with > -kernel-qemu. I'm using kqemu-1.3.0pre5 and > qemu-snapshot-2006-03-27_23. > > The guest kernel is a precompiled Fedora Core 4 kernel, version > 2.6.14-1.1656_FC4. It works fine with kqemu in non-kernel-kqemu mode. > > Any hints for how to track this problem down? [snip] > monitor/mwait feature present. > using mwait in idle threads. [snip] > invalid operand: [#1] > Modules linked in: > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010246 (2.6.14-1.1656_FC4) > EIP is at mwait_idle+0x2f/0x41 I don't think qemu supports PNI, which includes the monitor/mwait additions. I wonder why Linux detects that. You can probably get around it for now by either passing idle=poll as a boot parameter, or compile your kernel for plain i586 for instance. -- Jens Axboe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu version 1.3.0pre5
Ed Swierk wrote: I'm still getting a kernel panic running a Linux guest kernel with -kernel-qemu. I'm using kqemu-1.3.0pre5 and qemu-snapshot-2006-03-27_23. The guest kernel is a precompiled Fedora Core 4 kernel, version 2.6.14-1.1656_FC4. It works fine with kqemu in non-kernel-kqemu mode. Any hints for how to track this problem down? I was getting an almost _identical_ error on my laptop.. turned out I had forgot to copy the latest and greatest bios *.bin files to /usr/local/share/qemu Updated the bios from the cvs source dir and it's all been peachy since.. Hope yours is similar.. You do need to be running the absolute latest cvs really for this to work properly.. My desktop was ok, but my laptop was a couple of days worth of commits out of date and *boom* Brad -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu version 1.3.0pre5
I'm still getting a kernel panic running a Linux guest kernel with -kernel-qemu. I'm using kqemu-1.3.0pre5 and qemu-snapshot-2006-03-27_23. The guest kernel is a precompiled Fedora Core 4 kernel, version 2.6.14-1.1656_FC4. It works fine with kqemu in non-kernel-kqemu mode. Any hints for how to track this problem down? --Ed Linux version 2.6.14-1.1656_FC4 ([EMAIL PROTECTED]) (gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 Thu Jan 5 22:13:22 EST 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0010 - 1000 (usable) 0MB HIGHMEM available. 256MB LOWMEM available. Using x86 segment limits to approximate NX protection DMI not present. ACPI: Unable to locate RSDP Allocating PCI resources starting at 2000 (gap: 1000:f000) Built 1 zonelists Kernel command line: bootdev=hda1 bootnod=b,3,1 boottype=vfat bootdir=/swi/Aros-1.3.0 console=ttyS0 selinux=0 Initializing CPU#0 CPU 0 irqstacks, hard=c03f3000 soft=c03f2000 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 3000.676 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 254412k/262144k available (2099k kernel code, 7072k reserved, 718k data, 172k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 6043.49 BogoMIPS (lpj=12086981) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 monitor/mwait feature present. using mwait in idle threads. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) CPU: Intel(R) Pentium(R) D CPU 3.00GHz stepping 04 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. checking if image is initramfs... it is Freeing initrd memory: 1232k freed NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xf9ce0, last bus=0 PCI: Using configuration type 1 ACPI: Subsystem revision 20050916 ACPI: Interpreter disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI: disabled usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Using IRQ router PIIX/ICH [8086/7000] at :00:01.0 PCI: BIOS reporting unknown device 01:00 PCI: BIOS reporting unknown device 01:00 PCI: BIOS reporting unknown device 01:00 PCI: BIOS reporting unknown device 01:00 PCI: BIOS reporting unknown device 01:00 PCI: Ignore bogus resource 6 [0:0] of :00:02.0 apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) audit: initializing netlink socket (disabled) audit(1143569137.708:1): initialized Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API ksign: Installing public key data Loading keyring - Added public key 86D1D7472B6BE898 - User ID: Red Hat, Inc. (Kernel Module GPG key) PCI: PIIX3: Enabling Passive Release on :00:01.0 Limiting direct PCI/PCI transfers. Activating ISA DMA hang workarounds. pci_hotplug: PCI Hot Plug PCI Core version: 0.5 isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Real Time Clock Driver v1.12 Linux agpgart interface v0.101 (c) Dave Jones PNP: No PS/2 controller found. Probing ports directly. serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 32 ports, IRQ sharing enabled invalid operand: [#1] Modules linked in: CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010246 (2.6.14-1.1656_FC4) EIP is at mwait_idle+0x2f/0x41 eax: c03c1008 ebx: c03c1008 ecx: edx: esi: c03c1000 edi: 0010 ebp: esp: c03c1fc4 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c03c1000 task=c0361c60) Stack: 0800 c03c1000 c0113749 c03c1000 0800 00099100 c03bd800 00461007 c01010a6 c03c270a 004c c03c22e9 c03f4e60 c0100199 Call Trace: [] apm_cpu_idle+0x5e/0x157 [] cpu_idle+0x34/0x4c [] start_kernel+0x15f/0x1b9 [] unknown_bootoption+0x0/0x1b6 Code: 00 f0 ff ff 21 e2 8b 42 08 a8 08 75 2d 0f ba 6a 08 10 89 d6 8d 5a 08 31 c9 eb 0c 89 c8 0f 01 c9 8b 46 08 a8 08 75 0e 89 d8 89 ca <0f> 01 c8 8b 46 08 a8 08 74 e6 0f ba 76 08 10 5b 5e c3 83 ec 04 <0>Kernel panic - not syncing: Attempted to kill the idle task! [] panic+0x45/0x1b4 [] profile_task_exit+0x30/0x43 [] do_exit+0x375/0x3b8 [] do_divide_error+0x0/0xa8 [] do_invalid_op+0x0/0xab [] do_invalid_op+0xa2/0xab [] mwait_idle+0x2f/0x41 [] serial8250_console_write+0x0/0x1ec [] __call_co
Re: [Qemu-devel] kqemu version 1.3.0pre5
On Tue, 28 Mar 2006 12:26:37 +0400, Brad Campbell <[EMAIL PROTECTED]> wrote: > Fabrice Bellard wrote: >> Hi, >> >> I just released a new version of kqemu which fixes some recently >> discovered issues. The fixes are the following: >> >> - Support for guest Linux kernels compiled with gcc >= 3.3 >> > > Tested with 2.4.26 & 2.6.16 - gcc-3.2, gcc-3.3, gcc-3.4 & gcc-4.0.2 > Win2k-SP3, Win2k-SP4, WinXP-SP1, WinXP-SP2 > AthlonXP, Sempron & PIII-M > > and all combinations of. > > Nice work :) > thanks for putting in the MODULE_LICENSE folks! Auke ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu version 1.3.0pre5
Sent: Tuesday, March 28, 2006 8:50 PM Brad Campbell wrote: > Kazu wrote: > >> I tested Linux guest/WinXP host but the host OS crashed. > > I believe -kernel-kqemu is still somewhat experimental on Windows host. > >> Redhat 7.2 guest/Fedora Core 4 host with normal kqemu is slower >> than -no-kqemu. Why ? > > Have you got your tmpfs set up correctly so qemu can place its memory swap file in a ramdisk rather > than on disk? > I used tmpfs but the result is the same. Thanks, anyway. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add gcc 4.0 support
On Wed, Feb 15, 2006 at 12:25:01PM +, Thiemo Seufer wrote: > Hello all, > > the appended patch > > - Adds detection of gcc commandline flag support, based on the theory > "If it exists, we want to use it". > - Uses this to add enough gcc4 flag magic to OP_FLAGS, and remove the > specialcasing for gcc3 as well as the bail out for gcc4. > - Makes CFLAGS and OP_CLFAGS distinct sets because options like -O0 > are useful for debugging in CFLAGS but break qemu in OP_CFLAGS. > - Updates the ppc.ld script to work with gcc4. > - Adds preliminary mips/mipsel support to Makefile.target. > - Adds to RETURN and FORCE_RET a "memory" constraint to ensure it works > as optimisation barrier. > > Caveats: > - Those changes weren't tested with earlier compilers. The linker > script probably requires some more recent ld. Please test if it > still works for you. > - The -malign-functions=0 is now used as a fallback for > -fno-align-functions on all architectures, not only on i386. This > might be wrong. > > > Tested on Debian unstable on powerpc, while working on improving the > mips emulation support. Updated version, note that this is still not suitable for CVS since x86 fails to build with it. Thiemo Index: Makefile.target === --- Makefile.target.orig2006-03-28 15:05:19.0 +0100 +++ Makefile.target 2006-03-28 15:05:45.0 +0100 @@ -17,6 +17,14 @@ VPATH+=:$(SRC_PATH)/linux-user DEFINES+=-I$(SRC_PATH)/linux-user -I$(SRC_PATH)/linux-user/$(TARGET_ARCH) endif + +# cc-option +# Usage: CFLAGS += $(call cc-option, -falign-functions=0, -malign-functions=0) + +cc-option = $(shell if $(CC) $(CFLAGS) $(1) -S -o /dev/null -xc /dev/null \ + > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;) + + CFLAGS=-Wall -O2 -g -fno-strict-aliasing #CFLAGS+=-Werror LDFLAGS=-g @@ -65,15 +73,19 @@ LDFLAGS+=-static endif -ifeq ($(ARCH),i386) -CFLAGS+=-fomit-frame-pointer -OP_CFLAGS=$(CFLAGS) -mpreferred-stack-boundary=2 -ifeq ($(HAVE_GCC3_OPTIONS),yes) -OP_CFLAGS+= -falign-functions=0 -fno-gcse -else -OP_CFLAGS+= -malign-functions=0 -endif +# We require -O2 to avoid the stack setup prologue in EXIT_TB +OP_CFLAGS = -Wall -O2 -g -fno-strict-aliasing +OP_CFLAGS += $(call cc-option, -fno-reorder-blocks, "") +OP_CFLAGS += $(call cc-option, -fno-tree-ch, "") +OP_CFLAGS += $(call cc-option, -fno-optimize-sibling-calls, "") +OP_CFLAGS += $(call cc-option, -fno-crossjumping, "") +OP_CFLAGS += $(call cc-option, -fno-align-labels, "") +OP_CFLAGS += $(call cc-option, -fno-align-jumps, "") +OP_CFLAGS += $(call cc-option, -fno-align-functions, -malign-functions=0) +ifeq ($(ARCH),i386) +CFLAGS += -fomit-frame-pointer +OP_CFLAGS += -fomit-frame-pointer -preferred-stack-boundary=2 ifdef TARGET_GPROF USE_I386_LD=y endif @@ -91,64 +103,61 @@ endif ifeq ($(ARCH),x86_64) -OP_CFLAGS=$(CFLAGS) -falign-functions=0 LDFLAGS+=-Wl,-T,$(SRC_PATH)/x86_64.ld endif ifeq ($(ARCH),ppc) -CFLAGS+= -D__powerpc__ -OP_CFLAGS=$(CFLAGS) +CFLAGS += -D__powerpc__ LDFLAGS+=-Wl,-T,$(SRC_PATH)/ppc.ld endif ifeq ($(ARCH),s390) -OP_CFLAGS=$(CFLAGS) LDFLAGS+=-Wl,-T,$(SRC_PATH)/s390.ld endif ifeq ($(ARCH),sparc) -CFLAGS+=-m32 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6 -LDFLAGS+=-m32 -OP_CFLAGS=$(CFLAGS) -fno-delayed-branch -ffixed-i0 -HELPER_CFLAGS=$(CFLAGS) -ffixed-i0 -mflat +CFLAGS += -m32 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6 +LDFLAGS += -m32 +OP_CFLAGS += -m32 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6 \ + -fno-delayed-branch -ffixed-i0 +HELPER_CFLAGS = $(CFLAGS) -ffixed-i0 -mflat # -static is used to avoid g1/g3 usage by the dynamic linker LDFLAGS+=-Wl,-T,$(SRC_PATH)/sparc.ld -static endif ifeq ($(ARCH),sparc64) -CFLAGS+=-m64 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6 -LDFLAGS+=-m64 -OP_CFLAGS=$(CFLAGS) -fno-delayed-branch -ffixed-i0 +CFLAGS += -m64 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6 +LDFLAGS += -m64 +OP_CFLAGS += -m64 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6 \ + -fno-delayed-branch -ffixed-i0 endif ifeq ($(ARCH),alpha) -# -msmall-data is not used because we want two-instruction relocations -# for the constant constructions -OP_CFLAGS=-Wall -O2 -g # Ensure there's only a single GP CFLAGS += -msmall-data +# -msmall-data is not used for OP_CFLAGS because we want +# two-instruction relocations for the constant constructions LDFLAGS+=-Wl,-T,$(SRC_PATH)/alpha.ld endif ifeq ($(ARCH),ia64) CFLAGS += -mno-sdata -OP_CFLAGS=$(CFLAGS) +OP_CFLAGS += -mno-sdata LDFLAGS+=-Wl,-G0 -Wl,-T,$(SRC_PATH)/ia64.ld endif ifeq ($(ARCH),arm) -OP_CFLAGS=$(CFLAGS) -mno-sched-prolog -fno-omit-frame-pointer +OP_CFLAGS += -mno-sched-prolog -fno-omit-frame-pointer LDFLAGS+=-Wl,-T,$(SRC_PATH)/arm.ld endif ifeq ($(ARCH),m68k) -OP_CFLAGS=$(CFLAGS) -fomit-frame-pointer -LDFLAGS+=-Wl,-T,m68k.ld +OP_CFLAGS += -fomit-frame-pointer +LDFLAGS+=-Wl,-T,$(SRC_PATH)/m68k.ld endif -ifeq ($(HAVE_GCC3_OPTIONS),y
Re: [Qemu-devel] kqemu version 1.3.0pre5
On Tuesday, March 28, 2006, 14:27:48, andrzej zaborowski wrote: > Normal Operating Systems don't crash no matter what program they are running. That only applies to user-mode programs that don't make calls to device drivers. Kqemu is basically a device driver which runs in kernel space, and a crash in there will bring down whole system. -- < Jernej Simončič ><><><><>< http://deepthought.ena.si/ > The first pull on the cord ALWAYS sends the drapes in the wrong direction. -- Boyle's Other Law ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add MIPS ELF loader
On Tue, Mar 28, 2006 at 08:57:15AM +0200, Dirk Behme wrote:
> Hi,
>
> ELF loader feature for MIPS in patch
>
> http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00033.html
>
> was rejected because it breaks loading of raw kernel images:
>
> http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00082.html
>
> What about the patch in attachment? It first tries to load
> image as an ELF file. If this fails it falls back to raw
> image load. Additionally, it takes feature of patch above to
> go on even if no BIOS is found.
A slightly more polished version with less noisy messages is appended.
It also adjusts the ramdisk load address to physical addressing,
similiar to the binary kernel load.
Thiemo
Index: qemu-work/hw/mips_r4k.c
===
--- qemu-work.orig/hw/mips_r4k.c2006-03-28 12:27:55.0 +0100
+++ qemu-work/hw/mips_r4k.c 2006-03-28 13:49:10.0 +0100
@@ -1,6 +1,8 @@
#define KERNEL_LOAD_ADDR 0x8001
#define INITRD_LOAD_ADDR 0x8080
+#define PHYSADDR(addr) ((addr) & 0x1fff)
+
extern FILE *logfile;
static PITState *pit;
@@ -101,6 +105,108 @@
cpu_mips_update_count(env, 1, 0);
}
+#include "disas.h"
+
+#define ELF_CLASS ELFCLASS32
+#ifdef TARGET_WORDS_BIGENDIAN
+# define ELF_DATAELFDATA2MSB
+#else
+# define ELF_DATAELFDATA2LSB
+#endif
+#define ELF_ARCHEM_MIPS
+
+#include "elf.h"
+
+#ifndef BSWAP_NEEDED
+#define bswap_ehdr32(e) do { } while (0)
+#define bswap_phdr32(e) do { } while (0)
+#define bswap_shdr32(e) do { } while (0)
+#define bswap_sym32(e) do { } while (0)
+#endif
+
+#define SZ 32
+#define elf_worduint32_t
+#define bswapSZs bswap32s
+#include "elf_ops.h"
+
+static int load_mips_kernel_elf(const char *filename, elf_word *entry)
+{
+struct elf32_hdr ehdr;
+int retval, fd, i;
+Elf32_Half machine;
+
+fd = open(filename, O_RDONLY | O_BINARY);
+if (fd < 0)
+ goto error;
+
+retval = read(fd, &ehdr, sizeof(ehdr));
+if (retval < 0)
+ goto error;
+
+if (ehdr.e_ident[0] != 0x7f || ehdr.e_ident[1] != 'E'
+ || ehdr.e_ident[2] != 'L' || ehdr.e_ident[3] != 'F')
+ goto error;
+machine = tswap16(ehdr.e_machine);
+if (machine == EM_MIPS) {
+ struct elf32_phdr phdr;
+
+ bswap_ehdr32(&ehdr);
+
+ *entry = ehdr.e_entry;
+ retval = lseek(fd, ehdr.e_phoff, SEEK_SET);
+ if (retval < 0)
+ goto error;
+
+ for (i = 0; i < ehdr.e_phnum; i++) {
+ retval = read(fd, &phdr, sizeof(phdr));
+ if (retval < 0)
+ goto error;
+ bswap_phdr32(&phdr);
+ if (phdr.p_type == PT_LOAD) {
+ uint8_t *addr;
+ size_t sz = phdr.p_filesz;
+
+ if (phdr.p_vaddr < 0x8000
+ || phdr.p_memsz > 0x2000
+ || (phdr.p_vaddr < 0xa000
+ && (phdr.p_vaddr + phdr.p_memsz) >= 0xa000)
+ || (phdr.p_vaddr < 0xc000
+ && (phdr.p_vaddr + phdr.p_memsz) >= 0xc000))
+ goto error;
+ addr = (uint8_t *)(phys_ram_base + PHYSADDR(phdr.p_vaddr));
+ retval = lseek(fd, phdr.p_offset, SEEK_SET);
+ if (retval < 0)
+ goto error;
+ while (sz) {
+ retval = read(fd, addr, sz);
+ switch (retval) {
+ case -1:
+ goto error;
+ case 0: /* EOF */
+ if (sz)
+ goto error;
+ break;
+ default:
+ if (sz < retval)
+ goto error;
+ sz -= retval;
+ retval = 0;
+ break;
+ }
+ }
+ }
+ }
+ load_symbols32(&ehdr, fd);
+}
+
+close(fd);
+return retval;
+ error:
+close(fd);
+return -1;
+}
+
+
static void io_writeb (void *opaque, target_phys_addr_t addr, uint32_t value)
{
#if 0
@@ -183,72 +319,70 @@
const char *initrd_filename)
{
char buf[1024];
-target_ulong kernel_base, kernel_size, initrd_base, initrd_size;
+elf_word entry = 0;
unsigned long bios_offset;
int io_memory;
-int linux_boot;
int ret;
CPUState *env;
-
-printf("%s: start\n", __func__);
-linux_boot = (kernel_filename != NULL);
+int i;
env = cpu_init();
register_savevm("cpu", 0, 3, cpu_save, cpu_load, env);
/* allocate RAM */
cpu_register_physical_memory(0, ram_size, IO_MEM_RAM);
+
+/* Try to load a BIOS image. If this fails, we continue regardless,
+ but initialize the hardware ourselves. When a kernel gets
+ preloaded we also initialize the hardware, since the BIOS wasn't
+ run. */
bios_offset
Re: [Qemu-devel] kqemu version 1.3.0pre5
Paul Brook wrote: Normal Operating Systems don't crash no matter what program they are running. Except that kqemu is a kernel module (or windows equivalent). As such it is effectively part of the OS, and can easily crash the whole machine. Yes indeed. I'm actually quite impressed. I've crashed my guests loads, I've crashed qemu loads and yet I've never managed to leave kqemu in a state that compromised the system integrity I'm not betting my life it won't happen, but thus far I've been quite lucky I guess.. (And I have done some severely stupid things to blow up both qemu and the guests so far) All bets are off for a Windows host though. I'm sure it's much easier to write a module that does what kqemu does when you a) have a good understanding of what goes on under the hood, and b) have the source to verify this.. unlike writing a Windows system module. Kudos to the guys who put that together and their progress thus far. Brad -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu version 1.3.0pre5
Works fine on my computer too! OS: Ubuntu 5.10 (Breezy Badger) CPU: Athlon XP 2000+ (with kernel 2.6.12-10-k7) Using latest CVS version of QEMU with some USB patches from http://gnome.dnsalias.net/patches/On 3/28/06, Paul Brook <[EMAIL PROTECTED]> wrote: > Normal Operating Systems don't crash no matter what program they are> running.Except that kqemu is a kernel module (or windows equivalent). As such it iseffectively part of the OS, and can easily crash the whole machine. Paul___Qemu-devel mailing listQemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel-- Bruno de Oliveira Abinader10LE/INdT ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu version 1.3.0pre5
> Normal Operating Systems don't crash no matter what program they are > running. Except that kqemu is a kernel module (or windows equivalent). As such it is effectively part of the OS, and can easily crash the whole machine. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu version 1.3.0pre5
On 28/03/06, Marco Matthies <[EMAIL PROTECTED]> wrote: > Brad Campbell wrote: > > none 768M 137M 632M 18% /tmp <-- not sure why it > > says none.. it's tmpfs > > change the none to tmpfs in /etc/fstab. normally the mount point goes > there, but tmpfs (and proc, for example) don't have a mount point so you > can put anything there. You mean they don't have a device node. They do have mountpoints. Regarding crashes of the host OS, that might have nothing to do with QEMU. Ms Windows is known to be an "experimental" OS in general (by experimental I mean that it crashes a lot) :-) Normal Operating Systems don't crash no matter what program they are running. > > marco > > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > -- balrog 2oo6 Dear Outlook users: Please remove me from your address books http://www.newsforge.com/article.pl?sid=03/08/21/143258 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu version 1.3.0pre5
Brad Campbell wrote: none 768M 137M 632M 18% /tmp <-- not sure why it says none.. it's tmpfs change the none to tmpfs in /etc/fstab. normally the mount point goes there, but tmpfs (and proc, for example) don't have a mount point so you can put anything there. marco ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu version 1.3.0pre5
Kazu wrote: I tested Linux guest/WinXP host but the host OS crashed. I believe -kernel-kqemu is still somewhat experimental on Windows host. Redhat 7.2 guest/Fedora Core 4 host with normal kqemu is slower than -no-kqemu. Why ? Have you got your tmpfs set up correctly so qemu can place its memory swap file in a ramdisk rather than on disk? /dev/hda1 4.6G 3.1G 1.4G 69% / tmpfs 506M 0 506M 0% /dev/shm /dev/hda2 4.6G 4.5G 103M 98% /home /dev/hda6 44G 44G 424K 100% /tracks none 768M 137M 632M 18% /tmp <-- not sure why it says none.. it's tmpfs Regards, Brad -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu version 1.3.0pre5
Sent: Tuesday, March 28, 2006 6:30 AM Fabrice Bellard wrote: > Hi, > > I just released a new version of kqemu which fixes some recently > discovered issues. The fixes are the following: > > - Support for guest Linux kernels compiled with gcc >= 3.3 > > - x86_64 host support is working again (only i386 on x86_64 full > virtualization has been tested, x86_64 on x86_64 is implemented but not > tested yet). > > - Workaround for full virtualization on Windows host (more tests needed). > I tested Linux guest/WinXP host but the host OS crashed. Redhat 7.2 guest/Fedora Core 4 host with normal kqemu is slower than -no-kqemu. Why ? Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu version 1.3.0pre5
Fabrice Bellard wrote: Hi, I just released a new version of kqemu which fixes some recently discovered issues. The fixes are the following: - Support for guest Linux kernels compiled with gcc >= 3.3 Tested with 2.4.26 & 2.6.16 - gcc-3.2, gcc-3.3, gcc-3.4 & gcc-4.0.2 Win2k-SP3, Win2k-SP4, WinXP-SP1, WinXP-SP2 AthlonXP, Sempron & PIII-M and all combinations of. Nice work :) -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VM Memory limit with kernel-kqemu?
Andrew Barr wrote: I'm running a Windows 2000 SP4 guest on a Linux 2.6.16 host with Qemu CVS and kqemu 1.3.0pre3. I am trying to use -kernel-kqemu. I have been allocating 256 MB of RAM to my guest (out of 768 MB total) and I have found that using that amount of memory with -kernel-kqemu causes Windows 2000 to freeze at the graphical boot up screen (after 'Starting Windows...') and qemu to take up 95-100% CPU. Reducing the amount of guest RAM to 160 MB makes that problem go away. I also tried 192 MB and that did not work. Is there a limit to the amount of memory that may be used with the -kernel-kqemu option? Ok I've just reproduced this with the 256M problem doing some more homework. Brad -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
