From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:48497)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1V20Gn-0003OK-Tt
	for qemu-devel@nongnu.org; Wed, 24 Jul 2013 10:42:28 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1V20Gm-00089Y-OL
	for qemu-devel@nongnu.org; Wed, 24 Jul 2013 10:42:25 -0400
Received: from mx1.redhat.com ([209.132.183.28]:57740)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1V20Gm-00089U-Fc
	for qemu-devel@nongnu.org; Wed, 24 Jul 2013 10:42:24 -0400
Message-ID: <51EFE7C0.5060202@redhat.com>
Date: Wed, 24 Jul 2013 16:42:08 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
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>
In-Reply-To: <20130708195259.GA19775@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, seabios@seabios.org, qemu-devel@nongnu.org, Aurelien Jarno <aurelien@aurel32.net>, =?ISO-8859-1?Q?Andreas_F=E4rber?= <afaerber@suse.de>

  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