From: Don Slutz <dslutz@verizon.com>
To: "Michael S. Tsirkin" <mst@redhat.com>, Don Slutz <don.slutz@gmail.com>
Cc: "Markus Armbruster" <armbru@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Luiz Capitulino" <lcapitulino@redhat.com>,
"Anthony Liguori" <aliguori@amazon.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Andreas Färber" <afaerber@suse.de>,
"Richard Henderson" <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc
Date: Thu, 18 Jun 2015 14:40:36 -0400 [thread overview]
Message-ID: <558310A4.2000302@one.verizon.com> (raw)
In-Reply-To: <20150617205714-mutt-send-email-mst@redhat.com>
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
>>>
next prev parent reply other threads:[~2015-06-18 18:40 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-12 14:05 [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [BUGFIX][PATCH v7 1/9] vmport: The io memory region needs to be at least a size of 4 Don Slutz
2015-06-12 22:38 ` Eric Blake
2015-06-15 13:53 ` Don Slutz
2015-06-15 15:09 ` Eric Blake
2015-06-15 16:15 ` Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [PATCH v7 2/9] vmport: Switch to trace Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [BUGFIX][PATCH v7 3/9] vmport: Fix vmport_cmd_ram_size Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [PATCH v7 4/9] vmport_rpc: Add the object vmport_rpc Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [PATCH v7 5/9] vmport_rpc: Add limited support of VMware's hyper-call rpc Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [PATCH v7 6/9] vmport_rpc: Add QMP access to vmport_rpc object Don Slutz
2015-06-15 15:53 ` Eric Blake
2015-06-17 16:42 ` Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [PATCH v7 7/9] vmport_rpc: Add migration Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [PATCH v7 8/9] vmport: Add VMware all ring hack Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [PATCH v7 9/9] MAINTAINERS: add VMware port Don Slutz
2015-06-17 13:44 ` [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc Paolo Bonzini
2015-06-17 22:26 ` Don Slutz
2015-06-18 7:58 ` Michael S. Tsirkin
2015-06-18 8:33 ` Paolo Bonzini
2015-06-18 9:40 ` Michael S. Tsirkin
2015-06-18 8:33 ` Paolo Bonzini
2015-06-17 14:11 ` Michael S. Tsirkin
2015-06-17 14:13 ` Paolo Bonzini
2015-06-17 14:18 ` Michael S. Tsirkin
2015-06-17 14:27 ` Paolo Bonzini
2015-06-17 14:29 ` Michael S. Tsirkin
2015-06-17 16:17 ` Paolo Bonzini
2015-06-17 16:29 ` Michael S. Tsirkin
2015-06-17 16:48 ` Paolo Bonzini
2015-06-17 18:43 ` Michael S. Tsirkin
2015-06-17 19:15 ` Paolo Bonzini
2015-06-17 19:22 ` Michael S. Tsirkin
2015-06-17 19:24 ` Paolo Bonzini
2015-06-17 19:29 ` Michael S. Tsirkin
2015-06-17 17:03 ` Don Slutz
2015-06-17 17:14 ` Paolo Bonzini
2015-06-17 17:25 ` Paolo Bonzini
2015-06-17 17:34 ` Don Slutz
2015-06-17 18:58 ` Michael S. Tsirkin
2015-06-18 18:40 ` Don Slutz [this message]
2015-06-17 18:45 ` Michael S. Tsirkin
2015-06-17 18:45 ` Michael S. Tsirkin
2015-06-18 7:03 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=558310A4.2000302@one.verizon.com \
--to=dslutz@verizon.com \
--cc=afaerber@suse.de \
--cc=aliguori@amazon.com \
--cc=armbru@redhat.com \
--cc=don.slutz@gmail.com \
--cc=lcapitulino@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.