On Wed, Jun 10, 2009 at 05:08:15PM +0100, Paul Brook wrote: > On Wednesday 10 June 2009, Michael S. Tsirkin wrote: > > On Wed, Jun 10, 2009 at 04:15:04PM +0100, Paul Brook wrote: > > > > > That's seems just plain wrong to me. > > > > > Loading a VM shouldn't not > > > > > do anything that can't happen during normal operation. > > > > > > > > At least wrt pci, we are very far from this state: load just overwrites > > > > all registers, readonly or not, which can never happen during normal > > > > operation. > > > > > > IMO that code is wrong. We should only be loading things that the guest > > > can change (directly or indirectly). > > > > Making it work this way will mean that minor changes to a device can > > break backwards compatibility with old images, often in surprising ways. > > What are the advantages? > > If you can't create an identical machine from scratch then I don't consider > snapshot/migration to be a useful feature. i.e. as soon as you shutdown and > restart the guest it is liable to break anyway. Why is liable to break? Configuration does not change until you load another image. Look here: void msix_reset(PCIDevice *dev) { if (!(dev->cap_present & QEMU_PCI_CAP_MSIX)) return; ... } So once you load and image with MSIX capability off, it will stay off across guest restarts. > It may be that the snapshot/migration code wants to include a machine config, > and create a new machine from that. However this is a separate issue, and > arguably something your VM manager should be handling for you. > > Paul Since the image already has a necessary information, duplicating it in a separate machine config will just lead to errors. -- MST _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization