From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:46657)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1V2Mzs-0001ix-M9
	for qemu-devel@nongnu.org; Thu, 25 Jul 2013 10:58:30 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1V2Mzn-00033R-VB
	for qemu-devel@nongnu.org; Thu, 25 Jul 2013 10:58:28 -0400
Received: from mx1.redhat.com ([209.132.183.28]:51522)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1V2Mzn-00033K-O8
	for qemu-devel@nongnu.org; Thu, 25 Jul 2013 10:58:23 -0400
Message-ID: <51F13D0C.20602@redhat.com>
Date: Thu, 25 Jul 2013 16:58:20 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <1374681580-17439-1-git-send-email-mst@redhat.com>
	<1374681580-17439-15-git-send-email-mst@redhat.com>
	<51F122D1.4010600@redhat.com> <20130725132301.GA2575@redhat.com>
In-Reply-To: <20130725132301.GA2575@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v3 14/14] i386: ACPI table generation code
 from seabios
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>, qemu-devel@nongnu.org

On 07/25/13 15:23, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2013 at 03:06:25PM +0200, Gerd Hoffmann wrote:
>>   Hi,
>>
>>>     As table content is likely to change over time,
>>>     the following measures are taken to simplify
>>>     cross-version migration:
>>>     - All tables besides the RSDP are packed in a single FW CFG entry.
>>>       This entry size is currently 23K. We round it up to 64K
>>>       to avoid too much churn there.
>>
>> Does it need to be that way?  I'd prefer to have one fw_cfg entry per table.
>>
>> cheers,
>>   Gerd
>>
> 
> It's better I think.  The advantages are:
> 	- when we add more tables we don't break cross-version
>           migration compatibility

New tables are a guest-visible change, so I think we have to turn them
off for old machine types via compat properties anyway.  This will also
solve the migration issue.

> 	- we have limited number of files, this way we won't
>           run out of them

Anything which prevents us from raising that number?

> what are advantages of file per table?

You can look at the tables without doing a full linker pass first, so
the firmware can easily initialize the hardware according to what it
finds in specific acpi tables.  Check FADT for pm_base.  Check MCFG for
mmconf xbar location.

cheers,
  Gerd