qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 0/4] Machine config files


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] Re: [PATCH 0/4] Machine config files
Date: Mon, 6 Jul 2009 15:49:28 +0300
User-agent: Mutt/1.5.19 (2009-01-05)

On Fri, Jun 12, 2009 at 06:11:24PM +0200, Jan Kiszka wrote:
> Gerd Hoffmann wrote:
> > On 06/12/09 15:37, Markus Armbruster wrote:
> >> It can be compiled from source with dtc, which doesn't seem to be
> >> included in the patch series.  The language accepted by dtc is pretty
> >> low-level: it talks NUL-terminates strings, byte strings and arrays of
> >> "cells" (32 bit integers).
> > 
> > [ a bunch of examples snipped ]
> > 
> >> Is that really what we want for a configuration file?
> > 
> > I do see a point in using fdt as qemu-internal representation.  ppc
> > needs it anyway.  It is also a nice way to store the guest configuration
> > for save/load and migration, you can just send the blob over the wire.
> > And we can hide the details such as cells behind some nifty helper
> > functions.
> > 
> > Qemu users should not be required to be fdt experts though.  We need
> > another, more user-friendly interface to configure virtual machines.
> > 
> > libfdt has functions to modify the device tree.  I think we will need
> > them to keep the fdt in sync with the machine configuration when
> > hot-plugging in and out devices (otherwise the fdt is useless for
> > migration).  So when we have code to handle the fdt updates triggered by
> > the "drive_add ..." monitor command anyway, also handling the -drive
> > command line switch (or the same input from a more userfriendly machine
> > config file) should be easy.
> 
> And if you factor out that code so that a stand-alone tool, say
> 'qemu-config' could use it too, you would have a way to generate such
> files: Simply pass the well-known command line switches to that tool and
> let it generate the corresponding config file for you. That file could
> then be stuffed into qemu on startup again, maybe temporarily customized
> by additional command line switches. Of course, the qemu-config tool
> could also read existing configs and modify them according to the
> specified wishes.
> 
> Not having thought too much about this whole topic, such a path sounds
> quite handy for me, specifically as I do not use fancy front-ends for
> daily work either.
> 
> Jan

Can't we extend loadvm/savevm format to support machine config? It is
already supported by all devices, it seems that we just need to add some
detail such as pci addresses, and qemu flags to save/load this config.
No?

-- 
MST




reply via email to

[Prev in Thread] Current Thread [Next in Thread]