On Wed, Jun 10, 2009 at 06:43:02PM +0100, Jamie Lokier wrote: > 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. Yes. This clearly isn't what I'm building here. You *can* create a guest without msi-x support by passing an appropriate flag. > 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 And then we'll have the same set of problems there. -- MST _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
