This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] ACPI-Tables corrupted?

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] ACPI-Tables corrupted?
From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Date: Wed, 28 Jul 2010 15:27:54 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 28 Jul 2010 06:28:41 -0700
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@xxxxxxxxxxxxxx; q=dns/txt; s=s1536b; t=1280323671; x=1311859671; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4C50305A.8070209@xxxxxxxxxxxxxx>|Date:=20 Wed,=2028=20Jul=202010=2015:27:54=20+0200|From:=20Juergen =20Gross=20<juergen.gross@xxxxxxxxxxxxxx>|MIME-Version: =201.0|To:=20Keir=20Fraser=20<keir.fraser@xxxxxxxxxxxxx> |CC:=20"xen-devel@xxxxxxxxxxxxxxxxxxx"=20<xen-devel@lists .xensource.com>|Subject:=20Re:=20[Xen-devel]=20ACPI-Table s=20corrupted?|References:=20<C875E4E8.1BE14%keir.fraser@ eu.citrix.com>|In-Reply-To:=20<C875E4E8.1BE14%keir.fraser @eu.citrix.com>|Content-Transfer-Encoding:=207bit; bh=Oxv3oTzVYlz/KCJ4fTDQrhodLAeZ5PFWrRuh92o7UVQ=; b=p6oxr05XS+0ZjBADsXucyyVfVLD4T7HR1WnqZpYqfUMKyHaF4+UEVODu 98192y29TibJ5XpffotPVxJUOxIMkNiyWJguQJEAsJeN9u6loE8dR2JIL KsfMIqmgd+SdwJWS89ZI/8EQsVEXo5NB9cJmK6zLVyPdTW/FSkB0yqGKt oq4dsIjTO0ccSnUFQiCgiYXfsZ831XtFGLsE0S98xkPKDnNczT5KFNBND QYWk7V/+d6Jv02HRYp84ZOUd9Y6SH;
Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=CrztTxxTy+7WB6yTT/bVD5qo4+ypGu7HV6aA2mN6TIb+Uxj8HsmNa7N0 OAjsisnAb2vMaZcv9v5eJHOIvqUz3615YBpzsW9VB157zZY+WJLsKd6zd rasD9oaCPyPO5RANfScFGBw9BIwcU3ugTaGyM9dPJ15sJxbqjgL3mkp8A llqRSW/yLNlwoRKMeA75jn5hLUup2rAQwkUT+k6R+HbNzda3b+qFjEB5F Xldr5jJTPRvG6Om6Hj6yHKV1TRavE;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C875E4E8.1BE14%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Fujitsu Technology Solutions
References: <C875E4E8.1BE14%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100620 Iceowl/1.0b1 Icedove/3.0.5
On 07/28/2010 02:45 PM, Keir Fraser wrote:
On 28/07/2010 13:13, "Juergen Gross"<juergen.gross@xxxxxxxxxxxxxx>  wrote:

As Dom0 is a pv-kernel, it should be able to ignore this entry.
The crash kernel OTOH should not panic due to the trashed entry!
What is the correct solution here?

Could provide a cmdline option to not nobble the DMAR?

That's a possibility.
I wonder whether it wouldn't be better to let dom0 decide not to use it if
running under xen. This would remove the requirement for zapping the ACPI
table. IMO it's always a bad idea to change data of a deeper layer...

If we don't zap the DMAR then every existing dom0 kernel will fail with new
hypervisor. We could gate it on a new elfnote, or rename to XMAR and have
dom0 rename it back, or just have a flag day.

The really clean solution would be to virtualize the ACPI table for dom0 and
remove the DMAR entry in this version. This would require some major work, I
guess (clone at least the BIOS page containing the ACPI anchor and present
a modified version to dom0).

The crash kernel expects a valid DMAR entry, as following code in
enable_IR_x2apic() suggests:

I don't know what that function does, nor how the error path below depends
on DMAR. DMAR isn't mentioned in the below code.

Sorry, here a larger fragment (source arch/x86/kernel/apic/apic.c):
                  /* IR is required if there is APIC ID>  255 even when running
                   * under KVM
                  if (max_physical_apicid>  255 || !kvm_para_available())
                          goto nox2apic;

The if stmt is confusing. Also, what would happen if this kernel was booted
on a system without VT-d (and hence no DMAR)? Presumably it *can* boot in a
DMAR-less environment -- there must be something odd going on for it to end
on this path for us.

Yeah, that puzzled me, too.


Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@xxxxxxxxxxxxxx
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

Xen-devel mailing list