Glauber Costa [Mon, 28 Sep 2009 18:27:44 +0000 (15:27 -0300)]
do proper cpu_self check
Currently, our check for qemu_cpu_self only checks if there is a cpu
currently in execution (represented by cpu_single_env being set). While
this might be okay for tcg, it is certainly not okay for kvm, since multiple
cpus might be executing.
Instead, I propose we use pthread primitives to test if the caller thread is
the same as env->thread.
For tcg, it will have the same semantics as before, since all CPUStates will
point to the same thread, and we'll only have one in execution at a time.
Signed-off-by: Glauber Costa <glommer@mothafucka.localdomain> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Juan Quintela [Tue, 29 Sep 2009 23:10:56 +0000 (01:10 +0200)]
bdf: Remove last users of FALSE/TRUE
This brings bfd_boolean to the wonderful world of <stdbool.h>, it is needed
because it defines bdf_boolean as an enum with values true and false,
and some architectures use TRUE, FALSE and give problems when you try to use
<stdbool.h>
Signed-off-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Jan Kiszka [Fri, 18 Sep 2009 18:51:23 +0000 (20:51 +0200)]
musicpal: Rework GPIO input events
The qdev_gpio conversion of 343ec8e caused come polarity mismatch of key
event pins and left an overly complex solution behind. Take this chance
and refactor the GPIO input system of the Musicpal, moving it closer to
reality:
- Instantiate all 32 GPIO input pins and do the routing only via
qdev_connect_gpio_out.
- Implement IMR and IER registers. They manage the GPIO pin IRQ. IMR
seems to enable IRQs on rising edges, IER on falling ones. At least
this matches what the Musicpal fireware require.
- Move key pin logic inversion from the GPIO layer to musicpal_key.
Signed-off-by: Jan Kiszka <jan.kiszka@web.de> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Juan Quintela [Tue, 29 Sep 2009 20:48:42 +0000 (22:48 +0200)]
lm832x: make fields to have the same types that they are saved/loaded
They were saved as uint8_t already. To make things simpler, I just
reg == -1 used to indicate an error, I create LM832x_GENERAL_ERROR
with vale 0xff to represet it
Signed-off-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Juan Quintela [Tue, 29 Sep 2009 20:48:40 +0000 (22:48 +0200)]
vmstate: port twl92230 device
Just don't look. struct tm members are ints' and they are sent as uint16_t.
VMState code complains as it should. Have to create hacky int32_as_uint16
type. Don't ever think about copying it
Signed-off-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Juan Quintela [Tue, 29 Sep 2009 20:48:24 +0000 (22:48 +0200)]
vmstate: Add support for sending partial arrays
This one is needed for changees happening on fdc. It allows you to send
arrays of structs whose size we want to send it is another field with type
uint8_t. (If you have been able to read the whole sentence without
stoping for breathing, you can use it.
Signed-off-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Juan Quintela [Tue, 29 Sep 2009 20:48:20 +0000 (22:48 +0200)]
vmstate: remove const for put operations
In a later patch, we introduce pre_save() and post_save() functions.
The whole point of that operation is to change things in the state.
Without this patch, we have to remove the const qualifier in each
use with a cast
Signed-off-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Kevin Wolf [Fri, 2 Oct 2009 20:28:57 +0000 (22:28 +0200)]
target-i386: Fix exceptions for fxsave/fxrstor
This patch corrects the following aspects of exception generation in
fxsave/fxrstor:
* Generate #GP if the operand is not aligned to a 16 byte boundary
* Generate #UD if the LOCK prefix is used
* For CR0.EM = 1 #NM is generated, not #UD
Signed-off-by: Kevin Wolf <mail@kevin-wolf.de> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Stefan Weil [Sat, 19 Sep 2009 11:02:09 +0000 (13:02 +0200)]
eepro100: Add more i825xx devices
The new devices added here are still not functional -
partially because some patches are still missing,
partially because I cannot test them. Nevertheless
they belong to the same family and will be supported
by this driver some day.
As soon as they work, they will also be added to hw/pci.c.
Signed-off-by: Stefan Weil <weil@mail.berlios.de> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Andre Przywara [Fri, 18 Sep 2009 22:30:49 +0000 (00:30 +0200)]
target-i386: add RDTSCP support
RDTSCP reads the time stamp counter and atomically also the content
of a 32-bit MSR, which can be freely set by the OS. This allows CPU
local data to be queried by userspace.
Linux uses this to allow a fast implementation of the getcpu()
syscall, which uses the vsyscall page to avoid a context switch.
AMD CPUs since K8RevF and Intel CPUs since Nehalem support this
instruction.
RDTSCP is guarded by the RDTSCP CPUID bit (Fn8000_0001:EDX[27]).
Signed-off-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Andre Przywara [Fri, 18 Sep 2009 22:30:48 +0000 (00:30 +0200)]
target-i386: add SSE4a instruction support
This adds support for the AMD Phenom/Barcelona's SSE4a instructions.
Those include insertq and extrq, which are doing shift and mask on
XMM registers, in two versions (immediate shift/length values and
stored in another XMM register).
Additionally it implements movntss, movntsd, which are scalar
non-temporal stores (avoiding cache trashing). These are implemented
as normal stores, though.
SSE4a is guarded by the SSE4A CPUID bit (Fn8000_0001:ECX[6]).
Signed-off-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Andre Przywara [Fri, 18 Sep 2009 22:30:47 +0000 (00:30 +0200)]
target-i386: add lock mov cr0 = cr8
AMD CPUs featuring a shortcut to access CR8 even from 32-bit mode.
If you use the LOCK prefix with "mov CR0", it accesses CR8 instead.
This behavior is guarded by the CR8_LEGACY CPUID bit
(Fn8000_0001:ECX[1]).
Signed-off-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Currently zero extensions ops are implemented by a and op with a
constant. This is then catched in some backend, and replaced by
a zero extension instruction. While this works well on RISC
machines, this adds a useless register move on non-RISC machines.
Example on x86:
ext16u_i32 r1, r2
is translated into
mov %eax,%ebx
movzwl %bx, %ebx
while the optimized version should be:
movzwl %ax, %ebx
This patch adds ext{8,16,32}u_i{32,64} TCG ops that can be
implemented in the backends to avoid emitting useless register
moves.
Paul Bolle [Fri, 2 Oct 2009 12:06:47 +0000 (14:06 +0200)]
linux-user: fix "#if 0"'d printf()
Make an "#if 0"'d printf() in load_elf_binary(), probably left to aid in
debugging, reflect what the actual code does. The current printf() will
only confuse those who "#if 1" it (it certainly confused me enough to
write this trivial patch).
Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
MULTI_REQ is never defined, so it doesn't matter much, but since
we have an if statement there, let's add {} to clarify what it
should do if it's uncommented, and indent the code properly.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Blue Swirl [Fri, 2 Oct 2009 19:32:12 +0000 (19:32 +0000)]
Fix warning about undefined madvise() on OpenSolaris
OpenSolaris headers can't export madvise() with a sane set of #defines.
For background, see MySQL bug #7156 (http://bugs.mysql.com/bug.php?id=7156)
for discussion about Solaris header problems.
Looks like linux-user code was correct, just unreadable: what it wanted
to do with "-=" was really assign a negative number, not decrement. Fix
up accordingly.
Reported-by: Laurent Desnogues <laurent.desnogues@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Anthony Liguori [Thu, 1 Oct 2009 21:12:16 +0000 (16:12 -0500)]
Revert "Get rid of _t suffix"
In the very least, a change like this requires discussion on the list.
The naming convention is goofy and it causes a massive merge problem. Something
like this _must_ be presented on the list first so people can provide input
and cope with it.