* Problem with KVM guest switching to x86 long mode
@ 2010-04-08 18:26 Pekka Enberg
2010-04-08 18:36 ` Avi Kivity
0 siblings, 1 reply; 13+ messages in thread
From: Pekka Enberg @ 2010-04-08 18:26 UTC (permalink / raw)
To: Avi Kivity, KVM General
Hi!
I am working on a light-weight KVM userspace launcher for Linux and am
bit stuck with a guest Linux kernel restarting when it tries to enter
long mode.
The register dump looks like this:
penberg@tiger:~/vm$ ./kvm bzImage
KVM exit reason: 8 ("KVM_EXIT_SHUTDOWN")
Registers:
rip: 00000000001000ed rsp: 00000000005d54b8 flags: 0000000000010046
rax: 0000000080000001 rbx: 0000000001f2c000 rcx: 00000000c0000080
rdx: 0000000000000000 rsi: 0000000000013670 rdi: 0000000002408000
rbp: 0000000000100000 r8: 0000000000000000 r9: 0000000000000000
r10: 0000000000000000 r11: 0000000000000000 r12: 0000000000000000
r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
cr0: 0000000080000011 cr2: 00000000001000ed cr3: 0000000002402000
cr4: 0000000000000020 cr8: 0000000000000000
Segment registers:
register selector base limit type p dpl db s l g avl
cs 0010 0000000000000000 ffffffff 0b 1 0 1 1 0 1 0
ss 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
ds 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
es 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
fs 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
gs 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
tr 0020 0000000000001000 00000067 0b 1 0 0 0 0 0 0
ldt 0000 0000000000000000 ffffffff 00 0 0 0 0 0 0 0
[ efer: 0000000000000500 apic base: 0000000000000000 nmi: disabled ]
Interrupt bitmap:
0000000000000000 0000000000000000 0000000000000000 0000000000000000
Code: 08 49 75 f3 8d 83 00 60 4d 00 0f 22 d8 b9 80 00 00 c0 0f 32 0f
ba e8 08 0f 30 6a 10 8d 85 00 02 00 00 50 b8 01 00 00 80 0f 22 c0 <cb>
f4 eb fd 9c 6a 00 9d 9c 58 89 c3 35 00 00 20 00 50 9d 9c 58
Using Linux 'scripts/decodecode', we can see that we are at
startup_32() of arch/x86/boot/compressed/head_64.S:
All code
========
0: 08 49 75 or %cl,0x75(%rcx)
3: f3 8d 83 00 60 4d 00 repz lea 0x4d6000(%rbx),%eax
a: 0f 22 d8 mov %rax,%cr3
d: b9 80 00 00 c0 mov $0xc0000080,%ecx
12: 0f 32 rdmsr
14: 0f ba e8 08 bts $0x8,%eax
18: 0f 30 wrmsr
1a: 6a 10 pushq $0x10
1c: 8d 85 00 02 00 00 lea 0x200(%rbp),%eax
22: 50 push %rax
23: b8 01 00 00 80 mov $0x80000001,%eax
28: 0f 22 c0 mov %rax,%cr0
2b:* cb lret <-- trapping instruction
2c: f4 hlt
2d: eb fd jmp 0x2c
2f: 9c pushfq
30: 6a 00 pushq $0x0
32: 9d popfq
33: 9c pushfq
34: 58 pop %rax
35: 89 c3 mov %eax,%ebx
37: 35 00 00 20 00 xor $0x200000,%eax
3c: 50 push %rax
3d: 9d popfq
3e: 9c pushfq
3f: 58 pop %rax
I already asked Avi in private about this and he suggested I'd post a
register dump to the list. Please note that I am in no way ruling out
a bug in our fakebios "emulation" but my gut feeling is that I'm just
missing something obvious in the KVM setup.
For those that might be interested, source code to the launcher is
available here:
git clone git://github.com/penberg/vm.git
Launching a Linux kernel is as simple as:
make ; ./kvm bzImage
Pekka
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with KVM guest switching to x86 long mode
2010-04-08 18:26 Problem with KVM guest switching to x86 long mode Pekka Enberg
@ 2010-04-08 18:36 ` Avi Kivity
2010-04-08 18:59 ` Pekka Enberg
0 siblings, 1 reply; 13+ messages in thread
From: Avi Kivity @ 2010-04-08 18:36 UTC (permalink / raw)
To: Pekka Enberg; +Cc: KVM General
On 04/08/2010 09:26 PM, Pekka Enberg wrote:
> Hi!
>
> I am working on a light-weight KVM userspace launcher for Linux and am
> bit stuck with a guest Linux kernel restarting when it tries to enter
> long mode.
>
> The register dump looks like this:
>
> penberg@tiger:~/vm$ ./kvm bzImage
> KVM exit reason: 8 ("KVM_EXIT_SHUTDOWN")
> Registers:
> rip: 00000000001000ed rsp: 00000000005d54b8 flags: 0000000000010046
> rax: 0000000080000001 rbx: 0000000001f2c000 rcx: 00000000c0000080
> rdx: 0000000000000000 rsi: 0000000000013670 rdi: 0000000002408000
> rbp: 0000000000100000 r8: 0000000000000000 r9: 0000000000000000
> r10: 0000000000000000 r11: 0000000000000000 r12: 0000000000000000
> r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
> cr0: 0000000080000011 cr2: 00000000001000ed cr3: 0000000002402000
> cr4: 0000000000000020 cr8: 0000000000000000
> Segment registers:
> register selector base limit type p dpl db s l g avl
> cs 0010 0000000000000000 ffffffff 0b 1 0 1 1 0 1 0
> ss 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
> ds 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
> es 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
> fs 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
> gs 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
> tr 0020 0000000000001000 00000067 0b 1 0 0 0 0 0 0
> ldt 0000 0000000000000000 ffffffff 00 0 0 0 0 0 0 0
>
These all look reasonable. Please add a gdtr dump and an idtr dump.
> 2b:* cb lret<-- trapping instruction
>
Post the two u32s at ss:rsp -> ss:rsp+8. That will tell us where the
guest is trying to return. Actually, from the dump:
1a: 6a 10 pushq $0x10
1c: 8d 85 00 02 00 00 lea 0x200(%rbp),%eax
22: 50 push %rax
it looks like you're returning to segment 0x10, this should be the word
at ss:rsp+4. So if you dump the 2 u32s at
gdtr.base+0x10..gdtr.base+0x18 we'll see if there's anything wrong with
the segment descriptor.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with KVM guest switching to x86 long mode
2010-04-08 18:36 ` Avi Kivity
@ 2010-04-08 18:59 ` Pekka Enberg
2010-04-08 19:30 ` Avi Kivity
0 siblings, 1 reply; 13+ messages in thread
From: Pekka Enberg @ 2010-04-08 18:59 UTC (permalink / raw)
To: Avi Kivity; +Cc: KVM General
Avi Kivity wrote:
> These all look reasonable. Please add a gdtr dump and an idtr dump.
Done.
>> 2b:* cb lret<-- trapping instruction
>>
>
> Post the two u32s at ss:rsp -> ss:rsp+8. That will tell us where the
> guest is trying to return. Actually, from the dump:
>
> 1a: 6a 10 pushq $0x10
> 1c: 8d 85 00 02 00 00 lea 0x200(%rbp),%eax
> 22: 50 push %rax
>
> it looks like you're returning to segment 0x10, this should be the word
> at ss:rsp+4. So if you dump the 2 u32s at
> gdtr.base+0x10..gdtr.base+0x18 we'll see if there's anything wrong with
> the segment descriptor.
Here you go:
penberg@tiger:~/vm$ ./kvm bzImage
KVM exit reason: 8 ("KVM_EXIT_SHUTDOWN")
Registers:
rip: 00000000001000ed rsp: 00000000005d54b8 flags: 0000000000010046
rax: 0000000080000001 rbx: 0000000001f2c000 rcx: 00000000c0000080
rdx: 0000000000000000 rsi: 0000000000013670 rdi: 0000000002408000
rbp: 0000000000100000 r8: 0000000000000000 r9: 0000000000000000
r10: 0000000000000000 r11: 0000000000000000 r12: 0000000000000000
r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
cr0: 0000000080000011 cr2: 00000000001000ed cr3: 0000000002402000
cr4: 0000000000000020 cr8: 0000000000000000
Segment registers:
register selector base limit type p dpl db s l g avl
cs 0010 0000000000000000 ffffffff 0b 1 0 1 1 0 1 0
ss 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
ds 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
es 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
fs 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
gs 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
tr 0020 0000000000001000 00000067 0b 1 0 0 0 0 0 0
ldt 0000 0000000000000000 ffffffff 00 0 0 0 0 0 0 0
gdt 00000000005ca458 00000030
idt 0000000000000000 00000000
[ efer: 0000000000000500 apic base: 0000000000000000 nmi: disabled ]
Interrupt bitmap:
0000000000000000 0000000000000000 0000000000000000 0000000000000000
Code: 08 49 75 f3 8d 83 00 60 4d 00 0f 22 d8 b9 80 00 00 c0 0f 32 0f ba
e8 08 0f 30 6a 10 8d 85 00 02 00 00 50 b8 01 00 00 80 0f 22 c0 <cb> f4
eb fd 9c 6a 00 9d 9c 58 89 c3 35 00 00 20 00 50 9d 9c 58
Stack:
0x005d54b8: 00 02 10 00 10 00 00 00 <-- return value
0x005d54c0: 00 00 00 00 00 00 00 00
0x005d54c8: 00 00 00 00 00 00 00 00
0x005d54d0: 00 00 00 00 00 00 00 00
GDT:
0x005ca458: 30 00 58 a4 5c 00 00 00
0x005ca460: 00 00 00 00 00 00 00 00
0x005ca468: ff ff 00 00 00 9a af 00 <-- gtr.base + 0x10
0x005ca470: ff ff 00 00 00 92 cf 00
0x005ca478: 00 00 00 00 00 89 80 00
0x005ca480: 00 00 00 00 00 00 00 00
Pekka
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with KVM guest switching to x86 long mode
2010-04-08 18:59 ` Pekka Enberg
@ 2010-04-08 19:30 ` Avi Kivity
2010-04-11 6:30 ` Pekka Enberg
0 siblings, 1 reply; 13+ messages in thread
From: Avi Kivity @ 2010-04-08 19:30 UTC (permalink / raw)
To: Pekka Enberg; +Cc: KVM General
On 04/08/2010 09:59 PM, Pekka Enberg wrote:
>
>>> 2b:* cb lret<-- trapping instruction
>>
>> Post the two u32s at ss:rsp -> ss:rsp+8. That will tell us where the
>> guest is trying to return. Actually, from the dump:
>>
>> 1a: 6a 10 pushq $0x10
>> 1c: 8d 85 00 02 00 00 lea 0x200(%rbp),%eax
>> 22: 50 push %rax
>>
>> it looks like you're returning to segment 0x10, this should be the
>> word at ss:rsp+4. So if you dump the 2 u32s at
>> gdtr.base+0x10..gdtr.base+0x18 we'll see if there's anything wrong
>> with the segment descriptor.
>
> Here you go:
I was asking for the wrong things.
>
> penberg@tiger:~/vm$ ./kvm bzImage
> KVM exit reason: 8 ("KVM_EXIT_SHUTDOWN")
> Registers:
> rip: 00000000001000ed rsp: 00000000005d54b8 flags: 0000000000010046
> rax: 0000000080000001 rbx: 0000000001f2c000 rcx: 00000000c0000080
> rdx: 0000000000000000 rsi: 0000000000013670 rdi: 0000000002408000
> rbp: 0000000000100000 r8: 0000000000000000 r9: 0000000000000000
> r10: 0000000000000000 r11: 0000000000000000 r12: 0000000000000000
> r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
> cr0: 0000000080000011 cr2: 00000000001000ed cr3: 0000000002402000
cr2 points at rip. So it isn't lret not executing correctly, it's the
cpu not able to fetch lret at all.
The code again:
> 23: b8 01 00 00 80 mov $0x80000001,%eax
> 28: 0f 22 c0 mov %rax,%cr0
> 2b:* cb lret<-- trapping instruction
>
The instruction at 0x28 is enabling paging, next insn fetch faults, so
the paging structures must be incorrect.
Questions:
- what is the u64 at cr3? (call it pte4)
- what is the u64 at (pte4 & ~0xfff)? (call it pte3)
- what is the u64 at (pte3 & ~0xfff)? ("pte2")
- what is the u64 at ((pte2 & ~0xfff) + 2048)? ("pte1")
Note if bit 7 of pte2 is set, then pte1 is unneeded.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with KVM guest switching to x86 long mode
2010-04-08 19:30 ` Avi Kivity
@ 2010-04-11 6:30 ` Pekka Enberg
2010-04-11 9:16 ` Avi Kivity
0 siblings, 1 reply; 13+ messages in thread
From: Pekka Enberg @ 2010-04-11 6:30 UTC (permalink / raw)
To: Avi Kivity; +Cc: KVM General
Avi Kivity wrote:
> The instruction at 0x28 is enabling paging, next insn fetch faults, so
> the paging structures must be incorrect.
>
> Questions:
> - what is the u64 at cr3? (call it pte4)
> - what is the u64 at (pte4 & ~0xfff)? (call it pte3)
> - what is the u64 at (pte3 & ~0xfff)? ("pte2")
> - what is the u64 at ((pte2 & ~0xfff) + 2048)? ("pte1")
>
> Note if bit 7 of pte2 is set, then pte1 is unneeded.
Sorry for the delay. Here you go:
penberg@tiger:~/vm$ ./kvm bzImage
KVM exit reason: 8 ("KVM_EXIT_SHUTDOWN")
Registers:
rip: 00000000001000ed rsp: 00000000005d54b8 flags: 0000000000010046
rax: 0000000080000001 rbx: 0000000001f2c000 rcx: 00000000c0000080
rdx: 0000000000000000 rsi: 0000000000013670 rdi: 0000000002408000
rbp: 0000000000100000 r8: 0000000000000000 r9: 0000000000000000
r10: 0000000000000000 r11: 0000000000000000 r12: 0000000000000000
r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
cr0: 0000000080000011 cr2: 00000000001000ed cr3: 0000000002402000
cr4: 0000000000000020 cr8: 0000000000000000
Segment registers:
register selector base limit type p dpl db s l g avl
cs 0010 0000000000000000 ffffffff 0b 1 0 1 1 0 1 0
ss 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
ds 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
es 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
fs 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
gs 0018 0000000000000000 ffffffff 03 1 0 1 1 0 1 0
tr 0020 0000000000001000 00000067 0b 1 0 0 0 0 0 0
ldt 0000 0000000000000000 ffffffff 00 0 0 0 0 0 0 0
gdt 00000000005ca458 00000030
idt 0000000000000000 00000000
[ efer: 0000000000000500 apic base: 0000000000000000 nmi: disabled ]
Interrupt bitmap:
0000000000000000 0000000000000000 0000000000000000 0000000000000000
Code: 08 49 75 f3 8d 83 00 60 4d 00 0f 22 d8 b9 80 00 00 c0 0f 32 0f ba
e8 08 0f 30 6a 10 8d 85 00 02 00 00 50 b8 01 00 00 80 0f 22 c0 <cb> f4
eb fd 9c 6a 00 9d 9c 58 89 c3 35 00 00 20 00 50 9d 9c 58
Stack:
0x005d54b8: 00 02 10 00 10 00 00 00
0x005d54c0: 00 00 00 00 00 00 00 00
0x005d54c8: 00 00 00 00 00 00 00 00
0x005d54d0: 00 00 00 00 00 00 00 00
Page Tables:
pte4: 0000000002403007 pte3: 0000000002404007 pte2: 0000000000000183
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with KVM guest switching to x86 long mode
2010-04-11 6:30 ` Pekka Enberg
@ 2010-04-11 9:16 ` Avi Kivity
2010-04-11 9:48 ` Pekka Enberg
0 siblings, 1 reply; 13+ messages in thread
From: Avi Kivity @ 2010-04-11 9:16 UTC (permalink / raw)
To: Pekka Enberg; +Cc: KVM General
On 04/11/2010 09:30 AM, Pekka Enberg wrote:
> Avi Kivity wrote:
>> The instruction at 0x28 is enabling paging, next insn fetch faults,
>> so the paging structures must be incorrect.
>>
>> Questions:
>> - what is the u64 at cr3? (call it pte4)
>> - what is the u64 at (pte4 & ~0xfff)? (call it pte3)
>> - what is the u64 at (pte3 & ~0xfff)? ("pte2")
>> - what is the u64 at ((pte2 & ~0xfff) + 2048)? ("pte1")
>>
>> Note if bit 7 of pte2 is set, then pte1 is unneeded.
>
> Sorry for the delay. Here you go:
>
> Page Tables:
> pte4: 0000000002403007 pte3: 0000000002404007 pte2: 0000000000000183
These are all correct.
The only thing I can think of, is that MAXPHYADDR is small value. And
indeed, if I run it on an ept capable machine (which does the check in
hardware, not software), I get
IO error: OUT port=cf8, size=4, count=1
KVM exit reason: 2 ("KVM_EXIT_IO")
Registers:
rip: ffffffff813a0d8f rsp: ffffffff8167bdf8 flags: 0000000000000086
rax: 000000008000c300 rbx: 000000000000c000 rcx: 0000000000000000
rdx: 0000000000000cf8 rsi: 0000000000000018 rdi: 0000000000000000
rbp: ffffffff8167be08 r8: 0000000000000000 r9: 0000000000000000
r10: 0000000000000006 r11: 00000000bbceeb20 r12: 0000000000000000
r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
cr0: 0000000080050033 cr2: 0000000000000000 cr3: 0000000001001000
cr4: 00000000000000a0 cr8: 0000000000000000
So the guest is in long mode, happily trying to access pci config space.
MAXPHYADDR comes from cpuid 80000008.eax[0:7]. Typical values are 36-40
(number of physical address bits supported by the processor). What
value does your guest see?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with KVM guest switching to x86 long mode
2010-04-11 9:16 ` Avi Kivity
@ 2010-04-11 9:48 ` Pekka Enberg
2010-04-11 9:59 ` Avi Kivity
0 siblings, 1 reply; 13+ messages in thread
From: Pekka Enberg @ 2010-04-11 9:48 UTC (permalink / raw)
To: Avi Kivity; +Cc: KVM General
Avi Kivity wrote:
>> Sorry for the delay. Here you go:
>>
>> Page Tables:
>> pte4: 0000000002403007 pte3: 0000000002404007 pte2: 0000000000000183
>
> These are all correct.
>
> The only thing I can think of, is that MAXPHYADDR is small value. And
> indeed, if I run it on an ept capable machine (which does the check in
> hardware, not software), I get
>
> IO error: OUT port=cf8, size=4, count=1
> KVM exit reason: 2 ("KVM_EXIT_IO")
> Registers:
> rip: ffffffff813a0d8f rsp: ffffffff8167bdf8 flags: 0000000000000086
> rax: 000000008000c300 rbx: 000000000000c000 rcx: 0000000000000000
> rdx: 0000000000000cf8 rsi: 0000000000000018 rdi: 0000000000000000
> rbp: ffffffff8167be08 r8: 0000000000000000 r9: 0000000000000000
> r10: 0000000000000006 r11: 00000000bbceeb20 r12: 0000000000000000
> r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000
> cr0: 0000000080050033 cr2: 0000000000000000 cr3: 0000000001001000
> cr4: 00000000000000a0 cr8: 0000000000000000
>
> So the guest is in long mode, happily trying to access pci config space.
>
> MAXPHYADDR comes from cpuid 80000008.eax[0:7]. Typical values are 36-40
> (number of physical address bits supported by the processor). What
> value does your guest see?
Ah, nice catch! The host cpuid doesn't seem to support 80000008 at so I
didn't set it up in the guest either. I now added dummy emulation for it
and the triple fault is fixed.
Thanks Avi!
Pekka
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with KVM guest switching to x86 long mode
2010-04-11 9:48 ` Pekka Enberg
@ 2010-04-11 9:59 ` Avi Kivity
2010-04-11 10:02 ` Pekka Enberg
0 siblings, 1 reply; 13+ messages in thread
From: Avi Kivity @ 2010-04-11 9:59 UTC (permalink / raw)
To: Pekka Enberg; +Cc: KVM General
On 04/11/2010 12:48 PM, Pekka Enberg wrote:
>> So the guest is in long mode, happily trying to access pci config space.
>>
>> MAXPHYADDR comes from cpuid 80000008.eax[0:7]. Typical values are
>> 36-40 (number of physical address bits supported by the processor).
>> What value does your guest see?
>
>
> Ah, nice catch! The host cpuid doesn't seem to support 80000008 at so
> I didn't set it up in the guest either. I now added dummy emulation
> for it and the triple fault is fixed.
It should work without 80000008 set up - failure should happen only if
it is setup incorrectly:
int cpuid_maxphyaddr(struct kvm_vcpu *vcpu)
{
struct kvm_cpuid_entry2 *best;
best = kvm_find_cpuid_entry(vcpu, 0x80000008, 0);
if (best)
return best->eax & 0xff;
return 36;
}
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with KVM guest switching to x86 long mode
2010-04-11 9:59 ` Avi Kivity
@ 2010-04-11 10:02 ` Pekka Enberg
2010-04-11 11:48 ` Avi Kivity
0 siblings, 1 reply; 13+ messages in thread
From: Pekka Enberg @ 2010-04-11 10:02 UTC (permalink / raw)
To: Avi Kivity; +Cc: KVM General
Avi Kivity wrote:
> On 04/11/2010 12:48 PM, Pekka Enberg wrote:
>>> So the guest is in long mode, happily trying to access pci config space.
>>>
>>> MAXPHYADDR comes from cpuid 80000008.eax[0:7]. Typical values are
>>> 36-40 (number of physical address bits supported by the processor).
>>> What value does your guest see?
>>
>>
>> Ah, nice catch! The host cpuid doesn't seem to support 80000008 at so
>> I didn't set it up in the guest either. I now added dummy emulation
>> for it and the triple fault is fixed.
>
> It should work without 80000008 set up - failure should happen only if
> it is setup incorrectly:
>
> int cpuid_maxphyaddr(struct kvm_vcpu *vcpu)
> {
> struct kvm_cpuid_entry2 *best;
>
> best = kvm_find_cpuid_entry(vcpu, 0x80000008, 0);
> if (best)
> return best->eax & 0xff;
> return 36;
> }
Well, like I said, if I don't add an entry for it in struct kvm_cpuid2
that's passed to KVM_SET_CPUID2 ioctl, I see a triple fault on Core 2
Duo CPU that doesn't seem to have native 0x80000008.
Pekka
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with KVM guest switching to x86 long mode
2010-04-11 10:02 ` Pekka Enberg
@ 2010-04-11 11:48 ` Avi Kivity
2010-04-11 11:52 ` Pekka Enberg
0 siblings, 1 reply; 13+ messages in thread
From: Avi Kivity @ 2010-04-11 11:48 UTC (permalink / raw)
To: Pekka Enberg; +Cc: KVM General
On 04/11/2010 01:02 PM, Pekka Enberg wrote:
>> It should work without 80000008 set up - failure should happen only
>> if it is setup incorrectly:
>>
>> int cpuid_maxphyaddr(struct kvm_vcpu *vcpu)
>> {
>> struct kvm_cpuid_entry2 *best;
>>
>> best = kvm_find_cpuid_entry(vcpu, 0x80000008, 0);
>> if (best)
>> return best->eax & 0xff;
>> return 36;
>> }
>
>
> Well, like I said, if I don't add an entry for it in struct kvm_cpuid2
> that's passed to KVM_SET_CPUID2 ioctl, I see a triple fault on Core 2
> Duo CPU that doesn't seem to have native 0x80000008.
Do you have a function 8, though? Looks like a bug in kvm may confuse
the two.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with KVM guest switching to x86 long mode
2010-04-11 11:48 ` Avi Kivity
@ 2010-04-11 11:52 ` Pekka Enberg
2010-04-11 12:02 ` Avi Kivity
0 siblings, 1 reply; 13+ messages in thread
From: Pekka Enberg @ 2010-04-11 11:52 UTC (permalink / raw)
To: Avi Kivity; +Cc: KVM General
Avi Kivity wrote:
> On 04/11/2010 01:02 PM, Pekka Enberg wrote:
>>> It should work without 80000008 set up - failure should happen only
>>> if it is setup incorrectly:
>>>
>>> int cpuid_maxphyaddr(struct kvm_vcpu *vcpu)
>>> {
>>> struct kvm_cpuid_entry2 *best;
>>>
>>> best = kvm_find_cpuid_entry(vcpu, 0x80000008, 0);
>>> if (best)
>>> return best->eax & 0xff;
>>> return 36;
>>> }
>>
>>
>> Well, like I said, if I don't add an entry for it in struct kvm_cpuid2
>> that's passed to KVM_SET_CPUID2 ioctl, I see a triple fault on Core 2
>> Duo CPU that doesn't seem to have native 0x80000008.
>
> Do you have a function 8, though? Looks like a bug in kvm may confuse
> the two.
Yeah, the host has function 8. I'm more than happy to test patches to
fix the problem.
Pekka
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with KVM guest switching to x86 long mode
2010-04-11 11:52 ` Pekka Enberg
@ 2010-04-11 12:02 ` Avi Kivity
2010-04-11 12:04 ` Avi Kivity
0 siblings, 1 reply; 13+ messages in thread
From: Avi Kivity @ 2010-04-11 12:02 UTC (permalink / raw)
To: Pekka Enberg; +Cc: KVM General
On 04/11/2010 02:52 PM, Pekka Enberg wrote:
>> Do you have a function 8, though? Looks like a bug in kvm may
>> confuse the two.
>
>
> Yeah, the host has function 8. I'm more than happy to test patches to
> fix the problem.
Coming up after a quick git blame to see if I can see how the bug was
introduced.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with KVM guest switching to x86 long mode
2010-04-11 12:02 ` Avi Kivity
@ 2010-04-11 12:04 ` Avi Kivity
0 siblings, 0 replies; 13+ messages in thread
From: Avi Kivity @ 2010-04-11 12:04 UTC (permalink / raw)
To: Pekka Enberg; +Cc: KVM General
On 04/11/2010 03:02 PM, Avi Kivity wrote:
> On 04/11/2010 02:52 PM, Pekka Enberg wrote:
>>> Do you have a function 8, though? Looks like a bug in kvm may
>>> confuse the two.
>>
>>
>> Yeah, the host has function 8. I'm more than happy to test patches to
>> fix the problem.
>
> Coming up after a quick git blame to see if I can see how the bug was
> introduced.
>
Ugh, I shouldn't have.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2010-04-11 12:04 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-08 18:26 Problem with KVM guest switching to x86 long mode Pekka Enberg
2010-04-08 18:36 ` Avi Kivity
2010-04-08 18:59 ` Pekka Enberg
2010-04-08 19:30 ` Avi Kivity
2010-04-11 6:30 ` Pekka Enberg
2010-04-11 9:16 ` Avi Kivity
2010-04-11 9:48 ` Pekka Enberg
2010-04-11 9:59 ` Avi Kivity
2010-04-11 10:02 ` Pekka Enberg
2010-04-11 11:48 ` Avi Kivity
2010-04-11 11:52 ` Pekka Enberg
2010-04-11 12:02 ` Avi Kivity
2010-04-11 12:04 ` Avi Kivity
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox