qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: devicetree-discuss@ozlabs.org, Hollis Blanchard <hollisb@us.ibm.com>
Subject: Re: [Qemu-devel] Machine config files
Date: Sat, 15 Nov 2008 00:13:03 +0000	[thread overview]
Message-ID: <200811150013.03865.paul@codesourcery.com> (raw)
In-Reply-To: <491DF47B.9000602@codemonkey.ws>

> > Some translation code would be required for compatibility. For example,
> > when the DTS has 128MB of memory, and the user invokes qemu with -m 256,
> > now you need to update the device tree in order to pass it into the
> > guest. That's pretty easy, but once you start talking about adding PCI
> > devices it gets a little more difficult. I seem to recall this
> > conversation was had on qemu-devel a little while back.
>...
> > Of course, *some* code would still be needed *somewhere* to load the
> > kernel, initrd, set initial register state to point to those memory
> > locations, etc. In the case of KVM on 440, we also need to override the
> > DTS with the real host clock frequency. (This probably isn't necessary
> > for qemu+TCG.)
> >
> > But yes, replacing all the pci_nic_init(), isa_mmio_init(),
> > cpu_register_physical_memory(), etc could be automated by walking the
> > device tree.
>
> Ok.  This is starting to look interesting.  Paul, what do you think of DTS?

Things like kernel loading are easy, you just add a special device (which 
linux will ignore) specifying the relevant parameters. IMO it should be 
possible to use the same device tree for both linux and qemu, but it's ok to 
require some additional information on top of what linux currently requires.

I agree with Hollis that the tricky bits are when you want to augment a board 
with use supplied options (e.g. RAM size or additional PCI devices). That 
either requires qemu to modify the supplied device tree, merging multiple 
trees, or some other magic. I'm ignoring this problem for now. Worst case we 
remove the existing options, provide a reasonable set of "standard" configs 
and anyone who wants exotic setups can modify the machine description.

I'm mainly interested in emulation, where any host information leaking through 
to the emulated machine is a bug :-)

Paul

  reply	other threads:[~2008-11-15  0:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-14  3:32 [Qemu-devel] Machine config files Paul Brook
2008-11-14 17:54 ` Hollis Blanchard
2008-11-15  6:52   ` David Gibson
2008-11-14 19:04 ` Blue Swirl
2008-11-14 19:29   ` Anthony Liguori
2008-11-14 19:51     ` Hollis Blanchard
2008-11-14 20:11       ` Anthony Liguori
2008-11-14 21:39         ` Hollis Blanchard
2008-11-14 21:58           ` Anthony Liguori
2008-11-15  0:13             ` Paul Brook [this message]
2008-11-15  6:45               ` David Gibson
2008-11-15  6:58       ` David Gibson

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=200811150013.03865.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=devicetree-discuss@ozlabs.org \
    --cc=hollisb@us.ibm.com \
    --cc=qemu-devel@nongnu.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).