On 26 July 2011 22:46, Anthony Liguori <anth...@codemonkey.ws> 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
