Re: [Qemu-devel] [PATCH v4 0/6] save/restore on Xen

[Avi Kivity]

On 01/24/2012 03:14 PM, Anthony Liguori wrote:
> On 01/24/2012 05:10 AM, Avi Kivity wrote:
>> On 01/23/2012 07:18 PM, Anthony Liguori wrote:
>>> Generally speaking, RAM is an independent device in most useful cases.
>>
>> Can you give examples?  Do you mean a subdevice with composition, or a
>> really independent device?
>
> I expect we'll have one Ram device.  It's size will be configurable. 
> One Ram device will hang off of the machine which would be the main ram.

We'll also have a hotpluggable variant which talks to some GPIOs.  A
motherboard may support multiple slots with such devices.

> A video card would have a Ram device via composition.

IMO, overkill.

>
> The important consideration about reset is how it propagates.  My
> expectation is that we'll propagate reset through the composition tree
> in a preorder transversal.  That means in the VGA device reset
> function, it's child device (Ram) has not been reset yet.

Doesn't depth first make more sense?  A bus is considered reset after
all devices in the bus have been reset.


>
>>> We really should view RAM as just another device so I don't like the
>>> idea of propagating a global concept of "when RAM is restored" because
>>> that treats it specially compared to other devices.
>>
>> Agree.  In fact the first step has been taken as now creating a RAM
>> region with memory_region_init_ram() doesn't register it for migration.
>> The next step would be a VMSTATE_RAM() to make it part of the containing
>> device.
>
> That's not necessary (or wise).
>
> Let's not confuse a Ram device with a MemoryRegion.  They are separate
> things and should be treated as separate things.  I thought we
> discussed that MemoryRegions are stateless (or at least, there state
> is all derived) and don't need to be serialized?

Well, the actual bits in memory are state.  All other attributes are
indeed derived.

I just think that making any device that has a bit of RAM a composed
device is overkill.  What do we gain from it?  The cost is not trivial.

-- 
error compiling committee.c: too many arguments to function