Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc

[Don Slutz]

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
>>>