From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXXoq-0001kp-B7 for qemu-devel@nongnu.org; Thu, 24 May 2012 09:11:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXXoj-0004FO-Jd for qemu-devel@nongnu.org; Thu, 24 May 2012 09:11:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57333) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXXoj-0004Ct-C0 for qemu-devel@nongnu.org; Thu, 24 May 2012 09:11:01 -0400 Message-ID: <4FBE3359.6040407@redhat.com> Date: Thu, 24 May 2012 15:10:49 +0200 From: Igor Mammedov MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH qom-next 4/6] pc: move apic_mapped initialization into common apic init code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: aliguori@us.ibm.com, ehabkost@redhat.com, stefano stabellini , sw@weilnetz.de, mtosatti@redhat.com, qemu-devel@nongnu.org, agraf@suse.de, blauwirbel@gmail.com, avi@redhat.com, jan kiszka , anthony perard , pbonzini@redhat.com, afaerber@suse.de On 05/23/2012 11:26 PM, Peter Maydell wrote: > On 23 May 2012 22:09, Igor Mammedov wrote: >> For cpu-hotplug it was suggested to use device_add/del >> interface for it. To do so in a generalized way hot-plugged cpu >> should follow general QOM object creation sequence, i.e. >> - create new cpu instance >> - set properties >> - realize instance >> without creating precedent of special case for cpus in device_add/del >> if possible. So goal is to have a self-sufficient cpu object that >> doesn't require external hooks to create/initialize it. It looks >> possible do so for target-i386 at least. > > I think your self-sufficient CPU object should probably be a > container QOM object which contains the CPU core itself and > the APIC device. Then the container object's initialisation > can map the APIC device. For x86 it would be artificial thing without a real hardware to model after, that would needlessly complicate code and interface. I'd rather avoid this. Meanwhile I've found only two devices that do mapping inside device's initfn :( hw/lm32_sys.c hw/bonito.c and lm32_sys has comment: /* Note: This device is not created in the board initialization, * instead it has to be added with the -device parameter. Therefore, * the device maps itself. */ So for some devices it's possible to do so. And since APIC after power-on/reset should have it's regs mapped at initial APIC base, APIC's initfn looks like a legitimate place to do it. However if you are strongly opposed to this idea, I'll try Jan's idea to put mapping into CPU code that creates APIC instance. It would be uglier than if mapping were in APIC itself, but at least it could be justified by fact that Integrated APIC is a part of cpu and manuals don't specify which of them is responsible for setting mapping (mapping just exists after cpu power-on/reset). -- ----- Thanks, Igor