[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: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc |
Date: |
Wed, 17 Jun 2015 20:45:06 +0200 |
On Wed, Jun 17, 2015 at 01:03:00PM -0400, 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.
>
> I have no problem adding it.
>
> -Don Slutz
I'd prefer -device instead. This way we don't need to deal
with it in PC code at all.
--
MST
- Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc, (continued)
- Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc, Don Slutz, 2015/06/17
- Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc, Paolo Bonzini, 2015/06/17
- Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc, Paolo Bonzini, 2015/06/17
- Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc, Don Slutz, 2015/06/17
- Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc, Michael S. Tsirkin, 2015/06/17
- Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc, Michael S. Tsirkin, 2015/06/17
- Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc,
Michael S. Tsirkin <=
- Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc, Gerd Hoffmann, 2015/06/18