From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0 of 3] RFC: creating a particular vcpu type Date: Mon, 11 Feb 2008 10:23:06 +0200 Message-ID: <47B005EA.5000108@qumranet.com> References: <47A89285.40802@us.ibm.com> <1202234014.26953.25.camel@basalt> <47A8A582.5060502@us.ibm.com> <1202239399.26953.42.camel@basalt> <47A8B9C4.3010709@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel@lists.sourceforge.net, kvm-ppc-devel@lists.sourceforge.net, Hollis Blanchard To: Anthony Liguori Return-path: In-Reply-To: <47A8B9C4.3010709@us.ibm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org Anthony Liguori wrote: > > So the new ioctl() has the extra data and the old ioctl() is just a > compat interface which calls the new ioctl with a NULL extra data. I > think this is the better approach if you're going this route. > > However, I still don't think that supporting asymmetric cores is > really useful at the moment and that introducing a per-vm arch ioctl > would be the best approach. Note that kvm/x86 supports slightly asymmetric cores, in that the cpuid results can be different for different vcpus. I can't judge how important this feature is for ppc, though. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/