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

[Anthony Liguori <anthony@codemonkey.ws>]

On 07/26/2011 05:22 PM, Peter Maydell wrote:
> On 26 July 2011 22:46, Anthony Liguori<anthony@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...

 From a modelling PoV, I think the way to handle this is to make 
save/restore a pure virtual interface in the Device base class.  A 
device that doesn't implement something won't be instantiateble.

That's the approach I took for QOM.  But Gerd already did something for 
qdev here.

>> 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.

Exactly.  In my mind, beagleboard should be a device that creates all of 
these parts via composition.

And if the logic is truly trivial, such that everything can be expressed 
without any special code, than beagleboard can just be a config file.

>> 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.

I'm basically suggesting that we model motherboards as devices.  They're 
boards with some wiring logic, a bunch of sockets for peripherals 
(sometimes including sockets for CPUs and memory, but not always), and 
all the necessary devices to be useful.

If everything can be constructed trivial without code, then it should be 
possible to do this.  But I don't think we'll ever be able to totally 
eliminate code in constructing these devices.

>> 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?)

No, but there is an interface to the CPU which essentially becomes a 
socket.  Likewise, there are sockets for RAM dims.  So in my mind, 
creation would look like this:

(qemu) plug_create host-cpu id=cpu0
(qemu) plug_create ram id=ram0 size=4G
(qemu) plug_create i440fx id=chipset ram=ram0 cpu=cpu0

>
> 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.

In the model I proposed, properties can be locked at run time. 
Normally, they're locked by default at realize but a device could 
certainly initialize it's child devices and then lock all of it's 
properties.  It's as simple as:

struct MySocUSB
{
    Device parent;

    UsbOhci ohci;
    UsbEhci ehci;
};

void my_soc_usb_initfn(...)
{
     // Identify children devices
     plug_add_property_plug(PLUG(obj), "ochi", &obj->ochi, TYPE_OCHI);
     plug_add_property_plug(PLUG(obj), "ehci", &obj->ehci, TYPE_EHCI);

     // Configure children devices
     ohci_set_foo(&obj->ohci, ...);
     ehci_set_bar(&obj->ehci, ...);

     // Prevent child device properties from being modified
     plug_lock_all_properties(PLUG(&obj->ohci));
     plug_lock_all_properties(PLUG(&obj->ehci));
}

This is all there today infrastructure wise.

Regards,

Anthony Liguori

>
> -- PMM
>