On Tue, Oct 20, 2009 at 09:13:02AM -0200, Marcelo Tosatti wrote: > On Tue, Oct 20, 2009 at 06:14:04PM +0900, Avi Kivity wrote: > > On 10/20/2009 06:08 PM, Gleb Natapov wrote: > >> On Tue, Oct 20, 2009 at 06:06:36PM +0900, Avi Kivity wrote: > >> > >>> On 10/20/2009 05:56 PM, Jan Kiszka wrote: > >>> > >>>> So save/restore kvm_vcpu_arch::exception? As another substate or as part > >>>> of a generalized NMI substate? > >>>> > >>> Yes. It's not part of an nmi substate, but both can be part of an > >>> exception substate (but need to look at the docs vewy cawefuwy to > >>> make sure we don't screw up again). > >>> > >>> > >> What do you mean? How they can be both part of exception substate? > >> > >> > > > > Sorry, nomenclature failure. We need NMI state, Interrupt state > > (already provided), and pending exception state (which can be a fault or > > a trap). There's also some extra state associated with pending debug > > exceptions (maybe we can copy it into dr6). > > KVM_REQ_TRIPLE_FAULT can also be lost, but i don't think anybody cares? > If pending exception will be migrated KVM_REQ_TRIPLE_FAULT will be restored after guest will try to re-execute instruction that caused it. One more reason to migrate pending exceptions. And why not migrate KVM_REQ_TRIPLE_FAULT while we are at it. > > > > We can either put all of these into one substate, or into separate > > substates. I'm not sure which is best. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html