WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: Is: Xen 4.1.1, xend, HVM, 3.1 kernel; Was:Re: [Xen-devel] xen 4.2 un

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: Is: Xen 4.1.1, xend, HVM, 3.1 kernel; Was:Re: [Xen-devel] xen 4.2 unstable; HVM; 2.6.39.3; HD/Network card error
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Thu, 10 Nov 2011 17:20:52 +0000
Cc: "xen-users@xxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>, Walter Robert Ditzler <ditwal001@xxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 10 Nov 2011 09:24:02 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20111110171435.GA6616@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <alpine.DEB.2.00.1107201238440.12963@kaball-desktop> <!&!AAAAAAAAAAAYAAAAAAAAAOJK0u4CH31Kl5v1RPAzyrZCgQAAEAAAAIMchHuG/6dIqtJ7GgPrsOEBAAAAAA==@xxxxxxxxx> <!&!AAAAAAAAAAAYAAAAAAAAAOJK0u4CH31Kl5v1RPAzyrZCgQAAEAAAAAKIP0TTIelKl7OMHw7/aSQBAAAAAA==@xxxxxxxxx> <alpine.DEB.2.00.1107251142270.12963@kaball-desktop> <!&!AAAAAAAAAAAYAAAAAAAAAOJK0u4CH31Kl5v1RPAzyrZCgQAAEAAAAICr5HMuz3FOpEbmgui+XxgBAAAAAA==@xxxxxxxxx> <alpine.DEB.2.00.1107251748160.12963@kaball-desktop> <20111103173837.GA21554@xxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1111071646210.3519@kaball-desktop> <20111107212619.GA24889@xxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1111081058060.3519@kaball-desktop> <20111110171435.GA6616@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Thu, 10 Nov 2011, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 08, 2011 at 11:09:11AM +0000, Stefano Stabellini wrote:
> > On Mon, 7 Nov 2011, Konrad Rzeszutek Wilk wrote:
> > > > > XENBUS: Timeout connecting to device: device/vkbd/0 (local state 3, 
> > > > > remote state 1)
> > > > > [which seems odds as the vkb from VNC looks to be working]
> > > > 
> > > > Thanks for pointing this out: I enabled vkbd in upstream qemu but I
> > > > forgot to do the same in qemu-xen so as a result you would get failures
> > > > of this kind.
> > > 
> > > Oh boy. Seems that there are a couple of issues here. It might be that the
> > > timeout I had experienced was _only_ related to this and the other were 
> > > red-herrings.
> > > 
> > > You might want to make sure M A Young and Stefan Bader are CC-ed on your 
> > > Xen 4.1.1
> > > patch so they can pull it in.
> > 
> > Actually I have just realized that the vkbd feature couldn't possibly
> > have been backported to xen 4.1.1. In fact I didn't even add any vkbd
> > devices for HVM guests in XL in xen-unstable yet.
> > Of course this was to avoid situations like this one.
> > 
> > So my guess is that when you use "vfb" in an HVM guest config file
> > you cause xend to create a vkbd device that is without backend.
> > A PV on HVM guest would try to connect to it but it wouldn't get any
> > response back so it would timeout.
> > 
> > The solution to this problem is to avoid using vfb in the config file. I
> > strongly hope that the config file you showed us before is not generated
> > by libvirt somehow. If it is we need to file a bug against libvirt.
> 
> And sure enough, if I modify the xm file libvirt creates to be:
> 
> [root@phenom ~]# diff /tmp/b.autogenerated /tmp/b
> 8c8
> < boot = "c"
> ---
> > boot = "dc"
> 20c20,21
> < vfb = [ "type=vnc,vncunused=1" ]
> ---
> > #vfb = [ "type=vnc,vncunused=1,keymap=en-us" ]
> > vnc=1
> 
> 
> It bootes right up. Is this a new behavior with xend? I would think
> not - it just seems that the 'vfb' for HVM guests worked in the past -
> as Windows boots just fine? And I think the accelerated drivers
> for Windows take advantage of that?
> 

Have you noticed that the vnc parameters inside vfb look very similar to
the normal vnc parameters outside vfb?
Xend happens to store both set of vnc parameters the same way, using
the same internal variables. That is why it happened to work in the
past. It was working by pure chance, I have no idea what changed.
Windows doesn't take advance of vfb or vkbd at all.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel