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. > >>nested VM. We can just #VMEXIT just before migrating with a > >>VMEXIT_INTR intercept. > >> > >We don't notify kernel about migration currently. CPU state is > >migrated > >when VM is already paused, how we can exit nested guest at this point? > > Hm - introduce a new ioctl? I haven't fully thought it through yet :-). > There is not software problem that can't be solved by introducing new ioctl :) -- 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
