From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V20QG-0006pH-E0 for qemu-devel@nongnu.org; Wed, 24 Jul 2013 10:52:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V20QF-0002kd-4W for qemu-devel@nongnu.org; Wed, 24 Jul 2013 10:52:12 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33375 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V20QE-0002kO-Rh for qemu-devel@nongnu.org; Wed, 24 Jul 2013 10:52:11 -0400 Message-ID: <51EFEA15.1090700@suse.de> Date: Wed, 24 Jul 2013 16:52:05 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1373307914-18543-1-git-send-email-mst@redhat.com> <1373307914-18543-4-git-send-email-mst@redhat.com> <87fvvo3m2c.fsf@codemonkey.ws> <20130708195259.GA19775@redhat.com> <51EFE7C0.5060202@redhat.com> In-Reply-To: <51EFE7C0.5060202@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [SeaBIOS] [PATCH v2 3/4] i386: generate pc guest info List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Anthony Liguori , seabios@seabios.org, qemu-devel@nongnu.org, Aurelien Jarno , "Michael S. Tsirkin" Hi Gerd, Am 24.07.2013 16:42, schrieb Gerd Hoffmann: >>> This does not satisfy the "should use QOM properties" requirement tha= t >>> we discussed in the RFC thread. >> >> I don't know which part of the RFC thread still applied and >> which doesn't: at that point you were rejecting the whole >> approach. >> >> I found a mail where you said: >> I'd be a lot happier if we were passing more information to this rout= ine >> and not hard coding it. For instance, the PCI interrupt assignments, >> the APIC ids, the number of available CPUs, etc. >> >> So this is exactly what this code does. >> What, exactly, would you like to see instead? >> Create a guest info QOM object, and encode all information used by ACP= I >> generation as properties of this object? >=20 > Don't touch device code for this. >=20 >>>> -void pvpanic_init(ISABus *bus) >>>> +void pvpanic_init(ISABus *bus, PcGuestInfo *guest_info) >>>> { >>>> ISADevice *dev; >>>> - FWCfgState *fw_cfg =3D fw_cfg_find(); >>>> + FWCfgState *fw_cfg =3D guest_info->fw_cfg; >>>> if (!fw_cfg) { >>>> return; >>>> } >>>> dev =3D isa_create_simple (bus, TYPE_ISA_PVPANIC_DEVICE); >>>> - pvpanic_fw_cfg(dev, fw_cfg); >>>> + pvpanic_guest_info(dev, guest_info); >>>> } >=20 > To pick this one as example: Instead of patching pvpanic code to stuff > config info into GuestInfo you should (1) search the device object tree > for a pvpanic device and (b) if present read the ioport property to > figure the base address. Yeah, the above does not feel so nice from a QOM view (didn't review the ACPI series yet). > /me suggests to check out qmp_qom_get() in qmp.c. Some qom aequivalent > for qdev_find_recursive would be handy, dunno whenever such a thing > exists already, Andreas? Not sure what's needed here? object_resolve_path() and object_foreach_child() come to mind... Regards, Andreas > I'd tend to accept GuestInfo as temporary thing for stuff which can't b= e > figured using qom properties today. Anthony might disagree though. >=20 > cheers, > Gerd >=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