From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Gk0-0001im-Fk for qemu-devel@nongnu.org; Wed, 17 Jun 2015 13:03:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5Gjx-0007pH-7o for qemu-devel@nongnu.org; Wed, 17 Jun 2015 13:03:08 -0400 Received: from mail-qc0-x236.google.com ([2607:f8b0:400d:c01::236]:35737) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Gjx-0007pB-3g for qemu-devel@nongnu.org; Wed, 17 Jun 2015 13:03:05 -0400 Received: by qcsf5 with SMTP id f5so15606399qcs.2 for ; Wed, 17 Jun 2015 10:03:04 -0700 (PDT) From: Don Slutz Message-ID: <5581A844.9090203@Gmail.com> Date: Wed, 17 Jun 2015 13:03:00 -0400 MIME-Version: 1.0 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> In-Reply-To: <20150617182322-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: "Michael S. Tsirkin" , Paolo Bonzini Cc: qemu-devel@nongnu.org, Markus Armbruster , Don Slutz , Luiz Capitulino , Anthony Liguori , =?windows-1252?Q?Andreas_F=E4rber?= , Richard Henderson On 06/17/15 12: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. > >> we enable this thing by default (why do we?) > > Sigh. There is a very simple way to add a device in qemu: let user > request it with -device. If one does this, one gets to maintain the > resulting mess without bothering with pc maintainers in any way. > > But of course, everyone implementing a new feature feels it's such a > great thing, and completel zero risk, it must be part of the default > machine. Guess what, one then gets to bother with versioning from day 0. > >>>>> this seems like a big deal ... >>>> >>>> The PC speaker device is also enabled by default. >>> >>> This is historical, isn't it? >> >> Yes, but it has broken 2.3->2.2 migration. >> >> Let's just stop fighting windmills. >> >> Paolo > > I don't see what you are saying. Suddenly guest visible > changes within a machine type are ok? > > So we have a bug, need to fix it, preferably before piling up > more features. The best way imho is for 2.4 to avoid > this device unless requested explicitly. > My take on this is that Michael would like me to have a vmport_rpc=on option, just like vmport=on (which already exists). With a default of off. I have no problem adding it. -Don Slutz