qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH V3] hw/virtio: Add PCIe capability to virtio dev


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH V3] hw/virtio: Add PCIe capability to virtio devices
Date: Thu, 5 Nov 2015 18:22:10 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

* Eduardo Habkost (address@hidden) wrote:
> On Mon, Nov 02, 2015 at 02:12:32PM +0200, Marcel Apfelbaum wrote:
> > On 11/02/2015 02:05 PM, Cornelia Huck wrote:
> [...]
> > >What's the word on compat machines and new device types, btw.? If we
> > >fire up a compat machine, we can still specify devices that were added
> > >with later machine versions, but of course we can't migrate to an old
> > >machine as the device types did not exist there. Do we want to give the
> > >user a hint here by disallowing new device types?
> > >
> > 
> > I started to wonder about this too, so I added to this thread the migration
> > maintainers that should be qualified to answer this :)
> 
> This looks no different from all other features that are available on
> newer QEMU versions and prevent migration to older hosts (even ones that
> are not guest-visible, like backend configuration). Management can
> easily detect the unavailability of those features in other hosts, long
> before trying migration (and have better ways to warn the user if
> necessary).
> 
> Also, it looks like a potential nightmare for downstream maintainers
> that cherry-pick and rebase patches, so I hope we don't consider
> implementing that. :)

   a) It's fine to add new devices and allow them to be used with old machine
      types
   b) The rule is that any old machine type used in the way it used to be used
      must stay the same.
   c) That also means it's fine to add new features that can be turned on
      with old machine types; as long as the default is that they behave
      just like they always did.
   d) If you know a new device just isn't going to work with an old
      machine type then please make it fail early with an obvious
      error.

Having said all that; I have seen requests for some magic which would
tell the management tool whether something is 'safe for migration';
so imagine that a user has a pile of hosts, some of which have qemu 2.n on
and some have qemu 2.n+1 ; if he creates his VM on 2.n+1 and uses
a feature that's new in 2.n+1 the management tool can't warn him
because they've not yet expressed an interest in migrating to
the 2.n machine.

Dave
 
> 
> -- 
> Eduardo
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

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