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

[Paul Brook <paul@codesourcery.com>]

> > > > > See my comment above, I'm not seeing a sufficient argument about
> > > > > why driver name matching is a false sense of security.
> > > > 
> > > > I still say it should be the migration code that checks that both
> > > > vmstate structures are for the same type of device. i.e. if
> > > > necessary the device name should be embedded in the device state,
> > > > not the device path.
> > > 
> > > I not sure how that fixes the ramblock issue that started this whole
> > > discussion.  It's not part of device's vmstate, it goes w/ ram.  I
> > > think I'm missing a piece of the puzzle here?
> > 
> > My main point there was that ram blocks should be associated with a
> > device state.  Once you do this it should just work as we already know
> > how to match device states.
> > 
> > It you're trying to transfer ram blocks before matching up the rest of
> > the state then you're likely to loose in all kinds of different ways.

... or not. See below.

> Yes, I see, thanks for clarifying.  I agree, ideally we'd create the
> entire target image dynamically.  It'd still need to know how to connect
> all the guest devices to the host, but it makes more sense to me than
> half building the system from cmdline on target, then rest filled in.

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.

Paul