From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNjeT-00049M-EE for qemu-devel@nongnu.org; Thu, 04 Apr 2013 08:52:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNjeM-00074o-UX for qemu-devel@nongnu.org; Thu, 04 Apr 2013 08:52:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62048) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNjeM-00074T-Lt for qemu-devel@nongnu.org; Thu, 04 Apr 2013 08:52:18 -0400 Date: Thu, 4 Apr 2013 14:52:01 +0200 From: Igor Mammedov Message-ID: <20130404145201.16b4f2ad@thinkpad.mammed.net> In-Reply-To: <515D5FBE.4040608@suse.de> References: <1363876125-8264-1-git-send-email-imammedo@redhat.com> <1363876125-8264-8-git-send-email-imammedo@redhat.com> <20130328115501.51ff4ee6@thinkpad.mammed.net> <515D5FBE.4040608@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 07/12] target-i386: Add ICC_BUS and attach apic, kvmvapic and cpu to it List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?UTF-8?B?RsOkcmJlcg==?= Cc: kwolf@redhat.com, peter.maydell@linaro.org, aliguori@us.ibm.com, yang.z.zhang@intel.com, ehabkost@redhat.com, mst@redhat.com, jan.kiszka@siemens.com, stefano.stabellini@eu.citrix.com, claudio.fontana@huawei.com, qemu-devel@nongnu.org, aderumier@odiso.com, armbru@redhat.com, blauwirbel@gmail.com, quintela@redhat.com, alex.williamson@redhat.com, kraxel@redhat.com, anthony.perard@citrix.com, pbonzini@redhat.com, lcapitulino@redhat.com, rth@twiddle.net On Thu, 04 Apr 2013 13:10:54 +0200 Andreas F=C3=A4rber wrote: > Am 28.03.2013 11:55, schrieb Igor Mammedov: > > On Wed, 27 Mar 2013 11:57:53 +0100 > > Paolo Bonzini wrote: > >=20 > >> Il 21/03/2013 15:28, Igor Mammedov ha scritto: =20 > >>> +static BusState *icc_bus; > >>> + > >>> +BusState *get_icc_bus(void) > >>> +{ > >>> + if (icc_bus =3D=3D NULL) { > >>> + icc_bus =3D g_malloc0(icc_bus_info.instance_size); > >>> + qbus_create_inplace(icc_bus, TYPE_ICC_BUS, NULL, "icc-bus"); > >>> + icc_bus->allow_hotplug =3D 1; > >>> + OBJECT(icc_bus)->free =3D g_free; =20 > >> > >> You can just use qbus_create. > >> =20 > >>> + object_property_add_child(container_get(qdev_get_machine(), > >>> + "/unattached"), =20 > >> > >> Please put it straight under /machine, not /unattached. =20 > >=20 > > sure > >=20 > >> > >> But actually, you lack a device that instantiates the bus. That device > >> would be a simple container device similar hw/a15mpcore.c, and would = =20 > >=20 > > About a year ago something like that device was proposed "cpu_sockets",= but > > there was suggestion to drop it: > > http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg02157.html > > So I've opted in favor of parent-less bus, but I could create it > > explicitly at board level as you suggest. > >=20 > > However having parent sysbus device for icc-bus will allow to see it via > > monitor info qtree >=20 > As I said on IRC, info qtree should not influence our design decisions. > All that's missing is a convenient script that pretty-prints the output > from the QOM graph using qom-list and qom-get in a non-interactive way. > Whether CPUs or busses are shown in info qtree is totally irrelevant IMO > by now. >=20 > > and reset on SysBus could be propagated through it as well, > > it may be good to add it later. >=20 > What exactly is this ICC bus needed for? Is it just a workaround for > qdev_init() or something making assumptions about busses and falling > back to SysBus otherwise? Or about avoiding SysBus? SysBus doesn't allow hotplug on it, I've asked Anthony on IRC and short ans= wer was do not touch what doesn't exists. Hence hotplug-able bus that exists on real hw. x86 hw had ICC bus some time ago through which APICs, IOAPICs and CPUs communicated. So here it is. More close to the code: - device_add assigns SysBus to any bus-less device, therefore CPU hits assertion because hotplug is not allowed on bus. - when x86 CPU is realizing, it creates APIC and possible kvmvapic, which = are SysBus devices presently, it triggers the same assert as above. >=20 > And where would it sit if be hosted you think of something like Qseven > modules - on the board or on the module? I don't see pc.c being touched > here at all... I've reworked it quite a bit to Paolo's suggestions. now board creates following QOM tree: /machine/icc-bridge/--->child/->link | | =20 | ->link | | | ->linklink ->child where icc-bridge is created by board and serves as a parent, which creates icc-bus, ioapic and takes care about mapping memory regions registered by *apic* devices. > >=20 > Andreas >=20 > --=20 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3= =BCrnberg --=20 Regards, Igor