-- On Wed, 8 Aug 2007, Andi Kleen wrote: > > When I said "this part of the code I don't fully understand" I was not > > talking about entry.S. I understand entry.S very well, but the comment > > was originally on the paranoid_restore code. Which I thought had to deal > > with NMIs and such that I didn't worry about that I simply did the > > default. > > The paranoid path is used for more than just NMIs; it's also used for MCEs, > stack faults, double faults or debug exceptions. Anything that might > happen with a invalid stack or unknown GS state or system in other unknown > state. > > If you can guarantee your hypervisor never injects any of those it could be ignored; > but at least losing debug exceptions would be probably not nice. For now it does ignore them. But that's something to work on for later versions of lguest64. I want lguest out in the public and working for the general case. I don't plan on ignoring the paranoid section forever. But it's more on an anomaly for now. But you are right, I want the debug stuff working. But I also need to walk before I can run ;-) > > > > > >> paranoid_restore\trace: > > >> RESTORE_ALL 8 > > >> - iretq > > >> + INTERRUPT_RETURN > > > > > >I suspect Xen will need much more changes anyways because of its > > >ring 3 guest. Are these changes sufficient for lguest? > > This was really a general comment not especially applying to the > paranoid path. Ah, OK, I assumed you were talking about just the previous code. But rereading your post, I see it was more general. Sorry, for the miscommunication. -- Steve _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
