From: Igor Mammedov <imammedo@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: aliguori@us.ibm.com, ehabkost@redhat.com,
stefano stabellini <stefano.stabellini@eu.citrix.com>,
sw@weilnetz.de, mtosatti@redhat.com, qemu-devel@nongnu.org,
agraf@suse.de, blauwirbel@gmail.com, avi@redhat.com,
jan kiszka <jan.kiszka@siemens.com>,
anthony perard <anthony.perard@citrix.com>,
pbonzini@redhat.com, afaerber@suse.de
Subject: Re: [Qemu-devel] [PATCH qom-next 4/6] pc: move apic_mapped initialization into common apic init code
Date: Thu, 24 May 2012 15:10:49 +0200 [thread overview]
Message-ID: <4FBE3359.6040407@redhat.com> (raw)
In-Reply-To: <CAFEAcA-QgPKrU-sW6gCCTaRhavyPfqVgQptj45=b0PTWzmC=Yw@mail.gmail.com>
On 05/23/2012 11:26 PM, Peter Maydell wrote:
> On 23 May 2012 22:09, Igor Mammedov<imammedo@redhat.com> 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
next prev parent reply other threads:[~2012-05-24 13:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-23 16:39 [Qemu-devel] [PATCH qom-next v2 0/6] target-i386: re-factor CPU creation/initialization to QOM Igor Mammedov
2012-05-23 16:39 ` [Qemu-devel] [PATCH qom-next 1/6] pc: Enable MSI support at APIC level Igor Mammedov
2012-05-23 16:39 ` [Qemu-devel] [PATCH qom-next 2/6] target-i386: move cpu halted decision into x86_cpu_reset Igor Mammedov
2012-05-23 16:39 ` [Qemu-devel] [PATCH qom-next 3/6] target-i386: add cpu-model property to x86_cpu Igor Mammedov
2012-05-23 16:39 ` [Qemu-devel] [PATCH qom-next 4/6] pc: move apic_mapped initialization into common apic init code Igor Mammedov
2012-05-23 16:44 ` Peter Maydell
2012-05-23 20:08 ` Jan Kiszka
2012-05-23 21:09 ` Igor Mammedov
2012-05-23 21:26 ` Peter Maydell
2012-05-24 13:10 ` Igor Mammedov [this message]
2012-05-24 13:21 ` Peter Maydell
2012-05-24 13:25 ` Jan Kiszka
2012-05-24 13:39 ` Igor Mammedov
2012-05-24 13:45 ` Andreas Färber
2012-05-23 16:39 ` [Qemu-devel] [PATCH qom-next 5/6] target-i386: make initialize CPU in QOM way Igor Mammedov
2012-05-23 21:27 ` Andreas Färber
2012-05-24 9:29 ` Igor Mammedov
2012-05-23 16:39 ` [Qemu-devel] [PATCH qom-next 6/6] target-i386: move reset callback to cpu.c Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FBE3359.6040407@redhat.com \
--to=imammedo@redhat.com \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=aliguori@us.ibm.com \
--cc=anthony.perard@citrix.com \
--cc=avi@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=ehabkost@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=sw@weilnetz.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).