From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qo2yR-0007An-29 for qemu-devel@nongnu.org; Mon, 01 Aug 2011 20:36:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qo2yP-0003D8-Of for qemu-devel@nongnu.org; Mon, 01 Aug 2011 20:36:42 -0400 Received: from mail-qy0-f180.google.com ([209.85.216.180]:41157) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qo2yP-0003BF-LI for qemu-devel@nongnu.org; Mon, 01 Aug 2011 20:36:41 -0400 Received: by qyk30 with SMTP id 30so3945150qyk.4 for ; Mon, 01 Aug 2011 17:36:40 -0700 (PDT) Date: Mon, 1 Aug 2011 20:36:38 -0400 From: Kevin O'Connor Message-ID: <20110802003637.GA3046@morn.localdomain> References: <87d3y3p4sc.fsf@nemi.mork.no> <20100414012749.GB29097@morn.localdomain> <87ochmmhma.fsf@nemi.mork.no> <87sjqi9jsx.fsf@nemi.mork.no> <20110707235009.GB12991@morn.localdomain> <87fwmh9puv.fsf@nemi.mork.no> <20110710204100.GA25495@morn.localdomain> <0895461378D74EC49BD787BDBFF8C934@FSCPC> <8739hlb5t4.fsf@nemi.mork.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8739hlb5t4.fsf@nemi.mork.no> Subject: Re: [Qemu-devel] [SeaBIOS] SeaBIOS error with Juniper FreeBSD kernel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?iso-8859-1?Q?Bj=F8rn?= Mork Cc: Brandon Bennett , seabios@seabios.org, qemu-devel@nongnu.org, Sebastian Herbszt On Mon, Aug 01, 2011 at 03:49:11PM +0200, Bjørn Mork wrote: > I just confirmed the issue running > > "JUNOS 11.1R3.5 built 2011-06-25 00:17:21 UTC" > > which is as new as it officially gets at the moment. [...] > Also confirmed that 11.1R3.5 is working with SeaBIOS modified as > follows: [...] > - void *finaltable = malloc_high(structure_table_length); > + void *finaltable = malloc_fseg(structure_table_length); I'm not really sure how best to handle this. The smbios table can be larger than the current space reserved for the f-segment (when there are a large number of CPUs). Some ideas: There is actually space in the f-segment that is unused, but not given to the malloc_fseg pool. That space could be given to the pool - though the available space will still vary depending on the code size. It's also possible to relocate the 32bit "run-time" code to high memory which would then free up more space in the f-segment (at the cost of some high memory being reserved from the OS). As above, though, the f-segment is still fundamentally limited by the 16bit code size. Also, it's possible the code could try to use the f-segment if there are less than say 16 cpus and use high memory when more cpus are present. -Kevin