xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Bader <stefan.bader@canonical.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: Correct format for HVM graphics
Date: Thu, 05 Apr 2012 17:35:05 +0200	[thread overview]
Message-ID: <4F7DBBA9.3010902@canonical.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1204051622530.15151@kaball-desktop>


[-- Attachment #1.1: Type: text/plain, Size: 2456 bytes --]

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 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 modify 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 = [ 'vnc=1, ...' ]" or similar for sxpr 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. Providing the
>> means to run guests is something rather under our control. Be it Ubuntu 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 libvirt 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 wrong version).
>>
>> The kernel change to remove delays imo is a completely separate issue. And if
>> just as an additional "pre-caution".
> 
> 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.
> 
> 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 agreeing
most of the time... just not always about the same thing. ;) Which is probably
due to me trying to wrap the issue into too many words...


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

  reply	other threads:[~2012-04-05 15:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-04 15:08 Correct format for HVM graphics Stefan Bader
2012-04-05 11:02 ` Stefano Stabellini
2012-04-05 12:51   ` Konrad Rzeszutek Wilk
2012-04-05 12:56   ` Stefan Bader
2012-04-05 14:26     ` Stefano Stabellini
2012-04-05 15:15       ` Stefan Bader
2012-04-05 15:29         ` Stefano Stabellini
2012-04-05 15:35           ` Stefan Bader [this message]
2012-04-20 16:28 ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F7DBBA9.3010902@canonical.com \
    --to=stefan.bader@canonical.com \
    --cc=konrad.wilk@oracle.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).