From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5IJi-0000EV-OE for qemu-devel@nongnu.org; Wed, 17 Jun 2015 14:44:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5IJd-0000Vu-VJ for qemu-devel@nongnu.org; Wed, 17 Jun 2015 14:44:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49406) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5IJd-0000Vm-Pf for qemu-devel@nongnu.org; Wed, 17 Jun 2015 14:44:01 -0400 Date: Wed, 17 Jun 2015 20:43:57 +0200 From: "Michael S. Tsirkin" Message-ID: <20150617184357.GA7080@redhat.com> References: <1434117956-4929-1-git-send-email-dslutz@verizon.com> <20150617160826-mutt-send-email-mst@redhat.com> <558180A0.8040708@redhat.com> <20150617161716-mutt-send-email-mst@redhat.com> <558183C1.3010402@redhat.com> <20150617162836-mutt-send-email-mst@redhat.com> <55819D8F.3000003@redhat.com> <20150617182322-mutt-send-email-mst@redhat.com> <5581A4E8.8080505@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5581A4E8.8080505@redhat.com> Subject: Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Markus Armbruster , qemu-devel@nongnu.org, Don Slutz , Luiz Capitulino , Anthony Liguori , Andreas =?iso-8859-1?Q?F=E4rber?= , Richard Henderson On Wed, Jun 17, 2015 at 06:48:40PM +0200, Paolo Bonzini wrote: > > > On 17/06/2015 18:29, Michael S. Tsirkin wrote: > > On Wed, Jun 17, 2015 at 06:17:19PM +0200, Paolo Bonzini wrote: > >> > >> > >> On 17/06/2015 16:29, Michael S. Tsirkin wrote: > >>> On Wed, Jun 17, 2015 at 04:27:13PM +0200, Paolo Bonzini wrote: > >>>> > >>>> > >>>> On 17/06/2015 16:18, Michael S. Tsirkin wrote: > >>>>>>> Yes, that's what was done for parallel and pcspk as well. There's no > >>>>>>> infrastructure to avoid it. > >>>>>>> > >>>>>>> Paolo > >>>>> How do you mean? We have multiple ways to keep devices > >>>>> compatible with old versions. > >>>>> Set a new property to skip the extra stuff. > >>>> > >>>> Not if the device didn't have a vmstate at all, unfortunately. > >>> > >>> Skip creating the device completely for old machine types. > >> > >> Which device? The vmstate is tied to the same device that has always > >> been created. > > > > Just disable the new functionality. Make it behave in > > a compatible way. > > Ok. Doesn't solve the fact that the migration stream changes just > because dc->vmsd was NULL and now isn't. We cannot add a subsection: > there is no toplevel section for it to hang it from. It seems pretty obvious: + vmport_rpc = isa_try_create(isa_bus, "vmport_rpc"); + if (vmport_rpc) { + qdev_init_nofail(DEVICE(vmport_rpc)); + } Don't do this. Let user specify the device using -device vmport_rpc. Then all issues just go away. I don't see any reason not to do it like this - we should have done the same for other vmport things. -- MST