kern/175757: xen pvhvm looses keyboard input from VNC

[Roger Pau Monné]

>Number:         175757
>Category:       kern
>Synopsis:       xen pvhvm looses keyboard input from VNC
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Feb 01 10:40:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator:     Roger Pau Monné
>Release:        9.1 and HEAD
>Organization:
Citrix
>Environment:
FreeBSD  9.1-RELEASE FreeBSD 9.1-RELEASE #0: Thu Jan 31 18:37:40 CET 2013     root@:/usr/obj/root/freebsd/freebsd/sys/XENHVM  amd64
>Description:
I've tried a FreeBSD guest using the XENHVM kernel (release 
9.1), and I've found that when using the XENHVM kernel the keyboard 
input form the vnc client stops working (output to the vnc seems to be 
ok thought), so I have to set up a serial port before switching to 
XENHVM or there's no way to interact with the guest (apart from 
ssh of course).

HEAD also seems to be experiencing the same issue. Is this 
expected/know? I'm using Xen unstable and the device model is  
Qemu-upstream.
>How-To-Repeat:
Install a FeeeBSD guest in Xen and switch to the XENHVM kernel, the keyboard on the VNC stops sending keys to the guest.
>Fix:
The problem is that we set all devices in xenstore that we don't know how to handle to state '6' (closed), which is not right. We should not mess with the state of devices that we cannot handle. The following patch fixes the problem by probing the devices first, and only try to attach the ones that we can handle.

---
From: Roger Pau Monne <roger.pau at citrix.com>
Date: Thu, 31 Jan 2013 17:24:48 +0000
Subject: [PATCH] xenbus: fix device detection

Devices that cannot be handled should not be closed, instead leave
them as is. This prevents closing the vkbd device, which has the
effect of making Qemu stop sending keys to the guest.

Tested with qemu-xen-traditional, qemu-xen and qemu stubdomains, all
working as expected.
---
 sys/xen/xenbus/xenbusb.c |   19 ++++++++++++++++++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/sys/xen/xenbus/xenbusb.c b/sys/xen/xenbus/xenbusb.c
index 3e2d56f..8370195 100644
--- a/sys/xen/xenbus/xenbusb.c
+++ b/sys/xen/xenbus/xenbusb.c
@@ -418,6 +418,9 @@ xenbusb_probe_children(device_t dev)
 	device_t *kids;
 	struct xenbus_device_ivars *ivars;
 	int i, count;
+	struct xenbusb_softc *xbs;
+
+	xbs = device_get_softc(dev);
 
 	if (device_get_children(dev, &kids, &count) == 0) {
 		for (i = 0; i < count; i++) {
@@ -430,7 +433,21 @@ xenbusb_probe_children(device_t dev)
 				continue;
 			}
 
-			if (device_probe_and_attach(kids[i])) {
+			if (device_probe(kids[i])) {
+				/*
+				 * Don't mess the state of devices the kernel
+				 * cannot handle.
+				 */
+				xenbusb_delete_child(dev, kids[i]);
+
+				mtx_lock(&xbs->xbs_lock);
+				xbs->xbs_connecting_children--;
+				mtx_unlock(&xbs->xbs_lock);
+
+				continue;
+			}
+
+			if (device_attach(kids[i])) {
 				/*
 				 * Transition device to the closed state
 				 * so the world knows that attachment will


>Release-Note:
>Audit-Trail:
>Unformatted: