Bug 580033

Summary: boot as KVM guest fails
Product: [Fedora] Fedora Reporter: James Findley <sixy>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 13CC: anton, dougsland, gansalmon, itamar, jlaska, jonathan, kernel-maint, mtosatti
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 578579 Environment:
Last Closed: 2010-04-09 12:07:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description James Findley 2010-04-07 10:53:09 UTC 
Description of problem:

Booting the F13 Beta RC#4 image as a KVM guest (host centos 5 x86_64) fails.

Version-Release number of selected component (if applicable):

I'm not sure exactly which kernel version is applicable, but it affects at least RC1 and RC4.

How reproducible:

Always (on this hardware, I haven't tested other hardware yet).

Steps to Reproduce:
1. Boot F13 Beta RC4 (any image will do) as a KVM guest.
2.
3.
  
Actual results:

kernel bug


Expected results:


Additional info:

rodata_test: test data was not read only
BUG: unable to handle kernel paging request at ffffffff81029153
IP: [<ffffffff81029153>] kvm_leave_lazy_mmu+0x60/0x90
PGD 1a45067 PUD 1a49063 PMD 10001e1 
Oops: 0003 [#1] SMP 
last sysfs file: 
CPU 0 
Pid: 1, comm: init Not tainted 2.6.33.1-19.fc13.x86_64 #1 /KVM
RIP: 0010:[<ffffffff81029153>]  [<ffffffff81029153>] kvm_leave_lazy_mmu+0x60/0x90
RSP: 0018:ffff88000eda7920  EFLAGS: 00010297
RAX: 0000000000000002 RBX: 0000000000000018 RCX: 000000000320e640
RDX: 0000000000000000 RSI: ffff88000eda7938 RDI: ffff88000320e640
RBP: ffff88000eda7960 R08: 0000000000000200 R09: ffff88000f200398
R10: 0000000000000000 R11: 0000000000000000 R12: ffff88000320e640
R13: 0000000000000018 R14: ffff88000320e640 R15: 0000000000000002
FS:  0000000000000000(0000) GS:ffff880003200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff81029153 CR3: 000000000f1a1000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process init (pid: 1, threadinfo ffff88000eda6000, task ffff88000eda8000)
Stack:
 ffff880000000001 0000000000000000 80000000019ff067 00007fffffffe000
<0> ffff88000f208000 00007fffbee29000 80000000019ff067 00007ffffffff000
<0> ffff88000eda7a20 ffffffff810fb864 ffff88000eda7990 ffffffff8147943b
Call Trace:
 [<ffffffff810fb864>] move_page_tables+0x34f/0x48f
 [<ffffffff8147943b>] ? _raw_spin_unlock+0x2b/0x2f
 [<ffffffff81124f68>] setup_arg_pages+0x194/0x2f1
 [<ffffffff8115bfea>] load_elf_binary+0x467/0x15b5
 [<ffffffff81010471>] ? native_sched_clock+0x2d/0x5f
 [<ffffffff810710fd>] ? sched_clock_local+0x1c/0x82
 [<ffffffff81123f11>] ? search_binary_handler+0xb8/0x27f
 [<ffffffff81071226>] ? sched_clock_cpu+0xc3/0xce
 [<ffffffff8107ba94>] ? trace_hardirqs_off+0xd/0xf
 [<ffffffff81071274>] ? cpu_clock+0x43/0x5e
 [<ffffffff8107baca>] ? lock_release_holdtime+0x34/0xe3
 [<ffffffff81123f1b>] search_binary_handler+0xc2/0x27f
 [<ffffffff8115bb83>] ? load_elf_binary+0x0/0x15b5
 [<ffffffff8115a684>] load_script+0x1dc/0x204
 [<ffffffff8107baca>] ? lock_release_holdtime+0x34/0xe3
 [<ffffffff81123f1b>] search_binary_handler+0xc2/0x27f
 [<ffffffff8115a4a8>] ? load_script+0x0/0x204
 [<ffffffff81125653>] do_execve+0x1ce/0x2cf
 [<ffffffff810110b4>] sys_execve+0x43/0x5a
 [<ffffffff8100ab58>] kernel_execve+0x68/0xd0
 [<ffffffff810021b8>] ? run_init_process+0x23/0x25
 [<ffffffff81002255>] init_post+0x9b/0x116
 [<ffffffff81d837b2>] kernel_init+0x260/0x26f
 [<ffffffff8100aae4>] kernel_thread_helper+0x4/0x10
 [<ffffffff81479710>] ? restore_args+0x0/0x30
 [<ffffffff81d83552>] ? kernel_init+0x0/0x26f
 [<ffffffff8100aae0>] ? kernel_thread_helper+0x0/0x10
Code: 00 00 45 85 ed 74 40 4d 89 e6 41 bf 02 00 00 00 31 d2 4c 89 f7 48 89 55 c8 44 89 eb e8 bb a4 00 00 48 8b 55 c8 48 89 c1 44 89 f8 <0f> 01 c1 48 89 c3 48 98 49 01 c6 41 29 dd 75 d7 41 c7 84 24 00 
RIP  [<ffffffff81029153>] kvm_leave_lazy_mmu+0x60/0x90
 RSP <ffff88000eda7920>
CR2: ffffffff81029153
---[ end trace 51133477b1b2634f ]---
input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3
async/1 used greatest stack depth: 3800 bytes left
Comment 1 James Laska 2010-04-08 11:38:44 UTC 
A similar issue reported in ubuntu (see https://lists.ubuntu.com/archives/ubuntu-server-bugs/2010-March/029629.html) attributes this failure to the following fix:

   KVM: fix memory access during x86 emulation.

A proposed patch by Marcelo Tosatti <mtosatti>
 as available at http://launchpadlibrarian.net/40827609/KVM%3A%20x86%3A%20ignore%20access%20permissions%20for%20hypercall%20patching.patch
Comment 2 Chuck Ebbert 2010-04-08 23:37:31 UTC 
ffffffff81029153:       0f 01 c1                vmcall
Comment 3 Chuck Ebbert 2010-04-09 00:01:00 UTC 
It faulted trying to write to the instruction address. But we don't have the patch mentioned in comment #2 in our kernel?

From: Gleb Natapov <gleb>
Date: Wed, 10 Feb 2010 12:21:32 +0000 (+0200)
Subject: KVM: x86 emulator: fix memory access during x86 emulation
X-Git-Tag: v2.6.34-rc1~193^2~15
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=1871c6020d7308afb99127bba51f04548e7ca84e

It's not in our kernel and the patch from comment #2 will not apply.
Comment 4 Chuck Ebbert 2010-04-09 12:07:13 UTC 
Oh, you're using Centos5 for the host. This error is caused by a bug in that kernel, not Fedora's.