From patchwork Tue May 22 13:05:05 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gerd Hoffmann X-Patchwork-Id: 160630 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id B8D5BB6FA3 for ; Tue, 22 May 2012 23:05:36 +1000 (EST) Received: from localhost ([::1]:41470 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWomL-0005AV-21 for incoming@patchwork.ozlabs.org; Tue, 22 May 2012 09:05:33 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWom7-00059z-D2 for qemu-devel@nongnu.org; Tue, 22 May 2012 09:05:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWom0-0004Fc-Vo for qemu-devel@nongnu.org; Tue, 22 May 2012 09:05:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58126) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWom0-0004Ei-I4 for qemu-devel@nongnu.org; Tue, 22 May 2012 09:05:12 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4MD59KJ002103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 May 2012 09:05:09 -0400 Received: from rincewind.home.kraxel.org (ovpn-116-33.ams2.redhat.com [10.36.116.33]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q4MD56Af025256; Tue, 22 May 2012 09:05:07 -0400 Message-ID: <4FBB8F01.8090008@redhat.com> Date: Tue, 22 May 2012 15:05:05 +0200 From: Gerd Hoffmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120422 Thunderbird/10.0.4 MIME-Version: 1.0 To: Jan Kiszka References: <4FBA735D.4010701@rdsoftware.de> <4FBB6BD1.9080003@siemens.com> <4FBB8647.4060307@siemens.com> In-Reply-To: <4FBB8647.4060307@siemens.com> X-Enigmail-Version: 1.4 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.132.183.28 Cc: Stefan Hajnoczi , Avi Kivity , Erik Rull , "qemu-devel@nongnu.org" , Marcelo Tosatti Subject: Re: [Qemu-devel] Current differences between qemu --enable-kvm and qemu-kvm? X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Hi, > BTW, if someone could have a look at the VGA diffs and resolve them, > that would be great. There isn't much ... I think we should just make them large enougth that they are practically unlimited. Those are 16bit registers in virtual hardware. Guess we better leave the high bit clear to avoid possible issues with signed integers. So (1<<14) aka 16384 maybe? Or 16000? -#define VGA_RAM_SIZE (8192 * 1024) +#define VGA_RAM_SIZE (16 * 1024 * 1024) That one is more tricky as it breaks migration. I guess qemu has to stick to 8M by default for that reason. We certainly can make the vga memory size configurable via property though, so you can easily go for 16M or even more (or 1M to reduce the memory footprint of your guests when using text mode only). > Gerd, what's the state of switching the BIOS? Postponed to 1.2. Too risky for 1.1, also malc vetoed the switch without seavgabios supporting the vesa protected mode interface which still needs to be done. cheers, Gerd --- a/hw/vga_int.h +++ b/hw/vga_int.h @@ -31,8 +31,8 @@ -#define VBE_DISPI_MAX_XRES 1600 -#define VBE_DISPI_MAX_YRES 1200 +#define VBE_DISPI_MAX_XRES 2560 +#define VBE_DISPI_MAX_YRES 1600 The vgabios (both lgpl'ed and seavgabios) filters the mode list by available memory anyway, so there is no need to keep those low enougth that the xmax * ymax * 32bpp fits into vga memory. And when the vgamem becomes configurable (see below) this will be moot anyway.