From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@novell.com>
Subject: AW: Re: Xen BUG in mm / Xen 4.0.1 with
	2.6.32.18/21 pvops Kernel?
Date: Fri, 10 Sep 2010 09:45:00 +0100
Message-ID: <4C8A0C2C0200007800015607@vpn.id2.novell.com>
References: <H000006700083044.1284056830.uhura.space.zz@MHS>
	<H00000670008304a.1284057636.uhura.space.zz@MHS>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <H00000670008304a.1284057636.uhura.space.zz@MHS>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Carsten Schiers <carsten@schiers.de>
Cc: xen-devel <xen-devel@lists.xensource.com>
List-Id: xen-devel@lists.xenproject.org

>>> On 09.09.10 at 20:40, "Carsten Schiers" <carsten@schiers.de> wrote:
> OK, here are the three SSDT's that I seem to have. BR, Carsten.

SSDT1.dsl seems to be the bad one: While the SSDT package defined
at the top is reasonable (having invalid entries only for CPUs 2 and
up), the CSDT package is bogus, and gets referenced later in the
same file in \_PR.P001._OSC:

            If (LAnd (LAnd (LEqual (And (PDC0, 0x18), 0x18), LEqual (
                CTB0, Zero)), LEqual (And (CFGD, 0x20), 0x20)))
            {
                Or (CTB0, 0x01, CTB0)
                OperationRegion (CT00, SystemMemory, DerefOf (Index (CSDT, =
0x01)), DerefOf (Index (CSDT, 0x02
                    )))
                Load (CT00, HC0)
            }

Hence, at least if the condition is true (not sure how the ACPI
interpreter works wrt mapping memory in the body of false
conditionals) a memory range of 0x80000000 bytes at address
0x80000000 will be attempted to be created and accessed,
no matter how much memory the system has (and the
variable the initialize with the memory access doesn't appear
to be used at all). I'm really surprised you (they) get away
with this on a native kernel... Did you try to compare control
flow of Xen and native kernels?

Jan