From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N5E3n-0007bD-Fh for qemu-devel@nongnu.org; Tue, 03 Nov 2009 02:44:11 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N5E3j-0007YY-PE for qemu-devel@nongnu.org; Tue, 03 Nov 2009 02:44:11 -0500 Received: from [199.232.76.173] (port=36166 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N5E3j-0007YN-JN for qemu-devel@nongnu.org; Tue, 03 Nov 2009 02:44:07 -0500 Received: from mx20.gnu.org ([199.232.41.8]:34696) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N5E3j-00035h-04 for qemu-devel@nongnu.org; Tue, 03 Nov 2009 02:44:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N5E3i-0001Df-5r for qemu-devel@nongnu.org; Tue, 03 Nov 2009 02:44:06 -0500 Message-ID: <4AEFDF35.3020806@redhat.com> Date: Tue, 03 Nov 2009 09:43:49 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1257199759-2941-1-git-send-email-agraf@suse.de> <4AEFCBED.50804@redhat.com> <4AEFCCBA.9050408@redhat.com> <8BA1853F-11C9-44B1-9FDB-1DFDAED40E1B@suse.de> <4AEFCEDA.4030308@redhat.com> <87F51670-CB3F-431C-87B4-A8746F996C6F@suse.de> In-Reply-To: <87F51670-CB3F-431C-87B4-A8746F996C6F@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] Add VirtIO Frame Buffer Support List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: linux-fbdev-devel@lists.sourceforge.net, qemu-devel@nongnu.org, kvm@vger.kernel.org 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.