Incrementing the array index was missed in the previous series which causes
us to not store all the values.
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6617 c046a42c-6fe2-441c-8c8c-71466251a162
cpuid function 2 can have multiple values to describe cache behaviour.
Loop till we have fetched all the values.
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6567 c046a42c-6fe2-441c-8c8c-71466251a162
CPUID functions 4, 0xb and 0xd have sub-leaf values which depend on the
input value of ECX. Store these values as well.
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6566 c046a42c-6fe2-441c-8c8c-71466251a162
The CPUID instruction takes the value of ECX as an input parameter
in addition to the value of EAX as the count for functions 4, 0xb
and 0xd. Make sure we pass the value to the instruction.
Also convert to the qemu-style whitespace for the surrounding code.
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6565 c046a42c-6fe2-441c-8c8c-71466251a162
It seems that the conversion of the kernel-delivered eflags state into
qemu's internal split representation was once needed in an older kvm
design (register read-back may have taken place from inside cpu_exec).
Today it is plain wrong and causes incorrect cpu state reporting (gdb,
monitor) and should also corrupt its saving (savevm, migration). Drop
the related lines.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6461 c046a42c-6fe2-441c-8c8c-71466251a162
Hollis Blanchard noticed that the last commit was not sufficient. We also need
to initialize the msr size in our newly allocated list.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6018 c046a42c-6fe2-441c-8c8c-71466251a162
I believe this was spotted by Gerd Hoffman but I can't find his patch
now. This will cause very subtle corruption on the heap because we
don't allocate the appropriately sized buffer.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6017 c046a42c-6fe2-441c-8c8c-71466251a162
Fix crash with kvm enabled.
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5984 c046a42c-6fe2-441c-8c8c-71466251a162
The third argument to ioctl is a ... which allows any value to be passed. In
practice, glibc always treats the argument as a void *.
Do the same thing for the kvm ioctls to keep things consistent with a
traditional ioctl.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5715 c046a42c-6fe2-441c-8c8c-71466251a162
