From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: Correct format for HVM graphics Date: Thu, 05 Apr 2012 17:15:18 +0200 Message-ID: <4F7DB706.5010909@canonical.com> References: <4F7C63EE.6000703@canonical.com> <4F7D9664.8080406@canonical.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2928090477756891074==" Return-path: 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: Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2928090477756891074== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig73B8E73C3E5D12671FAFA157" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig73B8E73C3E5D12671FAFA157 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05.04.2012 16:26, Stefano Stabellini wrote: > 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 so= me HVM setup >>>> problems via libvirt. One part was graphics and the problem seemed t= o be that >>>> when creating a new instance through xend for HVM, the use of vfb wa= s wrong. It >>>> mostly does work but then also defines a vkbd which takes a long tim= e 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 d= oes 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 numbe= r 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 de= finition >>>> 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 wh= en 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 curren= t 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 >=3D 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, b= ut >>> 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 >>> =20 >>> 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 Lin= ux >>> side, see the following thread: >>> >>> http://marc.info/?l=3Dxen-devel&m=3D133238564132683&w=3D2 >> >> That would work as well. The downside being that this modification the= n has to >> go in any kernels between 3.1 and the patch. The approach from the oth= er 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 t= oo. But I >> would suspect that whenever libvirt starts to support xen api/xl/libxe= n it will >> be using a different interface which then could make use of vfb and vk= bd. >> >> Of course that does not make the change in the kernel less valuable. I= t 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 a= n >> interface that does not support it. >=20 > 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. My impression is that you (the generic you) would not really want to modi= fy xend too much as it and the xm stack should go away anyway. Instead I would fix libvirt's use of xend when it is known that it is not= working well (if using "vfb =3D [ 'vnc=3D1, ...' ]" or similar for sxpr i= s creating a vkbd and xend/the xm stack does not support it, then just don't use it)= =2E The question of removing the delays is not so much (well yes it is too, b= ut not always in ones own hands) whether it can be done or how quickly. Providin= g the means to run guests is something rather under our control. Be it Ubuntu a= s dom0 or Xenserver. But which kernels are run as guests is not. So, as long as xend does not change its behavior, then changing libvirt i= n a way that does never use the configuration format which causes a vkbd to be cr= eated (for HVM) is ok. And if it gets picked up upstream it helps all users of = libvirt the same. But if xend would change to allow using a vkbd, then it would be good if = that could be synced with a xend version change which could be used inside lib= virt to modify its config output (as it does now but in some way with the wrong v= ersion). The kernel change to remove delays imo is a completely separate issue. An= d if just as an additional "pre-caution". --------------enig73B8E73C3E5D12671FAFA157 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPfbcHAAoJEOhnXe7L7s6j+G8QAJ2JbOJUsKhEipQcZb/WgqW3 zWIoptqSk/Nfk3qVcOQZkTsQObM96Y5RXscODJq8QtSE1EP8fJa8FGXMefCqqJxD d1YJ+LT/4Xqfs0/1R9lzPC2+hbpnBOogU05N3KutxWpLmONC0V4JR5bCtD1CzFvh CI2UvBz01wpYKMkP5rHWHeUSPvzDMbDA8VILBXpmiSOt4FMiMsSdA8HB5sFMkw/T 1l3x8jaTHXWUoI3+B/8xauaqrnNlZQE0A4bi3j/YOzGmqx3i1wwbJwuMzuVSGRck NG9j2cnUY5liFmJrAltdPFhiejZnn9KijbXVOKBoWg3xIJuVocZ9eUCWGZkTnxGS DahaKckcdpsRLztFCXrFz8wpTkLJYGH1+KuYSVwdsyQcQZ0s84W7bBMZ79pi7680 jZYui7URgC5FHFHeOXHFKizCL2FtLujgDSi+0AG29sAH5wksLWB3ixIEoMEmWu+m 2OUdTXP+a0Lu5GpI8bIOIOtfkuxGrdzQQV03ayIkufQXKZBoDiDA0qakjYccpQH1 e/zyOgH27rg1WgTc51zPgsLfeKDtqn/ro46nHMG8xm7MwDtI+Bzy4blkSvW8+3jl Zxi7Nui/4Px946hoPrzn/t5csVnMqa8rYLWST1ZGHdvvCDfXn8C+pksRb7+8bEPh TTQC8u9I/Prvzsg+OFai =YLnV -----END PGP SIGNATURE----- --------------enig73B8E73C3E5D12671FAFA157-- --===============2928090477756891074== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2928090477756891074==--