qemu-devel
[Top][All Lists]
Advanced

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

Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13]


From: Michael S. Tsirkin
Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities]
Date: Sun, 14 Jun 2009 12:34:11 +0300
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

On Fri, Jun 12, 2009 at 04:53:27PM +0100, Mark McLoughlin wrote:
> On Fri, 2009-06-12 at 09:55 -0500, Anthony Liguori wrote:
> > Mark McLoughlin wrote:
> > > On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
> > >   
> > > = Solution - Separate configuration from compat hints =
> > >
> > > As I suggested before:
> > >
> > >   - Allow the VM manager to dump compat hints; this would be an opaque 
> > >     file format, more like the savevm format than a config file
> > >   
> > 
> > How is compat hints different from a device tree?
> > 
> > In my mind, that's what compat hints is.  I don't see another sane way 
> > to implement it.
> 
> A device tree with a different purpose than a config file.
> 
> In its simplest form it could be a device tree with a version number for
> each device[1]. 
> 
> The other obvious piece to add to it would be PCI addresses, so that
> even if you remove a device, the addresses assigned to existing devices
> don't change.

Could you clarify this requirement please?

If we want to remove a device from under a running guest, you need
hotplug. So we can't just remove several lines from the config and hope
that it'll work simply because the PCI address is stable.

OTOH, if you reboot the guest, it's ok for addresses to change.


> Cheers,
> Mark.
> 
> [1] - Adding such a per-device version number to the config file would
> solve problem (2)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to address@hidden
> More majordomo info at  http://vger.kernel.org/majordomo-info.html




reply via email to

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