[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Lguest] lguest: unhandled trap 13 and CONFIG_MICROCODE_INTEL_EARLY

On Wed, 2013-05-08 at 20:24 -0700, H. Peter Anvin wrote:
> On 05/08/2013 06:43 PM, Rusty Russell wrote:
> > 
> > OK, that confirms my understanding it's lguest-only.
> > 
> > To return to the immediate proposal: I'd like to expand it KEEP_SEGMENTS
> > to say "don't do any privileged ops before the platform entry point"
> > which is what it used to do (before we added those config options), and
> > still does (if they're disabled).
> > 
> > This fixes lguest for those configs, and if there *are* any other users,
> > this just means they don't support OLPC machines (since 2.6.37) or early
> > microcode (3.9).  OLPC + KEEP_SEGMENTS is vanishingly unlikely (the OLPC
> > bootloader doesn't use it), and early microcode never worked with
> > paravirt anyway (those native_cpuid() calls).
> > 
> > Failing that, second best to remove KEEP_SEGMENTS, and have lguest
> > 'emulate' (ie. skip!) those instructions.  We already do this for in/out
> > instructions, see drivers/lguest/x86/core.c emulate_insn().  More code,
> > but it's lguest code.
> >
> Or we can skip the microcode stuff for platform == 2.

And could the OLPC specific code
    movl %cr3, %eax
    movl %eax, pa(olpc_ofw_pgd)

in head_32.S perhaps be moved to (just before) the enable_paging label?

I don't think anything cares about %cr3 before that, so it won't
interfere with OLPC's  (creative?) use of that register. And
olpc_ofw_pgd seems to be only used much later on, as the call chain
looks something like:

                    early_ioremap(olpc_ofw_pgd, [...]);

That would move those two OLPC specific lines to a point were
pv_mmu_ops.read_cr3 points to lguest_read_cr3() so lguest can handle
them, wouldn't it?

Paul Bolle

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.