qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@qumranet.com>
To: Sebastian Herbszt <herbszt@gmx.de>
Cc: bochs-developers@lists.sourceforge.net, qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [Bochs-developers] BIOS, ACPI, CMOS and Windows EvenID: 4
Date: Thu, 21 Aug 2008 08:34:06 +0300	[thread overview]
Message-ID: <20080821053405.GA27587@minantech.com> (raw)
In-Reply-To: <00c801c9031b$e69fc340$0201a8c0@zeug>

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.

  reply	other threads:[~2008-08-21  5:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-20 13:15 [Qemu-devel] BIOS, ACPI, CMOS and Windows EvenID: 4 Gleb Natapov
2008-08-20 23:23 ` [Qemu-devel] Re: [Bochs-developers] " Sebastian Herbszt
2008-08-21  5:34   ` Gleb Natapov [this message]
2008-08-21 11:45     ` Kevin O'Connor
2008-08-21 14:14       ` Gleb Natapov
2008-08-21 22:37         ` Sebastian Herbszt
2008-08-23 16:22           ` Gleb Natapov
2008-08-24 21:29             ` Sebastian Herbszt
2008-08-25  4:41               ` [Qemu-devel] " Stanislav Shwartsman
2008-08-21 22:47     ` [Qemu-devel] " Sebastian Herbszt
2008-08-24 15:45 ` Kevin O'Connor
2008-08-25  6:38   ` Gleb Natapov
2008-08-25 13:57     ` [Qemu-devel] " Stanislav Shwartsman
2008-08-25 14:00       ` [Qemu-devel] " Gleb Natapov
2008-08-31 19:34       ` Sebastian Herbszt
2008-08-31 20:04         ` Gleb Natapov
2008-08-31 21:19         ` [Qemu-devel] " Stanislav Shwartsman
2008-09-11 22:09           ` [Qemu-devel] " Sebastian Herbszt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080821053405.GA27587@minantech.com \
    --to=gleb@qumranet.com \
    --cc=bochs-developers@lists.sourceforge.net \
    --cc=herbszt@gmx.de \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).