From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] [patch 2/6] Use machine options to emulate -no-kvm-irqchip Date: Thu, 04 Oct 2012 18:04:31 +0200 Message-ID: <506DB38F.4010704@siemens.com> References: <20121003105255.972669952@amt.cnet> <20121003105509.391284251@amt.cnet> <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: Anthony Liguori , Marcelo Tosatti , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , Gerd Hoffmann To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Return-path: Received: from goliath.siemens.de ([192.35.17.28]:34172 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750827Ab2JDQEp (ORCPT ); Thu, 4 Oct 2012 12:04:45 -0400 In-Reply-To: <506DAD06.1030803@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 2012-10-04 17:36, 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. >> >> Reminds me that we still need to agree on the final default accel st= rategy. >> >>> >>> I just ran across a user that was injecting '-no-kvm-irqchip' in th= eir >>> libvirt XML via a custom attribute. It turned out it was to work a= round >>> 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. The= re's >>> no reason to remove them if they are trivial to maintain (and they = are >>> in their current form). >> >> 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. -M is marked as deprecated in the file that you would have to mess up. Jan --=20 Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux