From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Correct format for HVM graphics Date: Thu, 5 Apr 2012 08:51:05 -0400 Message-ID: <20120405125105.GB1854@phenom.dumpdata.com> References: <4F7C63EE.6000703@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: Stefan Bader , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Thu, Apr 05, 2012 at 12:02:45PM +0100, Stefano Stabellini wrote: > On Wed, 4 Apr 2012, Stefan Bader wrote: > > Hi Stefano, > > > > quite a while back in time, you and Konrad had a discussion about some HVM setup > > problems via libvirt. One part was graphics and the problem seemed to be that > > when creating a new instance through xend for HVM, the use of vfb was wrong. It > > mostly does work but then also defines a vkbd which takes a long time in the > > xenbus setup to finally fail. > > > > Because this was not a really fatal problem it did take a long time to actually > > get back to it. But now I had a look and found that libvirt indeed does use the > > vfb form for both the xen-xm and xen-sxpr formats (the latter being used to > > create guests). The decision is made based on the xend version number in the HVM > > case. Which would be wrong if I did understand your reply correctly. > > > > I have been testing a patch to libvirt, which would not use a vfb definition > > whenever HVM is used (regardless of xend version). And it does seem to work (xm > > list -l however has a vfb device definition, but the same happens when creating > > the instance with a xm style config file that definitely has no vfb section in > > it). But I am testing based on our 12.04 release which uses Xen 4.1.2. So I want > > to make sure the solution for libvirt is correct for even the current Xen version. > > > > So in short, is this always correct? > > > > if (HVM or (PVM when xend is from xen < 3.0.4 / xend version < 3)) > > do not define a vfb device > > else /* PVM and xend version >= 3 */ > > define a vfb device > > vkbd and vfb can be considered optimizations for PV on HVM guests. > No PV on HVM guest that I know should be able to use vfb right now, but > Linux should be able to use vkbd since: > > commit 5f098ecd4288333d87e2293239fab1c13ec90dae > Author: Stefano Stabellini > Date: Mon Jul 4 19:22:00 2011 -0700 > > Input: xen-kbdfront - enable driver for HVM guests > > Signed-off-by: Stefano Stabellini > Acked-by: Konrad Rzeszutek Wilk > Signed-off-by: Dmitry Torokhov > > XL in xen-unstable enables vkbd for HVM guests so that you can have > keyboard and mouse without usb emulation (that eats significant > resources in dom0). > > That said, vkbd is just a (small) optimization, it is far more > important to get rid of the very annoying wait time at bootup. > Rather than messing with libvirt and xend I would fix it from the Linux > side, see the following thread: > > http://marc.info/?l=xen-devel&m=133238564132683&w=2 > > I think that the right thing to do would be removing the additional wait > time for vfb and vkbd devices in the PV on HVM case. We don't want to > completely remove vfb and vkbd support for PV on HVM guests though. > > Konrad, do you agree with the last reply I sent? Do you think you can Yes. > come up with a patch? Maybe separating non-essential from essential Yes. I was going to after wresting with the dom0_mem=X patches. > devices to have two wait loops is not feasible? It should be no trouble. > In any case, given the current state of affairs, the first patch in the > thread from Konrad is still better than nothing.