From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57434) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6dRV-0007ou-UZ for qemu-devel@nongnu.org; Tue, 06 Aug 2013 05:20:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V6dRP-0008AQ-VL for qemu-devel@nongnu.org; Tue, 06 Aug 2013 05:20:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6dRP-00089I-Oa for qemu-devel@nongnu.org; Tue, 06 Aug 2013 05:20:31 -0400 Date: Tue, 6 Aug 2013 12:20:27 +0300 From: Gleb Natapov Message-ID: <20130806092027.GK8218@redhat.com> References: <703333176.9515483.1375697447963.JavaMail.root@redhat.com> <20130805151723.GF877@redhat.com> <1970367422.9695773.1375718517492.JavaMail.root@redhat.com> <20130805161833.GA4244@redhat.com> <51FFD6CE.5090302@redhat.com> <20130805182628.GC4244@redhat.com> <20130806072152.GK10891@redhat.com> <20130806083309.GA11051@redhat.com> <20130806083625.GF8218@redhat.com> <5200B78D.2060708@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <5200B78D.2060708@suse.de> Subject: Re: [Qemu-devel] [SeaBIOS] [PATCH] don't expose pvpanic device in the UI List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?utf-8?Q?F=C3=A4rber?= Cc: Marcel Apfelbaum , seabios@seabios.org, qemu-devel@nongnu.org, "Michael S. Tsirkin" , Gerd Hoffmann , Paolo Bonzini On Tue, Aug 06, 2013 at 10:45:01AM +0200, Andreas F=C3=A4rber wrote: > Am 06.08.2013 10:36, schrieb Gleb Natapov: > > On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote: > >> On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote: > >>>> If you see a mouse in a room, how likely is it that there's > >>>> a single mouse there? > >>>> > >>>> This is a PV technology which to me looks like it was > >>>> rushed through and not only set on by default, but > >>>> without a way to disable it - apparently on the assumption > >>>> there's 0 chance it can cause any damage. Now that > >>>> we do know the chance it's not there, why not go back > >>>> to the standard interface, and why not give > >>>> users a chance to enable/disable it? > >>> You should be able to disable it with: -device pvpanic,ioport=3D0 > >> > >> Doesn't work for me. > > Bug that should be fixed. With this command line _STA should return > > zero. > >=20 > >> Besides, both -device pvpanic and use of ioport=3D0 to disable it > >> are completely undocumented. > >> > > Not the only undocumented thing in QEMU command line :) > [snip] >=20 > I disagree: -device adds a device, not removes one. It will still be > present. >=20 I assume you are answering to the quote about ioport=3D0, not documentation here. ioport=3D0 does not removes the device, it disables it. The claim was it cannot be disabled, it can (assuming no bugs), but it should not be. > I am neutral as to whether qemu-system-x86_64 should have it enabled by > default or not. But if we want to suppress it, then -nodefaults should > disable it. Since libvirt uses that though, it would mean libvirt would > need to add it back, whether via user's XML domain config or by libvirt > itself based on some version/etc. heuristics. >=20 There is no clear definition of what -nodefaults should or should not do. Should it disable PV ACPI hotplug device? Should it create a machine with no mmio/io regions registered at all? -- Gleb.