Re: [Xen-devel] Correct format for HVM graphics

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 5 Apr 2012, Stefan Bader wrote:
> On 05.04.2012 13:02, 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 <stefano.stabellini@xxxxxxxxxxxxx>
> > Date:   Mon Jul 4 19:22:00 2011 -0700
> > 
> >     Input: xen-kbdfront - enable driver for HVM guests
> >     
> >     Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> >     Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> >     Signed-off-by: Dmitry Torokhov <dtor@xxxxxxx>
> > 
> > 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
> 
> That would work as well. The downside being that this modification then has to
> go in any kernels between 3.1 and the patch. The approach from the other side
> seemed to make sense so far as it changes generated output that seems targeted
> only at talking to xend. The xen-xm format looks to be usable for xl too. But 
> I
> would suspect that whenever libvirt starts to support xen api/xl/libxen it 
> will
> be using a different interface which then could make use of vfb and vkbd.
> 
> Of course that does not make the change in the kernel less valuable. It 
> prevents
> the wait time whenever someone manually configures things with vfb.
> It just seems to be useless to generate a config that has no use for an
> interface that does not support it.

Nobody is using vfb right now, but vkbd is already enabled in Linux.
This is why it is not that clear to me what we should do on the xend
side: are we going to disable vfb and keep vkbd?

In any case, as I said before, if the alternatives are keeping the wait
time or patching xend, I would go for patching xend.
If we don't think we can fix Linux and backport the fix in a reasonable
time, patching xend might be the only option.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel