From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/30] nVMX: Nested VMX, v9 Date: Mon, 23 May 2011 16:08:00 +0300 Message-ID: <4DDA5C30.10107@redhat.com> References: <1304842511-nyh@il.ibm.com> <4DC7CD81.2070305@redhat.com> <20110511082027.GG19019@redhat.com> <20110512154228.GA7943@fermat.math.technion.ac.il> <20110512155727.GA20193@redhat.com> <20110512163115.GA13138@fermat.math.technion.ac.il> <20110512165157.GC20193@redhat.com> <20110522193239.GA13130@fermat.math.technion.ac.il> <4DDA2E72.8070907@redhat.com> <20110523130226.GC23407@8bytes.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Nadav Har'El" , Gleb Natapov , kvm@vger.kernel.org, abelg@il.ibm.com To: Joerg Roedel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:48689 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752312Ab1EWNIM (ORCPT ); Mon, 23 May 2011 09:08:12 -0400 In-Reply-To: <20110523130226.GC23407@8bytes.org> Sender: kvm-owner@vger.kernel.org List-ID: On 05/23/2011 04:02 PM, Joerg Roedel wrote: > On Mon, May 23, 2011 at 12:52:50PM +0300, Avi Kivity wrote: > > On 05/22/2011 10:32 PM, Nadav Har'El wrote: > >> What do we need to do with this idt-vectoring-information? In regular (non- > >> nested) guests, the answer is simple: On the next entry, we need to inject > >> this event again into the guest, so it can resume the delivery of the > >> same event it was trying to deliver. This is why the nested-unaware code > >> has a vmx_complete_interrupts which basically adds this idt-vectoring-info > >> into KVM's event queue, which on the next entry will be injected similarly > >> to the way virtual interrupts from userspace are injected, and so on. > > > > The other thing we may need to do, is to expose it to userspace in case > > we're live migrating at exactly this point in time. > > About live-migration with nesting, we had discussed the idea of just > doing an VMEXIT(INTR) if the vcpu runs nested and we want to migrate. > The problem was that the hypervisor may not expect an INTR intercept. > > How about doing an implicit VMEXIT in this case and an implicit VMRUN > after the vcpu is migrated? What if there's something in EXIT_INT_INFO? > The nested hypervisor will not see the > vmexit and the vcpu will be in a state where it is safe to migrate. This > should work for nested-vmx too if the guest-state is written back to > guest memory on VMEXIT. Is this the case? It is the case with the current implementation, and we can/should make it so in future implementations, just before exit to userspace. Or at least provide an ABI to sync memory. But I don't see why we shouldn't just migrate all the hidden state (in guest mode flag, svm host paging mode, svm host interrupt state, vmcb address/vmptr, etc.). It's more state, but no thinking is involved, so it's clearly superior. -- error compiling committee.c: too many arguments to function