From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [Qemu-devel] [patch 2/6] Use machine options to emulate
 -no-kvm-irqchip
Date: Thu, 4 Oct 2012 14:16:52 -0300
Message-ID: <20121004171652.GB25143@amt.cnet>
References: <87fw5vhb5a.fsf@codemonkey.ws>
 <20121003150341.GA15164@amt.cnet>
 <506C5DED.7000705@web.de>
 <878vbn4gs9.fsf@codemonkey.ws>
 <506C74E0.8080409@web.de>
 <20121003182652.GA32381@amt.cnet>
 <506D56B1.8090804@web.de>
 <87626qiahv.fsf@codemonkey.ws>
 <506D9D82.2090202@siemens.com>
 <506DAD06.1030803@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org,
	kvm@vger.kernel.org, Gerd Hoffmann <kraxel@redhat.com>
To: Andreas =?iso-8859-1?Q?F=E4rber?= <afaerber@suse.de>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:10549 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1756306Ab2JDRRs (ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 4 Oct 2012 13:17:48 -0400
Content-Disposition: inline
In-Reply-To: <506DAD06.1030803@suse.de>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Thu, Oct 04, 2012 at 05:36:38PM +0200, Andreas F=E4rber wrote:
> Am 04.10.2012 16:30, schrieb Jan Kiszka:
> > On 2012-10-04 16:21, Anthony Liguori wrote:
> >> -no-kvm should be included too.
> >=20
> > Reminds me that we still need to agree on the final default accel s=
trategy.
> >=20
> >>
> >> I just ran across a user that was injecting '-no-kvm-irqchip' in t=
heir
> >> libvirt XML via a custom attribute.  It turned out it was to work =
around
> >> broken MSI support in their funky guest they were running.  It was=
 the
> >> wrong solution to the problem but they were doing it regardless.
> >>
> >> The point is, there are users in the wild using these options.  Th=
ere's
> >> no reason to remove them if they are trivial to maintain (and they=
 are
> >> in their current form).
> >=20
> > So let's define a consistent policy for them all:
> >  - warn on the command line on use
>=20
> >  - avoid adding them to the help or other user documentation
>=20
> That's dangerous - at some point someone will notice and propose a pa=
tch
> documenting them and the reviewers may have forgotten by then why it =
was
> not documented in the first place. Better clearly document them in he=
lp
> output as "DEPRECATED, to be removed in future versions" or so.

Adding the policy to docs/qemukvm-compat-commands-policy.txt should wor=
karound
that problem.

And a friendly text on the announce e-mail.

> Andreas
>=20
> >  - keep them until we rework the whole command line
> >=20
> > Jan
> >=20