> : > > Any news on the possible cvs->svn migration?
> : >
> : > To be perfectly honest, IMO there is little point moving an existing
> : > project from CVS to SVN.
> :
> : I disagree. CVS has several fairly fundamental flaws (no global revision
> : IDs, unable to move files, and more subtle prob
On Thursday 31 January 2008 10:46, Jamie Lokier wrote:
> Anthony Liguori wrote:
> > VGA framebuffer operations come in as memory operations. They're
> > tracked by watching what memory gets dirtied. This can only operate at
> > a page-granularity so this results in scan-line granularity updates.
> > > As it is, Fabrice's code generator will most likely be something
> > > similar to Paul's qops, which means that you have to invent a
> > > "primitive C" in which to write the miniops, and you will have to
> > > write a backend for _each_ and _every_ host CPU you support.
It's not a terribly
> [discussion about where to host a bugzilla]
Perhaps a more important question is, is there interest in making
a stable branch, tracking bugs and producing bug-fix-only releases
from the stable branch? As is traditional in (eg) gcc, etc? If not,
I don't think there is much point in having a b
> Well, I admit I've invented the term "ppc32", but there are dozens of
> 32-bit PowerPC chips. I'd be amazed if they do 64-bit computations or have
> 64-bit GPRs.
Indeed not. Valgrind implements the 32-bit PPC user-space instruction set
quite adequately using 32-bit computations throughout. No
> > way around. Below is a simple test case. On QEMU it prints
> >
> > result is 000fc000
> >
> > and on a real 7447
> >
> > result is 4000
> >
> What is strange is that 0xFC + 0x04... I will have to check all the CR
> ops, I guess...
Another strange thing is that 000fc000 does not hav
Hi Jocelyn
I ran valgrind's ppc32 insn set tests and got the impression that
the above insns are not correctly implemented. It seems like 7 bits
of CR are set to 1 and one is set to 0, when it should be the other
way around. Below is a simple test case. On QEMU it prints
result is 000fc000
On Saturday 13 October 2007 16:24, Werner Dittmann wrote:
> Bruno Cornec wrote:
> > On Sat, Oct 13, 2007 at 01:53:37PM +0200, Bruno Cornec wrote:
> >> However, mandriva 2008.0 x86_64 doesn't exhibit this error on the same
> >> host.
> >
> > I stand corrected. It also crashed but later during the in
Some x86_64 SSE2 instructions that convert floats to ints appear
to ignore the rounding mode (in mxcsr), and so produce wrong results
if mxcsr is set to anything other than default rounding. For example
cvtsd2si et al.
I'm looking at softfloat-native.c and softfloat.c and wondering how
to fix it
> > > > This means you have a choice: Write standard conforming code (long)
> > > > that works on all known systems except win64, or use features that
> > > > do't exist on many systems. IIRC C99 types like intptr_t are not
> > > > supported on several fairly common unix systems.
> > >
> > > In th
> > Unfortunately C99 relaxed this requirement, and allowed abominations like
> > the win64 ABI.
> >
> > This means you have a choice: Write standard conforming code (long) that
> > works on all known systems except win64, or use features that do't exist
> > on many systems. IIRC C99 types like in
Does this fix some specific bug you encountered?
J
On Monday 26 March 2007 14:53, Bernhard Kauer wrote:
> The Intel manual states for LTR and 64-Bit Exceptions:
>
> #GP(selector)
>If the descriptor type of the upper 8-byte of the 16-byte descriptor
>is non-zero.
>
> Qemu curr
> As far as X86 is concerned i386/i486/i586 are very different from later
> generation
> processors. I am wondering whether another host and target architecture
> could be
> created called i686 that makes use of something like MMX or other
> registers in Intel
> Pentium II/III/4 and AMD Athlon to
On Thursday 22 March 2007 23:27, Paul Brook wrote:
> > Do you mean you're asking me to break up Paul Brook's QOPS tree at
> > https://nowt.dyndns.org and submit it to mainline? I can do this thing,
> > if you really think it would help.
>
> If you implement all the missing bits in the process it'l
On Thursday 15 March 2007 14:53, Paul Brook wrote:
> > Subsequent releases of the branch would contain no functionality
> > enhancements, but just bug fixes, with the eventual aim of achieving
> > 'it just works' status for any x86/x86_64 guest I try to install/run.
> > I know that's a tall order,
Thinking about this more, you ask "is this correct", but that
is only meaningful if you say what the specification is.
Correct relative to what?
> Yes, it seems to be the correct way, but thinking more about the
> problem, it appeared to me that the implementation could be even easier
> than yo
> Note that float64_to_uint64 functions are not correct, as they won't
> return results between INT64_MAX and UINT64_MAX. Hope someone may know
> the proper solution for this.
How about this?
J
uint64_t float64_to_uint64 (float64 a STATUS_PARAM)
{
uint64_t res;
int64_t v;
if (isinf
The helpers for x86/amd64 fprem and fprem1 in target-i386/helper.c are
significantly borked and, for example, cause konqueror in RedHat8 (x86
guest) to go into an infinite loop when displaying http://news.bbc.co.uk.
helper_fprem has the following borkage:
- various Inf/Nan/zero inputs not handled
> ifeq ($(ARCH),x86_64)
> +OP_CFLAGS+= -mtune=nocona -W -Wall -O4
> BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
> endif
That works. Thanks.
J
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
On Friday 16 March 2007 18:40, Anthony Liguori wrote:
> Hi Julian,
>
> Julian Seward wrote:
> > Here is a somewhat revised version of a patch I first made nearly
> > three years ago. The original thread is
> >
> > http://lists.gnu.org/archive/html/qemu-devel/2004-
I ran QEMU on Valgrind for several hours last night, including a couple
of boot-shutdown cycles of RedHat8, and lots of file copying/deletion
in the guest to get the qcow2 image up to 8GB and generally cause a lot
of disk IO. I got no memory errors whatsoever from Valgrind and got no
filesystem
On Friday 16 March 2007 18:07, Rob Landley wrote:
> On Tuesday 13 March 2007 10:21 pm, Julian Seward wrote:
> > > 0.9.0, or that the compiler/host combination used to build the qemu
> > > binary Julian is running generated bad code for the float compares.
> >
> >
On Friday 16 March 2007 14:28, Paul Brook wrote:
> On Friday 16 March 2007 14:15, Julian Seward wrote:
> > I'm seeing redundant repz (0xF3) prefixes in generated code, typically
> > just before jumps:
> >
> > : repz mov $0xe07f,%eax
> > : mov%eax,0x20(%r
I'm seeing redundant repz (0xF3) prefixes in generated code, typically
just before jumps:
: repz mov $0xe07f,%eax
: mov%eax,0x20(%rbp)
: lea-25168302(%rip),%ebx # 0xaf0420
: retq
: mov-25168245(%rip),%eax # 0xaf0460
: jmpq *%rax
: repz mov $0xe092,%eax
: mov%eax,0x20
On Thursday 15 March 2007 13:48, Anthony Liguori wrote:
> I'm not necessarily sure I agree that a stable branch is the best thing
> to have (verses aiming for never introducing regressions).
Aiming for no regressions is a worthy aim, but I believe unachieveable
in a project of any size. For sure
I am a great fan of QEMU, and have used it more or less continuously
for the past 2+ years. Over that time I've installed and operated
various Linux and Windows guests with varying degrees of success.
The recently released 0.9.0 seems a big step forward in the
stability/usability department, whi
Something similar happened to me. At first I thought it was a hardware
(host) problem and so do not have good details - this is from memory.
- 0.9.0, binary build from qemu.org
- i386 openSUSE 10.2 host
- RedHat 8 guest
- .qcow2 image, max size 8GB
- using the Accelerator but not -kernel-kqemu
On Wednesday 14 March 2007 04:57, Mark Williamson wrote:
> > > Here is a somewhat revised version of a patch I first made nearly
> > > three years ago. The original thread is
> >
> > The idea here is quite similar to what the VNC server does now.
> >
> > If this is desirable for SDL too, then perh
> 0.9.0, or that the compiler/host combination used to build the qemu
> binary Julian is running generated bad code for the float compares.
I used gcc 3.4.6 bootstrapped as normal ('make bootstrap; make install')
on a 64-bit machine. If it is qemu generating bad code due to variations
in gcc beh
Here is a somewhat revised version of a patch I first made nearly
three years ago. The original thread is
http://lists.gnu.org/archive/html/qemu-devel/2004-07/msg00263.html
The patch makes QEMU's graphics emulation much more usable over remote
X connections, by reducing the amount of data sent
> QEMU and Core 2 Duo disagree on the handling of NaNs it seems.
>
> http://courses.ece.uiuc.edu/ece390/books/labmanual/inst-ref-simd.html
> - this implies that MAXPS should leave the NaNs alone, no idea how
> normative that is though (and no IA32 manual at hand)
Having looked at an IA32 manual I
The program below tests the 'maxps' instruction. When run on
qemu-0.9.0, host amd64, guest x86, guest OS redhat8, it prints:
f9a511d1 8d37d67f b34825b8 e2f40739
scp the binary to a Core 2 (real) machine and run:
f9a511d1 22dcb9b9 b34825b8 e2f40739
Second 32-bit word is completely diffe
Thanks for the feedback. Since I do not wish to be involved in a
great battle (as you so nicely put it) I'll stick with VMware (sigh).
J
On Wednesday 21 February 2007 15:05, Robin Atwood wrote:
> On Wednesday 21 Feb 2007, Julian Seward wrote:
> > (replying off list)
>
> > Would someone be able to track down this SSE QEMU bug seen only in SLES's
> > modf() function ?
The Valgrind sources contain test programs, including expected outputs,
for all SSE/SSE2/SSE3 instructions on amd64 (see none/tests/amd64/insn-sse
and insn-sse2). Running those on QEMU might be a
On Saturday 16 December 2006 21:11, Anthony Liguori wrote:
> info block is impossible to parse reliably because there is no escaping
> done on the filename.
Don't you also need to convert \ to \\ ? Else any \ which was in
the original string will confuse the parser of the escaped output.
J
___
I have used VMware on a Windows host with the vmdk files on a compressed
NTFS partition. The result of compression was eventually to cause the
vmdk files to become extremely fragmented (tens of thousands of fragments)
which seriously reduces performance in the end. I'm not sure why this
happens.
> > Really? My win2k install couldn't do anything useful with -std-vga.
> > It would only do the very basic 640x480x4 mode. I'm fairly sure win9x
> > can't do anything useful with straight VGA either.
>
> Same here. Also std-vga seemed to be slower than cirrus when I tried
> it recently on my lin
I've been using -std-vga for a couple of weeks now, and it works well
at least for the guests I've been using (Win2K/XP, Red Hat 9, SuSE 10.1).
Overall it seems to work much better than the default 5446 simulation
and it seems to me that non-developer users, who are presumably the larger
fractio
> It appears that cvttps2dq is indeed the only exception in the range,
> combined patch that fixes both movd?q2d?q and cvttps2dq is attached.
>
> I don't have any kind of SSE on this machine so would apprecaite if
> someone would run tests/test-i386 with the patch attached.
That works for me. Th
Malc, your sse-movq.patch works for me. Thanks.
> soft-float was a red herring, translate.c is at fault here (interpreter
> does not use it, hence behaved correctly)
>
> translate.c:3009
> if (b1 >= 2 && ((b >= 0x50 && b <= 0x5f) ||
> b == 0xc2)) {
> /* specific case for SS
> > [EMAIL PROTECTED] qemu]$ gcc -msse2 sse2test.c -o sse2test
> > [EMAIL PROTECTED] qemu]$ ./sse2test
> > cvttps2dq_1 ... failed
> > cvttps2dq_2 ... failed
> > movdq2q_1 ... failed
> > movq2dq_1 ... failed
> >
> > what am i doing wrong here ?
>
> Running it on a CPU without SSE2, if i'm allowed t
On Tuesday 20 June 2006 12:29, malc wrote:
> The signature of movdq2q is Pq, VRq and for movq2dq - Vo, PRq it appears
> that translate.c gets it backwards, attached patch should deal with it.
Cool.
> As for cvttps2dq i ran it with interpreter which uses outdated(i.e. non
> soft-float) conversion
The SSE2 instructions cvttps2dq, movdq2q, movq2dq do not behave
correctly, as shown by the attached program. It should print
cvttps2dq_1 ... ok
cvttps2dq_2 ... ok
movdq2q_1 ... ok
movq2dq_1 ... ok
but instead produces
cvttps2dq_1 ... ok
cvttps2dq_2 ... not ok
result0.sd[0] = 12
> be the cause the of Win2K SP4 installation failure.
This doesn't seem to help alas.
Here's a context diff of the same patch (easier to make sense of).
J
===
RCS file: /sources/qemu/qemu/target-i386/helper.c,v
retrieving revisio
I've been doing some instruction set testing on i386-softmmu,
with the aim of seeing if I can find any anomalies which might
be the cause the of Win2K SP4 installation failure.
helper_fxam_ST0 doesn't correctly distinguish infinities from
nans, and thereby causes programs that use the x86 'fxam'
On Saturday 17 June 2006 18:03, Rick Vernam wrote:
> On Saturday 17 June 2006 11:32, Alex wrote:
> > This patch has been around for a while but never committed to the
> > mainstream.
Huh? Fabrice committed it some time around Tuesday. I've been
using it 8+ hours/day since then and it seems fine
On Thursday 15 June 2006 14:18, WaxDragon wrote:
> On 6/15/06, kadil <[EMAIL PROTECTED]> wrote:
> > On Wed, 2006-06-14 at 18:10 +0200, Oliver Gerlich wrote:
> > Real world, gui's are just so easy & desirable, especially if the gui is
> > consistent across os's, and part of the original distro. I t
Could somebody please commit, or at least consider committing,
Anthony Liguori's "invisible wall" patch, shown at
http://lists.gnu.org/archive/html/qemu-devel/2006-05/msg00112.html ?
Without it, QEMU is essentially unusable on my SuSE 10 host; with it,
the mouse stuff works perfectly. A couple
On Wednesday 07 June 2006 12:49, Julian Seward wrote:
> > On Wednesday 07 June 2006 02:31, Ben Taylor wrote:
> > I've been able to get 1152x864 out of the Solaris Xorg gdm5446 driver
> > so there must be something else that's causing you problems. I think
> > I&
> On Wednesday 07 June 2006 02:31, Ben Taylor wrote:
> I've been able to get 1152x864 out of the Solaris Xorg gdm5446 driver
> so there must be something else that's causing you problems. I think I've
> gotten win98se to do it as well.
Thanks for the confirmation. So, I re-tried (extensively) to
Using the latest cvs sources on x86 SuSE 10.0 host, Win2K guest,
the 1152x864 mode offered to me by Windows doesn't work. Instead
I just get moved to 640x480, it looks like. The modes on either
side of it - 1024x768 and 1280x1024 work fine. Is 1152x864
supported by the driver?
Does this proje
> autodetect what color format to use. Also putting if inside the inner loop
> of the low-level conversion routines is a bad idea.
While that's per-se true, maybe it's not such a big deal. The branch is
going to be perfectly predictable since the condition stays the same
for the entire run, so
> > -if ((T0 >> 31) ^ (T1 >> 31) ^ (tmp >> 31)) {
> > +if (((tmp ^ T1 ^ (-1)) & (T0 ^ T1)) >> 31) {
> > + /* operands of same sign, result different sign */
> > CALL_FROM_TB1(do_raise_exception_direct, EXCP_OVERFLOW);
> > }
>
> I see this went in, but - huh? The math doe
> I guess the problem comes from the usage of lrintl() on x86_64 in
> fpu/softfloat-native.c, but I cannot test it yet.
It might be that you have to pass in an extra value into those
float -> int conversion routines, which describes what to do if the
conversion is going to overflow. That's becau
Recently I've been playing with CVS qemu-system (softmmu) on amd64
and had some stability problems. I decided to run Valgrind's amd64
instruction-set tests (derived from qemu's) to see if they picked up
anything. Resulting diffs are attached.
There are a bunch of differences for the C flag for
Using qemu from cvs simulating x86-softmmu (no kqemu) on x86,
booting SuSE 9.1 and getting to the xdm (kdm?) graphical login
screen, requires making about 1088000 translations, and the
translation cache is flushed 17 times. Booting is not too bad,
but once user-mode starts to run the translation
> > Basically, if u want split images to be supported in qemu, speak up now.
> > ;)
>
> I speak!
Me too! I've always used split images with vmware; they are
easier to manage than files tens of gigabytes long.
J
___
Qemu-devel mailing list
Qemu-dev
What are the prospects for qemu-system-ppc being improved to the
point where I can do a vanilla install of popular ppc32-linux
distros?
I've tried a vanilla install of Debian Sarge (3.1). That went
smoothly, except for the stage right at the end, where the disk
image is made bootable. The resul
> it, if someone could test this patch and/or give me links to programs
> (Linux/Win98) that use SSE3 instructions (and preferably also prove
Valgrind (current svn trunk) has some pretty extensive SSE/SSE2 tests;
you could use those.
J
___
Qemu-devel
The use of gcc to generate the back end in QEMU's early days was a
clever way to get the project up and running quickly. But surely
now it would be better to transition to a handwritten backend, so
as to be independent future changes in gcc, and generally more robust?
J
On Wednesday 09 Novembe
> > Qemu itself segfaults. Normally I'd fire up gdb at this stage and have a
> > good look around,
Why don't you fire up Valgrind and have a good look around? It can
find all manner of bad stuff that GDB doesn't find, like out-of-
bounds memory accesses and use of uninitialised values that are
As of today, the Valgrind 3 development line supports
applications which use self-modifying code on x86 and amd64.
So it may now be possible to use Valgrind to debug/profile
an unmodified build of QEMU (at least the softmmu variants).
See http://www.valgrind.org/devel/cvs_svn.html for details
> Can you make a nightly build with the CVS?
I'm surprised that Qemu does not seem to have an automated nightly
build / regression test / mail-summary-to-developers system. We have
been doing that with Valgrind for a couple of years now and it makes
a big difference, allowing developers to trac
63 matches
Mail list logo
