Re: (qemu)info registers -- Not working for me.

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 3043 bytes --]

Zachery Salwasser wrote:
> Thank you for the prompt reply, you were correct, and I was able to
> resolve the issue by being a little more careful with my header files.
>  I will close the issue on sourceforge.
> 

OK, so we can safely conclude your problem was due to local changes in
the kvm headers? I would just like to exclude that there might be issues
due to different compilers / their switches / whatever, and that already
with vanilla headers.

Jan

> 
> On Sun, Feb 28, 2010 at 1:27 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>> Zachery Salwasser wrote:
>>> I have been having trouble with reading the extended registers
>>> normally read by kvm_get_sregs() on host kernels ~2.6.32 and higher.
>>>
>>> I am currently running Linux 2.6.32-8, kvm-kmod 2.6.32.8, and qemu 0.12.2.
>>>
>>> I get the following output when I try info registers on the qemu console:
>>>
>>> (qemu) info registers
>>> EAX=6d63c93d EBX=ffdffc70 ECX=ffdffc70 EDX=00000000
>>> ESI=ffdffc50 EDI=823e7b68 EBP=80550f50 ESP=80550f34
>>> EIP=f8621d3e EFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
>>> ES =3d65 00001000 b772bdf8 3fffe800 DPL=3 Reserved
>>> CS =4fe1 b7d59ff4 b7d5b3a0 6b300100
>>> SS =0000 b772bde8 0847ab38 6f300a00
>>> DS =b3d0 b7d5b3cc 00000000 7bffd500 DPL=2 DS   [E-A]
>>> FS =e008 b7d5b3a0 b7d59ff4 005bb900 DPL=1 CS32 [--A]
>>> GS =ffff ffffffff 00000007 7fffff00 DPL=3 CS64 [CRA]
>>> LDT=9ff4 b772bde0 00000008 7ffff500 DPL=3 DS   [E-A]
>>> TR =0000 00000080 b7fb63ab 00f00000
>>> GDT=     00014fe1 00000100
>>> IDT=     b7d5b3cc 0000b3d0
>>> CR0=08000101 CR2=00002000 CR3=00000000 CR4=08000101
>>> DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
>>> DR6=ffff0ff0 DR7=00000000
>>> FCW=027f FSW=0000 [ST=0] FTW=00 MXCSR=00000000
>>> FPR0=0000000000000000 ffff FPR1=00ff00ff00ff00ff ffff
>>> FPR2=0000000000000000 ffff FPR3=00fe000d009900ee ffff
>>> FPR4=ff0d9aefff6a604c ffff FPR5=00ff000d009a00ef ffff
>>> FPR6=0000000000000000 ffff FPR7=0080008000800080 ffff
>>> XMM00=
>>> 00000020000000000000000000000001 XMM01=81181ab88055f980e115d00000000020
>>> XMM02=f79092a481181ab8c03845740dd1d000 XMM03=81181ab8c03845740000016d804e93e0
>>> XMM04=c0384574000000000000000100000000 XMM05=e1150000804e7e36f790931400000000
>>> XMM06=806f02980000000000000000c0384574 XMM07=000000028055f62000000080c0384574
>>>
>>> Note that cr3 is 0, which doesn't seem possible.  The contents of the
>>> sregs is also static across invocations of info registers (whereas the
>>> "regs" chang), indicating that the values that are there are garbage.
>>>
>>> Delving deeper, when I check actual invocations of kvm_get_sregs(), it
>>> usually returns either 0 or -22, neither value indicating success.
>> -22 indicates something bad is happening. Maybe sizeof(struct kvm_sregs)
>> is different from kernel and user space POV on your host. That would
>> cause KVM_GET_SREGS to have different values, thus the kernel would be
>> unable to dispatch the request. Could you check this?
>>
>> Jan
>>
>>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]