From: Ian Campbell <Ian.Campbell@XenSource.com>
To: "Zhai, Edwin" <edwin.zhai@intel.com>
Cc: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>, xen-devel@lists.xensource.com
Subject: Re: switch out of 32e mode issue
Date: Tue, 03 Jul 2007 10:09:17 +0100 [thread overview]
Message-ID: <1183453757.30635.98.camel@localhost.localdomain> (raw)
In-Reply-To: <20070703065148.GD20797@edwin-srv.sh.intel.com>
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.
> "[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.
next prev parent reply other threads:[~2007-07-03 9:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-03 6:51 switch out of 32e mode issue Zhai, Edwin
2007-07-03 8:57 ` Keir Fraser
2007-07-03 9:32 ` Zhai, Edwin
2007-07-03 9:09 ` Ian Campbell [this message]
2007-07-03 9:48 ` Zhai, Edwin
2007-07-03 9:18 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1183453757.30635.98.camel@localhost.localdomain \
--to=ian.campbell@xensource.com \
--cc=edwin.zhai@intel.com \
--cc=m+Ian.Pratt@cl.cam.ac.uk \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.