qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabi


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities
Date: Wed, 10 Jun 2009 21:22:27 +0300
User-agent: Mutt/1.5.18 (2008-05-17)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]