From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46216) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6PYT-0005Yg-HC for qemu-devel@nongnu.org; Mon, 05 Aug 2013 14:30:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V6PYP-0001mY-Dg for qemu-devel@nongnu.org; Mon, 05 Aug 2013 14:30:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25525) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6PYO-0001m9-Ni for qemu-devel@nongnu.org; Mon, 05 Aug 2013 14:30:49 -0400 Date: Mon, 5 Aug 2013 21:32:18 +0300 From: "Michael S. Tsirkin" Message-ID: <20130805183218.GD4244@redhat.com> References: <1375688843-19573-1-git-send-email-hutao@cn.fujitsu.com> <20130805081055.GA356@redhat.com> <20130805081617.GB2258@redhat.com> <20130805091826.GA877@redhat.com> <20130805092044.GH2258@redhat.com> <20130805150333.GC877@redhat.com> <20130805160421.GB15901@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20130805160421.GB15901@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: Marcel Apfelbaum , Hu Tao , seabios@seabios.org, qemu-devel@nongnu.org, Gerd Hoffmann , Paolo Bonzini , Andreas =?iso-8859-1?Q?F=E4rber?= On Mon, Aug 05, 2013 at 07:04:22PM +0300, Gleb Natapov wrote: > On Mon, Aug 05, 2013 at 06:03:34PM +0300, Michael S. Tsirkin wrote: > > On Mon, Aug 05, 2013 at 12:20:44PM +0300, Gleb Natapov wrote: > > > On Mon, Aug 05, 2013 at 12:18:26PM +0300, Michael S. Tsirkin wrote: > > > > On Mon, Aug 05, 2013 at 11:16:17AM +0300, Gleb Natapov wrote: > > > > > On Mon, Aug 05, 2013 at 11:10:55AM +0300, Michael S. Tsirkin wr= ote: > > > > > > On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote: > > > > > > > pvpanic device is an internal default device in qemu. It ma= y cause > > > > > > > problem when upgrading qemu from a version without pvpanic. > > > > > > >=20 > > > > > > > for example: in Windows(let's say XP) the Device manager wi= ll open a > > > > > > > "new device" wizard and the device will appear as an unreco= gnized > > > > > > > device. On a cluster with hundreds of such VMs, If that cl= uster has > > > > > > > a health monitoring service it may show all the VMs in a "n= ot healthy" > > > > > > > state. > > > > > > >=20 > > > > > > > This patch is a workaround to not show pvpanic in UI to avo= id the > > > > > > > problem in Windows. > > > > > > >=20 > > > > > > > Cc: Marcel Apfelbaum > > > > > > > Cc: "Michael S. Tsirkin" > > > > > > > Cc: Paolo Bonzini > > > > > > > Cc: Gerd Hoffmann > > > > > > > Cc: Eric Blake > > > > > > > Cc: "Daniel P. Berrange" > > > > > > > Cc: Andreas F=E4rber > > > > > > > Signed-off-by: Hu Tao > > > > > >=20 > > > > > > Quoting from this discussion: > > > > > > >That may "fix" the issue of a windows guest showing the yel= low ! mark, > > > > > > >but what if, down the road, someone writes an actual window= s driver that > > > > > > >is aware of that port and how to make a windows BSOD write = a panic > > > > > > >notification to the port? How does a user go about install= ing such a > > > > > > >driver if the device is not exposed in the user interface l= ist of > > > > > > >devices? > > > > > >=20 > > > > > > I think the correct way to address this is: > > > > > > - don't create the device by default, only when -device pvpan= ic is > > > > > > present > > > > > > - teach management to supply said -device pvpanic for guests = which > > > > > > support the pvpanic device > > > > > >=20 > > > > > That's just pushing the problem elsewhere. How management suppo= se to know if > > > > > guest support pvpanic device? > > > >=20 > > > > Same as any PV device really. It's exactly the same problem > > > > as with virtio: user configures the XML properly. > > > >=20 > > > Virtio has alternatives. > >=20 > > I don't see why does it matter. In any case, only > > *some* virtio devices have alternatives. > > What about the balloon device? VIRTIO_9P? There are more examples. > > What about e.g. ivshmem? > >=20 > They take very limited pci resources and/or provide functionality that > should not be available for all guests. We do provide ACPI hotplug > device unconditionally. >=20 > > > > > What if initially guest did not have a > > > > > driver, but the it was installed? > > > >=20 > > > > You can reconfigure XML and reboot. > > > >=20 > > > Will it cause Windows reactivation? Maybe after adding several devi= ces? > >=20 > > I don't think it will. > > https://en.wikipedia.org/wiki/Microsoft_Product_Activation > > says: > > Display adapter > > SCSI adapter > > IDE adapter > > Network adapter MAC address > > RAM amount range (e.g. 0-512 MB) > > Processor type and serial number > > Hard drive device and volume serial number > > Optical drive (e.g. DVD-ROM) > >=20 > > As you see we do let people change many parameters > > that do affect activation. > By editing XML user can shoot himself in the foot, we should not preven= t > that. So that's what I'm saying basically. At the moment there's no way to remove this device from XML. That's just wrong. In QEMU, we have a standard way to specify devices with -device. That should be the interface for anything new really unless there's a very compelling reason for something else. *Not* building it into the PC machine type. > It should not be required though. libvirt can pass -device pvpanic by default if nothing is specified in XML. That discussion really has to happen on libvirt list. --=20 MST