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? > 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? > Now just after #VMEXIT we're in a state that's pure host context, > but has GIF=0. So we need to know about that in userspace to support > migration. > > Alex -- 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
