From: Hollis Blanchard <hollisb@us.ibm.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: devicetree-discuss@ozlabs.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Machine config files
Date: Fri, 14 Nov 2008 15:39:23 -0600 [thread overview]
Message-ID: <200811141539.23408.hollisb@us.ibm.com> (raw)
In-Reply-To: <491DDB74.5070701@codemonkey.ws>
On Friday 14 November 2008 14:11:32 Anthony Liguori wrote:
> Hollis Blanchard wrote:
> > We do; PLB, OPB, and EBC are all on-chip busses found on IBM PowerPC SoCs.
For
> > example, you can see devices representing the UARTs and PCI controller in
our
> > bamboo.dts file. Qemu only modifies the device tree at runtime with
> > information not known until then (memory size, clock frequency, etc).
> >
>
> Yes, but you don't build the machine based on the device tree. What
> would be useful would be to be able to simply write a device tree
> description and that would fully represent the board such that you
> didn't need a ppc440_bamboo.c file at all.
>
> So what I'm getting at is, what is preventing us from being able to do
> this today?
Theoretically, nothing. If qemu were a clean and modular place, it would
probably be pretty straightforward.
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.
--
Hollis Blanchard
IBM Linux Technology Center
next prev parent reply other threads:[~2008-11-14 21:39 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 [this message]
2008-11-14 21:58 ` Anthony Liguori
2008-11-15 0:13 ` Paul Brook
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=200811141539.23408.hollisb@us.ibm.com \
--to=hollisb@us.ibm.com \
--cc=anthony@codemonkey.ws \
--cc=devicetree-discuss@ozlabs.org \
--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).