On Tue, May 14, 2013 at 6:34 AM, Anthony Liguori anth...@codemonkey.ws wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Mon, May 13, 2013 at 03:38:51PM -0500, Anthony Liguori wrote:
I don't think it's a good idea to move BIOS functionality in QEMU.
Just to clarify: generating ACPI tables
Jordan Justen jljus...@gmail.com writes:
On Tue, May 14, 2013 at 6:34 AM, Anthony Liguori anth...@codemonkey.ws
wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Mon, May 13, 2013 at 03:38:51PM -0500, Anthony Liguori wrote:
I don't think it's a good idea to move BIOS functionality in
Hi,
Several future developments that this will enable:
- make it easier to use alternative firmware:
any firmware can just load the ACPI tables from QEMU.
case in point OVMF.
UEFI obviously can create ACPI tables already so I don't think this is a
valid advantage.
Yea, but it
Gerd Hoffmann kra...@redhat.com writes:
Hi,
and is also a good
reason why exposing this information via a common interface (fw_cfg)
would be a good idea.
Huh? As far I know we generate device trees in qemu instead of
expecting pseries firmware compile them from fw_cfg information.
On 14 May 2013 15:29, David Woodhouse dw...@infradead.org wrote:
On Tue, 2013-05-14 at 10:38 +0100, Peter Maydell wrote:
It depends. For ARM we insist that the user provides the
device tree that corresponds to the kernel they're going to
run, and then we just tweak it a bit.
Um... device
On Tue, 2013-05-14 at 10:38 +0100, Peter Maydell wrote:
It depends. For ARM we insist that the user provides the
device tree that corresponds to the kernel they're going to
run, and then we just tweak it a bit.
Um... device trees describe hardware, and should not be at all
kernel-specific.
