On Tue, Oct 20, 2009 at 08:59:48PM +0200, Alexander Graf wrote: > > On 20.10.2009, at 20:55, Gleb Natapov wrote: > > >On Tue, Oct 20, 2009 at 03:51:02PM +0200, Alexander Graf wrote: > >> > >>On 20.10.2009, at 15:48, Gleb Natapov wrote: > >> > >>>On Tue, Oct 20, 2009 at 03:41:57PM +0200, Alexander Graf wrote: > >>>> > >>>>On 20.10.2009, at 15:37, Jan Kiszka wrote: > >>>> > >>>>>Alexander Graf wrote: > >>>>>>On 20.10.2009, at 15:01, Jan Kiszka wrote: > >>>>>> > >>>>>>>Hi all, > >>>>>>> > >>>>>>>as the list of yet user-unaccessible x86 states is a bit > >>>>>>>volatile ATM, > >>>>>>>this is an attempt to collect the precise requirements for > >>>>>>>additional > >>>>>>>state fields. Once everyone feels the list is complete, we can > >>>>>>>decide > >>>>>>>how to partition it into one ore more substates for the new > >>>>>>>KVM_GET/SET_VCPU_STATE interface. > >>>>>>> > >>>>>>>What I read so far (or tried to patch already): > >>>>>>> > >>>>>>>- nmi_masked > >>>>>>>- nmi_pending > >>>>>>>- nmi_injected > >>>>>>>- kvm_queued_exception (whole struct content) > >>>>>>>- KVM_REQ_TRIPLE_FAULT (from vcpu.requests) > >>>>>>> > >>>>>>>Unclear points (for me) from the last discussion: > >>>>>>> > >>>>>>>- sipi_vector > >>>>>>>- MCE (covered via kvm_queued_exception, or does it > >>>>>>>require more?) > >>>>>>> > >>>>>>>Please extend or correct the list as required. > >>>>>> > >>>>>>hflags. Qemu supports GIF, kvm supports GIF, but no side > >>>>>>knows how to > >>>>>>sync it. > >>>>> > >>>>>BTW, GIF is related to svm nesting, right? > >>>> > >>>>Yes and no. It's an architecture addition that came with SVM, yes. > >>>> > >>>>The problem is that I don't want to support migrating while in a > >>>Why not? > >> > >>Because then we'd have to transfer the whole host cpu cache and the > >>merged intercept bitmaps to userspace as well. That's just too many > >>internals to expose IMHO. > >> > >But the amount of information is constant no matter how l2 guest there > >are. Correct? We can expose it as separate substate. > > Or we can just not migrate while in a nested guest :-). Which will > make everything a lot easier. > Suppose we have a l2 guest that handles interrupt/nmis by itself how can we force it to exit? I don't think requesting certain cpu state before migration is the right thing to do. What if user paused a VM and then decided to migrate? Or VM was paused automatically because of shortage of disk space and management want to migrate VM to other host with bigger disk? -- 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
