Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest

[David Woodhouse]

      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"? 

And I suppose you do have a kernel that corresponds to the machine it's
going to run on, so what you say isn't *entirely* bogus. But it's just
written in a way which makes it scary :)

-- 
dwmw2

[Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest

[Peter Maydell]

      On 14 May 2013 15:29, David Woodhouse <dwmw2(a)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 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