From mboxrd@z Thu Jan 1 00:00:00 1970 From: Raghavendra K T Subject: Re: [Qemu-devel] [PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target. Date: Mon, 26 Dec 2011 22:43:56 +0530 Message-ID: <4EF8AB54.8020709@linux.vnet.ibm.com> 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> <4EEF461E.8000107@siemens.com> <4EF87FB9.6060208@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , Raghavendra K T , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , Marcelo Tosatti , Srivatsa Vaddagiri , Alexander Graf , Suzuki Poulose To: Avi Kivity Return-path: Received: from e23smtp07.au.ibm.com ([202.81.31.140]:58116 "EHLO e23smtp07.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750804Ab1LZROF (ORCPT ); Mon, 26 Dec 2011 12:14:05 -0500 Received: from /spool/local by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 26 Dec 2011 17:11:01 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pBQHDwdk5075182 for ; Tue, 27 Dec 2011 04:13:58 +1100 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pBQHDv7N007206 for ; Tue, 27 Dec 2011 04:13:58 +1100 In-Reply-To: <4EF87FB9.6060208@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 12/26/2011 07:37 PM, Avi Kivity wrote: > On 12/19/2011 04:11 PM, Jan Kiszka wrote: >>>> >>>> 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). > > We do. I have a feeling the whole cpuid stuff, paravirt and > non-paravirt, needs some fixing in this area. It's different than the > normal compat code since not only qemu, but also kvm and the host cpu > have a say in what's supported and what's not. > Sorry, missed all threads except this due to some problem with mail client config. Yet to explore on what is to be done, But I Agree for the changes and work needed in this direction.