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

[Paul Brook <paul@codesourcery.com>]

> * Paul Brook (paul@codesourcery.com) wrote:
> > > > I find this argument contradictory. The migration code already needs
> > > > to check whether a device is compatible before it allows migration. 
> > > > The driver name is not sufficient to ensure compatibility, so I see
> > > > no benefit in including it in the device address.
> > > 
> > > See my comment above, I'm not seeing a sufficient argument about why
> > > driver name matching is a false sense of security.  If on an incoming
> > > migration I'm able to match the source provided e1000.03.0/vmstate
> > > against the target registered e1000.03.0/vmstate and hand off to the
> > > e1000 driver to check version ids, you bet I'm feeling a lot more
> > > secure than if I'm handing off to whatever happened to register
> > > 03.0/vmstate on the target.
> > 
> > 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.

Paul