From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJpRR-00047U-Bv for qemu-devel@nongnu.org; Thu, 04 Oct 2012 13:42:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJpRM-0004sA-Fn for qemu-devel@nongnu.org; Thu, 04 Oct 2012 13:42:33 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:54118) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJpRM-0004ry-B4 for qemu-devel@nongnu.org; Thu, 04 Oct 2012 13:42:28 -0400 Received: by mail-ob0-f173.google.com with SMTP id wc18so703783obb.4 for ; Thu, 04 Oct 2012 10:42:27 -0700 (PDT) From: Anthony Liguori In-Reply-To: <20121004160336.GC15784@otherpad.lan.raisama.net> References: <1349270954-4657-1-git-send-email-ehabkost@redhat.com> <1349270954-4657-2-git-send-email-ehabkost@redhat.com> <877gr6jqnt.fsf@codemonkey.ws> <506D940D.7080600@redhat.com> <87fw5uxqf6.fsf@codemonkey.ws> <20121004144359.GA15784@otherpad.lan.raisama.net> <87y5jmz31j.fsf@codemonkey.ws> <20121004160336.GC15784@otherpad.lan.raisama.net> Date: Thu, 04 Oct 2012 12:42:23 -0500 Message-ID: <878vbmjfr4.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Paolo Bonzini , Gleb Natapov , qemu-devel@nongnu.org, Andreas =?utf-8?Q?F=C3=A4rber?= , Igor Mammedov Eduardo Habkost writes: > On Thu, Oct 04, 2012 at 10:10:16AM -0500, Anthony Liguori wrote: >> Eduardo Habkost writes: >> >> > On Thu, Oct 04, 2012 at 09:28:13AM -0500, Anthony Liguori wrote: >> >> Paolo Bonzini writes: >> >> >> >> > Il 04/10/2012 15:46, Anthony Liguori ha scritto: >> >> >>> > +typedef struct PC { >> >> >>> > + DeviceState parent_obj; >> >> >>> > +} PC; >> >> >> So the general problem with this approach is that it strays from >> >> >> modeling hardware. >> >> > >> >> > It doesn't really; it's a motherboard object, there's no reason why >> >> > /machine shouldn't be a Device itself, with a few objects (CPUs, the >> >> > i440FX, the IOAPIC, and of course the peripherals) hanging off it. >> >> >> >> Okay, but modeling a motherboard is different than creating a "PC" >> >> object and throwing in the kitchen skink. >> >> >> >> And I'm not sure that going top-down is the best strategy. I think >> >> going bottom up makes more sense (starting with modeling Super IO chip). >> >> >> > >> > So, would you be OK with this implementation if the class were named >> > "Motherboard", "set-of-CPU-sockets", or something like that? >> >> I would, but you're mixing up modeling with bug fixing. >> >> There's a very easy way to achieve your goal without dramatic >> remodeling. >> >> Just assign APIC ids during CPU creation and make contiguous_apic_ids a >> parameter of pc_init1. >> >> You don't need to worry about CPU hotplug. It doesn't exist in qemu.git >> and is broken in qemu-kvm.git. > > With or without CPU hotplug, the max_cpus variable already exists, and I > want to avoid breaking code that's already using it, and adding Yet > Another problem to be fixed by whoever is going to make CPU hotplug > work. Sorry, what does max_cpus have to do with apic ids?? Regards, Anthony Liguori > > -- > Eduardo