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:35:05 +0200 Message-ID: <4F7DBBA9.3010902@canonical.com> References: <4F7C63EE.6000703@canonical.com> <4F7D9664.8080406@canonical.com> <4F7DB706.5010909@canonical.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8275528760848171114==" 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) --===============8275528760848171114== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigFFE3263A409ABEAB6AD0ECC4" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFFE3263A409ABEAB6AD0ECC4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05.04.2012 17:29, Stefano Stabellini wrote: > On Thu, 5 Apr 2012, Stefan Bader wrote: >>> In any case, as I said before, if the alternatives are keeping the wa= it >>> 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 reasonab= le >>> time, patching xend might be the only option. >> >> My impression is that you (the generic you) would not really want to m= odify 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 sxp= r is creating >> a vkbd and xend/the xm stack does not support it, then just don't use = it). >> >> The question of removing the delays is not so much (well yes it is too= , but not >> always in ones own hands) whether it can be done or how quickly. Provi= ding the >> means to run guests is something rather under our control. Be it Ubunt= u as dom0 >> or Xenserver. But which kernels are run as guests is not. >> >> So, as long as xend does not change its behavior, then changing libvir= t in a way >> that does never use the configuration format which causes a vkbd to be= created >> (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 = libvirt to >> modify its config output (as it does now but in some way with the wron= g version). >> >> The kernel change to remove delays imo is a completely separate issue.= And if >> just as an additional "pre-caution". >=20 > So the argument is that ATM libvirt uses a vfb config line with HVM > guests and that is wrong. Yes! :) > I agree with you there, the vfb config line is for PV guests only and > should be removed from any HVM guests configurations. > In fact, even if we add a vfb frontend/backend pair for HVM guests, it > probably won't go through a vfb config line, because the vnc/sdl > configuration would be shared between the vfb and vga devices. >=20 > So you convinced me that is OK to remove it from libvirt :-) Ok, then I try to convince them as well. :) Actually I think we were agre= eing most of the time... just not always about the same thing. ;) Which is pro= bably due to me trying to wrap the issue into too many words... --------------enigFFE3263A409ABEAB6AD0ECC4 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/ iQIcBAEBCgAGBQJPfbupAAoJEOhnXe7L7s6jfooQAKV8umaD9j7NcL8CiUi9ZFz2 nhyC67U62x4xcWmGBeK3hrFo63I5a5BxXvbhYg01qy9E2mbhkKjLd7JDLDsJlac4 m48J0ERl6RB9XPkZpAw25uQmfCdnv6x8YZIdJv3inMwwFpAR4Lp/C3OqQzZBPSId iWg4vIK8FMf47ddpwK+lmayShApv9SdiJGNXyjHpicxq/p8HhAPfeAk5EIeukrbF moqLCu7FEOQo9Qac5w90jGMx3HM4q5Jt1KHnK/HLqP6TgO4OaWLcJlToPuvL34eM Ch0JKriUGVFd4v+LOvccI+GGQzFwDwM7NG/DCMFfiHnJtUZbAq9qpQdLfcWSkm9V q9G+0lBfIvEOlZ0233s1GIdYNH+6sWC2A2Uy9Ju+rcoZ44Aq6GQ7i1E8ST5hPK+L xdUD5woiZnGK/PJK4cgxwnesekxs25OW2JSdCqo4DoO1nA5HGWNmCzX+BvvZke2t aZqwlBeeVTLw34sFHggbR/e27HSi3ugQ4siesYdkQOspUHtfIQ2+nbWgzPzrflHI 66g1sbkBHaBMEc7dOLLD0hdVvS7UjEE2ydHFI/36RZfghSrYu3zVljGVjN22pdJs 4PR1NFgPON12erpD33Lbo13oNevG641mGnH7IReOqZ7lgBIgJiw77pfP8dupG8Tc p7yCDDDOyezFt3q1x3Sv =fyVR -----END PGP SIGNATURE----- --------------enigFFE3263A409ABEAB6AD0ECC4-- --===============8275528760848171114== 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 --===============8275528760848171114==--