From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:48739)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UiLi9-000068-T6
	for qemu-devel@nongnu.org; Fri, 31 May 2013 05:33:28 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UiLi8-0004HY-Oh
	for qemu-devel@nongnu.org; Fri, 31 May 2013 05:33:25 -0400
Received: from mx1.redhat.com ([209.132.183.28]:33542)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UiLi8-0004HI-CT
	for qemu-devel@nongnu.org; Fri, 31 May 2013 05:33:24 -0400
Message-ID: <51A86E3F.5030803@redhat.com>
Date: Fri, 31 May 2013 11:32:47 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <20130523124132.GA18596@redhat.com>
	<20130528235309.GA31648@morn.localdomain>
	<51A5C117.6000609@redhat.com> <871u8p92v8.fsf@codemonkey.ws>
	<1369905828.20691.50.camel@shinybook.infradead.org>
	<51A73459.2020407@redhat.com>
	<1369916358.5141.32.camel@i7.infradead.org>
	<CAFe8ug_=WJEvJspRRWsTG7POWBxmeO3+kcUVQHmntt0gxZqfRA@mail.gmail.com>
	<51A78152.10000@redhat.com>
In-Reply-To: <51A78152.10000@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28
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: Laszlo Ersek <lersek@redhat.com>
Cc: KVM devel mailing list <kvm@vger.kernel.org>, Juan Quintela <quintela@redhat.com>, Jordan Justen <jljusten@gmail.com>, seabios@seabios.org, qemu-devel qemu-devel <qemu-devel@nongnu.org>, Kevin O'Connor <kevin@koconnor.net>, "Michael S. Tsirkin" <mst@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>, "Jordan Justen (Intel address)" <jordan.l.justen@intel.com>, David Woodhouse <dwmw2@infradead.org>

  Hi,

> I guess -bios would load coreboot. Coreboot would siphon the data
> necessary for ACPI table building through the current (same) fw_cfg
> bottleneck, build the tables,

Yes.

> load the boot firmware (SeaBIOS or OVMF or
> something else -- not sure how to configure that),

The coreboot rom has named sections (this is called cbfs which stands
for coreboot filesystem IIRC):

rincewind kraxel ~# cbfstool /usr/share/coreboot.git/bios.bin print
bios.bin: 256 kB, bootblocksize 848, romsize 262144, offset 0x0
alignment: 64 bytes

Name                           Offset     Type         Size
cmos_layout.bin                0x0        cmos_layout  1160
fallback/romstage              0x4c0      stage        14419
fallback/coreboot_ram          0x3d80     stage        37333
config                         0xcfc0     raw          2493
fallback/payload               0xd9c0     payload      56969
vgabios/sgabios                0x1b8c0    raw          4096
(empty)                        0x1c900    null         144216

where "fallback/payload" is seabios.

> and pass down the
> tables to the firmware (through a now unspecified interface -- perhaps
> the tables could even be installed at this point).

As far I know coreboot can add more stuff such as acpi tables to cbfs at
runtime and seabios able to access cbfs too and pull informations from
coreboot that way.

HTH,
  Gerd