x86 CPUs feature extended family/model bits in CPUID leaf
0000_0001|EAX. Refer to page 10 in:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25481.pdf
Those bits are necessary to model newer AMD CPUs:
-cpu qemu64,family=15,model=65,stepping=3 or
-cpu qemu64,family=16,model=4,stepping=2
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5664 c046a42c-6fe2-441c-8c8c-71466251a162
Also fix which argument gets negated in fandnot[12] and fornot[12]
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5662 c046a42c-6fe2-441c-8c8c-71466251a162
- Rename to gen_op_arith_neg for consistency with other functions.
- Correctly free TCG temp variable.
- Fix the return value in 64-bit mode in case of overflow.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5659 c046a42c-6fe2-441c-8c8c-71466251a162
gen_op_arith_divw():
- "deoptimize" gen_op_arith_divw to make it more readable.
- Correctly free TCG temp variable
gen_op_arith_divd():
- Call the right function.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5658 c046a42c-6fe2-441c-8c8c-71466251a162
Also optimise qemu_strdup by using memcpy - using pstrcpy is usually
suboptimal.
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5653 c046a42c-6fe2-441c-8c8c-71466251a162
The use of strncat and strndup was correct, pstrcpy and pstrdup wasn't.
I'll try to restore building on non-gnu OSes in a later commit.
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5651 c046a42c-6fe2-441c-8c8c-71466251a162
Generate an option rom instead of using a hijacked boot sector for kernel
booting. This just requires adding a small option ROM header and a few more
instructions to the boot sector to take over the int19 vector and run our
boot code.
A disk is no longer needed when using -kernel on x86.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5650 c046a42c-6fe2-441c-8c8c-71466251a162
It looks like the i386 runs out of registers for allocation due
to too many global registers allocated by the ppc target.
Here is a quick and dirty fix that seems to solve the problem.
This should be considered as temporary.
Signed-off-by: Laurent Desnogues <laurent.desnogues@gmail.com
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5648 c046a42c-6fe2-441c-8c8c-71466251a162
Fix reading of cpu_lock in gen_qemu_stql_c, original patch from Laurent
Desnogues.
A new flag was added to gen_store_mem to allocate local temps instead
of temps; this flag should be set when the tcg_gen_qemu_store callback
uses brcond before using the temps or else liveness analysis will get
rid of the temps.
This also adds lock printing in cpu_dump_state which can help
debug.
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5645 c046a42c-6fe2-441c-8c8c-71466251a162
Commit #5620 revealed an issue of the SSTEP_NOIRQ masking that was
applied on all interrupt sources (including internal ones) when single
stepping through the guest. Due to that commit, we now ended up in an
infinite loop when CPU_INTERRUPT_EXIT was pending on SSTEP resume. That
was due to #5620 eating all TBs while CPU_INTERRUPT_EXIT is pending, but
SSTEP_NOIRQ preventing CPU_INTERRUPT_EXIT to be processed.
What SSTEP_NOIRQ should actually do is to block the delivery of all
external, guest visible interrupts. With the fix below applied, single
stepping now works again.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5643 c046a42c-6fe2-441c-8c8c-71466251a162
- Makefile.target: re-enable profiling for user qemu. It seems
profiling was (accidently?) removed by commit 3937
- syscall.c:
* add an include to get _mcleanup prototype
* add a call to _mcleanup for exit_group in a way
similar to what is done for exit
(Laurent Desnogues)
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5642 c046a42c-6fe2-441c-8c8c-71466251a162
network traffic.
This was bug was reported by Chris Lalancette.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5640 c046a42c-6fe2-441c-8c8c-71466251a162
Hopefully pine doesn't corrupt this patch, I've had problems recently.
For an alpha "ret" instruction, of the type
ret $26
The return was being ignored. This is because in translate.c
register $26 (the return address) was being over-written with the current
PC before it could be jumped to. Thus the ret was ignored.
This patch just re-orders things so the return address is processed before
it is over-written with the current PC.
(Vince Weaver)
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5638 c046a42c-6fe2-441c-8c8c-71466251a162
host_alarm_timer fires in a separate thread. The windows build current
uses SetEvent() and WaitEvent() to then notify the main thread. This is
functionally equivalent to what we're doing in Unix with pipe(). So let's
just #ifdef the pipe() code on Windows since it doesn't build there anyway.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5637 c046a42c-6fe2-441c-8c8c-71466251a162
This further cleans up the main loop getting it a lot closer to what a main
loop should be.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5636 c046a42c-6fe2-441c-8c8c-71466251a162
Changing the default IO timeout to 5 s (#5578) made a race visible
between the alarm_timer and select() in main_loop_wait(): If the timer
fired before select was able to block, the full select() timeout could
have been applied instead of returning immediately. Since #5578, this
causes heavy problems to the Musicpal board emulation with stalls up to
5 s, but also with some older Linux guest kernels.
The following patch introduces a pipe that is written to by
host_alarm_handler and select()'ed in main_loop_wait(). This avoids
prevents that select() blocks though a timer has fired and waits for
processing.
Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5633 c046a42c-6fe2-441c-8c8c-71466251a162
This patch adds minimum emulation of SM501 multifunction device,
whose main feature is 2D graphics. It is one of the peripheral
of R2D, the SH4 evaluation board. We can see TUX printed on the
QEMU console.
Signed-off-by: Shin-ichiro KAWASAKI <kawasaki@juno.dti.ne.jp>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5632 c046a42c-6fe2-441c-8c8c-71466251a162
Inspired by a patch from Glauber Costa.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5631 c046a42c-6fe2-441c-8c8c-71466251a162
This allows a user to override the default search path and also makes cross
compilation work a bit nicer wrt KVM detection.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5628 c046a42c-6fe2-441c-8c8c-71466251a162
This patch adds very basic KVM support. KVM is a kernel module for Linux that
allows userspace programs to make use of hardware virtualization support. It
current supports x86 hardware virtualization using Intel VT-x or AMD-V. It
also supports IA64 VT-i, PPC 440, and S390.
This patch only implements the bare minimum support to get a guest booting. It
has very little impact the rest of QEMU and attempts to integrate nicely with
the rest of QEMU.
Even though this implementation is basic, it is significantly faster than TCG.
Booting and shutting down a Linux guest:
w/TCG: 1:32.36 elapsed 84% CPU
w/KVM: 0:31.14 elapsed 59% CPU
Right now, KVM is disabled by default and must be explicitly enabled with
-enable-kvm. We can enable it by default later when we have had better
testing.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5627 c046a42c-6fe2-441c-8c8c-71466251a162
KVM needs to call CPUID from outside of the TCG code. This patch
splits out the CPUID logic into a separate helper that both the op
helper and KVM can call.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5626 c046a42c-6fe2-441c-8c8c-71466251a162
Some x86 CPU definitions that KVM needs
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5625 c046a42c-6fe2-441c-8c8c-71466251a162
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5624 c046a42c-6fe2-441c-8c8c-71466251a162
cpu_interrupt might be called while translating the TB, but before it
is linked into a potentially infinite loop and becomes env->current_tb.
Currently this can (and does) cause huge problems only when using
dyntick clock, with other (periodic) clocks host_alarm_handler will
eventually be executed resulting in a call to cpu_interrupt which will
reset the recursion of running TB and the damage is "only" latency.
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5620 c046a42c-6fe2-441c-8c8c-71466251a162
