qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Don Slutz
Subject: Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc
Date: Wed, 17 Jun 2015 13:03:00 -0400
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]