From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNfPL-0003Mf-Sw for qemu-devel@nongnu.org; Tue, 17 Feb 2015 05:29:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNfPI-0006sM-MI for qemu-devel@nongnu.org; Tue, 17 Feb 2015 05:29:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43497) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNfPI-0006sF-FT for qemu-devel@nongnu.org; Tue, 17 Feb 2015 05:29:32 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1HATVuO025820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 17 Feb 2015 05:29:31 -0500 Date: Tue, 17 Feb 2015 11:29:28 +0100 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Message-ID: <20150217102928.GB4562@potion.brq.redhat.com> References: <1424121788-24560-1-git-send-email-rkrcmar@redhat.com> <1424121788-24560-2-git-send-email-rkrcmar@redhat.com> <1424160049.6014.4.camel@nilsson.home.kraxel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1424160049.6014.4.camel@nilsson.home.kraxel.org> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 1/2] vga: abort instead of shrinking memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org 2015-02-17 09:00+0100, Gerd Hoffmann: > On Mo, 2015-02-16 at 22:23 +0100, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > > Automatic shrinking of vram_size leads to a segfault, because other > > variables depend on being smaller and don't get shrinked. >=20 > --verbose please. Which other variables? I'm sorry, at least rom->surface0_area_size. (It is sourced from qxl->vgamem_size.) rom->surface0_area_size shouldn't be bigger than qxl->vga.vram_size, because it accesses memory allocated by it. > > Implications of shrinking would make the code needlessly complicated; > > assert instead. >=20 > assert isn't an option. vram_size_mb may come from the user (via vga > device properties), so we need a friendly error message here. Agreed, it would require a lot of code to do it though (in cover letter) ... what about just dropping [1/2]? :) ([2/2] does the same job) > Also the loop you are removing makes sure vram_size is a power of two, > removing that is not correct too. (True, the patch should have asserted that as well.)