From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wright Subject: Re: thread/core siblings info for guests Date: Mon, 6 Oct 2008 13:54:10 -0700 Message-ID: <20081006205410.GA17755@sequoia.sous-sol.org> References: <8EA2C2C4116BF44AB370468FBF85A7779B418DEF@orsmsx504.amr.corp.intel.com> <48E88C62.9030103@redhat.com> <8EA2C2C4116BF44AB370468FBF85A7779B61A9B8@orsmsx504.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , "kvm@vger.kernel.org" To: "Kamble, Nitin A" Return-path: Received: from sous-sol.org ([216.99.217.87]:42111 "EHLO sequoia.sous-sol.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753109AbYJFUzH (ORCPT ); Mon, 6 Oct 2008 16:55:07 -0400 Content-Disposition: inline In-Reply-To: <8EA2C2C4116BF44AB370468FBF85A7779B61A9B8@orsmsx504.amr.corp.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: * Kamble, Nitin A (nitin.a.kamble@intel.com) wrote: > >From: Avi Kivity [mailto:avi@redhat.com] > >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 > Avi, > Would you like to elaborate more on these three mode's usage scenario? > > As I see, there are 2 things to look for while providing the cpuid to the guest. > 1. Guest migration across different hosts. This limits exposed cpu features. This falls under managed above, as it's smth the mgmt app knows (e.g. what's the least common denominator in your migration pool?). > 2. Utilizing host CPU features. This expands exposed cpu features. This falls under host above. And the default mode above is just about picking a sane default. thanks, -chris