From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:44161)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1SUxWm-0007R8-Sl
	for qemu-devel@nongnu.org; Thu, 17 May 2012 06:01:53 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1SUxWf-00084n-W3
	for qemu-devel@nongnu.org; Thu, 17 May 2012 06:01:48 -0400
Received: from mx1.redhat.com ([209.132.183.28]:53764)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1SUxWf-00084a-O6
	for qemu-devel@nongnu.org; Thu, 17 May 2012 06:01:41 -0400
Message-ID: <4FB4CC7F.40001@redhat.com>
Date: Thu, 17 May 2012 12:01:35 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1336998923-30144-1-git-send-email-gleb@redhat.com>
	<1336998923-30144-2-git-send-email-gleb@redhat.com>
	<20120515014319.GA21845@morn.localdomain>
	<20120515080605.GD32036@redhat.com>
	<20120515231810.GA674@morn.localdomain>
	<20120516134657.GU32036@redhat.com> <4FB3CCC7.4070701@redhat.com>
	<20120517002453.GB19382@morn.localdomain>
In-Reply-To: <20120517002453.GB19382@morn.localdomain>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 2/2] Get system state configuration from
 QEMU and patcth DSDT with it.
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: Kevin O'Connor <kevin@koconnor.net>
Cc: seabios@seabios.org, qemu-devel@nongnu.org, Gleb Natapov <gleb@redhat.com>

Il 17/05/2012 02:24, Kevin O'Connor ha scritto:
>> > Can we build an SSDT that includes the contents of fw_cfg (e.g.
>> > FW_CFG_SIGNATURE at offset 0, FW_CFG_UUID at offset 4, FW_CFG_NOGRAPHIC
>> > at offset 16... the entry <-> offset mapping and the defaults would be
>> > part of SeaBIOS), and then read that data from normal DSDT methods?
>> > 
>> > That would be similar to Gerd's patch, but without letting the OSPM use
>> > the real fw_cfg device.
> I'm not sure I understand your proposal.  Are you suggesting reading
> every fw_cfg "port" into memory and then passing that memory into an
> SSDT?  If so, that wouldn't be easy (we don't necessarily know the
> size of each "port") and could potentially waste a lot of memory
> (think a vmlinuz stored in fw_cfg).

No, only entries and/or files that are needed by the DSDT (PCI region
and sleep data).

Paolo