From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:59907)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1V20yh-0002Au-V3
	for qemu-devel@nongnu.org; Wed, 24 Jul 2013 11:27:50 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1V20yb-0007Mk-GY
	for qemu-devel@nongnu.org; Wed, 24 Jul 2013 11:27:47 -0400
Received: from mx1.redhat.com ([209.132.183.28]:45459)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1V20yb-0007MY-7I
	for qemu-devel@nongnu.org; Wed, 24 Jul 2013 11:27:41 -0400
Date: Wed, 24 Jul 2013 18:28:49 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20130724152849.GA9754@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <51EFE7C0.5060202@redhat.com>
Subject: Re: [Qemu-devel] [SeaBIOS] [PATCH v2 3/4] i386: generate pc guest
 info
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, seabios@seabios.org, qemu-devel@nongnu.org, Aurelien Jarno <aurelien@aurel32.net>, Andreas =?iso-8859-1?Q?F=E4rber?= <afaerber@suse.de>

On Wed, Jul 24, 2013 at 04:42:08PM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> >> This does not satisfy the "should use QOM properties" requirement that
> >> 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 routine
> > 	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 ACPI
> > generation as properties of this object?
> 
> Don't touch device code for this.
> 
> >>> -void pvpanic_init(ISABus *bus)
> >>> +void pvpanic_init(ISABus *bus, PcGuestInfo *guest_info)
> >>>  {
> >>>      ISADevice *dev;
> >>> -    FWCfgState *fw_cfg = fw_cfg_find();
> >>> +    FWCfgState *fw_cfg = guest_info->fw_cfg;
> >>>      if (!fw_cfg) {
> >>>          return;
> >>>      }
> >>>      dev = isa_create_simple (bus, TYPE_ISA_PVPANIC_DEVICE);
> >>> -    pvpanic_fw_cfg(dev, fw_cfg);
> >>> +    pvpanic_guest_info(dev, guest_info);
> >>>  }
> 
> 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.
> 
> /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?
> 
> I'd tend to accept GuestInfo as temporary thing for stuff which can't be
> figured using qom properties today.  Anthony might disagree though.
> 
> cheers,
>   Gerd


That's exactly what I implemented, with APIs so that we don't
expose structure internals and path names to all the world.
Will post soon.