[Qemu-devel] qemu arm-semi.c m68k-semi.c softmmu-semi.h linu...
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/16 10:46:05 Modified files: . : arm-semi.c m68k-semi.c softmmu-semi.h linux-user : elfload.c flatload.c linuxload.c main.c qemu.h syscall.c target-arm/nwfpe: fpa11_cpdt.c Log message: suppressed tgetx and tputx (initial patch by Thayne Harbaugh) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/arm-semi.c?cvsroot=qemur1=1.7r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/m68k-semi.c?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu-semi.h?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/elfload.c?cvsroot=qemur1=1.56r2=1.57 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/flatload.c?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/linuxload.c?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.153r2=1.154 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/qemu.h?cvsroot=qemur1=1.49r2=1.50 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.152r2=1.153 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/nwfpe/fpa11_cpdt.c?cvsroot=qemur1=1.6r2=1.7
[Qemu-devel] qemu/fpu softfloat-specialize.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/11/16 14:57:36 Modified files: fpu: softfloat-specialize.h Log message: Fix NaN handling for MIPS and HPPA. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat-specialize.h?cvsroot=qemur1=1.3r2=1.4
Re: [Qemu-devel] RFC: fix for random Qemu crashes
On Fri, 2007-11-16 at 17:06 +0200, Heikki Lindholm wrote: J. Mayer kirjoitti: 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 Does -winline give a warning when this happens? I did not check this, but getting a warning won't help us a lot. The generated Qemu executable would still crash. -- Jocelyn Mayer [EMAIL PROTECTED]
[Qemu-devel] [PATCH] Collecting block device statistics
Hi,
I was looking for a way to collect information on the amount of data
being written and read from block devices. The attached patch adds a
few counters to the BlockDriverState structure to collect this
information, and a new info blockstats monitor command to display it.
This screenshot shows it in action:
http://www.annexia.org/tmp/Screenshot-QEMU.png
This is the sort of feature I'd really like to see merged into qemu
because it will let us enhance libvirt to centrally collect these stats
from qemu instances.
Any comments or feedback about this are most welcome.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
Index: block.c
===
RCS file: /sources/qemu/qemu/block.c,v
retrieving revision 1.47
diff -u -r1.47 block.c
--- block.c 11 Nov 2007 02:51:16 - 1.47
+++ block.c 16 Nov 2007 15:23:44 -
@@ -522,8 +522,12 @@
return ret;
else if (ret != len)
return -EINVAL;
-else
+else {
+ bs-rd_bytes += (unsigned) len;
+ bs-rd_sects += (unsigned) nb_sectors;
+ bs-rd_ops ++;
return 0;
+ }
} else {
return drv-bdrv_read(bs, sector_num, buf, nb_sectors);
}
@@ -554,8 +558,12 @@
return ret;
else if (ret != len)
return -EIO;
-else
+else {
+ bs-wr_bytes += (unsigned) len;
+ bs-wr_sects += (unsigned) nb_sectors;
+ bs-wr_ops ++;
return 0;
+ }
} else {
return drv-bdrv_write(bs, sector_num, buf, nb_sectors);
}
@@ -903,6 +911,27 @@
term_printf(\n);
}
}
+
+/* The info blockstats command. */
+void bdrv_info_stats (void)
+{
+BlockDriverState *bs;
+
+for (bs = bdrv_first; bs != NULL; bs = bs-next) {
+ term_printf (%s:
+ rd(bytes)=% PRIu64
+ wr(bytes)=% PRIu64
+ rd(sectors)=% PRIu64
+ wr(sectors)=% PRIu64
+ rd(operations)=% PRIu64
+ wr(operations)=% PRIu64
+ \n,
+ bs-device_name,
+ bs-rd_bytes, bs-wr_bytes,
+ bs-rd_sects, bs-wr_sects,
+ bs-rd_ops, bs-wr_ops);
+}
+}
#endif
void bdrv_get_backing_filename(BlockDriverState *bs,
@@ -1065,6 +1094,7 @@
BlockDriverCompletionFunc *cb, void *opaque)
{
BlockDriver *drv = bs-drv;
+BlockDriverAIOCB *ret;
if (!drv)
return NULL;
@@ -1077,7 +1107,16 @@
buf += 512;
}
-return drv-bdrv_aio_read(bs, sector_num, buf, nb_sectors, cb, opaque);
+ret = drv-bdrv_aio_read(bs, sector_num, buf, nb_sectors, cb, opaque);
+
+if (ret) {
+ /* Update stats even though technically transfer has not happened. */
+ bs-rd_bytes += (unsigned) nb_sectors * SECTOR_SIZE;
+ bs-rd_sects += (unsigned) nb_sectors;
+ bs-rd_ops ++;
+}
+
+return ret;
}
BlockDriverAIOCB *bdrv_aio_write(BlockDriverState *bs, int64_t sector_num,
@@ -1085,6 +1124,7 @@
BlockDriverCompletionFunc *cb, void *opaque)
{
BlockDriver *drv = bs-drv;
+BlockDriverAIOCB *ret;
if (!drv)
return NULL;
@@ -1094,7 +1134,16 @@
memcpy(bs-boot_sector_data, buf, 512);
}
-return drv-bdrv_aio_write(bs, sector_num, buf, nb_sectors, cb, opaque);
+ret = drv-bdrv_aio_write(bs, sector_num, buf, nb_sectors, cb, opaque);
+
+if (ret) {
+ /* Update stats even though technically transfer has not happened. */
+ bs-wr_bytes += (unsigned) nb_sectors * SECTOR_SIZE;
+ bs-wr_sects += (unsigned) nb_sectors;
+ bs-wr_ops ++;
+}
+
+return ret;
}
void bdrv_aio_cancel(BlockDriverAIOCB *acb)
Index: block.h
===
RCS file: /sources/qemu/qemu/block.h,v
retrieving revision 1.1
diff -u -r1.1 block.h
--- block.h 11 Nov 2007 02:51:16 - 1.1
+++ block.h 16 Nov 2007 15:23:44 -
@@ -48,6 +48,7 @@
#ifndef QEMU_IMG
void bdrv_info(void);
+void bdrv_info_stats(void);
#endif
void bdrv_init(void);
Index: block_int.h
===
RCS file: /sources/qemu/qemu/block_int.h,v
retrieving revision 1.14
diff -u -r1.14 block_int.h
--- block_int.h 11 Nov 2007 02:51:16 - 1.14
+++ block_int.h 16 Nov 2007 15:23:44 -
@@ -114,6 +114,14 @@
void *sync_aiocb;
+/* I/O stats (display with info blockstats). */
+uint64_t rd_bytes;
+uint64_t wr_bytes;
+uint64_t rd_sects;
+uint64_t wr_sects;
+uint64_t rd_ops;
+uint64_t wr_ops;
+
/* NOTE: the following infos are only hints for real hardware
drivers. They are not used by the block driver */
int cyls, heads, secs, translation;
Index: monitor.c
===
RCS file:
Re: [Qemu-devel] RFC: fix for random Qemu crashes
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. Presumably we only need one of the last two patches? It seems rather pointless to have always_inline *and* change the inlining heuristics. I'm ok with using always_inline for op.o (and things it uses directly) as this is required for correctness. I'm not convinced that that using always_inline everywhere is such a good idea. Paul
Re: [Qemu-devel] qemu target-ppc/cpu.h target-ppc/op.c target-pp...
On Fri, 2007-11-16 at 14:11 +, Jocelyn Mayer wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Jocelyn Mayer j_mayer 07/11/16 14:11:29 Modified files: target-ppc : cpu.h op.c op_helper.c op_helper.h translate.c . : translate-all.c Log message: Always make PowerPC hypervisor mode memory accesses and instructions available for full system emulation, then removing all #if TARGET_PPC64H from micro-ops and code translator. Add new macros to dramatically simplify memory access tables definitions in target-ppc/translate.c. Remark: one should take care that having the hypervisor memory accessor available might lead to trigger the gcc inlining limits bug. Then it seems to me that a fix for this bug is needed asap, as reported in my previous messages (titled RFC: fix for random Qemu crashes). -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] RFC: fix for random Qemu crashes
Jocelyn Mayer kirjoitti: On Fri, 2007-11-16 at 17:06 +0200, Heikki Lindholm wrote: J. Mayer kirjoitti: 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 Does -winline give a warning when this happens? I did not check this, but getting a warning won't help us a lot. The generated Qemu executable would still crash. But a warning makes the problem more noticable. I tried -Winline and it does give warnings, but I'm not sure whether I'm hitting the same behaviour you see. I silenced the lot with --param-max-inline-insns-single=4000 -- Heikki Lindholm
[Qemu-devel] [PATCH] hw/pxa2xx_gpio.c
This patch avoids crashing of QEMU when applications (e.g pxaregs) read the GPCR register. Index: pxa2xx_gpio.c === RCS file: /sources/qemu/qemu/hw/pxa2xx_gpio.c,v retrieving revision 1.5 diff -u -r1.5 pxa2xx_gpio.c --- pxa2xx_gpio.c 4 Oct 2007 19:41:17 - 1.5 +++ pxa2xx_gpio.c 16 Nov 2007 15:08:00 - @@ -157,6 +157,11 @@ printf(%s: Read from a write-only register REG_FMT \n, __FUNCTION__, offset); return s-gpsr[bank]; /* Return last written value. */ + +case GPCR: /* GPIO Pin-Output Clear registers */ +printf(%s: Read from a write-only register REG_FMT \n, +__FUNCTION__, offset); +return 0; /* Reading specified as unpredictable in documentation */ case GRER: /* GPIO Rising-Edge Detect Enable registers */ return s-rising[bank];
[Qemu-devel] ppc64 host support
Hello, I wrote a patch to add ppc64 host support somewhere in 2006 in posted it on this list, too. I haven't worked on it much since, but updated it now to the current CVS. The working status still seems to be mostly works, but unusable because of random crashes. The crashes happen when trying to boot a complex OS, say debian boot cd: it boots up to some point, occasionally even up to language select and crashes in some pretty random way, usually a guest segfault followed by an oops. I'm quite clueless where to look since sometimes things work and sometimes don't. Am I missing some ppc64 cache subtlety or what could this be? How could I create a test guest that is more deterministic than a linux install cd or such. FreeDOS, of course, works fine, but for example Duke Nukem in FreeDOS doesn't. I'd appreciate any tips/pointers how to get forward. -- Heikki Lindholm
Re: [Qemu-devel] RFC: fix for random Qemu crashes
On Fri, 2007-11-16 at 15:52 +, Paul Brook wrote: 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. Presumably we only need one of the last two patches? It seems rather pointless to have always_inline *and* change the inlining heuristics. From the tests I made, it seems that adding always_inline helps but unfortunatelly does not solve all cases. Should check in the gcc source code why it is so... I'm ok with using always_inline for op.o (and things it uses directly) as this is required for correctness. I'm not convinced that that using always_inline everywhere is such a good idea. That's exactly what I did: I changed 'inline' to 'always_inline' in headers that are included by op.c, I did not made any change in other headers. If some of the functions I changed should not be changed, that means that there is another bug, ie those functions should not be used by op.c in any way then should be moved to other headers, or maybe some of those headers should not be included directly or indirectly in op.c... If you see such cases, then we may better fix those issues first... -- Jocelyn Mayer [EMAIL PROTECTED]
Re: [Qemu-devel] RFC: fix for random Qemu crashes
J. Mayer kirjoitti: 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 Does -winline give a warning when this happens? -- Heikki Lindholm
Re: [Qemu-devel] RFC: fix for random Qemu crashes
On Fri, 2007-11-16 at 15:59 +, Jamie Lokier wrote: Heikki Lindholm wrote: J. Mayer kirjoitti: 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 Does -winline give a warning when this happens? And can it be repaired with __attribute__((__always_inline__))? As I already reported in the previous message, this helps solve the problem but is not sufficient. Please refer to the proposed patches and the rest of the discussion. Further invastigation also showed me that there may be problems while compiling translate-op.c. It seems the solution would be to change the gcc inlining limits into the BASE_CFLAGS too _and_ define functions in dyngen.h as always_inline. This would also avoid most inline related warnings during the compilation (but maybe not solve all cases, as seen in the op.c case). Reading gcc source code showed me there are cases where a function could be not inline when marked 'inline' without generating any warning message. What I don't know is if those cases are likely to happen during normal compilations, but as the op.c compilation seems to be buggy and never emit those warnings, I guess we can reach those cases. -- Jocelyn Mayer [EMAIL PROTECTED]
[Qemu-devel] qemu target-ppc/cpu.h target-ppc/op.c target-pp...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/11/16 14:11:29 Modified files: target-ppc : cpu.h op.c op_helper.c op_helper.h translate.c . : translate-all.c Log message: Always make PowerPC hypervisor mode memory accesses and instructions available for full system emulation, then removing all #if TARGET_PPC64H from micro-ops and code translator. Add new macros to dramatically simplify memory access tables definitions in target-ppc/translate.c. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.93r2=1.94 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemur1=1.67r2=1.68 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemur1=1.68r2=1.69 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.h?cvsroot=qemur1=1.28r2=1.29 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemur1=1.108r2=1.109 http://cvs.savannah.gnu.org/viewcvs/qemu/translate-all.c?cvsroot=qemur1=1.21r2=1.22
[Qemu-devel] Re: s390 host support
Updated patch attached.
On Sat, Nov 10, 2007 at 09:42:19PM +0100, Bastian Blank wrote:
It does the following changes:
- Hardcode -march=z900 to generate usable op code.
- Add redirection for parameter expansion in op code.
- Cleanup GOTO_LABEL_PARAM.
- Accept any return from function (like br %r5).
- Support R_390_PC32DBL relocation, including relocations into sections.
- Remove special GOTO_TB handler, it segfaults.
Bastian
--
A little suffering is good for the soul.
-- Kirk, The Corbomite Maneuver, stardate 1514.0
Index: check_ops.sh
===
RCS file: /sources/qemu/qemu/check_ops.sh,v
retrieving revision 1.1
diff -u -r1.1 check_ops.sh
--- check_ops.sh7 Jan 2007 19:38:08 - 1.1
+++ check_ops.sh16 Nov 2007 19:06:44 -
@@ -35,6 +35,9 @@
mips*)
ret='\tjr.*ra'
;;
+ s390*)
+ret='\tbr.*'
+;;
*)
echo Unknown machine `uname -m`
;;
Index: configure
===
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.172
diff -u -r1.172 configure
--- configure 12 Nov 2007 01:56:17 - 1.172
+++ configure 16 Nov 2007 19:06:44 -
@@ -354,6 +354,9 @@
ARCH_LDFLAGS=${SP_LDFLAGS}
fi
;;
+s390)
+ ARCH_CFLAGS=-march=z900
+ ;;
esac
if [ $solaris = yes -a $cpu = x86_64 ] ; then
Index: dyngen-exec.h
===
RCS file: /sources/qemu/qemu/dyngen-exec.h,v
retrieving revision 1.38
diff -u -r1.38 dyngen-exec.h
--- dyngen-exec.h 16 Sep 2007 21:07:49 - 1.38
+++ dyngen-exec.h 16 Nov 2007 19:06:44 -
@@ -38,7 +38,7 @@
// Linux/Sparc64 defines uint64_t
#if !(defined (__sparc_v9__) defined(__linux__))
/* XXX may be done for all 64 bits targets ? */
-#if defined (__x86_64__) || defined(__ia64)
+#if defined (__x86_64__) || defined(__ia64) || defined(__s390x__)
typedef unsigned long uint64_t;
#else
typedef unsigned long long uint64_t;
@@ -55,7 +55,7 @@
typedef signed int int32_t;
// Linux/Sparc64 defines int64_t
#if !(defined (__sparc_v9__) defined(__linux__))
-#if defined (__x86_64__) || defined(__ia64)
+#if defined (__x86_64__) || defined(__ia64) || defined(__s390x__)
typedef signed long int64_t;
#else
typedef signed long long int64_t;
@@ -205,7 +205,7 @@
#define stringify(s) tostring(s)
#define tostring(s)#s
-#ifdef __alpha__
+#if defined(__alpha__) || defined(__s390__)
/* the symbols are considered non exported so a br immediate is generated */
#define __hidden __attribute__((visibility(hidden)))
#else
@@ -224,6 +224,13 @@
#define PARAM1 ({ int _r; asm( : =r(_r) : 0 (__op_param1)); _r; })
#define PARAM2 ({ int _r; asm( : =r(_r) : 0 (__op_param2)); _r; })
#define PARAM3 ({ int _r; asm( : =r(_r) : 0 (__op_param3)); _r; })
+#elif defined(__s390__)
+extern int __op_param1 __hidden;
+extern int __op_param2 __hidden;
+extern int __op_param3 __hidden;
+#define PARAM1 ({ int _r; asm(bras %0,8; .long ASM_NAME(__op_param1) ; l
%0,0(%0) : =r(_r) : ); _r; })
+#define PARAM2 ({ int _r; asm(bras %0,8; .long ASM_NAME(__op_param2) ; l
%0,0(%0) : =r(_r) : ); _r; })
+#define PARAM3 ({ int _r; asm(bras %0,8; .long ASM_NAME(__op_param3) ; l
%0,0(%0) : =r(_r) : ); _r; })
#else
#if defined(__APPLE__)
static int __op_param1, __op_param2, __op_param3;
@@ -254,7 +261,7 @@
#define GOTO_LABEL_PARAM(n) asm volatile (b ASM_NAME(__op_gen_label) #n)
#elif defined(__s390__)
#define EXIT_TB() asm volatile (br %r14)
-#define GOTO_LABEL_PARAM(n) asm volatile (bras %r7,8; .long
ASM_NAME(__op_gen_label) #n ; l %r7, 0(%r7); br %r7)
+#define GOTO_LABEL_PARAM(n) asm volatile (larl %r7,12; l %r7,0(%r7); br %r7;
.long ASM_NAME(__op_gen_label) #n)
#elif defined(__alpha__)
#define EXIT_TB() asm volatile (ret)
#elif defined(__ia64__)
Index: dyngen.c
===
RCS file: /sources/qemu/qemu/dyngen.c,v
retrieving revision 1.57
diff -u -r1.57 dyngen.c
--- dyngen.c7 Nov 2007 16:07:32 - 1.57
+++ dyngen.c16 Nov 2007 19:06:45 -
@@ -1495,8 +1495,8 @@
p = (void *)(p_end - 2);
if (p == p_start)
error(empty code for %s, name);
-if (get16((uint16_t *)p) != 0x07fe get16((uint16_t *)p) != 0x07f4)
-error(br %%r14 expected at the end of %s, name);
+if ((get16((uint16_t *)p) 0xfff0) != 0x07f0)
+error(br expected at the end of %s, name);
copy_size = p - p_start;
}
#elif defined(HOST_ALPHA)
@@ -2120,6 +2120,19 @@
fprintf(outfile, *(uint8_t *)(gen_code_ptr +
%d) = %s + %d;\n,
reloc_offset, relname, addend);
break;
+case R_390_PC32DBL:
+if
Re: [Qemu-devel] [PATCH] Collecting block device statistics
On Fri, Nov 16, 2007 at 03:29:48PM +, Richard W.M. Jones wrote: Hi, I was looking for a way to collect information on the amount of data being written and read from block devices. The attached patch adds a few counters to the BlockDriverState structure to collect this information, and a new info blockstats monitor command to display it. This screenshot shows it in action: http://www.annexia.org/tmp/Screenshot-QEMU.png This is the sort of feature I'd really like to see merged into qemu because it will let us enhance libvirt to centrally collect these stats from qemu instances. It looks good to me - this would be a very useful feature addition. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Re: [Qemu-devel] RFC: fix for random Qemu crashes
Heikki Lindholm wrote: J. Mayer kirjoitti: 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 Does -winline give a warning when this happens? And can it be repaired with __attribute__((__always_inline__))? -- Jamie
[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
Hi, 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. For -cdrom you need ISO images. For -hd[a-d] you need harddisk-images, which are done like this dd id=/dev/hda of=myimage.img qemu -hda myimage.img You can´t dd a directory. You could mkisofs a directory or you could use the Samba sharing to hand over a directory. The same image I can successfully mount with -cdrom cannot be mounted with either -hdb or -hdd, Then it´s likely an ISO image, and not a harddisk image. What's up there. I could not figure out from the manuals if these should just be dd'ed images a directory or iso? You have to dd a whole harddisk (not just a partition) 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. I don´t know. 4) What is the attainable USB speed? Full USB-1 ? I think speed is something virtual at that point, but I am not sure. 5) Are the serial and parallel ports running at native speed without delays? You will always have delays in full-system emulation systems like Qemu. How large those are depends on a lot of factors, so you should measure it yourself, I guess. Best regards, Philipp Gühring
Re: [Qemu-devel] RFC: fix for random Qemu crashes
On 16/11/2007, Jocelyn Mayer [EMAIL PROTECTED] wrote: On Fri, 2007-11-16 at 15:52 +, Paul Brook wrote: 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. Presumably we only need one of the last two patches? It seems rather pointless to have always_inline *and* change the inlining heuristics. From the tests I made, it seems that adding always_inline helps but unfortunatelly does not solve all cases. Should check in the gcc source code why it is so... I'm ok with using always_inline for op.o (and things it uses directly) as this is required for correctness. I'm not convinced that that using always_inline everywhere is such a good idea. That's exactly what I did: I changed 'inline' to 'always_inline' in headers that are included by op.c, I did not made any change in other headers. I think a line like #define inline __attribute__ (( always_inline )) inline in dyngen-exec.h should be enough? Regards
Re: [Qemu-devel] Help needed! dyngen: Unsupported ELF class
I tried it, but still got the same error. Any further suggestion? Thanks, -x On Nov 15, 2007 2:46 AM, Ulrich Hecht [EMAIL PROTECTED] wrote: 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 ARM EABI project
Hi all, I'm creating a project in Sourceforge to maintain a bleeding edge version of QEMU for ARM-EABI programs. The main idea is to keep up to date the ARM EABI patches. This project will be specially useful for Maemo developers and Scratchbox users as it provides an alternative (newer) version of QEMU. For more details: http://qemu-arm-eabi.sf.net/. The current QEMU-ARM-EABI version was synchronized last wednesday with QEMU CVS and it's working well. It was tested with Maemo/Scratchbox and Mamona. Contributions are welcome. -- Lauro Ramos Venancio OpenBossa Labs - Instituto Nokia de Tecnologia Recife - Brazil
[Qemu-devel] Patch: Fix Win98SE MyComputer regression
After some testing, I've made a minor fix to the Rev 1.66 patch of hw/ide.c. With this patch, and the current CVS tree, I'm once again able to see the devices after clicking on MyComputer in my Win98SE guest. Ben --- qemu.ORIG/hw/ide.c 2007-11-08 11:38:17.0 -0500 +++ qemu/hw/ide.c 2007-11-16 17:02:22.579592000 -0500 @@ -1353,7 +1353,7 @@ buf[8] = 0x2a; buf[9] = 0x12; -buf[10] = 0x08; +buf[10] = 0x00; buf[11] = 0x00; buf[12] = 0x70;
Re: [Qemu-devel] Qemu ARM EABI project
On Friday 16 November 2007, Lauro Ramos Venancio wrote: Hi all, I'm creating a project in Sourceforge to maintain a bleeding edge version of QEMU for ARM-EABI programs. The main idea is to keep up to date the ARM EABI patches. Why don't you just fix whatever's wrong with normal qemu? Paul
Re: [Qemu-devel] Hardware virtualization with QEMU
On 16/11/2007, Philipp Gühring [EMAIL PROTECTED] wrote: Hi, 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. For -cdrom you need ISO images. For -hd[a-d] you need harddisk-images, which are done like this dd id=/dev/hda of=myimage.img qemu -hda myimage.img On systems where mounting is done manually you can use the ISO filesystem on a harddisk without problems. You can also mount filesystems from a partitioned image (what you call harddisk image) on a cdrom. So this is not true. You can´t dd a directory. You could mkisofs a directory or you could use the Samba sharing to hand over a directory. The same image I can successfully mount with -cdrom cannot be mounted with either -hdb or -hdd, Then it´s likely an ISO image, and not a harddisk image. What's up there. I could not figure out from the manuals if these should just be dd'ed images a directory or iso? dd just makes a copy. You can use the device or a dd'ed copy of the device (image) and it makes no difference. dd and cp can often be used interchangeably. You have to dd a whole harddisk (not just a partition) 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. I don´t know. 4) What is the attainable USB speed? Full USB-1 ? I think speed is something virtual at that point, but I am not sure. Yes, with virtual devices you can reach any speed the computer can do. With physical devices you can probably reach full speed (12 MB/s) or slow speed (1.5 MB/s) if your computer is fast enough. Regards
Re: [Qemu-devel] Qemu ARM EABI project
Hi Paul, Why don't you just fix whatever's wrong with normal qemu? Because some patches are not good enough to be applied in the mainstream version. Other patches was not applied because the developers that have write permission on CVS didn't have time to analyze them. The TLS patch is yours and it has never been applied. I think this project contributes to QEMU as it groups and updates the patches, making easier to test and apply them to the mainstream. This project will be dead in the near future when these patches are available in the mainstream QEMU. -- Lauro Ramos Venancio OpenBossa Labs - Instituto Nokia de Tecnologia Recife - Brazil
Re: [Qemu-devel] RFC: fix for random Qemu crashes
On Fri, 2007-11-16 at 21:32 +0100, andrzej zaborowski wrote: On 16/11/2007, Jocelyn Mayer [EMAIL PROTECTED] wrote: On Fri, 2007-11-16 at 15:52 +, Paul Brook wrote: 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. Presumably we only need one of the last two patches? It seems rather pointless to have always_inline *and* change the inlining heuristics. From the tests I made, it seems that adding always_inline helps but unfortunatelly does not solve all cases. Should check in the gcc source code why it is so... I'm ok with using always_inline for op.o (and things it uses directly) as this is required for correctness. I'm not convinced that that using always_inline everywhere is such a good idea. That's exactly what I did: I changed 'inline' to 'always_inline' in headers that are included by op.c, I did not made any change in other headers. I think a line like #define inline __attribute__ (( always_inline )) inline in dyngen-exec.h should be As I already pointed it in the first message of the thread, this kind of define would expand recursivelly, which is particullary ugly, and which can in some cases lead to compiler warnings or errors. I already had this kind of problems using the linux kernel headers which preciselly uses this definitition. But, once again, adding always_inline to functions does not completelly solve the problem (please read the thread !) or at least does not solves it with all gcc versions. The inline growth limits tweaking seems needed too. -- J. Mayer [EMAIL PROTECTED] Never organized
[Qemu-devel] qemu/darwin-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/11/17 01:52:38 Modified files: darwin-user: main.c Log message: Resynchronize darwin-user target with linux-user: add CPU selection feature, choose the correct default CPU and set the 32/64 bits computation mode properly. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/darwin-user/main.c?cvsroot=qemur1=1.12r2=1.13
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/11/17 01:54:46 Modified files: . : configure Log message: Remove ppc64h CPUs definitions from the configure script. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.172r2=1.173
[Qemu-devel] qemu hw/ppc.c target-ppc/cpu.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/11/17 02:04:00 Modified files: hw : ppc.c target-ppc : cpu.h Log message: Add missing definition for number of input pins for the PowerPC 970 bus. Use proper INPUT_NB definitions to allocate PowerPC input pins structure, fixing a buffer overflow in the 6xx bus case. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc.c?cvsroot=qemur1=1.37r2=1.38 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.95r2=1.96
[Qemu-devel] qemu darwin-user/main.c hw/ppc.c linux-user/mai...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/11/17 01:37:44 Modified files: darwin-user: main.c hw : ppc.c linux-user : main.c target-ppc : cpu.h helper.c helper_regs.h translate_init.c Log message: Always make all PowerPC exception definitions visible. Always make the hypervisor timers available. Remove all TARGET_PPC64H checks, keeping a few if (0) tests for cases that cannot be properly handled with the current PowerPC CPU definition. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/darwin-user/main.c?cvsroot=qemur1=1.11r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc.c?cvsroot=qemur1=1.36r2=1.37 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.154r2=1.155 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.94r2=1.95 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemur1=1.91r2=1.92 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper_regs.h?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.60r2=1.61
[Qemu-devel] qemu/target-ppc cpu.h translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/11/17 02:16:14 Modified files: target-ppc : cpu.h translate_init.c Log message: Make the PowerPC MMU model, exception model and input bus model typedefed enums. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.96r2=1.97 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.61r2=1.62
[Qemu-devel] Re: RFC: fix for random Qemu crashes
J. Mayer [EMAIL PROTECTED] writes: On Fri, 2007-11-16 at 21:32 +0100, andrzej zaborowski wrote: I think a line like #define inline __attribute__ (( always_inline )) inline in dyngen-exec.h should be As I already pointed it in the first message of the thread, this kind of define would expand recursivelly, [...] No. A macro is not expanded within its own expansion. See ISO C99: 6.10.3.4 Rescanning and further replacement [...] 2If the name of the macro being replaced is found during this scan of the replacement list (not including the rest of the source file's preprocessing tokens), it is not replaced. If it still bothers you, you could write it as #define inline __attribute__ (( always_inline )) __inline__ since GCC accepts __inline__ as a synonym for inline. -- Ben Pfaff http://benpfaff.org
