Ian, I have read the your changeset 13830 "[XEN] kexec: add compatability shim for kexec in 32on64 mode", which seems to be used for kexec a 32b kernel on 32e xen. I borrow some of the code from xen/arch/x86/x86_64/compat_kexec.S for similar purpose(switch out of 32e mode in xen) by similar way: 1. setup identity map in idle_pg_table then switch to it. 2. ljmp to a identity map code in another code segment of compatibility mode 3. turn of paging by clear CR0.PG 4. load a new cr3 with legacy page table 5. clear EFER.LME 6. turn on paging by set CR0.PG 7. a branch instruction But I always have a GP fault in step 3 when mov cr0:( (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) GENERAL PROTECTION FAULT (XEN) [error_code=0000] (XEN) **************************************** Do you have successful run for the above code? Your code missed step 7, does it matter? Do you have any comments for the GP fault? Thanks a lot. -- best rgds, edwin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 3/7/07 07:51, "Zhai, Edwin" <edwin.zhai@intel.com> wrote:> I have read the your changeset 13830 > "[XEN] kexec: add compatability shim for kexec in 32on64 mode", which seems to > be used for kexec a 32b kernel on 32e xen.You''re aware it got broken when 64-bit Xen became relocatable (in physical memory map), and was only fixed by changesets 15377 and 15379?> I borrow some of the code from xen/arch/x86/x86_64/compat_kexec.S for similar > purpose(switch out of 32e mode in xen) by similar way:Why would you want to do that, except for kexec? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 2007-07-03 at 14:51 +0800, Zhai, Edwin wrote:> Ian, > > I have read the your changeset 13830That was me rather than Ian P.> "[XEN] kexec: add compatability shim for kexec in 32on64 mode", which seems to > be used for kexec a 32b kernel on 32e xen. > > I borrow some of the code from xen/arch/x86/x86_64/compat_kexec.S for similar > purpose(switch out of 32e mode in xen) by similar way: > 1. setup identity map in idle_pg_table then switch to it. > 2. ljmp to a identity map code in another code segment of compatibility mode > 3. turn of paging by clear CR0.PG > 4. load a new cr3 with legacy page table > 5. clear EFER.LME > 6. turn on paging by set CR0.PG > 7. a branch instruction > > But I always have a GP fault in step 3 when mov cr0:( > (XEN) **************************************** > (XEN) Panic on CPU 0: > (XEN) GENERAL PROTECTION FAULT > (XEN) [error_code=0000] > (XEN) **************************************** > > Do you have successful run for the above code? Your code missed step 7, does it > matter? > > Do you have any comments for the GP fault?I was simply following the procedure described in vol3 of the software developers manual "Switching out of ia-32e mode operation" (section 9.8.5.4 in my slightly old copy). I presume you are seeing the GP when you try and write to CR0 with PG cleared. Without seeing the code I''d guess the GP is most likely because you aren''t actually in compatibility mode. Did Xen print any debug info before the panic, such as current register state? Another possibility is that EIP isn''t really an identity mapped page. Depending on the version of Xen you are using you would have to deal with the physical relocation which is performed at boot time, for example. I''m not sure that wouldn''t cause an invalid op rather than GPF though. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 2007-07-03 at 14:51 +0800, Zhai, Edwin wrote:> 7. a branch instruction[...]> Your code missed step 7, does it matter?I guess not (since it works ;-)) we have a pop then a call instead but it makes sense to add an explicit branch I think. I''ll do so shortly. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Jul 03, 2007 at 09:57:21AM +0100, Keir Fraser wrote:> On 3/7/07 07:51, "Zhai, Edwin" <edwin.zhai@intel.com> wrote: > > > I have read the your changeset 13830 > > "[XEN] kexec: add compatability shim for kexec in 32on64 mode", which seems to > > be used for kexec a 32b kernel on 32e xen.I worked on a pretty old changeset W/O relocation. vir=>phys just use PAGE_OFFSET> > You''re aware it got broken when 64-bit Xen became relocatable (in physical > memory map), and was only fixed by changesets 15377 and 15379? > > > I borrow some of the code from xen/arch/x86/x86_64/compat_kexec.S for similar > > purpose(switch out of 32e mode in xen) by similar way: > > Why would you want to do that, except for kexec?When boot xen with TXT, shutdown need trap back to sboot for some security operations.> > -- Keir >-- best rgds, edwin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Jul 03, 2007 at 10:09:17AM +0100, Ian Campbell wrote:> On Tue, 2007-07-03 at 14:51 +0800, Zhai, Edwin wrote: > > Ian, > > > > I have read the your changeset 13830 > > That was me rather than Ian P.Really sorry for it:)> > I was simply following the procedure described in vol3 of the software > developers manual "Switching out of ia-32e mode operation" (section > 9.8.5.4 in my slightly old copy). > > I presume you are seeing the GP when you try and write to CR0 with PG > cleared. Without seeing the code I''d guess the GP is most likely because > you aren''t actually in compatibility mode. Did Xen print any debug infoI have switched to 0xe038 code seg. compatibility mode is only decided by the "L" in the seg descr, right?> before the panic, such as current register state?I attached log in the end.> > Another possibility is that EIP isn''t really an identity mapped page. > Depending on the version of Xen you are using you would have to deal > with the physical relocation which is performed at boot time, for > example. I''m not sure that wouldn''t cause an invalid op rather than GPF > though.This changeset is pretty old (maybe r14422) without relocation. BTW, How to use kexec to trigger your code? Do I need a patched kexec? I want to get some clue by running the code. ================================================================(XEN) ----[ Xen-3.0-unstable x86_64 debug=n Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e038:[<0000000000100119>] ??? (XEN) RFLAGS: 0000000000010202 CONTEXT: hypervisor (XEN) rax: 000000000005003b rbx: ffff830000000000 rcx: 0000000000000e3b (XEN) rdx: ffff830000fec080 rsi: 000000000000000a rdi: ffff8300001edab0 (XEN) rbp: 0000000000000001 rsp: ffff8300001dfe60 r8: 0000000000000002 (XEN) r9: 0000000000000000 r10: 0000000000000001 r11: 0000000000000202 (XEN) r12: 0000000000000001 r13: 000000000000000a r14: 0000000000000008 (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: 00000000000026f0 (XEN) cr3: 0000000000103000 cr2: 0000003276bbd800 (XEN) ds: e010 es: e010 fs: e010 gs: e010 ss: e010 cs: e038 (XEN) Xen stack trace from rsp=ffff8300001dfe60: (XEN) ffff830000138b89 ffffffff80000a2e ffff8300001be080 0000000000000001 (XEN) 0000000001234567 00000000fee1dead 0000000000000008 0000000000000000 (XEN) ffff830000138e13 01ff830000213c98 ffff830000107f9a efff8300001bb180 (XEN) 0000000000000000 ffff88001591be18 ffff830000118270 90ef66fff9e123e8 (XEN) 00000001f9e16be9 0000000100000001 ffff830000fec080 ffff88001591bc18 (XEN) 0000000000004093 0000000000000002 ffff830000fec080 ffff88001591be18 (XEN) ffff830000178102 0000000000000000 0000000000000008 00000000fee1dead (XEN) 0000000001234567 ffff88001591be18 0000000000000000 0000000000000202 (XEN) ffff88001591bd58 0000000000000002 0000000000000000 000000000000001d (XEN) ffffffff802063aa 0000000000000000 ffff88001591be14 0000000000000002 (XEN) 0000010000000000 ffffffff802063aa 000000000000e033 0000000000000202 (XEN) ffff88001591bdf0 000000000000e02b 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 ffff830000fec080 (XEN) Xen call trace: (XEN) [<0000000000100119>] ??? (XEN) [<ffff830000138b89>] machine_teardown+0x79/0x2d0 (XEN) [<ffff830000138e13>] machine_restart+0x13/0x20 (XEN) [<ffff830000107f9a>] domain_shutdown+0x1a/0x70 (XEN) [<ffff830000118270>] do_sched_op+0x100/0x210 (XEN) [<ffff830000178102>] syscall_enter+0x62/0x67 (XEN) (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) GENERAL PROTECTION FAULT (XEN) [error_code=0000] (XEN) **************************************** (XEN) (XEN) Reboot in five seconds... Thanks, -- best rgds, edwin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel