From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [Qemu-devel] [patch 2/6] Use machine options to emulate -no-kvm-irqchip Date: Thu, 4 Oct 2012 14:14:12 -0300 Message-ID: <20121004171412.GA25143@amt.cnet> References: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Anthony Liguori , qemu-devel@nongnu.org, kvm@vger.kernel.org, Gerd Hoffmann To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:13031 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755819Ab2JDRR6 (ORCPT ); Thu, 4 Oct 2012 13:17:58 -0400 Content-Disposition: inline In-Reply-To: <506D9D82.2090202@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Oct 04, 2012 at 04:30:26PM +0200, Jan Kiszka wrote: > 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 strategy. Default accel=kvm for x86_64 targets, no fallback. Markus's argument is pretty convincing to me: "Friendly perhaps, generating an infinite series of questions "why is my guest slow as molasses?" certainly. And for each instance of the question, there's an unknown number of users who give QEMU a quick try, screw up KVM unknowingly, observe the glacial speed, and conclude it's crap." > > I just ran across a user that was injecting '-no-kvm-irqchip' in their > > 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. There'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 > - avoid adding them to the help or other user documentation > - keep them until we rework the whole command line > > Jan > > -- > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE > Corporate Competence Center Embedded Linux