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
--
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
