From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45940) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcGvN-0007gE-HQ for qemu-devel@nongnu.org; Tue, 14 May 2013 11:13:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UcGvI-0006si-C1 for qemu-devel@nongnu.org; Tue, 14 May 2013 11:13:57 -0400 Received: from mail-pd0-f182.google.com ([209.85.192.182]:34625) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcGvI-0006sF-6b for qemu-devel@nongnu.org; Tue, 14 May 2013 11:13:52 -0400 Received: by mail-pd0-f182.google.com with SMTP id 3so514462pdj.13 for ; Tue, 14 May 2013 08:13:50 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1368541788.11088.54.camel@i7.infradead.org> References: <87sj1qboo4.fsf@codemonkey.ws> <519203F7.8090200@redhat.com> <1368541788.11088.54.camel@i7.infradead.org> From: Peter Maydell Date: Tue, 14 May 2013 16:13:30 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [SeaBIOS] [PATCH RFC 00/13] qemu: generate acpi tables for the guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Woodhouse Cc: seabios@seabios.org, "Michael S. Tsirkin" , Gerd Hoffmann , qemu-devel@nongnu.org On 14 May 2013 15:29, David Woodhouse 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