Aurelien Jarno writes:
Don't people read what I write? From one of my previous email:
I do...and even scrutinise it for grammar errors. ;-)
Quoting the "IBM PowerPC Microprocessor Family: The Programming
Aurelien Jarno writes:
As it seems you have good contact with IBM, could you please ask them
to fix their manuals?
What flaw have your found?
At least Freescale CPUs match what IBM documentation says.
Which ones? Freescale 7447 and Freescale e500 disagree. (Or at least
some versions
Paolo Bonzini writes:
I think that would be faster on 32-bit hosts, truncs are cheap.
And slower perhaps on 64-bit hosts, at least for operations where
additional explicit trunctation will be needed (such as before
comparisions and after right shifts).
> There could be a disadvantage of t
Aurelien Jarno writes:
That said this does implement neither the specification nor the silicon
behaviour. This is fine for 1.5 as we are in freeze period, but this
should be fixed for the 1.6 release.
I talked to IBM now. Reserved fields should be ignored by hardware.
The architecture o
Alexander Graf writes:
Reported-by: Torbjorn Granlund
Signed-off-by: Alexander Graf
Ah, so my original patch was correct after all.
Only the name of the author needed changing, apparently. :-)
---
target-ppc/translate.c |8
1 files changed, 4 insertions(+), 4
Aurelien Jarno writes:
You have to declare the L bit as invalid, so that trying to execute a
64-bit cmp* instruction on a 32-bit CPU causes an invalid instruction
exception.
Don't people read what I write?
I give up.
Goodbye.
--
Torbjörn
Alexander Graf writes:
Ok, so the real problem here is that NARROW_MODE is not set, but is
used to differentiate whether to use the 32bit cmp only or not.
Eh?
Richard, there are 2 ways out of this:
1) get rid of NARROW_MODE and always check ctx->sf
No!
The cmp insn with L set s
Paolo Bonzini writes:
I guess that's the register windows. There's only so much you can do to
optimize them, and heavily recursive workloads (like Perl, or the RTL
half of GCC) pay a hefty price.
Two qemu targets stand out for slowness, sparc (32 and 64) and mips (64,
don't know about 3
Aurelien Jarno writes:
64-bit CPUs check for the L bit of comparison instruction to determine
if the instruction is 32-bit wide, and not to the MSR SF bit.
L=1 on a 32-bit CPU should generate an invalid instruction exception.
No. See my previous post.
The L bit is to be ignored for
Artyom Tarasenko writes:
Meaning it's even faster than estimated? That's fast. I don't see in
the table, how long does the build take?
About one hour. That's for:
configure + make + make check TESTS=
(The host is a 4X 3.6 GHz Bulldozer Zambezi.)
--
Torbjörn
The current ppc gen_op_cmp generates a long sequence of instructions,
using a plain series of three disjoint compares.
It is possible to compute the 3 result bits more cleverly. Below is a
possible replacement gen_op_cmp. (It is tested by booting GNU/Linux
ppx64, but not much more than that.)
S
Artyom Tarasenko writes:
Do I read it correct that qemu-system-ppc64 with the slowdown factor
of 33 is ~3 times faster than qemu-system-sparc64 with the slowdown
factor of 96 ?
You read it correctly.
But please see the caveat at the table end.
Do they both use Debian Wheezy guest? You
I realised a possible problem with my suggested patch.
What about a 32-bit processor? Then NARROW_MODE macro is identical 0.
The pre-patch behaviour was then to ignore the L bit and decode both
32-bit and 64-bit instruction in the same way.
Apparently that is correct behaviour. (The manual is
Alexander Graf writes:
> The first hunk is just a comment about suspicious code. I don't suggest
> to apply that.
The "suspicious" code is correct. The Rc update should indeed be
SF-mode dependent.
With the other 4 hunks, qemu-ppc64 is now able to execute GMP's
testsuite to completion, us
Aurelien Jarno writes:
Which version of QEMU are you using? This looks like a bug that has
appeared in version 1.3.0 and fixed in version 1.4.1. The corresponding
commit in master is 52ae646d4a3ebdcdcc973492c6a56f2c49b6578f
I cannot tell exactly, since I didn't keep sources to each qemu co
OK, so took to reading some of translate to see how well it agrees with
the PPC architecture definition.
I spotted a bug with cmp, which was repeated 4 times. Somebody decided
that NARROW_MODE should affect the handling of cmp instructions, which
is contrary to the ISA documentation.
The first h
Peter Maydell writes:
On 7 May 2013 11:27, Torbjorn Granlund wrote:
> Alexander Graf writes:
>
> There's a certain chance that happens, yes. We don't have instruction
> test suites for the PPC target.
>
> There certainly are more bugs. GMP stil
I am trying to use qemu to
1. cover more of the assembly code in GMP
2. check configuration logic of GMP
but I am not as successful as I would like to be.
The 2nd table of http://gmplib.org/devel/testsystems.html shows all
emulated systems I am using, most of which are qemu-based.
Unfortunately
Alexander Graf writes:
There's a certain chance that happens, yes. We don't have instruction
test suites for the PPC target.
There certainly are more bugs. GMP still crashes all over the place.
I have semi-isolated one more.
Extracted stand-alone sources:
bug-qemu-ppc-again.c
Descript
Alexander Graf writes:
Thanks a lot for the bug report and test case! Please CC qemu-ppc
whenever you find issues or have patches for PPC. That makes filtering
for important mails a lot easier.
Would that make my complaints be considered more or less important? :-)
Does the patch bel
I could finally make Debian GNU/Linux install and run under
qemu-system-ppc64. I used Debian 7.0.0 and qemu from the main git repo,
updated a few days ago.
While Debian runs well and not too slowly, GMP fails badly under all
ABIs, and in many different ways. I have isolated the first problem.
T
Peter Maydell writes:
On 25 March 2013 14:06, Torbjorn Granlund wrote:
> Still qemu-system-mips64, qemu-system-mips64el, and qemu-system-arm
> give spurious errors.
If you can provide a reasonably sized test case for
qemu-system-arm I can investigate that one.
I don'
After the latest patch of Richard's, qemu-system-x86_64 now runs
GNU/Linux properly. The denorm problem is gone, and there seem to be no
(or at least much fewer) spurious segfaults.
This ends a multi-month period of qemu-system-x86_64 instability.
Still qemu-system-mips64, qemu-system-mips64el,
Richard Henderson writes:
Patch at http://patchwork.ozlabs.org/patch/229139/
Thanks. I can confirm that this fixes the bug triggered by my test case
(and yours). However, the instability of Debian GNU/Linux x86_64 has
not improved.
The exact same Debian version (debian "testing") updated
Public bug reported:
The current qemu sources cause improper handling of flags on x86-64.
This bug seems to have shown up a few weeks ago.
A plain install of Debian GNU/Linux makes user processes catch
spurious signals. The kernel seems to run stably, though.
The ADX feature works very poorly.
Richard Henderson writes:
That's odd. I just booted a fedora installer and ran it part way
through. Long enough that I'm well past a "no bootable device" message
from the bios.
There were changes to my tree since the last push, but as far as I
remember they were cleanups to powerpc
Richard Henderson writes:
On 2013-02-19 13:52, Torbjorn Granlund wrote:
> Execute. I believe correct behaviour is to print:
>
> 000d 000d 040b 000a
>
> The program under your special qemu
The new gdb (7.5.1) did not change anything.
The program behaves one way inside gdb and one way outside.
The behaviour inside gdb is surely incorrect.
I think the behaviour outside of gdb is also incorrect, but I haven't
spent much time thinking about it.
To repdoduce curious behaviour:
Compile
Richard Henderson writes:
I've updated that branch; please try again.
Thanks.
I am no friend of git's, and my mercurial commands (pull -u) cause
million conflicts.
OK, I grabbed a new copy and have built it. It works better, sshd now
runs.
Somethings seems wrong with adcx and/or adox. O
Richard Henderson writes:
Yes, and "-cpu Haswell" will enable the BMI extensions.
I have used git://repo.or.cz/qemu/rth.git x86-next checked out around 15
January for a while now. The host system is Debian GNU/Linux amd64 and
the guest is FreeBSD 9.1 amd64.
I now updated x86-next in order
Richard Henderson writes:
Then you got the wrong branch from the repository:
translate.c:4055:case 0x3f6: /* mulx By, Gy, rdx, Ey */
You need the "x86-next" branch.
I am not a git user, and misundersand the command.
Now I have the correct version, and can confirm that
Richard Henderson writes:
On 01/14/2013 10:14 AM, Torbjorn Granlund wrote:
> Is it in such a state that grabbing that repo and building a
> qemu-system-x86_64 would give me MULX support?
Yes, and "-cpu Haswell" will enable the BMI extensions.
A review of the code
Richard Henderson writes:
> MULX implies a bunch of other instructions due to CPUID flag grouping.
> ADCX and ADOX can be implemented separately. None of these and the
> other instructions in the MULX group look very complex.
I've got a patch for (most of?) the bmi[12] insns:
gi
Blue Swirl writes:
MULX implies a bunch of other instructions due to CPUID flag grouping.
ADCX and ADOX can be implemented separately. None of these and the
other instructions in the MULX group look very complex.
I had not realised that qemu disabled instructions when emulating a CPU
not
There are 3 instructions, MULX, ADCX, and ADOX, which would be very
useful to see in qemu. I looked into putting them in myself, but the
startup time for hacking qemu is longer than I can affort in this
period.
Apparently, MULX is implemented in Haswell, while ADCX and ADOX will
appear in Broadwe
"Edgar E. Iglesias" writes:
> But running Debian's 64-bit kernel vmlinux-2.6.32-5-5kc-malta under
> qemu-system-mips64 consumes 100% on the host system, whether the guest
> is idle or busy. (And for qemu-system-mips64el, the same is true for the
> corresponding 64-bit el kernel.)
Hi,
Andreas Färber writes:
Am 28.09.2011 02:25, schrieb Torbjorn Granlund:
> Another issue I ran into what the sh4 qemu performance. It is much
> worse than other qemu ports (except perhaps ppc64). What is the reason
> behind that? (The idle thing works well for sh4, though.)
Running Debian's vmlinux-2.6.32-5-4kc-malta under qemu-system-mips works
very well--the system is fast, and when it is idle the qemu-system-mips
process on the host system consumes insignificant CPU. (The same is
true for qemu-system-mipsel, using the correesponding 'el' Debian
kernel.)
But runni
malc writes:
All is the keyword here, i doubt that exhaustive search was performed
furthermore, AMDs documentation (to the best of my knowledge still)
still maintains that ZF is undefined.
AMD indeed still says undefined in their documentation (as of two hours
ago). I have asked AMD for a
malc writes:
And this one was March 2009 (conveniently having the same file name
253666), the September 2010 issue reads differently:
Flags Affected
The CF flag contains the value of the selected bit. The ZF flag is
unaffected. The OF, SF, AF, and PF flags are undefined.
Have the q
malc writes:
ZF is undefined according to AMD's 24594.pdf page 69.
Ah, you're right. It seems that all existing x86 implementations leave
ZF alone, though. (I am not arguing that qeum is broken, the bug is in
my code.)
I apologize for the false alarm!
--
Torbjörn
[This is a bug report, reported here since I was redirected to some
corporate site when attempting to follow the recommended bug report
practice. If I am really required to register an account with a
corporation in order to report a qemu bug, and that bug reports are not
accepted here, then please
Artyom Tarasenko writes:
Nice. Btw, there is no OpenSolaris version for sparc. Only for i386,
x86-64 and sparc64.
Fixed, thanks.
"openbsd/sparc hangs" - can you be more specific? It used to work.
Some description of failues is in the plan.
Also, why would you like to start from scra
Alexander Graf writes:
> Please also keep in mind that PPC emulation is _very_ slow.
>
> Why is it slow?
Because we're flushing the TLB on almost every MMU opcode.
OK. Does that mean the TLB never gets more than a single entry?
(I mean, do you flush the TLB before inserting a new e
Blue Swirl writes:
On Wed, Oct 27, 2010 at 8:39 AM, Torbjorn Granlund wrote:
> > "install64", which comes a bit longer. It fails in a new way: it
> > ignores keyboard input, This happens after the kernel has booted, and
> > the installer has started.
&
Alexander Graf writes:
Sounds great :). Please keep in mind that if you're running into these
issues, others might too. And if you find something out and miss
documentation, please create some. That's why we made everything be a
wiki these days :).
If I get a meaningful number of OS/qemu
Alexander Graf writes:
> Device tree strings 0x0245 -> 0x024504d9
> Device tree struct 0x02451000 -> 0x02453000
> Calling quiesce ...
> returning from prom_init
>
> it hangs.
It doesn't hang. It tries to display stuff on the graphical scr
> "install64", which comes a bit longer. It fails in a new way: it
> ignores keyboard input, This happens after the kernel has booted, and
> the installer has started.
Yes, ignoring keyboard input sounds right. The issue here is that
we're basically emulating a PPC32 machine, but plug
Stefan Weil writes:
No, you need newer version of qemu, for example version 0.13.0
That's the version I am using:
king# qemu -version
QEMU emulator version 0.13.0, Copyright (c) 2003-2008 Fabrice Bellard
kqemu was replaced by kvm support (at least for some platforms).
Are you talking
Paolo Bonzini writes:
On 10/26/2010 09:12 PM, Torbjorn Granlund wrote:
> FreeBSD 8.1-p1 x86_64 (the CPU is AMD Phenom X6).
>
> I use the kqemu kernel module. All software (kernel, /usr/ports) are
> up-to-date as of yesterday.
I suggest that you use a newer version,
Alexander Graf writes:
> (1) For ppc32, gentoo hans quickly, the last line is this:
>
>Memory: 247644k/262144k avalable (5652k kernel code, 14500l reserved,
212k data, 137k bss, 260k ini
>
>This last line is long, it is truncated to the right.
Hrm. Please send me the vm
Stefan Weil writes:
Which kind of host did you use? i386? x86_64? Linux? Windows?
FreeBSD 8.1-p1 x86_64 (the CPU is AMD Phenom X6).
I use the kqemu kernel module. All software (kernel, /usr/ports) are
up-to-date as of yesterday.
My working setups run on a Debian Linux (x86_64) host
(m
Alexander Graf writes:
Where exactly do the Linux kernels hang here? For BSD, I don't
know. If there are patches flowing in to fix BSD support, I'll gladly
review and take them, but I won't proactively try to get it running.
Is this how most qemu hackers feel, in effect that qemu is a hard
I am not sure this inquiry is appropriate for this mailing list. But at
the qemu web site, this is the only mailing list mentioned.
I would like to run as many OS's as possible under as many processors as
possible, using qemu. Results thus far has not been very encouraging,
though.
Here is my t
54 matches
Mail list logo
