qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [SeaBIOS] [PATCH] don't expose pvpanic device in the UI


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [SeaBIOS] [PATCH] don't expose pvpanic device in the UI
Date: Mon, 5 Aug 2013 21:32:18 +0300

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 wrote:
> > > > > > On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote:
> > > > > > > pvpanic device is an internal default device in qemu. It may cause
> > > > > > > problem when upgrading qemu from a version without pvpanic.
> > > > > > > 
> > > > > > > for example: in Windows(let's say XP) the Device manager will 
> > > > > > > open a
> > > > > > > "new device" wizard and the device will appear as an unrecognized
> > > > > > > device.  On a cluster with hundreds of such VMs, If that cluster 
> > > > > > > has
> > > > > > > a health monitoring service it may show all the VMs in a "not 
> > > > > > > healthy"
> > > > > > > state.
> > > > > > > 
> > > > > > > This patch is a workaround to not show pvpanic in UI to avoid the
> > > > > > > problem in Windows.
> > > > > > > 
> > > > > > > Cc: Marcel Apfelbaum <address@hidden>
> > > > > > > Cc: "Michael S. Tsirkin" <address@hidden>
> > > > > > > Cc: Paolo Bonzini <address@hidden>
> > > > > > > Cc: Gerd Hoffmann <address@hidden>
> > > > > > > Cc: Eric Blake <address@hidden>
> > > > > > > Cc: "Daniel P. Berrange" <address@hidden>
> > > > > > > Cc: Andreas Färber <address@hidden>
> > > > > > > Signed-off-by: Hu Tao <address@hidden>
> > > > > > 
> > > > > > Quoting from this discussion:
> > > > > >     >That may "fix" the issue of a windows guest showing the yellow 
> > > > > > ! mark,
> > > > > >     >but what if, down the road, someone writes an actual windows 
> > > > > > 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 installing 
> > > > > > such a
> > > > > >     >driver if the device is not exposed in the user interface list 
> > > > > > of
> > > > > >     >devices?
> > > > > > 
> > > > > > I think the correct way to address this is:
> > > > > > - don't create the device by default, only when -device pvpanic is
> > > > > >   present
> > > > > > - teach management to supply said -device pvpanic for guests which
> > > > > >   support the pvpanic device
> > > > > > 
> > > > > That's just pushing the problem elsewhere. How management suppose to 
> > > > > know if
> > > > > guest support pvpanic device?
> > > > 
> > > > Same as any PV device really. It's exactly the same problem
> > > > as with virtio: user configures the XML properly.
> > > > 
> > > Virtio has alternatives.
> > 
> > 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?
> > 
> 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.
> 
> > > > > What if initially guest did not have a
> > > > > driver, but the it was installed?
> > > > 
> > > > You can reconfigure XML and reboot.
> > > > 
> > > Will it cause Windows reactivation? Maybe after adding several devices?
> > 
> > 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)
> > 
> > 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 prevent
> 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.

-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]