[Qemu-devel] Gcc 4 building error
Hello. I have (GCC) 4.2.1, when i'm tried to build qemu from cvs, i've got such error: Code: make -C i386-softmmu all make[1]: Entering directory `/mnt/work/install/compil/qemu/qemu/i386-softmmu' gcc -Wall -O2 -g -fno-strict-aliasing -fno-reorder-blocks -fno-gcse -fno-tree-ch -fno-optimize-sibling-calls -fno-crossjumping -fno-align-labels -fno-align-jumps -fno-align-functions -fno-section-anchors -mpreferred-stack-boundary=2 -fomit-frame-pointer -I. -I.. -I/mnt/work/install/compil/qemu/qemu/target-i386 -I/mnt/work/install/compil/qemu/qemu -MMD -MP -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/mnt/work/install/compil/qemu/qemu/fpu -I/opt/soft/gnutls-1.7.18/include -DHAS_AUDIO -DHAS_AUDIO_CHOICE -I/mnt/work/install/compil/qemu/qemu/slirp -c -o op.o /mnt/work/install/compil/qemu/qemu/target-i386/op.c /mnt/work/install/compil/qemu/qemu/target-i386/ops_template_mem.h: In function 'op_shlb_user_T0_T1_cc': ../softmmu_header.h:174: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' ../softmmu_header.h:174: error: 'asm' operand has impossible constraints make[1]: *** [op.o] Error 1 make[1]: Leaving directory `/mnt/work/install/compil/qemu/qemu/i386-softmmu' make: *** [subdir-i386-softmmu] Error 2 is this qemu bug, or gcc? is there any patches to avoid it?
Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)
On Sun, 2007-11-04 at 01:51 +, Paul Brook wrote: > > If you take a close look, you'll find more variations between Linux ABIs > > for different CPUs than between all BSD implementations: common syscalls > > of all BSD flavors do the same thing (and have the same ABI whatever the > > CPU...). You'll also find very few variations between the syscalls > > common to BSD & Linux because most of those directly map POSIX defined > > functions. > > Then, following the given argument, we never should try to share any > > code between linux-user for different targets, as the Linux ABI and > > behavior is different for different CPUs... > > I'd guess that the ones that are all the same are the ones that don't take > any > real effort to implement in the first place. > > If you can combine the implementations I'd also expect to be able to do cross > emulation. e.g. run *BSD applications on a Linux host. This definitely works > for simple cases, even in the extreme case of a windows host - as you say > many syscalls map directly onto POSIX functions so there is only ever one > implementation. Whether it works well enough for real applications or whole > distributions of software I'm not so sure. If you can't do cross emulation > I'm sceptical about how much they can be combined. Ooops... I should have been more precise. In my idea, it was "BSD-on-Linux" I was talking about. Let's say OpenBSD / NetBSD. FreeBSD has some specific tricks that might be difficult to map on Linux (or even other BSD), not even talking of Darwin which is quite impossible to emulate (or if one wants to emulate the IOkit...). The main difficulty of emulating BSD on Linux is the sysctl syscall, the trace facilites and the ioctls. I guess we can forget the ioctls... Most of the other syscalls mappings are quite like mapping one Linux port to another. -- J. Mayer <[EMAIL PROTECTED]> Never organized
Re: [Qemu-devel] [PATCH, RFC] Disable implicit self-modifying code support for RISC CPUs
On Sun, 2007-11-04 at 09:12 +0200, Blue Swirl wrote: > On 11/4/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote: > > Blue Swirl wrote: > > > Hi, > > > > > > RISC CPUs don't support self-modifying code unless the affected area > > > is flushed explicitly. This patch disables the extra effort for SMC. > > > The changes in this version would affect all CPUs except x86, but I'd > > > like to see if there are problems with some target, so that the > > > committed change can be limited. Without comments, I'll just disable > > > SMC for Sparc, as there are no problems. So please comment, especially > > > if you want to "opt in". > > > > > > For some reason, I can't disable all TB/TLB flushing, for example > > > there was already one line with TARGET_HAS_SMC || 1, but removing the > > > || 1 part causes crashing. Does anyone know why? > > > > With the current QEMU architecture, you cannot disable self-modifying > > code as you did. This is why I did not fully supported the > > TARGET_HAS_SMC flag. The problem is that the translator make the > > assumption that the RAM and the TB contents are consistent for example > > when handling exceptions. Suppressing this assumption is possible but > > requires more work. > > I think the conclusion is that we would need some kind of emulator for > i-cache for any accurate emulation. And handling the boot loader may > need an uncached mode. > The performance benefit from disabling SMC is unnoticeable according > to my benchmarks. Adding a TB flush to i-cache flushing made things > worse. Moreover, SMC is hardly ever used on Sparc. > > I'll just commit the debug statement fixes and > the fix that separates > PAGE_READ from PAGE_EXEC for Sparc. This patch is absolutely not needed. You have to directly call tlb_set_page_exec instead of tlb_set_page if you want to separate PAGE_READ from PAGE_EXEC. #ifdef TARGET_xxx should never occur in generic code and in that specific case, it's the Sparc target code that has to be fixed... > Maybe this issue should be documented in qemu-tech.texi, there are > also frequently some questions about caches. Yes, some documentation on such tricks can never hurt ! -- J. Mayer <[EMAIL PROTECTED]> Never organized
[Qemu-devel] qemu exec.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 07/11/04 07:31:40 Modified files: . : exec.c Log message: Fix debug statements CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.110&r2=1.111
Re: [Qemu-devel] [PATCH, RFC] Disable implicit self-modifying code support for RISC CPUs
On 11/4/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote: > Blue Swirl wrote: > > Hi, > > > > RISC CPUs don't support self-modifying code unless the affected area > > is flushed explicitly. This patch disables the extra effort for SMC. > > The changes in this version would affect all CPUs except x86, but I'd > > like to see if there are problems with some target, so that the > > committed change can be limited. Without comments, I'll just disable > > SMC for Sparc, as there are no problems. So please comment, especially > > if you want to "opt in". > > > > For some reason, I can't disable all TB/TLB flushing, for example > > there was already one line with TARGET_HAS_SMC || 1, but removing the > > || 1 part causes crashing. Does anyone know why? > > With the current QEMU architecture, you cannot disable self-modifying > code as you did. This is why I did not fully supported the > TARGET_HAS_SMC flag. The problem is that the translator make the > assumption that the RAM and the TB contents are consistent for example > when handling exceptions. Suppressing this assumption is possible but > requires more work. I think the conclusion is that we would need some kind of emulator for i-cache for any accurate emulation. And handling the boot loader may need an uncached mode. The performance benefit from disabling SMC is unnoticeable according to my benchmarks. Adding a TB flush to i-cache flushing made things worse. Moreover, SMC is hardly ever used on Sparc. I'll just commit the debug statement fixes and the fix that separates PAGE_READ from PAGE_EXEC for Sparc. Maybe this issue should be documented in qemu-tech.texi, there are also frequently some questions about caches.
Re: [Qemu-devel] qemu exec-all.h host-utils.c host-utils.h targe...
On Sun, 2007-11-04 at 02:24 +, Jocelyn Mayer wrote:
> CVSROOT: /sources/qemu
> Module name: qemu
> Changes by: Jocelyn Mayer 07/11/04 02:24:58
>
> Modified files:
> . : exec-all.h host-utils.c host-utils.h
> target-alpha : op.c
> target-i386: helper.c
>
> Log message:
> For consistency, move muls64 / mulu64 prototypes to host-utils.h
> Make x86_64 optimized versions inline.
Following this patch, I also got optimized versions of muls64 / mulu64 /
clz64 for PowerPC 64 and clz32 for PowerPC 32 hosts.
Seems like it could be useful...
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: host-utils.h
===
RCS file: /sources/qemu/qemu/host-utils.h,v
retrieving revision 1.3
diff -u -d -d -p -r1.3 host-utils.h
--- host-utils.h 4 Nov 2007 02:24:57 - 1.3
+++ host-utils.h 4 Nov 2007 02:26:34 -
@@ -40,6 +40,25 @@ static always_inline void muls64 (uint64
: "=d" (*phigh), "=a" (*plow)
: "a" (a), "0" (b));
}
+#elif defined(__powerpc64__)
+#define __HAVE_FAST_MULU64__
+static always_inline void mulu64 (uint64_t *plow, uint64_t *phigh,
+ uint64_t a, uint64_t b)
+{
+__asm__ ("mulld %1, %2, %3 \n\t"
+ "mulhdu %0, %2, %3 \n\t"
+ : "=r"(*phigh), "=r"(*plow)
+ : "r"(a), "r"(b));
+}
+#define __HAVE_FAST_MULS64__
+static always_inline void muls64 (uint64_t *plow, uint64_t *phigh,
+ uint64_t a, uint64_t b)
+{
+__asm__ ("mulld %1, %2, %3 \n\t"
+ "mulhd %0, %2, %3 \n\t"
+ : "=r"(*phigh), "=r"(*plow)
+ : "r"(a), "r"(b));
+}
#else
void muls64(int64_t *phigh, int64_t *plow, int64_t a, int64_t b);
void mulu64(uint64_t *phigh, uint64_t *plow, uint64_t a, uint64_t b);
@@ -50,7 +69,19 @@ void mulu64(uint64_t *phigh, uint64_t *p
cope with that. */
/* Binary search for leading zeros. */
+#if defined(__powerpc__)
+#define __HAVE_FAST_CLZ32__
+static always_inline int clz32 (uint32_t val)
+{
+int cnt;
+
+__asm__ ("cntlzw %0, %1 \n\t"
+ : "=r"(cnt)
+ : "r"(val));
+return cnt;
+}
+#else
static always_inline int clz32(uint32_t val)
{
int cnt = 0;
@@ -80,12 +111,26 @@ static always_inline int clz32(uint32_t
}
return cnt;
}
+#endif
static always_inline int clo32(uint32_t val)
{
return clz32(~val);
}
+#if defined(__powerpc64__)
+#define __HAVE_FAST_CLZ64__
+static always_inline int clz64 (uint32_t val)
+{
+int cnt;
+
+__asm__ ("cntlzd %0, %1 \n\t"
+ : "=r"(cnt)
+ : "r"(val));
+
+return cnt;
+}
+#else
static always_inline int clz64(uint64_t val)
{
int cnt = 0;
@@ -98,6 +143,7 @@ static always_inline int clz64(uint64_t
return cnt + clz32(val);
}
+#endif
static always_inline int clo64(uint64_t val)
{
[Qemu-devel] qemu/target-ppc cpu.h helper.c helper_regs.h op...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/11/04 02:55:34 Modified files: target-ppc : cpu.h helper.c helper_regs.h op.c op_helper.c op_helper.h translate.c translate_init.c Log message: PowerPC 601 need specific callbacks for its BATs setup. Implement PowerPC 601 HID0 register, needed for little-endian mode support. As a consequence, we need to merge hflags coming from MSR with other ones. Use little-endian mode from hflags instead of MSR during code translation. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.87&r2=1.88 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemu&r1=1.87&r2=1.88 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper_regs.h?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemu&r1=1.61&r2=1.62 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemu&r1=1.62&r2=1.63 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.h?cvsroot=qemu&r1=1.25&r2=1.26 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemu&r1=1.101&r2=1.102 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemu&r1=1.55&r2=1.56
[Qemu-devel] qemu exec-all.h host-utils.c host-utils.h targe...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/11/04 02:24:58 Modified files: . : exec-all.h host-utils.c host-utils.h target-alpha : op.c target-i386: helper.c Log message: For consistency, move muls64 / mulu64 prototypes to host-utils.h Make x86_64 optimized versions inline. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/exec-all.h?cvsroot=qemu&r1=1.69&r2=1.70 http://cvs.savannah.gnu.org/viewcvs/qemu/host-utils.c?cvsroot=qemu&r1=1.4&r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/host-utils.h?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/op.c?cvsroot=qemu&r1=1.4&r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemu&r1=1.92&r2=1.93
[Qemu-devel] qemu/target-ppc translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/11/04 01:57:29 Modified files: target-ppc : translate.c Log message: Improve PowerPC CPU state dump. Dump NIP on SPR access faults. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemu&r1=1.100&r2=1.101
Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)
> If you take a close look, you'll find more variations between Linux ABIs > for different CPUs than between all BSD implementations: common syscalls > of all BSD flavors do the same thing (and have the same ABI whatever the > CPU...). You'll also find very few variations between the syscalls > common to BSD & Linux because most of those directly map POSIX defined > functions. > Then, following the given argument, we never should try to share any > code between linux-user for different targets, as the Linux ABI and > behavior is different for different CPUs... I'd guess that the ones that are all the same are the ones that don't take any real effort to implement in the first place. If you can combine the implementations I'd also expect to be able to do cross emulation. e.g. run *BSD applications on a Linux host. This definitely works for simple cases, even in the extreme case of a windows host - as you say many syscalls map directly onto POSIX functions so there is only ever one implementation. Whether it works well enough for real applications or whole distributions of software I'm not so sure. If you can't do cross emulation I'm sceptical about how much they can be combined. Paul
Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)
On Sat, 2007-11-03 at 19:16 -0600, Thayne Harbaugh wrote: > On Sat, 2007-11-03 at 20:13 +0100, Fabrice Bellard wrote: > > Thayne Harbaugh wrote: > > > On Sat, 2007-11-03 at 13:52 +0100, J. Mayer wrote: > > >> On Sat, 2007-11-03 at 01:21 +, Thiemo Seufer wrote: > > >> [...] > > >> But it could be great to group the syscalls by > > >> categories, or so. For example, putting all POSIX compliant syscalls in > > >> a single file and using a syscall table could make quite easy to develop > > >> a BSD-user target (I did this in the past, not in Qemu though...). POSIX > > >> compliant interfaces can mostly be shared with Linux ones and a lot of > > >> other syscalls are common to the 3 BSD flavors (Net, Open and Free..). > > >> Being able to add a BSD target sharing the same code would be a proof > > >> the code is flexible and well organized; I guess large parts of the > > >> Darwin user target could also be merged with a FreeBSD user target... > > > > > > That's a reasonable strategy as well. I've looked through some of the > > > darwin code and have considered how common code could be merged. > > > > I am strongly against such merges. > > > > Different OS emulation must be handled in different directories (and > > maybe even in different projects) as they are likely to have subtle > > differences which makes impossible to test a modification made for one > > OS without testing all the other OSes. > > Agreed. If you take a close look, you'll find more variations between Linux ABIs for different CPUs than between all BSD implementations: common syscalls of all BSD flavors do the same thing (and have the same ABI whatever the CPU...). You'll also find very few variations between the syscalls common to BSD & Linux because most of those directly map POSIX defined functions. Then, following the given argument, we never should try to share any code between linux-user for different targets, as the Linux ABI and behavior is different for different CPUs... -- J. Mayer <[EMAIL PROTECTED]> Never organized
Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)
On Sat, 2007-11-03 at 20:13 +0100, Fabrice Bellard wrote: > Thayne Harbaugh wrote: > > On Sat, 2007-11-03 at 13:52 +0100, J. Mayer wrote: > >> On Sat, 2007-11-03 at 01:21 +, Thiemo Seufer wrote: > >> [...] > >> But it could be great to group the syscalls by > >> categories, or so. For example, putting all POSIX compliant syscalls in > >> a single file and using a syscall table could make quite easy to develop > >> a BSD-user target (I did this in the past, not in Qemu though...). POSIX > >> compliant interfaces can mostly be shared with Linux ones and a lot of > >> other syscalls are common to the 3 BSD flavors (Net, Open and Free..). > >> Being able to add a BSD target sharing the same code would be a proof > >> the code is flexible and well organized; I guess large parts of the > >> Darwin user target could also be merged with a FreeBSD user target... > > > > That's a reasonable strategy as well. I've looked through some of the > > darwin code and have considered how common code could be merged. > > I am strongly against such merges. > > Different OS emulation must be handled in different directories (and > maybe even in different projects) as they are likely to have subtle > differences which makes impossible to test a modification made for one > OS without testing all the other OSes. Agreed.
[Qemu-devel] qemu/hw macio.c mac_nvram.c ppc_chrp.c ppc_mac....
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/11/04 01:16:04 Modified files: hw : macio.c mac_nvram.c ppc_chrp.c ppc_mac.h ppc_oldworld.c Log message: Fix PowerMac NVRAM device. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/macio.c?cvsroot=qemu&r1=1.1&r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mac_nvram.c?cvsroot=qemu&r1=1.1&r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_chrp.c?cvsroot=qemu&r1=1.47&r2=1.48 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_mac.h?cvsroot=qemu&r1=1.1&r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_oldworld.c?cvsroot=qemu&r1=1.3&r2=1.4
Re: [Qemu-devel] [PATCH, RFC] Disable implicit self-modifying code support for RISC CPUs
> RISC CPUs don't support self-modifying code unless the affected area > is flushed explicitly. For experience with ARM cpus, I think this is only true for userspace. Many CPUs only require explicit flushes when the icache is enabled. It's not uncommon for bootloaders to leave the icache disabled and omit the cache flushes. The ARM cache flush instructions/syscalls are currently implemented as a no-op, so nontrivial additional work would be required to disabled the qemu SMC detections. IIRC there are also special cases where a system call instruction guarantees some level of architectural consistency for backwards compatibility. On some cores it is only necessary to flush the pipeline, but it's also common to know that e.g. a particular core has a 4-stage pipeline, so inserting 4 NOPs is sufficient to ensure consistency. Paul
Re: [Qemu-devel] [PATCH, RFC] Disable implicit self-modifying code support for RISC CPUs
Blue Swirl wrote: > Hi, > > RISC CPUs don't support self-modifying code unless the affected area > is flushed explicitly. This patch disables the extra effort for SMC. > The changes in this version would affect all CPUs except x86, but I'd > like to see if there are problems with some target, so that the > committed change can be limited. Without comments, I'll just disable > SMC for Sparc, as there are no problems. So please comment, especially > if you want to "opt in". > > For some reason, I can't disable all TB/TLB flushing, for example > there was already one line with TARGET_HAS_SMC || 1, but removing the > || 1 part causes crashing. Does anyone know why? With the current QEMU architecture, you cannot disable self-modifying code as you did. This is why I did not fully supported the TARGET_HAS_SMC flag. The problem is that the translator make the assumption that the RAM and the TB contents are consistent for example when handling exceptions. Suppressing this assumption is possible but requires more work. Regards, Fabrice.
Re: [Qemu-devel] [PATCH] Fix NaN handling in softfloat
On Sat, Nov 03, 2007 at 02:06:04PM -0400, Daniel Jacobowitz wrote:
> On Sat, Nov 03, 2007 at 06:35:48PM +0100, Aurelien Jarno wrote:
> > Hi all,
> >
> > The current softfloat implementation changes qNaN into sNaN when
> > converting between formats, for no reason. The attached patch fixes
> > that. It also fixes an off-by-one in the extended double precision
> > format (aka floatx80), the mantissa is 64-bit long and not 63-bit
> > long.
> >
> > With this patch applied all the glibc 2.7 floating point tests
> > are successfull on MIPS and MIPSEL.
>
> FYI, I posted a similar patch and haven't had time to get back to it.
> Andreas reminded me that we need to make sure at least one mantissa
> bit is set. If we're confident that the common NaN format will
> already have some bit other than the qnan/snan bit set, this is fine;
> otherwise, we might want to forcibly set some other mantissa bit.
>
Please find an updated patch below. I have tried to match real x86, MIPS,
HPPA, PowerPC and SPARC hardware when all mantissa bits are cleared.
Index: fpu/softfloat-specialize.h
===
RCS file: /sources/qemu/qemu/fpu/softfloat-specialize.h,v
retrieving revision 1.3
diff -u -d -p -r1.3 softfloat-specialize.h
--- fpu/softfloat-specialize.h 11 May 2007 17:10:14 - 1.3
+++ fpu/softfloat-specialize.h 3 Nov 2007 21:17:57 -
@@ -120,9 +120,17 @@ static commonNaNT float32ToCommonNaN( fl
static float32 commonNaNToFloat32( commonNaNT a )
{
-
-return ( ( (bits32) a.sign )<<31 ) | 0x7FC0 | ( a.high>>41 );
-
+bits32 mantissa = a.high>>41;
+if (mantissa)
+return ( ( (bits32) a.sign )<<31 ) | 0x7F80 | ( mantissa );
+else
+#if defined(TARGET_MIPS)
+return ( ( (bits32) a.sign )<<31 ) | 0x7FBF | ( mantissa );
+#elif defined(TARGET_HPPA)
+return ( ( (bits32) a.sign )<<31 ) | 0x7FA0 | ( mantissa );
+#else
+return ( ( (bits32) a.sign )<<31 ) | 0x7FC0;
+#endif
}
/*
@@ -230,11 +238,15 @@ static commonNaNT float64ToCommonNaN( fl
static float64 commonNaNToFloat64( commonNaNT a )
{
+bits64 mantissa = a.high>>12;
-return
- ( ( (bits64) a.sign )<<63 )
-| LIT64( 0x7FF8 )
-| ( a.high>>12 );
+if ( mantissa )
+return ( ( (bits64) a.sign )<<63 )
+| LIT64( 0x7FF0 )
+| ( mantissa );
+else
+return ( ( (bits64) a.sign )<<63 )
+| LIT64( 0x7FF8 );
}
@@ -329,7 +341,7 @@ static commonNaNT floatx80ToCommonNaN( f
if ( floatx80_is_signaling_nan( a ) ) float_raise( float_flag_invalid
STATUS_VAR);
z.sign = a.high>>15;
z.low = 0;
-z.high = a.low<<1;
+z.high = a.low;
return z;
}
@@ -343,7 +355,10 @@ static floatx80 commonNaNToFloatx80( com
{
floatx80 z;
-z.low = LIT64( 0xC000 ) | ( a.high>>1 );
+if (a.high)
+z.low = a.high;
+else
+z.low = LIT64( 0x8000 );
z.high = ( ( (bits16) a.sign )<<15 ) | 0x7FFF;
return z;
@@ -449,7 +464,7 @@ static float128 commonNaNToFloat128( com
float128 z;
shift128Right( a.high, a.low, 16, &z.high, &z.low );
-z.high |= ( ( (bits64) a.sign )<<63 ) | LIT64( 0x7FFF8000 );
+z.high |= ( ( (bits64) a.sign )<<63 ) | LIT64( 0x7FFF );
return z;
}
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
Re: [Qemu-devel] [PATCH, RFC] Disable implicit self-modifying code support for RISC CPUs
Blue Swirl wrote: > Hi, > > RISC CPUs don't support self-modifying code unless the affected area > is flushed explicitly. Not entirely true. There are cacheless MIPS CPUs (the m4k), and also cache-snooping MIPS CPUs (the R1x000). > This patch disables the extra effort for SMC. > The changes in this version would affect all CPUs except x86, but I'd > like to see if there are problems with some target, so that the > committed change can be limited. Without comments, I'll just disable > SMC for Sparc, as there are no problems. So please comment, especially > if you want to "opt in". I prefer at least MIPS to stay as is. Thiemo
[Qemu-devel] [PATCH, RFC] Disable implicit self-modifying code support for RISC CPUs
Hi,
RISC CPUs don't support self-modifying code unless the affected area
is flushed explicitly. This patch disables the extra effort for SMC.
The changes in this version would affect all CPUs except x86, but I'd
like to see if there are problems with some target, so that the
committed change can be limited. Without comments, I'll just disable
SMC for Sparc, as there are no problems. So please comment, especially
if you want to "opt in".
For some reason, I can't disable all TB/TLB flushing, for example
there was already one line with TARGET_HAS_SMC || 1, but removing the
|| 1 part causes crashing. Does anyone know why?
Index: qemu/exec.c
===
--- qemu.orig/exec.c 2007-11-03 11:39:44.0 +
+++ qemu/exec.c 2007-11-03 18:38:48.0 +
@@ -100,10 +100,12 @@
typedef struct PageDesc {
/* list of TBs intersecting this ram page */
TranslationBlock *first_tb;
+#ifdef TARGET_HAS_SMC
/* in order to optimize self modifying code, we count the number
of lookups we do to a given page to use a bitmap */
unsigned int code_write_count;
uint8_t *code_bitmap;
+#endif
#if defined(CONFIG_USER_ONLY)
unsigned long flags;
#endif
@@ -306,6 +308,7 @@
*penv = env;
}
+#ifdef TARGET_HAS_SMC
static inline void invalidate_page_bitmap(PageDesc *p)
{
if (p->code_bitmap) {
@@ -314,6 +317,7 @@
}
p->code_write_count = 0;
}
+#endif
/* set to NULL all the 'first_tb' fields in all PageDescs */
static void page_flush_tb(void)
@@ -326,7 +330,9 @@
if (p) {
for(j = 0; j < L2_SIZE; j++) {
p->first_tb = NULL;
+#ifdef TARGET_HAS_SMC
invalidate_page_bitmap(p);
+#endif
p++;
}
}
@@ -339,10 +345,11 @@
{
CPUState *env;
#if defined(DEBUG_FLUSH)
-printf("qemu: flush code_size=%d nb_tbs=%d avg_tb_size=%d\n",
- code_gen_ptr - code_gen_buffer,
+printf("qemu: flush code_size=%ld nb_tbs=%d avg_tb_size=%ld\n",
+ (unsigned long)(code_gen_ptr - code_gen_buffer),
nb_tbs,
- nb_tbs > 0 ? (code_gen_ptr - code_gen_buffer) / nb_tbs : 0);
+ nb_tbs > 0 ? ((unsigned long)(code_gen_ptr - code_gen_buffer))
+ / nb_tbs : 0);
#endif
nb_tbs = 0;
@@ -502,12 +509,16 @@
if (tb->page_addr[0] != page_addr) {
p = page_find(tb->page_addr[0] >> TARGET_PAGE_BITS);
tb_page_remove(&p->first_tb, tb);
+#ifdef TARGET_HAS_SMC
invalidate_page_bitmap(p);
+#endif
}
if (tb->page_addr[1] != -1 && tb->page_addr[1] != page_addr) {
p = page_find(tb->page_addr[1] >> TARGET_PAGE_BITS);
tb_page_remove(&p->first_tb, tb);
+#ifdef TARGET_HAS_SMC
invalidate_page_bitmap(p);
+#endif
}
tb_invalidated_flag = 1;
@@ -567,6 +578,7 @@
}
}
+#ifdef TARGET_HAS_SMC
static void build_page_bitmap(PageDesc *p)
{
int n, tb_start, tb_end;
@@ -597,6 +609,7 @@
tb = tb->page_next[n];
}
}
+#endif
#ifdef TARGET_HAS_PRECISE_SMC
@@ -653,12 +666,14 @@
p = page_find(start >> TARGET_PAGE_BITS);
if (!p)
return;
+#ifdef TARGET_HAS_SMC
if (!p->code_bitmap &&
++p->code_write_count >= SMC_BITMAP_USE_THRESHOLD &&
is_cpu_write_access) {
/* build code bitmap */
build_page_bitmap(p);
}
+#endif
/* we remove all the TBs in the range [start, end[ */
/* XXX: see if in some cases it could be faster to invalidate all the code */
@@ -733,7 +748,9 @@
#if !defined(CONFIG_USER_ONLY)
/* if no code remaining, no need to continue to use slow writes */
if (!p->first_tb) {
+#ifdef TARGET_HAS_SMC
invalidate_page_bitmap(p);
+#endif
if (is_cpu_write_access) {
tlb_unprotect_code_phys(env, start, env->mem_write_vaddr);
}
@@ -756,7 +773,9 @@
static inline void tb_invalidate_phys_page_fast(target_ulong start, int len)
{
PageDesc *p;
+#ifdef TARGET_HAS_SMC
int offset, b;
+#endif
#if 0
if (1) {
if (loglevel) {
@@ -770,6 +789,7 @@
p = page_find(start >> TARGET_PAGE_BITS);
if (!p)
return;
+#ifdef TARGET_HAS_SMC
if (p->code_bitmap) {
offset = start & ~TARGET_PAGE_MASK;
b = p->code_bitmap[offset >> 3] >> (offset & 7);
@@ -777,11 +797,15 @@
goto do_invalidate;
} else {
do_invalidate:
+#endif
tb_invalidate_phys_page_range(start, start + len, 1);
+#ifdef TARGET_HAS_SMC
}
+#endif
}
#if !defined(CONFIG_SOFTMMU)
+#ifndef TARGET_SPARC
static void tb_invalidate_phys_page(target_ulong addr,
unsigned long pc, void *puc)
{
@@ -849,6 +873,7 @@
#endif
}
#endif
+#endif
/* add the tb in the target page and protect it if necessary */
static inline void tb_alloc_page(TranslationBlock *tb,
@@ -862,11 +887,14 @@
tb->page_next[n] = p->first_tb;
last_first_tb = p->f
Re: [Qemu-devel] [PATCH] Fix NaN handling in softfloat
Daniel Jacobowitz a écrit : > On Sat, Nov 03, 2007 at 06:35:48PM +0100, Aurelien Jarno wrote: >> Hi all, >> >> The current softfloat implementation changes qNaN into sNaN when >> converting between formats, for no reason. The attached patch fixes >> that. It also fixes an off-by-one in the extended double precision >> format (aka floatx80), the mantissa is 64-bit long and not 63-bit >> long. >> >> With this patch applied all the glibc 2.7 floating point tests >> are successfull on MIPS and MIPSEL. > > FYI, I posted a similar patch and haven't had time to get back to it. > Andreas reminded me that we need to make sure at least one mantissa > bit is set. If we're confident that the common NaN format will > already have some bit other than the qnan/snan bit set, this is fine; > otherwise, we might want to forcibly set some other mantissa bit. > Good point. I will try to improve my patch. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net
Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)
Thayne Harbaugh wrote: > On Sat, 2007-11-03 at 13:52 +0100, J. Mayer wrote: >> On Sat, 2007-11-03 at 01:21 +, Thiemo Seufer wrote: >> [...] >> But it could be great to group the syscalls by >> categories, or so. For example, putting all POSIX compliant syscalls in >> a single file and using a syscall table could make quite easy to develop >> a BSD-user target (I did this in the past, not in Qemu though...). POSIX >> compliant interfaces can mostly be shared with Linux ones and a lot of >> other syscalls are common to the 3 BSD flavors (Net, Open and Free..). >> Being able to add a BSD target sharing the same code would be a proof >> the code is flexible and well organized; I guess large parts of the >> Darwin user target could also be merged with a FreeBSD user target... > > That's a reasonable strategy as well. I've looked through some of the > darwin code and have considered how common code could be merged. I am strongly against such merges. Different OS emulation must be handled in different directories (and maybe even in different projects) as they are likely to have subtle differences which makes impossible to test a modification made for one OS without testing all the other OSes. Regards, Fabrice.
Re: [Qemu-devel] [PATCH] Fix NaN handling in softfloat
Thiemo Seufer a écrit : > Aurelien Jarno wrote: >> Hi all, >> >> The current softfloat implementation changes qNaN into sNaN when >> converting between formats, for no reason. The attached patch fixes >> that. > > Did you take into account that MIPS and PA-RISC have the signalling > bit inverted to the rest of the world? Oh didn't know about that! Anyway that doesn't change anything, as the patch simply copy parts of the mantissa from one format to another. That just means on other architectures, sNaN are changed into qNaN. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net
Re: [Qemu-devel] Re: [PATCH] efault - add data type to put_user()/get_user()
I think that using host addresses in __put_user and __get_user is not logical. They should use target addresses as get_user and put_user. As Paul said, It is not worth mixing get/put/copy and lock/unlock functions. The ultimate goal of such cleanup is not only to generate -EFAULT correctly but also to be able to have arbitrary address space changes. In fact it would be good to be able to introduce an arbitrary address space change (such as a translation as Paul did) so that we can verify that all the Linux emulation stills works in this case. Regards, Fabrice. Thayne Harbaugh wrote: > On Wed, 2007-10-31 at 16:44 -0600, Thayne Harbaugh wrote: >> This patch updates get_user() and put_user() to take a third argument of >> data type. get_user() and put_user() use target address which are >> target_ulong and don't reflect the data type pointed to in target >> memory. >> >> Simply casting the target_ulong to a type before passing to >> get/put_user() is poor because target_ulong isn't always a simple cast >> to a host type (consider 32 bit on 64 bit where address are either >> extended or truncate). Also, simple casting of the argument to >> get/put_user() results in several warnings when target and long pointer >> sizes don't match. >> >> This patch has additional updates to fix places where get/put_user() are >> already used. > > This is an updated patch that doesn't conflict with the > abi_long/abi_ulong changes from a couple weeks ago.
Re: [Qemu-devel] [PATCH] Fix NaN handling in softfloat
Aurelien Jarno wrote:
> Hi all,
>
> The current softfloat implementation changes qNaN into sNaN when
> converting between formats, for no reason. The attached patch fixes
> that.
Did you take into account that MIPS and PA-RISC have the signalling
bit inverted to the rest of the world?
> It also fixes an off-by-one in the extended double precision
> format (aka floatx80), the mantissa is 64-bit long and not 63-bit
> long.
>
> With this patch applied all the glibc 2.7 floating point tests
> are successfull on MIPS and MIPSEL.
>
> Bye,
> Aurelien
>
> Index: fpu/softfloat-specialize.h
> ===
> RCS file: /sources/qemu/qemu/fpu/softfloat-specialize.h,v
> retrieving revision 1.3
> diff -u -d -p -r1.3 softfloat-specialize.h
> --- fpu/softfloat-specialize.h11 May 2007 17:10:14 - 1.3
> +++ fpu/softfloat-specialize.h3 Nov 2007 17:21:38 -
> @@ -121,8 +121,7 @@ static commonNaNT float32ToCommonNaN( fl
> static float32 commonNaNToFloat32( commonNaNT a )
> {
>
> -return ( ( (bits32) a.sign )<<31 ) | 0x7FC0 | ( a.high>>41 );
> -
> +return ( ( (bits32) a.sign )<<31 ) | 0x7F80 | ( a.high>>41 );
> }
>
>
> /*
> @@ -233,7 +232,7 @@ static float64 commonNaNToFloat64( commo
>
> return
>( ( (bits64) a.sign )<<63 )
> -| LIT64( 0x7FF8 )
> +| LIT64( 0x7FF0 )
> | ( a.high>>12 );
>
> }
> @@ -329,7 +328,7 @@ static commonNaNT floatx80ToCommonNaN( f
> if ( floatx80_is_signaling_nan( a ) ) float_raise( float_flag_invalid
> STATUS_VAR);
> z.sign = a.high>>15;
> z.low = 0;
> -z.high = a.low<<1;
> +z.high = a.low;
> return z;
>
> }
> @@ -343,7 +342,7 @@ static floatx80 commonNaNToFloatx80( com
> {
> floatx80 z;
>
> -z.low = LIT64( 0xC000 ) | ( a.high>>1 );
> +z.low = a.high;
> z.high = ( ( (bits16) a.sign )<<15 ) | 0x7FFF;
> return z;
>
> @@ -449,7 +448,7 @@ static float128 commonNaNToFloat128( com
> float128 z;
>
> shift128Right( a.high, a.low, 16, &z.high, &z.low );
> -z.high |= ( ( (bits64) a.sign )<<63 ) | LIT64( 0x7FFF8000 );
> +z.high |= ( ( (bits64) a.sign )<<63 ) | LIT64( 0x7FFF );
> return z;
>
> }
>
> --
> .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
> : :' : Debian developer | Electrical Engineer
> `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
>`-people.debian.org/~aurel32 | www.aurel32.net
>
>
>
Re: [Qemu-devel] [PATCH] Fix NaN handling in softfloat
On Sat, Nov 03, 2007 at 06:35:48PM +0100, Aurelien Jarno wrote: > Hi all, > > The current softfloat implementation changes qNaN into sNaN when > converting between formats, for no reason. The attached patch fixes > that. It also fixes an off-by-one in the extended double precision > format (aka floatx80), the mantissa is 64-bit long and not 63-bit > long. > > With this patch applied all the glibc 2.7 floating point tests > are successfull on MIPS and MIPSEL. FYI, I posted a similar patch and haven't had time to get back to it. Andreas reminded me that we need to make sure at least one mantissa bit is set. If we're confident that the common NaN format will already have some bit other than the qnan/snan bit set, this is fine; otherwise, we might want to forcibly set some other mantissa bit. -- Daniel Jacobowitz CodeSourcery
Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?
On Saturday 03 November 2007, TJ wrote:
> I'm building on x86_64 GNU/Linux. There are *lots* of (1053) compiler
> warnings of the class:
>
> warning: cast to pointer from integer of different size
There are at due to the recent EFAULT/access_ok changes. There should be (and
used to be) a clear separation between host and target addresses. The EFAULT
changes have broken this. Before these ghanges it wa trivial to remap the
target address space (e.g. place it at a high address on a 64-bit host), or
even enabling softmmu. I'm fairly sure that wouldn't work if you tried it
now.
> Fixing it looks to require a variety of fixes, from simple explicit
> casts in-line, to some complicated review of multiple levels of macros
> to decide where best to apply a fix.
Adding a cast is never the right thing to do. There should *always* be a clear
distinction and explicit conversion between host pointers and target
addresses. It is never safe to cast from one to the other.
I put quite a lot of effort into getting this separation right when I
implemented the lock_user interfaces. It was fairly trivial to implement
address space translation (even softmmu) using this inerface. I'm quite
annoyed that we seem to have regresses so badly in this area. AFAICS the
whole of syscalls.c needs re-auditing to figure out which values are host
pointers and which are target addresses.
We should have either lock_user or {get,put}_user, not both.
Paul
[Qemu-devel] [PATCH] Fix NaN handling in softfloat
Hi all,
The current softfloat implementation changes qNaN into sNaN when
converting between formats, for no reason. The attached patch fixes
that. It also fixes an off-by-one in the extended double precision
format (aka floatx80), the mantissa is 64-bit long and not 63-bit
long.
With this patch applied all the glibc 2.7 floating point tests
are successfull on MIPS and MIPSEL.
Bye,
Aurelien
Index: fpu/softfloat-specialize.h
===
RCS file: /sources/qemu/qemu/fpu/softfloat-specialize.h,v
retrieving revision 1.3
diff -u -d -p -r1.3 softfloat-specialize.h
--- fpu/softfloat-specialize.h 11 May 2007 17:10:14 - 1.3
+++ fpu/softfloat-specialize.h 3 Nov 2007 17:21:38 -
@@ -121,8 +121,7 @@ static commonNaNT float32ToCommonNaN( fl
static float32 commonNaNToFloat32( commonNaNT a )
{
-return ( ( (bits32) a.sign )<<31 ) | 0x7FC0 | ( a.high>>41 );
-
+return ( ( (bits32) a.sign )<<31 ) | 0x7F80 | ( a.high>>41 );
}
/*
@@ -233,7 +232,7 @@ static float64 commonNaNToFloat64( commo
return
( ( (bits64) a.sign )<<63 )
-| LIT64( 0x7FF8 )
+| LIT64( 0x7FF0 )
| ( a.high>>12 );
}
@@ -329,7 +328,7 @@ static commonNaNT floatx80ToCommonNaN( f
if ( floatx80_is_signaling_nan( a ) ) float_raise( float_flag_invalid
STATUS_VAR);
z.sign = a.high>>15;
z.low = 0;
-z.high = a.low<<1;
+z.high = a.low;
return z;
}
@@ -343,7 +342,7 @@ static floatx80 commonNaNToFloatx80( com
{
floatx80 z;
-z.low = LIT64( 0xC000 ) | ( a.high>>1 );
+z.low = a.high;
z.high = ( ( (bits16) a.sign )<<15 ) | 0x7FFF;
return z;
@@ -449,7 +448,7 @@ static float128 commonNaNToFloat128( com
float128 z;
shift128Right( a.high, a.low, 16, &z.high, &z.low );
-z.high |= ( ( (bits64) a.sign )<<63 ) | LIT64( 0x7FFF8000 );
+z.high |= ( ( (bits64) a.sign )<<63 ) | LIT64( 0x7FFF );
return z;
}
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
[Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?
I'm building on x86_64 GNU/Linux. There are *lots* of (1053) compiler
warnings of the class:
warning: cast to pointer from integer of different size
caused by the various conversions to/from host-to-target pointer and int
types.
On x86 the warnings mostly don't occur. An easy way to get an idea of
the scale of the build problems is to review the Ubuntu build logs for
x86, x86_64, powerpc, and solaris (It's a 0.9.0 build and the solaris
build fails, but the x86_64 build log is clear although the line numbers
don't match CVS).
Fixing it looks to require a variety of fixes, from simple explicit
casts in-line, to some complicated review of multiple levels of macros
to decide where best to apply a fix.
I am aiming to work through all 1053 errors to classify the reasons for
them, and then work up a solution for each class.
If you could review the details here and provide useful feedback and
ides I'd be grateful. I don't want to redo work others are already doing
or go against some implicit techniques hidden in the macro nesting in
particular.
This should be considered alongside Thayne Harbaugh's post "[RFC]
linux-user (mostly syscall.c)".
Thanks
TJ.
--- specimen details ---
The first warning is also one of the most complex to unravel. It occurs
in linux-user/syscall.c in functions
target_to_host_cmsg()
host_to_target_cmsg()
It is caused by use of the macro TARGET_CMSG_FIRSTHDR (which is a
reworking of the linux macro CMSG_FIRSTHDR defined in
):
static inline void target_to_host_cmsg(struct msghdr *msgh,
struct target_msghdr *target_msgh)
{
struct target_cmsghdr *target_cmsg = TARGET_CMSG_FIRSTHDR(target_msgh);
The macro is defined thus:
linux-user/syscall_defs.h
#define TARGET_CMSG_FIRSTHDR(mhdr) \
((size_t) tswapl((mhdr)->msg_controllen) >= sizeof (struct
target_cmsghdr) \
? (struct target_cmsghdr *) tswapl((mhdr)->msg_control) : (struct
target_cmsghdr *) NULL)
and the pre-processor generates:
struct target_cmsghdr *target_cmsg = ((size_t)
tswap32((target_msgh)->msg_controllen) >= sizeof (struct target_cmsghdr) ?
(struct target_cmsghdr *) tswap32((target_msgh)->msg_control) : (struct
target_cmsghdr *) ((void *)0));
The issue is in the 'true' action:
(struct target_cmsghdr *) tswap32((target_msgh)->msg_control)
and the fact that the macro wasn't designed to handle different pointer
sizes. In this case assigning a 32-bit unsigned int to a 64-bit pointer.
The variables are defined as:
linux-user/syscall_defs.h
struct target_msghdr { ...
abi_long msg_control;
linux-user/qemu.h
#ifdef TARGET_ABI32
typedef uint32_t abi_ulong;
typedef int32_t abi_long;
#define TARGET_ABI_BITS 32
and the 'tswap' function as:
cpu-all.h
static inline uint32_t tswap32(uint32_t s)
{
return s;
}
So the compiler assigns the 32-bit value returned by tswap32() to the 64-bit
pointer 'target_cmsg'.
For this case it appears the 'pure' solution would be to use additional
macros along the lines of:
struct target_cmsghdr *target_cmsg = TARGET_TO_HOST_PTR(
TARGET_CMSG_FIRSTHDR(target_msgh));
and define new macros along the lines of
TARGET_TO_HOST_PTR
HOST_TO_TARGET_PTR
The practical solution is to promote the 32-bit unsigned integer to a
64-bit unsigned integer (using a cast) and then let the compiler do
implicit conversion to a 64-bit pointer.
Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)
I'm glad you posted about your efforts since I've also been working on solving related x86_64 build warnings caused by 32-bit int to 64-bit pointer conversions. warning: cast to pointer from integer of different size There are a lot of these in syscall.c I have in my drafts folder an RFC I was planning to post detailing the issue (1,053 warnings in the x64_64 build) and how to resolve them - some simply require a cast from abi_long/unit32_t to a larger integer storage (same size as host-pointer-size) using the various pre-processor macros and typedefs so the compiler can do implicit conversion from the larger integer type to the pointer. I'll post what I've written so far so it can be considered in conjunction with your work. The title is "RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?" TJ.
Re: [Qemu-devel] Re: [PATCH] efault - add data type to put_user()/get_user()
Thayne Harbaugh wrote: > > On Wed, 2007-10-31 at 16:44 -0600, Thayne Harbaugh wrote: > > This patch updates get_user() and put_user() to take a third argument of > > data type. get_user() and put_user() use target address which are > > target_ulong and don't reflect the data type pointed to in target > > memory. > > > > Simply casting the target_ulong to a type before passing to > > get/put_user() is poor because target_ulong isn't always a simple cast > > to a host type (consider 32 bit on 64 bit where address are either > > extended or truncate). Also, simple casting of the argument to > > get/put_user() results in several warnings when target and long pointer > > sizes don't match. > > > > This patch has additional updates to fix places where get/put_user() are > > already used. > > This is an updated patch that doesn't conflict with the > abi_long/abi_ulong changes from a couple weeks ago. Still misses the sparc64 bits in linux-user/signal.c. Thiemo
[Qemu-devel] qemu/linux-user qemu.h strace.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/11/03 15:12:16 Modified files: linux-user : qemu.h strace.c Log message: Fix some compiler warnings. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/qemu.h?cvsroot=qemu&r1=1.44&r2=1.45 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/strace.c?cvsroot=qemu&r1=1.1&r2=1.2
[Qemu-devel] BUG: fxsave/fxrstor on unaligned address
Hello. According to AMD docs both FXSAVE and FXRSTOR instuctions have to generate GPF if the memory operand is not aligned on a 16-byte boundary. Qemu in contrary does not generate such exception in this case. Unfortunatelly, I'm not able to write proper patch since I have no experience in hacking qemu code (it has to be most likely fixed in the target-i386/translate.c file, around lines 6210-6237). regards, M. -- Michal Schulz
Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)
On Sat, 2007-11-03 at 13:52 +0100, J. Mayer wrote: > On Sat, 2007-11-03 at 01:21 +, Thiemo Seufer wrote: > > Thayne Harbaugh wrote: > > > There are several things that I'd like to see addressed in linux-user. > > > Some of these are to fix bugs, some are to make qemu linux-user more > > > like the Linux kernel, some are to make the internal qemu interfaces > > > more consistent. > > > > > > An internal coding practice that is being addressed bit-by-bit is that > > > of managing the interface between the host and the target. Currently > > > this is a bit sloppy and inconsistent (some of which I've contributed > > > to). There are examples of using target addresses for host pointers and > > > host errnos for target errnos, using different types between target and > > > host that don't sign-extend properly, as well as other things. This > > > causes compiler warnings to actual run-time bugs. Currently I'm > > > reviewing all of the linux-user code (mostly syscall.c) to fix these > > > inconsistencies. I will be writing developer documentation describing > > > the coding practices that should govern the target/host interface and > > > submitting patches for the fixes. > > > > > > As obvious as it may seem I'll re-state that the linux-user emulation is > > > emulating the Linux kernel (duh!). There are portions of qemu > > > linux-user that are even excerpted directly from the Linux kernel. > > > Consequently it is useful for internal qemu data and functions to > > > closely mimic the kernel for best code sharing. There are also > > > advantages to even structuring qemu directly and file organization in > > > similar divisions, groupings and locations. Some of this organization > > > might lead to good division so that other user/kernel divisions are > > > cleaner (different kernel versions, other OSes - darwin-user and > > > others). > > > > > > Internal qemu interfaces are consistent - except when they aren't. This > > > causes coding errors when passing target and host arguments or return > > > codes. I'll be documenting the coding practices as well as submitting > > > patches to make these consistent. (That sounds a bit redundant with > > > other things I've mentioned). > > > > > > I have about 40 patches already worked up that do this. Some of those > > > patches might be broken up smaller. The qemu that we've been working > > > with is nearly rock solid (still a few more bugs being wrung out). It > > > can nearly build an entire Debian arm distribution for an arm target > > > being hosted on x86_64. We're quite excited to get our patches upstream > > > so that others can benefit and to ease our maintenance overhead. We're > > > also turning our focus to PPC and other archs. > > > > > > Please let me know if you support the general idea of the coding changes > > > above: General clean-up, consistent target/host interfaces, file > > > splitting/reorganizing, etc.. In the meantime I'll be putting together > > > the developer documentation/coding guidelines for review. > > > > FWIW, I agree with everything you said above. > > I agree too. > Code cleanup and sanitization is needed there. > I'm just reserved about the code splitting point: as for the vl.h > splitting, it should not lead to get files with only a single or two > small function inside. Right now I have it split similar to the Linux kernel. It has reasonable code grouping and makes it easy to compare code with the kernel. > But it could be great to group the syscalls by > categories, or so. For example, putting all POSIX compliant syscalls in > a single file and using a syscall table could make quite easy to develop > a BSD-user target (I did this in the past, not in Qemu though...). POSIX > compliant interfaces can mostly be shared with Linux ones and a lot of > other syscalls are common to the 3 BSD flavors (Net, Open and Free..). > Being able to add a BSD target sharing the same code would be a proof > the code is flexible and well organized; I guess large parts of the > Darwin user target could also be merged with a FreeBSD user target... That's a reasonable strategy as well. I've looked through some of the darwin code and have considered how common code could be merged. > Just my few cents ideas, don't say it has to be implemented soon, just > think keeping those long-term goals in mind may help having a flexible > and clean implementation... It's likely closer than you realize. 8-)
[Qemu-devel] qemu/target-ppc translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/11/03 14:23:08 Modified files: target-ppc : translate_init.c Log message: Fix PowerPC high BATs access: BAT number was incorrect. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemu&r1=1.54&r2=1.55
[Qemu-devel] qemu/target-ppc cpu.h exec.h helper.c op_helper...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/11/03 13:37:12 Modified files: target-ppc : cpu.h exec.h helper.c op_helper.c translate_init.c Log message: PowerPC MMU and exception fixes: * PowerPC 601 (and probably POWER/POWER2) uses a different BAT format than later PowerPC implementation. * Bugfix in BATs check: must not stop after 4 BATs when more are provided. * Enable POWER 'rac' instruction. * Fix exception prefix for all supported PowerPC implementations. * Fix exceptions, MMU model and bus model for PowerPC 601 & 620. * Enable PowerPC 620 as it could mostly boot a PreP target. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.86&r2=1.87 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/exec.h?cvsroot=qemu&r1=1.30&r2=1.31 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemu&r1=1.86&r2=1.87 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemu&r1=1.61&r2=1.62 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemu&r1=1.53&r2=1.54
[Qemu-devel] qemu/linux-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/11/03 13:22:08 Modified files: linux-user : main.c Log message: Fix incorrect PowerPC instruction fetch exception dump. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemu&r1=1.139&r2=1.140
Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)
On Sat, 2007-11-03 at 01:21 +, Thiemo Seufer wrote: > Thayne Harbaugh wrote: > > There are several things that I'd like to see addressed in linux-user. > > Some of these are to fix bugs, some are to make qemu linux-user more > > like the Linux kernel, some are to make the internal qemu interfaces > > more consistent. > > > > An internal coding practice that is being addressed bit-by-bit is that > > of managing the interface between the host and the target. Currently > > this is a bit sloppy and inconsistent (some of which I've contributed > > to). There are examples of using target addresses for host pointers and > > host errnos for target errnos, using different types between target and > > host that don't sign-extend properly, as well as other things. This > > causes compiler warnings to actual run-time bugs. Currently I'm > > reviewing all of the linux-user code (mostly syscall.c) to fix these > > inconsistencies. I will be writing developer documentation describing > > the coding practices that should govern the target/host interface and > > submitting patches for the fixes. > > > > As obvious as it may seem I'll re-state that the linux-user emulation is > > emulating the Linux kernel (duh!). There are portions of qemu > > linux-user that are even excerpted directly from the Linux kernel. > > Consequently it is useful for internal qemu data and functions to > > closely mimic the kernel for best code sharing. There are also > > advantages to even structuring qemu directly and file organization in > > similar divisions, groupings and locations. Some of this organization > > might lead to good division so that other user/kernel divisions are > > cleaner (different kernel versions, other OSes - darwin-user and > > others). > > > > Internal qemu interfaces are consistent - except when they aren't. This > > causes coding errors when passing target and host arguments or return > > codes. I'll be documenting the coding practices as well as submitting > > patches to make these consistent. (That sounds a bit redundant with > > other things I've mentioned). > > > > I have about 40 patches already worked up that do this. Some of those > > patches might be broken up smaller. The qemu that we've been working > > with is nearly rock solid (still a few more bugs being wrung out). It > > can nearly build an entire Debian arm distribution for an arm target > > being hosted on x86_64. We're quite excited to get our patches upstream > > so that others can benefit and to ease our maintenance overhead. We're > > also turning our focus to PPC and other archs. > > > > Please let me know if you support the general idea of the coding changes > > above: General clean-up, consistent target/host interfaces, file > > splitting/reorganizing, etc.. In the meantime I'll be putting together > > the developer documentation/coding guidelines for review. > > FWIW, I agree with everything you said above. I agree too. Code cleanup and sanitization is needed there. I'm just reserved about the code splitting point: as for the vl.h splitting, it should not lead to get files with only a single or two small function inside. But it could be great to group the syscalls by categories, or so. For example, putting all POSIX compliant syscalls in a single file and using a syscall table could make quite easy to develop a BSD-user target (I did this in the past, not in Qemu though...). POSIX compliant interfaces can mostly be shared with Linux ones and a lot of other syscalls are common to the 3 BSD flavors (Net, Open and Free..). Being able to add a BSD target sharing the same code would be a proof the code is flexible and well organized; I guess large parts of the Darwin user target could also be merged with a FreeBSD user target... Just my few cents ideas, don't say it has to be implemented soon, just think keeping those long-term goals in mind may help having a flexible and clean implementation... -- J. Mayer <[EMAIL PROTECTED]> Never organized
[Qemu-devel] qemu Changelog Makefile.target qemu-doc.texi hw...
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/11/03 12:50:46 Modified files: . : Changelog Makefile.target qemu-doc.texi hw : omap.c omap.h Added files: hw : omap_i2c.c Log message: Split I^2C controller out of hw/omap.c. Insert a list of missing memory mappings from OMAP310 datasheet. Add missing "rtc" field for RTC. Correct PWL and PWT register read/write handler pointers. Add a Changelog entry about OMAP emulation. Add a qemu-doc snippet about Palm T|E platform. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Changelog?cvsroot=qemu&r1=1.145&r2=1.146 http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.215&r2=1.216 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemu&r1=1.162&r2=1.163 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.c?cvsroot=qemu&r1=1.15&r2=1.16 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.h?cvsroot=qemu&r1=1.11&r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap_i2c.c?cvsroot=qemu&rev=1.1
[Qemu-devel] qemu/hw omap.c omap.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/11/03 12:44:02 Modified files: hw : omap.c omap.h Log message: Implement OMAP on-chip RTC (Linux guest date/time now matches with host). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.c?cvsroot=qemu&r1=1.14&r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.h?cvsroot=qemu&r1=1.10&r2=1.11
Re: [Qemu-devel] qemu vl.c vl.h hw/an5206.c hw/etraxfs.c hw/inte...
On Sat, 2007-11-03 at 01:18 +, Thiemo Seufer wrote: > J. Mayer wrote: > [snip] > > > > It restricts the letter to the ones historically allowed by Qemu, not to > > > > anything specific to any architecture or hw platform. What I like in my > > > > implementation, compared to the strchr..., is that it exactly tells the > > > > user which given device is incorrect. > > > > > > Well, here it makes no difference, strchr tells you exactly same as much. > > > > Yes, you're right. Was thinking about the original strspn. > > > > > Instead of the check, the code could also allow everything from 'a' to > > > 'z' and then just AND the produced 32bit bitmap with a machine defined > > > bitmap that would be part of QEMUMachine. > > > > I guess we would better stop at 'n', because we can easily define a > > semantic for devices 'c' to 'm' (ie hard disk drives in a hardware > > platform specific order) but we have to define what means 'o' to 'z'. > > But I agree we would better extend it now, instead of having to rework > > it later... > > To select the network device to boot from would probably become a > 'n' 'o' 'p' 'q' series. Seems OK. Can we say 'c' to 'm' is sufficient to address all disk drive cases or some more possibilities are needed for SCSI devices, or MTD devices boot ? Maybe 'u'... for USB, as most available machines know how to boot on USB, in the real world ? Or may we just consider 'c' to 'm' are sufficient and it's up to the machine to determine the real meaning of the letters, according to its implementation ? In this case, I think we would better provide a per-machine callback to handle the '?' case, printing an help on available boot devices letters and their meaning... > [snip] > > > > Here's a second pass cleanup, adding the machine dependant checks for > > > > the PC machine and the PowerPC ones. As one can see, the OpenHack'Ware > > > > firmware is able to boot from devices 'e' and 'f'. For the PowerPC > > > > machines, I choosed to try to boot from the first given usable device, > > > > some may not agree with this choice. It can be noticed that the > > > > available boot devices are not the same for PowerPC PreP, g3bw and mac99 > > > > machines. > > > > As I don't know the features and requirements for the other > > > > architectures, I prefered not to add any check for those ones. > > > > > > Most other machines ignore -boot and those that don't, shouldn't break > > > from the introduced change, so please commit it when you feel ok with > > > it. > > > > I'd like to know what are the feelings around about this patch and if > > there are specific requirements and/or problems for some platforms to be > > addressed before... > > I think the proposed scheme (and the implementation) is flexible enough > to accomodate all relevant platforms. I think there are still a few problems here: 1/ it would not be easy to add a way to use the disk syntax as proposed here, but this could be useful. Another option could be added for this; or it could be part of the '-disk' syntax. 2/ doing a generic check in vl.c using the machine features would need a great rework. We then would have to first parse all options, then retrieve the machine features, then check all options according to those features. But this can be designed and done later 3/ it would be a great idea to provide a way to boot without any bloc device available. Embedded devices often just have a flash device or a ROM, then the checks done in vl.c to be sure there is a least one device present should be machine specific, imho. Then having an empty boot_devices string may not be a mistake. The two last point can sure be addressed separatly. For the first one, it seems to me that defining the way it has to be would be great: if it needs the -boot option to be extended or redesigned, I think the best would be to do it in the same patch... -- J. Mayer <[EMAIL PROTECTED]> Never organized
[Qemu-devel] Re: Redirect your Webcam
На Mon, 22 Oct 2007 08:03:42 -0700 "Arnon Gilboa" <[EMAIL PROTECTED]> написал(а): > Please connect your Webcam (or any other USB isochronous device) and > redirect it, using the UHCI (already in qemu head) and OHCI isochronous > patches. > > I need your feedback. > > TIA, > Arnon > > >
