From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41433) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6g2a-0007Bv-GT for qemu-devel@nongnu.org; Tue, 06 Aug 2013 08:07:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V6g2U-0007nN-GD for qemu-devel@nongnu.org; Tue, 06 Aug 2013 08:07:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28262) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6g2U-0007n7-8b for qemu-devel@nongnu.org; Tue, 06 Aug 2013 08:06:58 -0400 Date: Tue, 6 Aug 2013 15:08:32 +0300 From: "Michael S. Tsirkin" Message-ID: <20130806120832.GB14396@redhat.com> References: <20130805161833.GA4244@redhat.com> <51FFD6CE.5090302@redhat.com> <20130805182628.GC4244@redhat.com> <20130806072152.GK10891@redhat.com> <20130806083309.GA11051@redhat.com> <20130806083625.GF8218@redhat.com> <20130806092148.GC11051@redhat.com> <20130806093247.GL8218@redhat.com> <5200D15E.4030102@suse.de> <20130806110035.GS8218@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20130806110035.GS8218@redhat.com> Content-Transfer-Encoding: quoted-printable 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: Gleb Natapov Cc: minyard@acm.org, Marcel Apfelbaum , seabios@seabios.org, qemu-devel@nongnu.org, Gerd Hoffmann , Paolo Bonzini , Andreas =?iso-8859-1?Q?F=E4rber?= On Tue, Aug 06, 2013 at 02:00:35PM +0300, Gleb Natapov wrote: > On Tue, Aug 06, 2013 at 12:35:10PM +0200, Andreas F=E4rber wrote: > > Am 06.08.2013 11:32, schrieb Gleb Natapov: > > > On Tue, Aug 06, 2013 at 12:21:48PM +0300, Michael S. Tsirkin wrote: > > >> On Tue, Aug 06, 2013 at 11:36:25AM +0300, Gleb Natapov wrote: > > >>> On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrot= e: > > >>>> On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote: > > >>>>>> 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=3D= 0 > > >>>> > > >>>> Doesn't work for me. > > >>> Bug that should be fixed. With this command line _STA should retu= rn > > >>> zero. > > >> > > >> It doesn't have anything to do with _STA: device still appears in = QOM. > > > You said disabled, not removed. So does -global pvpanic,ioport=3D0 > > > disables the device for you? > > >=20 > > >> It's a QEMU issue, devices that are added with -device are > > >> documented in -device help and removed by dropping them from > > >> command line. Devices added by default have no way to > > >> be dropped from QOM except -nodefaults. > > >> > > > Are you saying that because pvpanic is added automatically QEMU -de= vice > > > help does not print help about it? Why not fix that? What QEMU --he= lp > > > issues has to do with deciding which devices should or should not b= e > > > present by default? > >=20 > > You misunderstand: -device pvpanic,? will document that there is a > > numeric port property, which as such is self-documenting. But there's= no > Yes, this is how I found it. >=20 > > way for us to document there that port=3D0 has special meaning of "di= sable > > this device in ACPI". > >=20 > Adding capability to describe a property should solve that and is a goo= d > idea regardless, no? "pvpanic.ioport=3Duint16" is not very descriptive. >=20 >=20 > > Disabling a device usually requires to not include that device (or in > > the future to "unrealize" it), which would require some way to suppre= ss > > having the device created internally by default. As done for floppy, > > serial, etc. devices in x86 IIUC, which are in the same PIO situation= as > > the pvpanic device, except that they represent physical devices. > > Adding some -no-pvpanic switch might be an alternative. And if not do= ne > > already, disabling the pvpanic device should definitely be documented > > for the man page. > We should not add -no-pvpanic! If there is a legitimate use for > -no-pvpanic we should go with MST suggestion and do not create it by > default. The question is why would anyone use -no-pvpanic? Legit reason= , > not just "to remove pvpanic". To be able to emulate a real hardware system without any PV devices. I think it's a reasonable requirement. > >=20 > > To me this is less a concrete problem with Windows guests but a > > conceptual question of how we go about enabling/disabling QEMU device= s > > in a hopefully consistent way. > Agree. Now I see that some devises always present (even with -nodefualt= s) > and some do not. The logic is not clear, but seams to be: if there is > not legit reason to disable device or for stable topology device > placemen need to be controlled, disable it with -nodefualts. In that > case I do not see why pvpanic would not be always present. >=20 > The reason this whole thread started with is non issue. >=20 > >=20 > > Writing a driver does not solve it fully, you'd still need to activel= y > > install that driver, same issue as with virtio. virtio is opt-in, so = for > > customers not using our VM Driver Pack we offer AHCI as driver-less > > alternative. > There is no functionality loss without a driver. User is not required > to install drivers. > >=20 > > I wonder if IPMI might be such an alternative in the future, in which > > case we should come up with some way to fully disable pvpanic device > > creation. CC'ing Corey. > >=20 > IPMI was considered, to complicated for what was needed. >=20 > -- > Gleb.