Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()

[Alex Williamson]

On Wed, 2010-06-16 at 02:30 +0100, Paul Brook wrote:
> Transferring the machine description on migration is a separate problem.
> 
> Lets say we associate each RAM block with a device. Each ram block also has a 
> name.  These names distinguish between blocks attached to a given device, but 
> need not be globally unique.  i.e. devices A and B can both have block named 
> "foo".  RAM block migration happens before device state migration (including 
> device properties).
> 
> There are three relevant migration failure modes:
> 
> (1) The same device is present, but has a different size property.
>   If the incoming block is larger than the allocated block then you loose.
> (2) A different device is present, but does not have a ram block of the same 
> name.
>   This safely fails migration because of the block name mismatch.
> (3) A different device is present, that happens to have a ram block of the 
> same name.
>   If the blocks are the same size then transferring the contents is harmless.
>   If they are different sizes then this will be caught by (1). Either way, the
>   migration will be failed once we get to the vmstate check.
> 
> Note how adding the device type to the canonical address does not effect the 
> outcome.
> 
> Going back to the original problem, (1) is the most interesting.
> 
> I suggest that the initial migration phase transfers a list of ram blocks. 
> Each entry in that list should be {canonical device path, name, size}. You 
> should lookup all these ram blocks, and fail migration if they are not 
> present 
> with the correct size[1].  This list also gives you a convenient numeric 
> index 
> to identify the block during RAM migration.
> 
> [1] In the future we may be able to resize blocks. However this is not safe 
> with the current API.

I think for the most part, you've just described the RAMBlock series of
patches I sent out last week.  I'll note that that series creates ram
blocks on the target if they aren't present because of the technicality
that we currently do not have a qemu_ram_free() to cleanup the list when
things go away.  Once we have that and cleanup drivers to use it, I
agree we should fail the migration if it occurs, or at least print out a
big warning so we can go fix the driver.  If I'm missing where else it's
significantly different please let me know.

Yes, case (3) would fail in the vmstate code without driver name in the
canonical path... or at least we hope it would.  But with the driver
name in the canonical path, we can avoid doing a useless operation, fail
earlier, and provide the vmstate with a key piece of information it can
use to help ensure that the incoming state information belongs to the
driver it thinks it does.  Seems like a win to me.  Thanks,

Alex