From mboxrd@z Thu Jan  1 00:00:00 1970
From: Laszlo Ersek <lersek@redhat.com>
Subject: Re: [SeaBIOS] KVM call agenda for 2013-05-28
Date: Thu, 30 May 2013 18:41:54 +0200
Message-ID: <51A78152.10000@redhat.com>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: KVM devel mailing list <kvm@vger.kernel.org>,
	Juan Quintela <quintela@redhat.com>,
	"Jordan Justen \(Intel address\)" <jordan.l.justen@intel.com>,
	seabios@seabios.org, qemu-devel qemu-devel <qemu-devel@nongnu.org>,
	Kevin O'Connor <kevin@koconnor.net>, "Michael S. Tsirkin" <mst@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	David Woodhouse <dwmw2@infradead.org>
To: Jordan Justen <jljusten@gmail.com>
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <CAFe8ug_=WJEvJspRRWsTG7POWBxmeO3+kcUVQHmntt0gxZqfRA@mail.gmail.com>
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>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
List-Id: kvm.vger.kernel.org

On 05/30/13 18:20, Jordan Justen wrote:

> I think ACPI table generation lives in firmware on real products,
> because on real products the firmware is the point that best
> understands the actual hardware layout for the machine. In qemu, I
> would say that qemu best knows the hardware layout, given that the
> firmware is generally a slightly separate project from qemu.
> 
> I don't think adding a coreboot layer into the picture helps, if it
> brings along the coreboot payload boot interface as a requirement.
> 
> Then again, I don't really understand how firmware could be swapped
> out in this case. What would -bios do? How would the coreboot ACPI
> shim layer be specified to qemu?

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, load the boot firmware (SeaBIOS or OVMF or
something else -- not sure how to configure that), and pass down the
tables to the firmware (through a now unspecified interface -- perhaps
the tables could even be installed at this point). This could introduce
another interface (fw_cfg+something rather than just fw_cfg), but ACPI
table preparation would be concentrated in one project.

I guess.

Laszlo