qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Alexander Graf <agraf@suse.de>
Cc: linux-fbdev-devel@lists.sourceforge.net, qemu-devel@nongnu.org,
	kvm@vger.kernel.org
Subject: [Qemu-devel] Re: [PATCH] Add VirtIO Frame Buffer Support
Date: Tue, 03 Nov 2009 09:43:49 +0200	[thread overview]
Message-ID: <4AEFDF35.3020806@redhat.com> (raw)
In-Reply-To: <87F51670-CB3F-431C-87B4-A8746F996C6F@suse.de>

On 11/03/2009 08:39 AM, Alexander Graf wrote:
>
> On 03.11.2009, at 07:34, Avi Kivity wrote:
>
>> On 11/03/2009 08:27 AM, Alexander Graf wrote:
>>>
>>>> How does it work today?
>>>
>>> You boot into a TERM=dumb line based emulation on 3270 (worst thing 
>>> haunting people's nightmares ever), trying to get out of that mode 
>>> as quickly as possible and off into SSH / VNC.
>>
>> Despite the coolness factor, IMO a few minutes during install time do 
>> not justify a new hardware model and a new driver.
>
> It's more than just coolness factor. There are use cases out there 
> (www.susestudio.com) that don't want to rely on the guest exporting a 
> VNC server to the outside just to access graphics. 

Instead you rely on the guest using virtio-fb. Since we have to make 
guest modifications, why not go for the simpler ones?

> You also want to see boot messages, have a console login screen, 

virtio-console does that, except for the penguins.  Better, since you 
can scroll back.

> be able to debug things without switching between virtio-console and 
> vnc, etc. etc.

Render virtio-console on your vnc session.  We do that already, no? 
(well, the host's vnc session, not the guest's).

> The hardware model isn't exactly new either. It's just the next 
> logical step to a full PV machine using virtio. If the virtio-fb stuff 
> turns out to be really fast and reliable, I could even imagine it 
> being the default target for kvm on ppc as well, as we can't switch 
> resolutions on the fly there atm.
>

We could with vmware-vga.

>>
>> Why?  the guest will typically have networking when it's set up, so 
>> it should have network access during install.  You can easily use 
>> slirp redirection and the built-in dhcp server to set this up with 
>> relatively few hassles.
>
> That's how I use it right now. It's no fun.
>

The toolstack should hide the unfun parts.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

  reply	other threads:[~2009-11-03  7:44 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-02 22:09 [Qemu-devel] [PATCH] Add VirtIO Frame Buffer Support Alexander Graf
     [not found] ` <20091102223249.GC22301@localhost>
     [not found]   ` <D295329B-4DE0-4935-8C6B-D45042E72826@suse.de>
2009-11-02 23:24     ` [Qemu-devel] Re: [Linux-fbdev-devel] " Alexander Graf
2009-11-02 23:57       ` Ondrej Zajicek
2009-11-02 23:59         ` Alexander Graf
2009-11-03  6:21 ` [Qemu-devel] " Avi Kivity
2009-11-03  6:22   ` Alexander Graf
2009-11-03  6:24     ` Avi Kivity
2009-11-03  6:27       ` Alexander Graf
2009-11-03  6:34         ` Avi Kivity
2009-11-03  6:39           ` Alexander Graf
2009-11-03  7:43             ` Avi Kivity [this message]
2009-11-03  7:50               ` Alexander Graf
2009-11-03  8:20                 ` Avi Kivity
2009-11-03  8:26                   ` Alexander Graf
2009-11-03  8:53                     ` Avi Kivity
2009-11-03 15:14                       ` Anthony Liguori
2009-11-03 15:57                         ` Avi Kivity
2009-11-03 11:25             ` Vincent Hanquez
2009-11-03  9:38               ` Avi Kivity
2009-11-03 15:29                 ` [Linux-fbdev-devel] " Ondrej Zajicek
2009-11-03 16:05                   ` Avi Kivity
2009-11-03 16:53                     ` Ondrej Zajicek
2009-11-03 17:33                     ` Paolo Bonzini
2009-11-04 16:09                 ` Vincent Hanquez
2009-11-04 16:35                   ` Anthony Liguori
2009-11-05  9:04                     ` Avi Kivity
2009-11-06  2:39   ` Jamie Lokier
2009-11-06  3:05     ` Anthony Liguori
2009-11-05 11:36 ` Michael S. Tsirkin

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=4AEFDF35.3020806@redhat.com \
    --to=avi@redhat.com \
    --cc=agraf@suse.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=qemu-devel@nongnu.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).