Paul Brook wrote: > > > caps can be anywhere, but we don't expect it to change during machine > > > execution lifetime. > > > > > > Or I am just confused by the name "pci_device_load" ? > > > > Right. So I want to load an image and it has capability X at offset Y. > > wmask has to match. I don't want to assume that we never change Y > > for the device without breaking old images, so I clear wmask here > > and set it up again after looking up capabilities that I loaded. > > We should not be loading state into a different device (or a similar device > with a different set of capabilities). > > If you want to provide backwards compatibility then you should do that by > creating a device that is the same as the original. As I mentioned in my > earlier mail, loading a snapshot should never do anything that can not be > achieved through normal operation. If you can create a machine be restoring a snapshot which you can't create by normally starting QEMU, then you'll soon have guests which work fine from their snapshots, but which cannot be booted without a snapshot because there's no way to boot the right machine for the guest. Ssomeone might even have guests like that for years without noticing, because they always save and restore guest state using snapshots, then one day they simply want to boot the guest from it's disk image and find there's no way to do it with any QEMU which runs on their host platform. I think the right long term answer to all this is a way to get QEMU to dump it's current machine configuration in glorious detail as a file which can be reloaded as a machine configuration. -- Jamie _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
