From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50520) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QUjED-0005Ml-6g for qemu-devel@nongnu.org; Thu, 09 Jun 2011 13:41:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QUjEB-0008Ec-Nc for qemu-devel@nongnu.org; Thu, 09 Jun 2011 13:41:08 -0400 Received: from david.siemens.de ([192.35.17.14]:19382) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QUjEB-0008E5-6a for qemu-devel@nongnu.org; Thu, 09 Jun 2011 13:41:07 -0400 Message-ID: <4DF105AF.5010404@siemens.com> Date: Thu, 09 Jun 2011 19:41:03 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <3c5277ff7e8ba99b17755e52e2d855a01dcefb87.1307542247.git.jan.kiszka@siemens.com> <20110609173317.GA5970@otherpad.lan.raisama.net> In-Reply-To: <20110609173317.GA5970@otherpad.lan.raisama.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 11/12] kvm: x86: Pass KVMState to kvm_arch_get_supported_cpuid List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity , Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org On 2011-06-09 19:33, Eduardo Habkost wrote: > On Wed, Jun 08, 2011 at 04:11:05PM +0200, Jan Kiszka wrote: >> kvm_arch_get_supported_cpuid checks for global cpuid restrictions, it >> does not require any CPUState reference. Changing its interface allows >> to call it before any VCPU is initialized. > > I'm wondering if it wouldn't be simpler to keep the existing interface > but just initialize CPUState->kvm_state earlier (today it is initialized > only on kvm_init_vcpu(), although the kvm_state global is initialized > much earlier). If there was more need for a slit up, I would agree. But I do not see it. > > Even with this new KVMState-based interface, code that needs to use > these functions before kvm_init_vcpu() (e.g. > check_features_against_host()) will have to use the 'kvm_state' global > (and I would like to avoid that). That is a different topic that needs to be resolved for other use cases as well (e.g. for kvm devices). In many cases you should be able to find a way to pass kvm_state from functions that already holds a reference. Is that not true for your use case? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux