From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57825) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ry3uG-0000Kt-Fl for qemu-devel@nongnu.org; Thu, 16 Feb 2012 11:10:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ry3uA-00025k-Jt for qemu-devel@nongnu.org; Thu, 16 Feb 2012 11:10:04 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:44264) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ry3uA-00025g-Cg for qemu-devel@nongnu.org; Thu, 16 Feb 2012 11:09:58 -0500 Received: by pbbro12 with SMTP id ro12so3232310pbb.4 for ; Thu, 16 Feb 2012 08:09:57 -0800 (PST) Message-ID: <4F3D2A51.1010107@codemonkey.ws> Date: Thu, 16 Feb 2012 10:09:53 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1329347774-23262-1-git-send-email-imammedo@redhat.com> <1329347774-23262-3-git-send-email-imammedo@redhat.com> <4F3CF010.1040607@siemens.com> <4F3CFBBB.5020600@codemonkey.ws> <4F3CFC85.9080706@siemens.com> In-Reply-To: <4F3CFC85.9080706@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/7] Convert pc cpu to qdev List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Igor Mammedov , "qemu-devel@nongnu.org" , "gleb@redhat.com" On 02/16/2012 06:54 AM, Jan Kiszka wrote: > On 2012-02-16 13:51, Anthony Liguori wrote: >> On 02/16/2012 06:01 AM, Jan Kiszka wrote: >>> On 2012-02-16 00:16, Igor Mammedov wrote: >>>> +static ICCBusDeviceInfo cpu_device_info = { >>>> + .qdev.name = "cpu-pc", >>>> + .qdev.size = sizeof(CPUPC), >>>> + .qdev.reset = cpu_device_reset, >>>> + .init = cpu_device_init, >>>> + .qdev.props = (Property[]) { >>>> + DEFINE_PROP_STRING("model", CPUPC, model), >>> >>> And how do you pass in feature flags? Or the core layout? Basically both >>> -cpu and -smp need to be expressible via multiple "-device cpu-x86,xxx" >>> (not "pc") commands. >> >> The approach that I'd recommend is: >> >> 1) convert CPU_COMMON_STATE to a structure named CPUCommonState, query/replace >> all references to members of CPU_COMMON_STATE appropriately. >> >> 2) convert as many users of CPUState to CPUCommonState as possible. >> >> 3) make CPUCommonState a base class, move it to the front of the structure, and >> attempt to measure the impact to TCG. >> >> 4) if (3) is significant, special case things in QOM >> >> 5) make target specific code use target specific CPUState typename >> >> 6) eliminate #define CPUState >> >> 7) make on-processor devices (like lapic) children of target specific CPUState >> >> 8) express target specific flags/features via QOM properties >> >> 9) make machine expose target specific CPUState links that can be set by the user. > > Also, I'm wondering what names those CPUs should have. I think we should > expose model names as device names and avoid a "model" property. Yeah, I think we want a CPUX86State and then a bunch of subclasses defined by that. By making use of the class_data field, we can register classes based on combinations of feature flags. So for instance: static TypeInfo opteron_g2 = { .name = "cpu-opteron-g2", .parent = TYPE_CPU_X86", .class_init = cpu_x86_generic_class_init, .class_data = (CPUX86Definition[]){ .level = 5, .vendor = "AuthenticAMD", .family = 15, .model = 6, .stepping = 1, .feature_edx = "sse2 sse fxsr mmx pat cmov pge sep apic cx8 mce pae msr tsc pse de fpu mtrr clflush mca pse36", ... }, }; And obviously, we can still using the existing cpudef directive to generate types. Regards, Anthony Liguori > > Jan >