Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format

[Peter Maydell]

On 26 July 2011 22:46, Anthony Liguori <address@hidden> wrote:

[This is a bit random-sniping at minor points because I'm still thinking
about the big-picture bits]

> So we never actually walk the VMState tables to do anything.  The
> unconverted purely imperative routines we just convert to use marshal to a
> Visitor instead of QEMUFile.
>
> What this gives us is a way to achieve the same level of abstraction that
> VMState would give us for almost no work at all.  That fundamentally let's
> us take the next step in "fixing" migration.

IME the problem with migration is not devices which implement old-style
imperative save/load routines but all the devices which (silently) implement
no kind of save/load support at all...

> With an improved qdev (which I think is QOM, but for now, just ignore that),
> we would be able to do the following:
>
> 1) create a device, that creates other devices as children of itself
> *without* those children being under a bus hierarchy.

This is really important, yes. In fact in some ways the logical
partitioning of a system doesn't inherently follow any kind of bus.
So a Beagle board is a top-level thing which contains (among other
things) an OMAP3 SOC, and some external-to-the-SOC devices like a
NAND chip. The OMAP3 contains a CPU and a pile of devices including
the GPMC which is the memory controller for the NAND chip. So the
logical structure of the system is:

 beagleboard (the "machine" in qemu terms)
  - omap3
     - cortex-a8 (cpu)
     - omap_gpmc
     - omap_uart
     - etc
  - NAND flash
  - etc

even though the bus topology is more like:
 cortex-a8
  - omap_uart
  - other system-bus devices
  - omap_gpmc
     - NAND flash
     - other devices hanging off the GPMC

(and the interrupt topology is different again, ditto the clock tree).

When you're trying to put together a machine then I think the logical
structure is more useful than the memory bus or interrupt tree.

> 2) eliminate the notion of machines altogether, and instead replace machines
> with a chipset, soc device, or whatever is the logic device that basically
> equates to what the machine logic does today.

This doesn't make any sense, though. A machine isn't a chipset or a SOC.
It's a set of devices (including a CPU) wired up and configured in a
particular way. A Beagle and an Overo are definitely different machines
(which appear differently to guests in some ways) even though they share
the same OMAP3 SOC.

> The pc machine code is basically the i440fx.  You could take everything that
> it does, call it an i440fx object, and make "machine" properties properties
> of the i440fx.  That makes what we think of as machine creation identical to
> device creation.

I don't really know enough about PC hardware but I can't help thinking
that doing this is basically putting things into the qemu "i440fx" object
which aren't actually in the h/w i440fx. (Is the CPU really part of the
chipset, just for example? RAM?)

A random other point I'll throw in: along with composition ("this device
is really the result of wiring up and configuring these other devices
like this", you also want to be able to have a device 'hide' and/or
make read-only the properties of its subdevices, eg where My-SOC-USB
implements USB by composing usb-ohci and usb-ehci but hardwires various
things the generic OHCI/EHCI leave configurable. Also the machine
model will want to hide things for similar reasons.

-- PMM