From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44451) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5Ali-0000a4-WC for qemu-devel@nongnu.org; Fri, 02 Aug 2013 04:31:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V5Ala-0003TI-7S for qemu-devel@nongnu.org; Fri, 02 Aug 2013 04:31:26 -0400 Received: from mail-wi0-x22f.google.com ([2a00:1450:400c:c05::22f]:56915) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5Ala-0003Sz-1r for qemu-devel@nongnu.org; Fri, 02 Aug 2013 04:31:18 -0400 Received: by mail-wi0-f175.google.com with SMTP id hq12so297296wib.2 for ; Fri, 02 Aug 2013 01:31:17 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51FB6E4F.4010107@redhat.com> Date: Fri, 02 Aug 2013 10:31:11 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1375362537.4891.28.camel@localhost.localdomain> <51FA6E34.5000404@redhat.com> <51FA8C4D.70308@redhat.com> <51FADFEB.1080804@redhat.com> <51FAE445.3020607@redhat.com> In-Reply-To: <51FAE445.3020607@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] pvpanic device should not be automatically included as an internal device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: aliguori@us.ibm.com, mst@redhat.com, libvir-list@redhat.com, hutao@cn.fujitsu.com, marcel.a@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com On 08/02/2013 12:42 AM, Eric Blake wrote: > On 08/01/2013 04:23 PM, Paolo Bonzini wrote: >>> Automatic devices with no command line argument have proven to be a >>> nightmare for libvirt as well. Although the just-released libvirt 1.1.1 >>> now supports the element for controlling the command line >>> parameters of qemu related to how qemu will behave when the pvpanic >>> device is triggered, I would also welcome having the ability to control >>> whether the guest even has a pvpanic device exposed, just as we can >>> control whether a guest has a memballoon device exposed. >> >> This is quite different from memballoon. >> >> pvpanic is a single I/O port, it doesn't use up a PCI slot (thus >> causing conflicts with other devices at the same address). >> >> Perhaps this issue is simply fixed by making the _STA method >> return 0x0B instead of 0x0F (i.e. turning off the "show in user >> interface" bit). > > 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? The user can still manually install a driver even for a device that is not exposed. Having to manually specify the pvpanic device would be yet another knob that nobody uses. Panic notification is a useful feature that should be supported with no particular intervention from the user. Paolo