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

[Paolo Bonzini <pbonzini@redhat.com>]

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.

Paolo