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

[Rusty Russell <rusty@xxxxxxxxxxxxxxx>]

"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.

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.
>
> 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