From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VW4Mp-0005Lm-8v for qemu-devel@nongnu.org; Tue, 15 Oct 2013 09:09:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VW4Mh-0007BE-TD for qemu-devel@nongnu.org; Tue, 15 Oct 2013 09:08:55 -0400 Received: from cantor2.suse.de ([195.135.220.15]:45876 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VW4Mh-0007B8-NL for qemu-devel@nongnu.org; Tue, 15 Oct 2013 09:08:47 -0400 Message-ID: <525D3E5C.1080007@suse.de> Date: Tue, 15 Oct 2013 15:08:44 +0200 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1381416174-5110-1-git-send-email-armbru@redhat.com> <878uxuiux3.fsf@blackfin.pond.sub.org> In-Reply-To: <878uxuiux3.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Why is TYPE_CPU no-user? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Peter Maydell , qemu-devel@nongnu.org Hi Markus, Am 15.10.2013 14:24, schrieb Markus Armbruster: > To go beyond RFC with this series, I need to explain why TYPE_CPU > cannot_instantiate_with_device_add_yet. Would you be so kind and help > me out with a suitable comment? >>From what I remember this was done when I started the whole process and most CPU subtypes did not yet use the QOM instance_init for initialization. Most importantly x86 still is not yet self-contained, nor is sparc. Such targets need to use cpu_init() et al. rather than -device. (This became visible in the first s390x vCPU hotplug series.) Most boards rely on being able to do postprocessing after they have instantiated the CPU: wiring up IRQs, adding reset handlers, halting non-first CPUs, ... -device would skip that. Another aspect is that no CPU subtype has been proven hot-pluggable with device_add yet. For s390x we're the closest to date. We could move the flag from the base type to the targets' base types if you prefer. Then we can knock the bad values out one by one rather than overriding the inherited value with an explicit positive one. Cheers, Andreas >=20 > You can find examples in PATCH 2-7/9. >=20 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg