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 14:56:04 +0200 Message-ID: <4F7D9664.8080406@canonical.com> References: <4F7C63EE.6000703@canonical.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0082248401099379230==" 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) --===============0082248401099379230== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig87163D122552A0693E0564C0" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig87163D122552A0693E0564C0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 doe= s use the >> vfb form for both the xen-xm and xen-sxpr formats (the latter being us= ed 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 defi= nition >> 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 se= ction 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 >=3D 3 */ >> define a vfb device >=20 > 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: >=20 > commit 5f098ecd4288333d87e2293239fab1c13ec90dae > Author: Stefano Stabellini > Date: Mon Jul 4 19:22:00 2011 -0700 >=20 > Input: xen-kbdfront - enable driver for HVM guests > =20 > Signed-off-by: Stefano Stabellini > Acked-by: Konrad Rzeszutek Wilk > Signed-off-by: Dmitry Torokhov >=20 > 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). >=20 > 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: >=20 > http://marc.info/?l=3Dxen-devel&m=3D133238564132683&w=3D2 That would work as well. The downside being that this modification then h= as 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 tar= geted 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 i= t 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 p= revents 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. Stefan > I think that the right thing to do would be removing the additional wai= t > 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. >=20 > Konrad, do you agree with the last reply I sent? Do you think you can > come up with a patch? Maybe separating non-essential from essential > devices to have two wait loops is not feasible? > In any case, given the current state of affairs, the first patch in the= > thread from Konrad is still better than nothing. --------------enig87163D122552A0693E0564C0 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/ iQIcBAEBCgAGBQJPfZZkAAoJEOhnXe7L7s6jEiUQAJLO5rpRCYErn29avM0Us3bJ CcMb3ARqCqMWoLCGaH/VJ+RWBod84cZE8zNzW1MGH11I0zn6itVWd0IGQJ1BTWGr sMuFR4iy0Z9cVyFxsZZtL+/2ksDOuhG0zOC95uhQGYGUDRIcgX6Uy+8RD/q6YoXI BSrDLDA5Tl7QXqI8jlF1dq62HlzeId2e4S9RVrlxf1L4ChL+4FJHslxXaWfJ7Nb/ KlNoTjdyywGiC9KP/dW5Np5oY8xds8oPqVx1EsqOV/VMRT28UndqRqO9oI68xTgY kVCCyutE8d2eqXH5mu6FdvLS1o8uDiDtNMnUimZlfuXh9QECObMvj03nNDwn6AWX FBUOHazxdY7/QromFIVw/wou8KtdvLxZ0EC41z3nqiGHdrB8OXL7PVD70tsH11fg aRDdFu7Kkn2OjNh0MEfv6geWrMRvdt3dksBPadqWgrLmQb0OL1HgmnV684qnrdaK f1LVwCdlZJpRKC1JXlKG+h1qXRHV/YglT9fiEZC75lwHPIvIPIpQFoIA/GlPt2YZ YmCYQcEV/IQLApwXLMRd53BI6FiSOB4OJDDh/XjT8X9s0PSHw0BdRiL4gTjXzHZi 5sWXDsLdzdpPc193sOY4d04BSMdhnFAIv7U2IuuBx2XZitazqNWl6AZJFKTuHxWA /Um95VIhlNUeJmSelFEg =gSq+ -----END PGP SIGNATURE----- --------------enig87163D122552A0693E0564C0-- --===============0082248401099379230== 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 --===============0082248401099379230==--