From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: thread/core siblings info for guests Date: Sun, 05 Oct 2008 11:44:02 +0200 Message-ID: <48E88C62.9030103@redhat.com> References: <8EA2C2C4116BF44AB370468FBF85A7779B418DEF@orsmsx504.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org" To: "Kamble, Nitin A" Return-path: Received: from mx2.redhat.com ([66.187.237.31]:59590 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752872AbYJEJoF (ORCPT ); Sun, 5 Oct 2008 05:44:05 -0400 In-Reply-To: <8EA2C2C4116BF44AB370468FBF85A7779B418DEF@orsmsx504.amr.corp.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: Kamble, Nitin A wrote: > Avi, > There are some OSes like windows server which impose licensing restriction on number of cpus. These licensing restrictions are based on number of packages/sockets. And look into the cupid data to decide which cpus are thread siblings, core siblings and packages siblings. With current KVM/Qemu implementation it is hiding all this cupid information from the guests. So guest sees each cpu as a single package. And the license restrictions inside the OS is limiting no of cpus the guest can run. > These cupid bits should be exposed to the guest so that the OS would see the thread or core sibling information correctly to utilize more cpus. > > Is anybody is working on this? > Not that I know of. Indeed finer control over cpuid is needed. We need to support at least three modes: - default: expose some machine that is likely to be widely supported - host: expose as much of the host cpu as we can - managed: management application controls everything -- error compiling committee.c: too many arguments to function