From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryan Harper Subject: Re: adding support for above 2giga to kvm (include patchs) Date: Tue, 14 Aug 2007 14:26:06 -0500 Message-ID: <20070814192606.GL1228@us.ibm.com> References: <64F9B87B6B770947A9F8391472E032160CBECF3E@ehost011-8.exch011.intermedia.net> <20070813202941.GB1228@us.ibm.com> <20070814022219.GF1228@us.ibm.com> <64F9B87B6B770947A9F8391472E032160CBECF4F@ehost011-8.exch011.intermedia.net> <20070814150937.GG1228@us.ibm.com> <1187106465.11302.27.camel@izike-desktop.qumranet.com> <20070814182454.GJ1228@us.ibm.com> <1187117890.14753.5.camel@izike-desktop.qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Izik Eidus , Ryan Harper To: Izik Eidus Return-path: Content-Disposition: inline In-Reply-To: <1187117890.14753.5.camel-wV29XY6ncz+I84jL4+POOYeT0m0igiSA0E9HWUfgJXw@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org * Izik Eidus [2007-08-14 13:59]: > On Tue, 2007-08-14 at 13:24 -0500, Ryan Harper wrote: > > * Izik Eidus [2007-08-14 10:49]: > > > On Tue, 2007-08-14 at 10:09 -0500, Ryan Harper wrote: > > > > * Izik Eidus [2007-08-14 01:29]: > > > > > Hey Ryan, > > > > > thanks for the testing, i hope you didnt have too much problems to get it working. > > > > > > > > Sure, it wasn't too much trouble. > > > > > > > > > anyway as far as i can tell it wont have problem to drive up to 256 + 3.75 giga ram for guest. > > > > > if we want it to drive systems with even more ram we have two options ( both very easily applied ): > > > > > we can add another cmos byte to a "future reserved" byte, or we can use the 3 cmos bytes that i already added and say that > > > > > we store memory in the above bios memory at multiplier of 1 MB. > > > > > it is important we decide now how we want to store the memory, that in the future when 256 + 3.75 giga of ram wont be enough > > > > > we wouldn't have to change bochs bios again. > > > > > > > > Yeah, I think we want to settle on a single method which gets us the > > > > most memory as possible. I think rather than doing the "future reserve" > > > > we should go head an move over to 1MB multiplier. > > > > > > > well this sound like a smart idea, > > > but what we have to think about is: > > > first in this way we have just 64 gigabyte of ram (unless we work with > > > the extra cmos memory bytes) > > > plus if we change the way we use the "normal cmos bytes", we arent > > > breaking compatibility with really old stuff that check the cmos > > > directly without doing bios interrupt? (i mean by ports) > > > > Hrm, yes. This might be an issue already. I just booted memtest-86 > > v3.3 with 6G, and memtest says we have 528G of RAM. Hrm, even below 2G, > > memtest still reports bogus memory values. > > memtest-86, report false memory values when the system is below 2G ?, in > this case i guess it isnt our fault... > memtest-86 was derived originally from linux 1.x i dont know if it even > support above 4 giga of ram. > > without the patch what result do you get from this memtest when runing > below 2giga? It is accurate without the patch. It can see up to 2039M guest with no changes to QEMU. Also, if you apply the qemu size patch (s/int/unsigned long) you can get up to 3831M guest to run without changing the BIOS. The memtest isos I've tried have no problem seeing that. > > (win2003 get good memory information on 14giga guest as well, so i guess > the e820 from the bios interrupt side, is right) Yes, I've looked at the e820 and that looks perfectly fine. Not sure what the issue here is. I'll see if I can track it down though. > > We might need to go look at a newer BIOS spec to see how this is done in > > newer bioses. > > -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/