Fails to boot rawhide pvops kernels. Output is attached sudo xenner -hda ~/images/rawhide.img -kernel ~/trees/rawhide/i386/images/xen/vmlinuz -initrd ~/trees/rawhide/i386/images/xen/initrd.img -m 512 2>&1 |tee ~/Desktop/xenner.out
Created attachment 299169 [details] command output
I take it this is with kernel-xen-2.6.25-0.4.rc6.fc9xen ? Looks like xenner needs to handle clts now: [emu/0] <0>instr emu failed: rip c0402feb bytes 0f 06 5d c3 55 89 e5 0f (gdb) l *0xc0402feb 0xc0402feb is in native_clts (include/asm/system.h:153). 148 return __limit+1; 149 } 150 151 static inline void native_clts(void) 152 { 153 asm volatile ("clts"); Could be e.g. math_state_restore(). Compare 2.6.25-rc6: asmlinkage void math_state_restore(void) { struct thread_info *thread = current_thread_info(); struct task_struct *tsk = thread->task; clts(); /* Allow maths ops (or we recurse) */ to linux-2.6.18-xen.hg: asmlinkage void math_state_restore(struct pt_regs regs) { struct thread_info *thread = current_thread_info(); struct task_struct *tsk = thread->task; /* NB. 'clts' is done for us by Xen during virtual trap. */
Good spotting, 0f 06 is clts indeed.
https://koji.fedoraproject.org/koji/taskinfo?taskID=559297 Does that one work for you?
It gets further (to the point I had gotten to with my hacked up tree before getting distracted by something shiny; the xenner code was surprisingly easy for me to follow and work on which made me happy :-) Kernel messages at failure are Checking if this processor honours the WP bit even in supervisor mode...<1>BUG: unable to handle kernel paging request at ffffffda IP: [<c08132e8>] hypercall_page+0x2e8/0x1000 *pdpt = 0000000000805001 *pde = 0000000000000000 Oops: 0002 [#1] SMP Modules linked in: Pid: 0, comm: swapper Not tainted (2.6.25-0.18.rc8.fc9.i686.xen #1) EIP: 0061:[<c08132e8>] EFLAGS: 00010286 CPU: 0 EIP is at hypercall_page+0x2e8/0x1000 EAX: ffffffda EBX: f4ffe000 ECX: 00000000 EDX: f57fd000 ESI: f5451000 EDI: 0000092e EBP: c0779f78 ESP: c0779f68 DS: e021 ES: e021 FS: 00d8 GS: 0000 SS: e021 Process swapper (pid: 0, ti=c0779000 task=c073c460 task.ti=c0779000) Stack: 00000001 c041d73c 0000e019 00010206 c0779fa8 c079049f 00000025 80000000 c06e8517 000004b4 00000248 0000269a f4ffe000 00000020 c080fa8c c2942a8c c0779fd4 c077e8b9 3f840000 00013ea3 c2945000 00052000 0004fa8c c07a780c Call Trace: [<c041d73c>] ? do_test_wp_bit+0x1c/0x1e [<c079049f>] ? mem_init+0x2dc/0x329 [<c077e8b9>] ? start_kernel+0x2ca/0x36d [<c0784317>] ? xen_start_kernel+0x32c/0x334 ======================= Code: 00 00 00 b8 16 00 00 00 cd 82 c3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50 b8 17 00 00 00 cd 82 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EIP: [<c08132e8>] hypercall_page+0x2e8/0x1000 SS:ESP e021:c0779f68 ---[ end trace ca143223eefdc828 ]--- And the xenner output (from boot on) [xenner,1] vcpu_thread/0: start [xenner,1] setup_regs: 32bit [emu/0] <0>this is emu32 (xenner 0.28), boot cpu #0 [emu/0] <1>cpu_alloc: cpu 0 [emu/0] <1>cpu_init: cpu 0 [emu/0] <1>pv_init: cpu 0, signature "KVMKVMKVM", features 0x00000000: [emu/0] <1>emu32: boot cpu setup done [emu/0] <1>emu32: paging setup done [emu/0] <1>lapic_init: no lapic present [emu/0] <1>emu32: irq setup done [emu/0] <1>emu32: booting guest kernel (entry e019:c077e000) ... [emu/0] <1>vm_assist: enable 0 [emu/0] <1>vm_assist: enable 2 [emu/0] <1>vm_assist: enable 3 [xenner,0] vcpu_op/0: FIXME: unknown 10 (register_vcpu_info) [emu/0] <1>mmuext_op: SET_LDT (va 0, nr 0) [emu/0] <1>emulate: ignore cr0 update: [emu/0] <1>request: PE MP +TS ET NE WP AM PG [xenner,0] unhandled xen hypercall #23 (32/pae, iret)
Oh, ok. That looks like a bit more work to make things fly. Three bugs / unimplemented features in the last five xenner log lines. I'll have a deeper look next days.
Can you test https://koji.fedoraproject.org/koji/taskinfo?taskID=560811 please? That one processes up to the "can't mount root device" panic for me.
Yep, that gets me into userspace