From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LnLiG-0000sM-W1 for qemu-devel@nongnu.org; Fri, 27 Mar 2009 19:43:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LnLiG-0000s3-Ex for qemu-devel@nongnu.org; Fri, 27 Mar 2009 19:43:48 -0400 Received: from [199.232.76.173] (port=36938 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LnLiG-0000rz-Bh for qemu-devel@nongnu.org; Fri, 27 Mar 2009 19:43:48 -0400 Received: from qw-out-1920.google.com ([74.125.92.149]:55864) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LnLiF-0002E6-Up for qemu-devel@nongnu.org; Fri, 27 Mar 2009 19:43:48 -0400 Received: by qw-out-1920.google.com with SMTP id 5so842610qwf.4 for ; Fri, 27 Mar 2009 16:43:47 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <49CD5D5F.9050105@gmx.net> References: <1238175456-9816-1-git-send-email-glommer@redhat.com> <49CD372B.5090205@gmx.net> <5d6222a80903271345x491c827fg81778d2497843fe7@mail.gmail.com> <49CD5D5F.9050105@gmx.net> Date: Fri, 27 Mar 2009 20:43:47 -0300 Message-ID: <5d6222a80903271643xdc7bd8dra8f481922d64512e@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH] get roms more room. From: Glauber Costa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: aliguori@us.ibm.com On Fri, Mar 27, 2009 at 8:12 PM, Carl-Daniel Hailfinger wrote: > On 27.03.2009 21:45, Glauber Costa wrote: >> On Fri, Mar 27, 2009 at 5:29 PM, Carl-Daniel Hailfinger >> wrote: >> >>> On 27.03.2009 18:37, Glauber Costa wrote: >>> >>>> This patch increases by 50 % the size available for option roms. >>>> The main motivator is that some roms grew bigger than the 64k we >>>> currently allocate for them (Hey, it's 2009!) >>>> >>>> One example is the gpxe project, that produces some roms with 69k, >>>> 70k, etc. The space proposed by this patch actually makes it as >>>> big as 84k. Probably still a fit for some time. >>>> >>>> But there is no free lunch. This space must come from somewhere, >>>> and we take it from vga rom space. Currently, our vga roms are >>>> around 35k in size. With this patch, they will be limited to >>>> 44k, instead of 64k, which seems reasonable to me. >>>> >>>> >>> As a firmware developer, I have to speak up here. Although I agree that >>> option ROMs may be bigger than 64k, replacing one hardcoded magic limit >>> with another hardcoded magic limit seems to be a bit questionable. >>> >>> If you really want to hardcode this instead of calculating it >>> dynamically, please use at least some symbolic constants and tell the >>> user to change the symbolic constants and recompile Qemu if he hits the >>> size limit. >>> >>> This patch reduces the room for the VGA option ROM without checking for >>> its size. If we perform option ROM size checks, we may as well not >>> exclude the VGA option ROM from that check. >>> >> >> We load the VGA rom before loading any option roms. Would you be >> okay with an approach that loads the vga rom, round up its size to the >> next boundary, and assign the remaining space to option roms? >> > > Excellent idea. > Could you please change the error message to tell the user that > VGA+other option ROMs may not exceed a total size? > A check for VGA ROM size to be less than the total allowed size may be > useful to prevent underflows in calculations of the remaining space for > other option ROMs. Such a check already exists. -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."