From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V21jf-0000N2-Sw for qemu-devel@nongnu.org; Wed, 24 Jul 2013 12:16:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V21jc-0008Fv-V2 for qemu-devel@nongnu.org; Wed, 24 Jul 2013 12:16:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V21jc-0008Fp-Nr for qemu-devel@nongnu.org; Wed, 24 Jul 2013 12:16:16 -0400 Date: Wed, 24 Jul 2013 19:17:27 +0300 From: "Michael S. Tsirkin" Message-ID: <20130724161727.GA17743@redhat.com> 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> <51EFEA15.1090700@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <51EFEA15.1090700@suse.de> 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: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: Anthony Liguori , seabios@seabios.org, Gerd Hoffmann , Aurelien Jarno , qemu-devel@nongnu.org On Wed, Jul 24, 2013 at 04:52:05PM +0200, Andreas F=E4rber wrote: > Hi Gerd, >=20 > Am 24.07.2013 16:42, schrieb Gerd Hoffmann: > >>> This does not satisfy the "should use QOM properties" requirement t= hat > >>> 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 ro= utine > >> and not hard coding it. For instance, the PCI interrupt assignment= s, > >> 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 A= CPI > >> 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 stu= ff > > config info into GuestInfo you should (1) search the device object tr= ee > > for a pvpanic device and (b) if present read the ioport property to > > figure the base address. >=20 > Yeah, the above does not feel so nice from a QOM view (didn't review th= e > ACPI series yet). If you do please review v3 which was just posted. It should address your comment - though long term, it would be nicer if we had multiple inheritance for interfaces, then we could expose a generic panic interface with the io port number, avoid need to poke at specific device. > > /me suggests to check out qmp_qom_get() in qmp.c. Some qom aequivale= nt > > for qdev_find_recursive would be handy, dunno whenever such a thing > > exists already, Andreas? >=20 > Not sure what's needed here? object_resolve_path() and > object_foreach_child() come to mind... >=20 > Regards, > Andreas >=20 > > I'd tend to accept GuestInfo as temporary thing for stuff which can't= be > > figured using qom properties today. Anthony might disagree though. > >=20 > > cheers, > > Gerd > >=20 >=20 >=20 > --=20 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrn= berg