On Mon, May 13, 2013 at 09:20:08PM +0100, Peter Maydell wrote:
On 13 May 2013 21:01, Michael S. Tsirkin m...@redhat.com wrote:
Sometimes we need to pass ranges around, add a
handy structure for this purpose.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/qemu/range.h |
On Mon, May 13, 2013 at 09:23:54PM +0100, Peter Maydell wrote:
On 13 May 2013 21:01, Michael S. Tsirkin m...@redhat.com wrote:
This fills in guest info table with misc
information of interest to the guest.
Will be used by ACPI table generation code.
Bunch of coding style violations 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
On Tue, May 14, 2013 at 08:34:43AM -0500, Anthony Liguori 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 is not
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.
