[Qemu-devel] TCG doesn't seem to like gcc 4.3
Hi all, I can't seem to get TCG work with gcc 4.3, I get : 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 -m32 -I. -I.. -I/packages/qemu/target-i386 -I/packages/qemu -MMD -MP -DNEED_CPU_H -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/packages/qemu/tcg -I/packages/qemu/tcg/i386 -I/packages/qemu/fpu -DHAS_AUDIO -DHAS_AUDIO_CHOICE -I/packages/qemu/slirp -c -o op.o /packages/qemu/target-i386/op.c /packages/qemu/target-i386/ops_template_mem.h: In function 'op_rolb_kernel_T0_T1_cc': ../softmmu_header.h:170: error: can't find a register in class 'Q_REGS' while reloading 'asm' ../softmmu_header.h:170: error: 'asm' operand has impossible constraints This is on i686 building with ./configure --target-list="i386-softmmu x86_64-softmmu" --disable-gcc-check Any ideas? Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
[Qemu-devel] Re: [PATCH 2/6] Use correct types to enable > 2G support (v2)
Hi Izik, Anthony Liguori wrote: Index: qemu/cpu-all.h === --- qemu.orig/cpu-all.h 2008-02-01 15:24:45.0 -0600 +++ qemu/cpu-all.h 2008-02-01 15:28:48.0 -0600 @@ -695,7 +695,7 @@ /* page related stuff */ -#define TARGET_PAGE_SIZE (1 << TARGET_PAGE_BITS) +#define TARGET_PAGE_SIZE (1ul << TARGET_PAGE_BITS) #define TARGET_PAGE_MASK ~(TARGET_PAGE_SIZE - 1) #define TARGET_PAGE_ALIGN(addr) (((addr) + TARGET_PAGE_SIZE - 1) & TARGET_PAGE_MASK Do you recall what this change fixed? As Paul pointed out in IRC, using the host type here doesn't really fix the problem (target_ulong would be more appropriate). However, we're both curious what problem it's actually fixing since sign extending the int should just work. Regards, Anthony Liguori
[Qemu-devel] qemu/tcg README tcg-op.h tcg-opc.h tcg.c tcg.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/04 00:37:54 Modified files: tcg: README tcg-op.h tcg-opc.h tcg.c tcg.h Log message: fixed sign extensions - added explicit side effect op flag - added discard instruction CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/README?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-op.h?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-opc.h?cvsroot=qemu&r1=1.1&r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.c?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.h?cvsroot=qemu&r1=1.2&r2=1.3
[Qemu-devel] Re: [kqemu] gpf in memory access
Ok, here's a patch that also makes -kernel-kqemu behave (with the previous patch it would abort with a "triple fault"). Due to the way kqemu sets up the mmu there should never be a GP fault in the mem access operations, so it would normally indicate some breakage and kqemu correctly aborts. However I looked it up in the amd64 specs and there can be a GP fault in a memory access when the sign extend bits ([63:52]) of the address are not in "canonical form" (for instance 0xff00 is not in canonical form). This patch will make such a GPF be reported to qemu. The patch only affects the x86-64 on x86-64 case. diff --git a/common/common.c b/common/common.c index 285b072..29443ce 100644 --- a/common/common.c +++ b/common/common.c @@ -242,7 +242,7 @@ static inline uint64_t *mon_get_ptep_l3(struct kqemu_state *s, if (!(pml4e & PG_PRESENT_MASK)) { if (!alloc) return NULL; -/* allocage a new page */ +/* allocate a new page */ ptr = mon_alloc_page(s, &pdp_page_index); if (!ptr) return NULL; diff --git a/common/kqemu_int.h b/common/kqemu_int.h index d881d85..b2f0b6e 100644 --- a/common/kqemu_int.h +++ b/common/kqemu_int.h @@ -1065,6 +1065,9 @@ static inline void stq_fast(struct kqemu_state *s, unsigned long addr, #define MMU_EXCEPTION(label) \ ".section \"mmu_ex_table\", \"a\"\n"\ ".quad " #label "\n"\ +".previous\n"\ +".section \"seg_ex_table\", \"a\"\n"\ +".quad " #label "\n"\ ".previous\n" #else #define MMU_EXCEPTION(label) \ diff --git a/common/monitor.c b/common/monitor.c index ed46845..b3b72dc 100644 --- a/common/monitor.c +++ b/common/monitor.c @@ -1515,6 +1515,10 @@ static void handle_mon_exception(struct kqemu_state *s, /* division exception from interp */ /* XXX: verify for fxsave/fxrstor */ s->regs = &s->regs1; +#ifdef __x86_64__ +} else if (intno == 0x0d && expected_monitor_exception(pc)) { +raise_exception(s, KQEMU_RET_SOFTMMU); +#endif } else { /* Note: the exception state is reliable only for goto_user handling */
Re: [Qemu-devel] qemu-img convert does not handle -O correctly
Andreas Färber wrote: Hello, When running `qemu-img convert haikuware.vmdk -O qcow2 haikuware.qcow2` on OSX, it complains it cannot open '-O'. According to `qemu-img convert --help` my syntax is correct. Andreas I had similar problems and needed to change the order of parameters on the command line. For your statement try... qemu-img convert -f vmdk -O qcow2 haikuware.vmdk haikuware.qcow2 ... as -f and -O come first before filenames
[Qemu-devel] qemu/tcg/i386 tcg-target.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/03 21:06:23 Modified files: tcg/i386 : tcg-target.c Log message: compare fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/i386/tcg-target.c?cvsroot=qemu&r1=1.1&r2=1.2
[Qemu-devel] qemu/tcg/x86_64 tcg-target.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/02/03 21:06:03 Modified files: tcg/x86_64 : tcg-target.c Log message: compare fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/x86_64/tcg-target.c?cvsroot=qemu&r1=1.1&r2=1.2
[Qemu-devel] qemu target-i386/translate.c tcg/tcg-op.h tcg/t...
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 08/02/03 19:56:34 Modified files: target-i386: translate.c tcg: tcg-op.h tcg.c tcg.h Log message: Add TCG variable opaque type. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/translate.c?cvsroot=qemu&r1=1.77&r2=1.78 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-op.h?cvsroot=qemu&r1=1.1&r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.c?cvsroot=qemu&r1=1.1&r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.h?cvsroot=qemu&r1=1.1&r2=1.2
Re: [Qemu-devel] qemu configure
mingw doesn't have "readlink" - Original Message - From: "andrzej zaborowski" <[EMAIL PROTECTED]> To: "C.W. Betts" <[EMAIL PROTECTED]> Cc: Sent: Sunday, February 03, 2008 8:58 AM Subject: Re: [Qemu-devel] qemu configure On 03/02/2008, C.W. Betts <[EMAIL PROTECTED]> wrote: That's all nice and good, but it doesn't seem to work with systems that don't use symlinks, such as mingw (the ln command creates duplicates). Can you give an example scenario that would fail under a system that doesn't use symlinks? AFAICT in the simplest case of "./configure", $workdir will be equal with $source_path as it was without this patch - no matter if there are symlinks or duplicates. Regards
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 08/02/03 19:20:13 Modified files: . : configure Log message: Robustify source directory check. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.186&r2=1.187
[Qemu-devel] [PATCH] loadvm for read-only snapshot files
Hi all, The following patch, against cvs, supports read-only snapshots on read-only qcow2 image files. Snapshots can be loaded, but not saved. This is really useful in my context, which is operating systems projects; a read-only memory snapshot allows students to share a snapshot that skips the boot process, allowing them to run their code right away. Please let me know if anything needs changing. Eddie Kohler Index: block-qcow2.c === RCS file: /sources/qemu/qemu/block-qcow2.c,v retrieving revision 1.10 diff -u -u -r1.10 block-qcow2.c --- block-qcow2.c 11 Nov 2007 02:51:16 - 1.10 +++ block-qcow2.c 3 Feb 2008 18:10:07 - @@ -429,7 +429,6 @@ BDRVQcowState *s = bs->opaque; int new_l1_size, new_l1_size2, ret, i; uint64_t *new_l1_table; -uint64_t new_l1_table_offset; uint64_t data64; uint32_t data32; @@ -450,28 +449,32 @@ memcpy(new_l1_table, s->l1_table, s->l1_size * sizeof(uint64_t)); /* write new table (align to cluster) */ -new_l1_table_offset = alloc_clusters(bs, new_l1_size2); +if (!bs->read_only) { + uint64_t new_l1_table_offset = alloc_clusters(bs, new_l1_size2); -for(i = 0; i < s->l1_size; i++) -new_l1_table[i] = cpu_to_be64(new_l1_table[i]); -ret = bdrv_pwrite(s->hd, new_l1_table_offset, new_l1_table, new_l1_size2); -if (ret != new_l1_size2) -goto fail; -for(i = 0; i < s->l1_size; i++) -new_l1_table[i] = be64_to_cpu(new_l1_table[i]); - -/* set new table */ -data64 = cpu_to_be64(new_l1_table_offset); -if (bdrv_pwrite(s->hd, offsetof(QCowHeader, l1_table_offset), -&data64, sizeof(data64)) != sizeof(data64)) -goto fail; -data32 = cpu_to_be32(new_l1_size); -if (bdrv_pwrite(s->hd, offsetof(QCowHeader, l1_size), -&data32, sizeof(data32)) != sizeof(data32)) -goto fail; + for(i = 0; i < s->l1_size; i++) + new_l1_table[i] = cpu_to_be64(new_l1_table[i]); + ret = bdrv_pwrite(s->hd, new_l1_table_offset, new_l1_table, new_l1_size2); + if (ret != new_l1_size2) + goto fail; + for(i = 0; i < s->l1_size; i++) + new_l1_table[i] = be64_to_cpu(new_l1_table[i]); + + /* set new table */ + data64 = cpu_to_be64(new_l1_table_offset); + if (bdrv_pwrite(s->hd, offsetof(QCowHeader, l1_table_offset), + &data64, sizeof(data64)) != sizeof(data64)) + goto fail; + data32 = cpu_to_be32(new_l1_size); + if (bdrv_pwrite(s->hd, offsetof(QCowHeader, l1_size), + &data32, sizeof(data32)) != sizeof(data32)) + goto fail; + free_clusters(bs, s->l1_table_offset, s->l1_size * sizeof(uint64_t)); + + s->l1_table_offset = new_l1_table_offset; +} + qemu_free(s->l1_table); -free_clusters(bs, s->l1_table_offset, s->l1_size * sizeof(uint64_t)); -s->l1_table_offset = new_l1_table_offset; s->l1_table = new_l1_table; s->l1_size = new_l1_size; return 0; @@ -521,7 +524,8 @@ /* update the L1 entry */ s->l1_table[l1_index] = l2_offset | QCOW_OFLAG_COPIED; tmp = cpu_to_be64(l2_offset | QCOW_OFLAG_COPIED); -if (bdrv_pwrite(s->hd, s->l1_table_offset + l1_index * sizeof(tmp), +if (!bs->read_only && + bdrv_pwrite(s->hd, s->l1_table_offset + l1_index * sizeof(tmp), &tmp, sizeof(tmp)) != sizeof(tmp)) return 0; min_index = l2_cache_new_entry(bs); @@ -535,7 +539,8 @@ s->l2_size * sizeof(uint64_t)) return 0; } -if (bdrv_pwrite(s->hd, l2_offset, +if (!bs->read_only && + bdrv_pwrite(s->hd, l2_offset, l2_table, s->l2_size * sizeof(uint64_t)) != s->l2_size * sizeof(uint64_t)) return 0; @@ -624,7 +629,8 @@ } /* update L2 table */ l2_table[l2_index] = tmp; -if (bdrv_pwrite(s->hd, +if (!bs->read_only && + bdrv_pwrite(s->hd, l2_offset + l2_index * sizeof(tmp), &tmp, sizeof(tmp)) != sizeof(tmp)) return 0; return cluster_offset; @@ -1322,7 +1328,7 @@ } } } -if (l2_modified) { +if (l2_modified && !bs->read_only) { if (bdrv_pwrite(s->hd, l2_offset, l2_table, l2_size) != l2_size) goto fail; @@ -1342,7 +1348,7 @@ } } } -if (l1_modified) { +if (l1_modified && !bs->read_only) { for(i = 0; i < l1_size; i++) cpu_to_be64s(&l1_table[i]); if (bdrv_pwrite(s->hd, l1_table_offset, l1_table, @@ -1553,6 +1559,9 @@ int i, ret; uint64_t *l1_table = NULL; +if (bs->read_only) + return -EACCES; + memset(sn, 0, sizeof(*sn)); if (sn_info->id_str[0] == '\0') { @@ -1628,7 +1637,8 @@ return -ENOENT; sn = &s->snapshots[snapshot_index]; -if (update_snapshot_refcount(bs, s->l1_tabl
[Qemu-devel] qemu exec-all.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 08/02/03 17:35:41 Modified files: . : exec-all.h Log message: Fix opparam_buf size estimate. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/exec-all.h?cvsroot=qemu&r1=1.74&r2=1.75
[Qemu-devel] [kqemu] gpf in memory access
I was playing with gpm (mouse daemon) in Linux guest and apparently my gpm binary is broken and with the "ps2" plugin it segfaults because of a general protection fault when trying to load a quadword from the address 0xff00. Under qemu as well as on the my physical amd64 it just segfaults, but under kqemu if makes kqemu panic and qemu aborts. Attached is a patch to make kqemu pass the gpf to qemu. It's probably wrong but it gives identical behaviour as with -no-kqemu or as on physical cpu, in this case. Regards diff --git a/common/kqemu_int.h b/common/kqemu_int.h index d881d85..cdb3a73 100644 --- a/common/kqemu_int.h +++ b/common/kqemu_int.h @@ -1065,11 +1065,17 @@ static inline void stq_fast(struct kqemu_state *s, unsigned long addr, #define MMU_EXCEPTION(label) \ ".section \"mmu_ex_table\", \"a\"\n"\ ".quad " #label "\n"\ +".previous\n"\ +".section \"seg_ex_table\", \"a\"\n"\ +".quad " #label "\n"\ ".previous\n" #else #define MMU_EXCEPTION(label) \ ".section \"mmu_ex_table\", \"a\"\n"\ ".long " #label "\n"\ +".previous\n"\ +".section \"seg_ex_table\", \"a\"\n"\ +".long " #label "\n"\ ".previous\n" #endif
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 08/02/03 16:27:13 Modified files: . : configure Log message: Use ARCH_CFLAGS in configure tests. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.185&r2=1.186
Re: [Qemu-devel] qemu configure
On 03/02/2008, C.W. Betts <[EMAIL PROTECTED]> wrote: > That's all nice and good, but it doesn't seem to work with systems that > don't use symlinks, such as mingw (the ln command creates duplicates). Can you give an example scenario that would fail under a system that doesn't use symlinks? AFAICT in the simplest case of "./configure", $workdir will be equal with $source_path as it was without this patch - no matter if there are symlinks or duplicates. Regards
[Qemu-devel] qemu-img convert does not handle -O correctly
Hello, When running `qemu-img convert haikuware.vmdk -O qcow2 haikuware.qcow2` on OSX, it complains it cannot open '-O'. According to `qemu-img convert --help` my syntax is correct. Andreas
Re: [Qemu-devel] PS/2 mouse support for FC4 guest broken in QEMU 0.9.1
Le Sunday 03 February 2008 04:15:52 andrzej zaborowski, vous avez écrit : > I have no clue about ps2 but seeing as redirecting the command from > kbd to mouse (0 -> 1 in the kbd_queue call) fixes the keyboard issue > for Gujin, but breaks mouse, the obvious conclusion is that the > command should not be done for either kbd or mouse. Can you try with > line 214 (previously line 207) simply removed? If you can test also > how that affects Gujin that would be even better. > > Cheers I've tried as you suggested to remove line 214 ( "kbd_queue(s, s->mode, 1)" ), and it breaks both keyboard and mouse support for the FC4 install DVD or my FC4 disk image. When booting the FC4 disk image, I can read "i8042.c : Can't read CTR while initializing i8042." in the kernel boot log. As far as Gujin is concerned, it would be great if people familiar with it could try. I'm looking for an available disk image with Gujin as the boot loader but no success for the moment. I guess I'll have to figure how to install and use it. Best regards.
[Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct types to enable > 2G support
On Thu, 2008-01-31 at 16:36 -0600, Anthony Liguori wrote: > KVM supports more than 2GB of memory for x86_64 hosts. The following patch > fixes a number of type related issues where int's were being used when they > shouldn't have been. It also introduces CMOS support so the BIOS can build > the appropriate e820 tables. the CMOS addresses that we used to register the above 4 giga memory are reserved and therefor the qemu bios does not know them you have to patch the bios as well to make it work with above 4 giga i once wrote this patch to qemu, hope it still apply. commit 21ea5f8286fd9cd7124dfa0865a213613b51add5 Author: Izik Eidus <[EMAIL PROTECTED]> Date: Mon Aug 20 17:46:04 2007 +0300 kvm: bios: add support to memory above the pci hole the new memory region is mapped after address 0x1, the bios take the size of the memory after the 0x1 from three new cmos bytes. diff --git a/bios/rombios.c b/bios/rombios.c index 9ea2dbc..ac918ad 100644 --- a/bios/rombios.c +++ b/bios/rombios.c @@ -4078,22 +4078,25 @@ BX_DEBUG_INT15("case default:\n"); #endif -void set_e820_range(ES, DI, start, end, type) +void set_e820_range(ES, DI, start, end, extra_start, extra_end, type) Bit16u ES; Bit16u DI; Bit32u start; Bit32u end; + Bit8u extra_start; + Bit8u extra_end; Bit16u type; { write_word(ES, DI, start); write_word(ES, DI+2, start >> 16); -write_word(ES, DI+4, 0x00); +write_word(ES, DI+4, extra_start); write_word(ES, DI+6, 0x00); end -= start; +extra_end -= extra_start; write_word(ES, DI+8, end); write_word(ES, DI+10, end >> 16); -write_word(ES, DI+12, 0x); +write_word(ES, DI+12, extra_end); write_word(ES, DI+14, 0x); write_word(ES, DI+16, type); @@ -4106,7 +4109,9 @@ int15_function32(regs, ES, DS, FLAGS) Bit16u ES, DS, FLAGS; { Bit32u extended_memory_size=0; // 64bits long + Bit32u extra_lowbits_memory_size=0; Bit16u CX,DX; + Bit8u extra_highbits_memory_size=0; BX_DEBUG_INT15("int15 AX=%04x\n",regs.u.r16.ax); @@ -4179,11 +4184,18 @@ ASM_END extended_memory_size *= 1024; } +extra_lowbits_memory_size = inb_cmos(0x5c); +extra_lowbits_memory_size <<= 8; +extra_lowbits_memory_size |= inb_cmos(0x5b); +extra_lowbits_memory_size *= 64; +extra_lowbits_memory_size *= 1024; +extra_highbits_memory_size = inb_cmos(0x5d); + switch(regs.u.r16.bx) { case 0: set_e820_range(ES, regs.u.r16.di, - 0x000L, 0x0009fc00L, 1); + 0x000L, 0x0009fc00L, 0, 0, 1); regs.u.r32.ebx = 1; regs.u.r32.eax = 0x534D4150; regs.u.r32.ecx = 0x14; @@ -4192,7 +4204,7 @@ ASM_END break; case 1: set_e820_range(ES, regs.u.r16.di, - 0x0009fc00L, 0x000aL, 2); + 0x0009fc00L, 0x000aL, 0, 0, 2); regs.u.r32.ebx = 2; regs.u.r32.eax = 0x534D4150; regs.u.r32.ecx = 0x14; @@ -4201,7 +4213,7 @@ ASM_END break; case 2: set_e820_range(ES, regs.u.r16.di, - 0x000e8000L, 0x0010L, 2); + 0x000e8000L, 0x0010L, 0, 0, 2); regs.u.r32.ebx = 3; regs.u.r32.eax = 0x534D4150; regs.u.r32.ecx = 0x14; @@ -4211,7 +4223,7 @@ ASM_END case 3: set_e820_range(ES, regs.u.r16.di, 0x0010L, - extended_memory_size - ACPI_DATA_SIZE, 1); + extended_memory_size - ACPI_DATA_SIZE ,0, 0, 1); regs.u.r32.ebx = 4; regs.u.r32.eax = 0x534D4150; regs.u.r32.ecx = 0x14; @@ -4221,7 +4233,7 @@ ASM_END case 4: set_e820_range(ES, regs.u.r16.di, extended_memory_size - ACPI_DATA_SIZE, - extended_memory_size, 3); // ACPI RAM + extended_memory_size ,0, 0, 3); // ACPI RAM regs.u.r32.ebx = 5; regs.u.r32.eax = 0x534D4150; regs.u.r32.ecx = 0x14; @@ -4231,7 +4243,20 @@ ASM_END case 5: /* 256KB BIOS area at the end of 4 GB */