From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48045) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rcdwf-00026N-70 for qemu-devel@nongnu.org; Mon, 19 Dec 2011 09:12:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RcdwZ-0001NW-J6 for qemu-devel@nongnu.org; Mon, 19 Dec 2011 09:12:01 -0500 Received: from goliath.siemens.de ([192.35.17.28]:26646) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcdwZ-0001NB-4B for qemu-devel@nongnu.org; Mon, 19 Dec 2011 09:11:55 -0500 Message-ID: <4EEF461E.8000107@siemens.com> Date: Mon, 19 Dec 2011 15:11:42 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <20111204182541.28487.68163.sendpatchset@oc5400248562.ibm.com> <20111204182622.28487.98656.sendpatchset@oc5400248562.ibm.com> <4EEF432A.3030905@redhat.com> <784A6583-DC7F-4EF7-9F07-AAF11F83AA0C@suse.de> In-Reply-To: <784A6583-DC7F-4EF7-9F07-AAF11F83AA0C@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Raghavendra K T , "kvm@vger.kernel.org" , Marcelo Tosatti , Srivatsa Vaddagiri , "qemu-devel@nongnu.org" , Suzuki Poulose , Avi Kivity On 2011-12-19 15:03, Alexander Graf wrote: > > On 19.12.2011, at 14:59, Avi Kivity wrote: > >> On 12/19/2011 03:54 PM, Alexander Graf wrote: >>> On 04.12.2011, at 19:26, Raghavendra K T wrote: >>> >>>> Extend the KVM Hypervisor to enable KICK_VCPU feature that allows >>>> a vcpu to kick the halted vcpu to continue with execution in PV ticket >>>> spinlock. >>>> >>>> Signed-off-by: Srivatsa Vaddagiri >>>> Signed-off-by: Raghavendra K T >>>> --- >>>> diff --git a/target-i386/kvm.c b/target-i386/kvm.c >>>> index 5bfc21f..69bce21 100644 >>>> --- a/target-i386/kvm.c >>>> +++ b/target-i386/kvm.c >>>> @@ -97,6 +97,7 @@ struct kvm_para_features { >>>> { KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY }, >>>> { KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP }, >>>> { KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF }, >>>> + { KVM_CAP_KICK_VCPU, KVM_FEATURE_KICK_VCPU }, >>> >>> So this is handled in the kernel? Who enables the feature? Is it always on? Why bother with it in user space at all then? >> >> Backwards compatibility > > If we want backwards compatibility, we need more than just a simple feature check, no? Oh, you feed that into CPUID? That's nifty. Ok, so you behave like VMX/SVM do on real hardware - you always expose the functionality but don't list it in CPUID for older user space. Do we want this to be on when providing a compat machine type ("pc-0.12" etc.) to the guest? Then it does need more work (see the dance around kvmclock). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux