* 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? thanks, -chris -- 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
