qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: seabios@seabios.org, "Michael S. Tsirkin" <mst@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	qemu-devel@nongnu.org
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	[thread overview]
Message-ID: <CAFEAcA8fOpXaGgBcKG7BGwpQHSFZqOW0nLonb0QfXO5N7tsbcw@mail.gmail.com> (raw)
In-Reply-To: <1368541788.11088.54.camel@i7.infradead.org>

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

  reply	other threads:[~2013-05-14 15:13 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-13 20:00 [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest Michael S. Tsirkin
2013-05-13 20:00 ` [Qemu-devel] [PATCH RFC 03/13] refer to FWCfgState explicitly Michael S. Tsirkin
2013-05-13 20:00 ` [Qemu-devel] [PATCH RFC 02/13] hw/i386/pc.c: move IO_APIC_DEFAULT_ADDRESS to include/hw/i386/apic.h Michael S. Tsirkin
2013-05-13 20:08   ` Eric Blake
2013-05-13 20:00 ` [Qemu-devel] [PATCH RFC 01/13] apic: rename apic specific bitopts Michael S. Tsirkin
2013-05-13 20:22   ` Peter Maydell
2013-05-13 20:29     ` Michael S. Tsirkin
2013-05-13 20:00 ` [Qemu-devel] [PATCH RFC 04/13] fw_cfg: move typedef to qemu/typedefs.h Michael S. Tsirkin
2013-05-13 20:00 ` [Qemu-devel] [PATCH RFC 05/13] i386: add ACPI table files from seabios Michael S. Tsirkin
2013-05-13 20:01 ` [Qemu-devel] [PATCH RFC 06/13] acpi: add rules to compile ASL source Michael S. Tsirkin
2013-05-13 20:01 ` [Qemu-devel] [PATCH RFC 07/13] acpi: pre-compiled ASL files Michael S. Tsirkin
2013-05-13 20:01 ` [Qemu-devel] [PATCH RFC 08/13] range: add Range structure Michael S. Tsirkin
2013-05-13 20:20   ` Peter Maydell
2013-05-14  7:55     ` Michael S. Tsirkin
2013-05-13 20:01 ` [Qemu-devel] [PATCH RFC 09/13] i386: add bios linker/loader Michael S. Tsirkin
2013-05-13 20:01 ` [Qemu-devel] [PATCH RFC 13/13] pc: reuse guest info for legacy fw cfg Michael S. Tsirkin
2013-05-13 20:01 ` [Qemu-devel] [PATCH RFC 10/13] i386: generate pc guest info Michael S. Tsirkin
2013-05-13 20:23   ` Peter Maydell
2013-05-14  8:06     ` Michael S. Tsirkin
2013-05-14  9:32       ` Peter Maydell
2013-05-13 20:01 ` [Qemu-devel] [PATCH RFC 12/13] i386: ACPI table generation code from seabios Michael S. Tsirkin
2013-05-13 20:27   ` Peter Maydell
2013-05-13 20:01 ` [Qemu-devel] [PATCH RFC 11/13] pc: pass PCI hole ranges to Guests Michael S. Tsirkin
2013-05-13 20:38 ` [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest Anthony Liguori
2013-05-14  1:54   ` [Qemu-devel] [SeaBIOS] " Kevin O'Connor
2013-05-14  9:29   ` [Qemu-devel] " Gerd Hoffmann
2013-05-14  9:38     ` Peter Maydell
2013-05-14 14:29       ` [Qemu-devel] [SeaBIOS] " David Woodhouse
2013-05-14 15:13         ` Peter Maydell [this message]
2013-05-14 13:26     ` [Qemu-devel] " Anthony Liguori
2013-05-14 13:53       ` Gerd Hoffmann
2013-05-14 14:40         ` Anthony Liguori
2013-05-14 11:58   ` Michael S. Tsirkin
2013-05-14 13:34     ` Anthony Liguori
2013-05-14 14:14       ` Michael S. Tsirkin
2013-05-15  6:38       ` [Qemu-devel] [SeaBIOS] " Gerd Hoffmann
2013-06-03 22:19       ` [Qemu-devel] " Jordan Justen
2013-06-03 23:12         ` Anthony Liguori
2013-06-04  4:14           ` Jordan Justen
2013-05-16 11:27   ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFEAcA8fOpXaGgBcKG7BGwpQHSFZqOW0nLonb0QfXO5N7tsbcw@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=dwmw2@infradead.org \
    --cc=kraxel@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=seabios@seabios.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).