On Tue, Oct 20, 2009 at 09:23:22PM +0200, Alexander Graf wrote: > > On 20.10.2009, at 21:09, Gleb Natapov wrote: > > >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? > > If the nested hypervisor doesn't intercept INTR we don't support it > anyways. > Why? I looked at the code briefly and it looks like we just inject interrupt as usual instead of do nested exit if l2 does not intercept INTR. Have I miss interpreted the code. Even if I have why not support it? > >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? > > So pausing has to make it go out of nested guest context too? Probably. > Then we're not in the nested guest context, right? :) > > >Or VM was paused automatically because of shortage > >of disk space and management want to migrate VM to other host with > >bigger disk? > > Same as before. What do you mean? > > > Really, pushing the whole nesting state over is not a good idea. > May be just disallow migration with nested guest running then? Cross vendor migration is not possible anyway. -- 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
