From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5ek1-0007sV-V8 for qemu-devel@nongnu.org; Thu, 18 Jun 2015 14:40:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5ejx-0006h7-Sq for qemu-devel@nongnu.org; Thu, 18 Jun 2015 14:40:45 -0400 Received: from omzsmtpe04.verizonbusiness.com ([199.249.25.207]:28427) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5ejx-0006dO-Jr for qemu-devel@nongnu.org; Thu, 18 Jun 2015 14:40:41 -0400 From: Don Slutz Message-ID: <558310A4.2000302@one.verizon.com> Date: Thu, 18 Jun 2015 14:40:36 -0400 MIME-Version: 1.0 References: <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> <5581A844.9090203@Gmail.com> <5581AAF0.3000307@redhat.com> <5581AD8C.40202@redhat.com> <5581AFA9.1090802@Gmail.com> <20150617205714-mutt-send-email-mst@redhat.com> In-Reply-To: <20150617205714-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" , Don Slutz Cc: Markus Armbruster , "qemu-devel@nongnu.org" , Luiz Capitulino , Anthony Liguori , Paolo Bonzini , =?windows-1252?Q?Andreas_F=E4rb?= =?windows-1252?Q?er?= , Richard Henderson On 06/17/15 14:58, Michael S. Tsirkin wrote: > On Wed, Jun 17, 2015 at 01:34:33PM -0400, Don Slutz wrote: >> On 06/17/15 13:25, Paolo Bonzini wrote: >>> >>> >>> On 17/06/2015 19:14, Paolo Bonzini wrote: >>>> >>>> >>>> On 17/06/2015 19:03, Don Slutz wrote: >>>>> 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. >>>> >>>> It wouldn't be enough, because dc->vmsd would be non-NULL anyway. >>>> >>>> (But yes, that option would be a good thing anyway). >>> >>> Even better would be to have a "-global vmport.rpc=no" option. It would >>> be simpler to disable it in existing machine types. >>> >> >> Either way I can avoid the device creation... Unless I hear otherwise I >> will go the global way. Since the default would be no, should I also >> make the default =yes for the 2.4 pc? >> >> -Don Slutz >> >> -Don Slutz > > Can you use -device vmport_rpc, and avoid adding code to the default pc? > I have made this change (drop default creation, require -device to use) and so far testing looks good. -Don Slutz >>> Paolo >>>