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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, May 07, 2013 at 02:48:15PM +0930, Rusty Russell wrote:
> "H. Peter Anvin" <hpa@xxxxxxxxx> writes:
> > On 05/05/2013 09:22 PM, Rusty Russell wrote:
> >> 
> >> HPA, how about we extend the KEEP_SEGMENTS flag to mean "don't touch
> >> privileged registers" in general?  That's what it used to do when it
> >> was introduced, and AFAIK only lguest uses it.  Xen folk CC'd.
> >> 
> >
> > KEEP_SEGMENTS was introduced at the request of Xen, not lguest.  I'm a
> > bit concerned about extending it as I don't know what else might end up
> > being affected.
> 
> Not sure if they ever used it, or if they still have their own entry
> point.

I don't ever recall it being used. But git commit 
bd53147db8bdf5dd49025c198ff18ac23f560e0e
says

    Both x86 and x86_64 support the same boot protocol so we need
    to implement the KEEP_SEGMENTS on x86_64 as well.  It isn't
    just paravirt bootloaders that could use this functionality.

And a quick Google search tells me:
http://lkml.indiana.edu/hypermail/linux/kernel/1102.0/01422.html

I think the only potential user is whatever Eric Biederman thought off?

> 
> All this stuff (OLPC and early microcode) probably belongs after we jump
> to the platform handler: the microcode calls to native_cpuid() is a clue
> that we're doing something *badly* wrong.
> 
> It's easy enough for lguest to decode and skip the unsupported
> instructions, though I've preferred not to do that.
> 
> > On that subject, I would genuinely like to have a discussion of the
> > value vs. pain of continuing to support lguest.  It has not been a
> > *huge* problem, especially not compared to Xen, but core
> > paravirtualization has turned out to be a maintenance nightmare and it
> > has had an enormous negative impact on development work.

<scratches his head>

I think this kind of discussion is best done face-to-face b/c people can
become emotional and then this discussion turns in the craper.

If I am reading you right the #1 issue is that you don't know whether
a certain paravirt instruction has any side-effects and as such you don't
feel that you can treat it like an equivalent instruction that is defined
in the Intel SDM?

And that means that any development work you have in the pipeline is
affected because you don't have the documentation on hand and are unsure
whether you will break something?

> >
> > That being said, lguest really hasn't been a huge problem, but partly it
> > is a "level of support" thing...
> 
> Yeah, I always figured when paravirt_ops goes, lguest goes.  By that
> stage, every reasonable piece of hardware should have VT support, so if
> lguest really wants to continue it can switch to that.  Which makes it
> look a lot like bhyve, I guess.
> 
> What's *really* weird is that there's been a burst of lguest activity in
> the last couple of months.  Someone's even reviving lguest64.  So maybe
> it's not dead yet.
> 
> Cheers,
> Rusty.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel