> * Paul Brook (paul@xxxxxxxxxxxxxxxx) 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
