[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [SeaBIOS] [PATCH RFC 00/13] qemu: generate acpi tables
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [SeaBIOS] [PATCH RFC 00/13] qemu: generate acpi tables for the guest |
Date: |
Tue, 14 May 2013 16:13:30 +0100 |
On 14 May 2013 15:29, David Woodhouse <address@hidden> 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 trees describe hardware, and should not be at all
> kernel-specific. Did you mean to say "the device tree that corresponds
> to the machine they're going to emulate"?
No, I meant "corresponding to the kernel". (Qualifier to the
following rant: I'm talking specifically about ARM; I understand
PPC is different.)
In my experience if you try to use a device tree blob other
than the one which you produce from the dts that is shipped
with the exact revision of the kernel that you're booting,
then it is likely to result in missing devices at best and
quite likely random inexplicable crashes. ARM device trees are
simply churning way too much at the moment (the usual failure
behaviour is "device which was driven by board data gets
a DT binding, so using an old DT means the kernel doesn't
think the device exists at all", but I've seen crashes too).
Maybe in a decade we'll be able to claim that device trees
are a description of the hardware, but right now the fact
is that this is a kernel specific data structure and it's
not guaranteed to work with anything other than the kernel
it goes with. If somebody reports a "this isn't booting"
kind of bug, "are you using the right device tree blob
for the kernel?" is among the first questions I ask (and
I have zero interest in debugging cases where there's
a mismatch.)
I make a very small exception for mach-virt, because it's
entirely device tree driven and there's a very small set
of things that appear in it. So we have a reasonable chance
of holding kernel peoples' feet to the fire if they try
to break existing device trees generated by QEMU or kvmtool.
For anything else I am absolutely against having QEMU
generate any ARM device tree blobs or do anything beyond
the minimal modifications to them we absolutely must.
thanks
-- PMM
- Re: [Qemu-devel] [PATCH RFC 10/13] i386: generate pc guest info, (continued)
[Qemu-devel] [PATCH RFC 11/13] pc: pass PCI hole ranges to Guests, Michael S. Tsirkin, 2013/05/13
[Qemu-devel] [PATCH RFC 12/13] i386: ACPI table generation code from seabios, Michael S. Tsirkin, 2013/05/13
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest, Anthony Liguori, 2013/05/13
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest, Anthony Liguori, 2013/05/14
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest, Gerd Hoffmann, 2013/05/14
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest, Anthony Liguori, 2013/05/14
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest, Michael S. Tsirkin, 2013/05/14
Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest, Michael S. Tsirkin, 2013/05/16