[Qemu-devel] Fabrice Bellard 's QEMU configuration files

[Qemu-devel] Fabrice Bellard 's QEMU configuration files

[Erik de Castro Lopo]

Hi all,

Back in June, Fabrice Bellard posted a patch against SVN 4734:

     http://www.archivum.info/qemu-devel@nongnu.org/2008-06/msg00513.html

to add configuration files to qemu.

It seems that this work was never merged into SVN and that patchset
does not apply to current SVN head.

Does anyone have an updated version of that patch or something similar?

Is there any interest in pushing this kind of functionality into
qemu mainline?

Cheers,
Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
C++: The power, elegance and simplicity of a hand grenade.

Re: [Qemu-devel] Fabrice Bellard 's QEMU configuration files

[Rob Landley]

On Friday 10 October 2008 18:44:23 Erik de Castro Lopo wrote:
> Hi all,
>
> Back in June, Fabrice Bellard posted a patch against SVN 4734:
>
>      http://www.archivum.info/qemu-devel@nongnu.org/2008-06/msg00513.html
>
> to add configuration files to qemu.
>
> It seems that this work was never merged into SVN and that patchset
> does not apply to current SVN head.
>
> Does anyone have an updated version of that patch or something similar?
>
> Is there any interest in pushing this kind of functionality into
> qemu mainline?

I point out that device trees are becoming standard in the Linux kernel, and 
being spread from powerpc and sparc to arm, mips, and so on.  I attented a 
BOF about them at OLS, and there's even a mailing list for them now:

https://ozlabs.org/mailman/listinfo/devicetree-discuss

This means the Linux kernel already has data files which describe boards on 
architectures that don't have big defacto standard hardware layouts already 
implemented in C, and lots of 'em are yanking the C implementation in favor 
of using the device tree parser.

Teaching qemu to parse a device tree means you get a ton of free board layouts 
from the linux kernel.  (It also simplifies "-kernel" since lots of platforms 
need the flattened device tree passed in from the firmware...)

Somewhat out-of-date documentation is available here:

http://kernel.org/doc/Documentation/powerpc/booting-without-of.txt

You could ping the above list to see if there's something more recent...

Rob

Re: [Qemu-devel] Fabrice Bellard 's QEMU configuration files

[Erik de Castro Lopo]

Rob Landley wrote:

> I point out that device trees are becoming standard in the Linux kernel,

This is completely orthogonal.

What I was talking about was a way to do:

     qemu -C my-machine.qvm

instead of

    qemu -m 512 -kqemu -no-reboot -nographic -serial stdio \
        -net vde,vlan=0,sock=/var/run/qemu-vde.ctl \
        -net nic,vlan=0,macaddr=53:64:10:12:47:31 \
        -name my_machine -boot c my-machine.img

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"No stronger retrograde force exists in the world."
-- Winston Churchill in "The River War", published in 1899.

Re: Fabrice Bellard 's QEMU configuration files

[Hollis Blanchard]

[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]

On Sat, Oct 11, 2008 at 11:56 PM, Rob Landley <rob@landley.net> wrote:

> On Friday 10 October 2008 18:44:23 Erik de Castro Lopo wrote:
> > Hi all,
> >
> > Back in June, Fabrice Bellard posted a patch against SVN 4734:
> >
> >
> http://www.archivum.info/qemu-devel@nongnu.org/2008-06/msg00513.html
> >
> > to add configuration files to qemu.
> >
> > It seems that this work was never merged into SVN and that patchset
> > does not apply to current SVN head.
> >
> > Does anyone have an updated version of that patch or something similar?
> >
> > Is there any interest in pushing this kind of functionality into
> > qemu mainline?
>
> I point out that device trees are becoming standard in the Linux kernel,
> and
> being spread from powerpc and sparc to arm, mips, and so on.  I attented a
> BOF about them at OLS, and there's even a mailing list for them now:
>
> https://ozlabs.org/mailman/listinfo/devicetree-discuss
>
> This means the Linux kernel already has data files which describe boards on
> architectures that don't have big defacto standard hardware layouts already
> implemented in C, and lots of 'em are yanking the C implementation in favor
> of using the device tree parser.
>
> Teaching qemu to parse a device tree means you get a ton of free board
> layouts
> from the linux kernel.  (It also simplifies "-kernel" since lots of
> platforms
> need the flattened device tree passed in from the firmware...)
>

FWIW, I've already had to teach qemu how to load and manipulate device trees
for my work with KVM on PPC440. Basically, rather than trying to run uboot
inside qemu, I have qemu replicate the post-uboot environment. That means
qemu is responsible for providing the device tree to the booted kernel.

There really wasn't a whole lot to it, really: just have the qemu board code
load a binary <board.dtb> file from the "pc-bios" (*ahem* ;) directory, and
use some libfdt calls to provide runtime information (e.g. memory layout).

Of course, the more complete solution would be to have qemu actually load
devices based on the contents of the device tree, so that you wouldn't need
to specify commandline options. (Erik, I have no idea why you think that's
orthogonal -- it's exactly what you're asking about.)

-Hollis

[-- Attachment #2: Type: text/html, Size: 2938 bytes --]

Re: [Qemu-devel] Fabrice Bellard 's QEMU configuration files

[Hollis Blanchard]

[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]

On Sat, Oct 11, 2008 at 11:56 PM, Rob Landley <rob@landley.net> wrote:

> On Friday 10 October 2008 18:44:23 Erik de Castro Lopo wrote:
> > Hi all,
> >
> > Back in June, Fabrice Bellard posted a patch against SVN 4734:
> >
> >
> http://www.archivum.info/qemu-devel@nongnu.org/2008-06/msg00513.html
> >
> > to add configuration files to qemu.
> >
> > It seems that this work was never merged into SVN and that patchset
> > does not apply to current SVN head.
> >
> > Does anyone have an updated version of that patch or something similar?
> >
> > Is there any interest in pushing this kind of functionality into
> > qemu mainline?
>
> I point out that device trees are becoming standard in the Linux kernel,
> and
> being spread from powerpc and sparc to arm, mips, and so on.  I attented a
> BOF about them at OLS, and there's even a mailing list for them now:
>
> https://ozlabs.org/mailman/listinfo/devicetree-discuss
>
> This means the Linux kernel already has data files which describe boards on
> architectures that don't have big defacto standard hardware layouts already
> implemented in C, and lots of 'em are yanking the C implementation in favor
> of using the device tree parser.
>
> Teaching qemu to parse a device tree means you get a ton of free board
> layouts
> from the linux kernel.  (It also simplifies "-kernel" since lots of
> platforms
> need the flattened device tree passed in from the firmware...)
>

FWIW, I've already had to teach qemu how to load and manipulate device trees
for my work with KVM on PPC440. Basically, rather than trying to run uboot
inside qemu, I have qemu replicate the post-uboot environment. That means
qemu is responsible for providing the device tree to the booted kernel.

There really wasn't a whole lot to it, really: just have the qemu board code
load a binary <board.dtb> file from the "pc-bios" (*ahem* ;) directory, and
use some libfdt calls to provide runtime information (e.g. memory layout).

Of course, the more complete solution would be to have qemu actually load
devices based on the contents of the device tree, so that you wouldn't need
to specify commandline options. (Erik, I have no idea why you think that's
orthogonal -- it's exactly what you're asking about.)

-Hollis

[-- Attachment #2: Type: text/html, Size: 2938 bytes --]