qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Juan Quintela <quintela@redhat.com>,
	Amit Shah <amit.shah@redhat.com>,
	mst@redhat.com, qemu-devel@nongnu.org,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	kraxel@redhat.com, Marcel Apfelbaum <marcel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH V3] hw/virtio: Add PCIe capability to virtio devices
Date: Thu, 5 Nov 2015 18:22:10 +0000	[thread overview]
Message-ID: <20151105182209.GC2445@work-vm> (raw)
In-Reply-To: <20151105174216.GQ4180@thinpad.lan.raisama.net>

* Eduardo Habkost (ehabkost@redhat.com) 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 / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2015-11-05 18:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-29 11:56 [Qemu-devel] [PATCH V3] hw/virtio: Add PCIe capability to virtio devices Marcel Apfelbaum
2015-10-30 15:20 ` Eduardo Habkost
2015-11-01  9:15   ` Marcel Apfelbaum
2015-11-02  9:07     ` Cornelia Huck
2015-11-02  9:20       ` Marcel Apfelbaum
2015-11-02  9:54         ` Cornelia Huck
2015-11-02 10:01           ` Marcel Apfelbaum
2015-11-02 12:05             ` Cornelia Huck
2015-11-02 12:12               ` Marcel Apfelbaum
2015-11-05 17:42                 ` Eduardo Habkost
2015-11-05 18:22                   ` Dr. David Alan Gilbert [this message]
2015-11-05 18:44                     ` Marcel Apfelbaum
2015-11-05 18:51                       ` Dr. David Alan Gilbert
2015-11-02  9:42 ` Greg Kurz
2015-11-02  9:53   ` Marcel Apfelbaum
2015-11-08 17:10 ` Michael S. Tsirkin
2015-11-08 18:13   ` Marcel Apfelbaum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151105182209.GC2445@work-vm \
    --to=dgilbert@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=ehabkost@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).