From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KW2oD-0006Js-KY for qemu-devel@nongnu.org; Thu, 21 Aug 2008 01:34:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KW2oC-0006Jg-BL for qemu-devel@nongnu.org; Thu, 21 Aug 2008 01:34:08 -0400 Received: from [199.232.76.173] (port=52012 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KW2oC-0006Jd-5s for qemu-devel@nongnu.org; Thu, 21 Aug 2008 01:34:08 -0400 Received: from il.qumranet.com ([212.179.150.194]:40410) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KW2oB-0003MJ-HX for qemu-devel@nongnu.org; Thu, 21 Aug 2008 01:34:07 -0400 Date: Thu, 21 Aug 2008 08:34:06 +0300 From: Gleb Natapov Message-ID: <20080821053405.GA27587@minantech.com> References: <20080820131529.GJ3235@minantech.com> <00c801c9031b$e69fc340$0201a8c0@zeug> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c801c9031b$e69fc340$0201a8c0@zeug> Subject: [Qemu-devel] Re: [Bochs-developers] BIOS, ACPI, CMOS and Windows EvenID: 4 Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sebastian Herbszt Cc: bochs-developers@lists.sourceforge.net, qemu-devel@nongnu.org On Thu, Aug 21, 2008 at 01:23:17AM +0200, Sebastian Herbszt wrote: >> We ignored this error for a long time since there was no any stability >> issues caused by it, but recently we encountered Windows 2008 reboot >> problem (one of 10 reboots hangs with ACPI error) that, according to >> Microsoft, is caused by CMOS access from AML code. Eliminating the >> access indeed fixed reboot problem. ACPI spec defines a way to read >> CMOS without accessing IO ports directly, but unfortunately neither >> Windows XP nor Linux implements this part of the spec (it works in >> Windows 2008 though). > > Do you mean OperationRegion type CMOS? > Yes. Tried that and it works only on Windows 2008 / Vista. XP doesn't boot and Linux complains that it doesn't have a handler for this region type. Linux can be fixed by XP is hopeless :) >> As far as I can see AML accesses CMOS in order >> to see how much memory is present and configure PCI hole to be maximum >> size. Is this really needed or we can just hard code a reasonably large >> PCI hole like in patch below and eliminate CMOS access > > The AML of my real hardware does calculate the maximal hole. VMware seems > to do the same. My real HW reads it from a chipset. > > Is there a minimal hole size specified somewhere? I looked at some specs but didn't > find any. Qemu has a minimal hole size hardcoded to start at 0xe0000000. > >> Any other ideas how to solve the problem? > > The Microsoft document suggests to copy the CMOS data to somewhere in memory > and access it there. I guess rombios space from 0xe000 to 0xffff could be a good > candidate. No need to copy the whole CMOS. Copying only memory size should be enough. Also putting it somewhere in first 4K should be better. You can't write into 0xe000-0xffff unless chipset shadows it in a memory. > The 440fx specs says "The top of memory is determined by the value written into DRB7." > We might get the proper value from there. But it also says "Note that the PMC supports > a maximum of 1 Gbytes of DRAM." > Yeah, I saw that my real HW takes top of the memory somewhere from the chipset and looked in 440fx specs if it has this info, but it turned out that we abuse 440fx and sometimes use much more memory that it supports. We can re-use DRB registers for our needs and store memory size there on POST (we can store 8 bytes there, so it should be enough) and read them from AML. Are all users of bochs BIOS uses the same chipset? -- Gleb.