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: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] ACPI-Tables corrupted?
From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Date: Thu, 29 Jul 2010 08:19:56 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Wed, 28 Jul 2010 23:21:05 -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=1280384516; x=1311920516; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; z=Message-ID:=20<4C511D8C.1010808@xxxxxxxxxxxxxx>|Date:=20 Thu,=2029=20Jul=202010=2008:19:56=20+0200|From:=20Juergen =20Gross=20<juergen.gross@xxxxxxxxxxxxxx>|MIME-Version: =201.0|To:=20Konrad=20Rzeszutek=20Wilk=20<konrad.wilk@ora cle.com>|CC:=20"xen-devel@xxxxxxxxxxxxxxxxxxx"=20<xen-dev el@xxxxxxxxxxxxxxxxxxx>,=20=0D=0A=20Keir=20Fraser=20<keir .fraser@xxxxxxxxxxxxx>|Subject:=20Re:=20[Xen-devel]=20ACP I-Tables=20corrupted?|References:=20<C875E4E8.1BE14%keir. fraser@xxxxxxxxxxxxx>=09<4C50305A.8070209@xxxxxxxxxxxxxx> =20<20100728133648.GC4272@xxxxxxxxxxxxxxxxxxx> |In-Reply-To:=20<20100728133648.GC4272@xxxxxxxxxxxxxxxxxx m>; bh=V7Y3qHJmMT+LbRh+/py2LRhoYfXeHOdG16VxNI6WctQ=; b=vf9kcHZf5qQbagvU3bzO0DAr2uHFHKO3FxYrGSTo1HrqZAxbH2ThhGAM SY9XXy0mRidD9ZkFS/HPqPGGzQiLhsdBs6V0xFWpzlQnqavn3OJF7JnwE Y/tOin2OTmWMNvg1S4yxsyciw/MH9sX+SVEgBwDSPB0virc4z0uauJTLk 1VgPYwyZNHn83nmfTRueTz35HQJBOKKaZSmJr1a8DRN1lQk5pcuOxsA+V 130ONUeldWfARdevm0OMgS1PttQWy;
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; b=dlAE/OvZUicZoEuHHS1qPJ49HgyoZPVFR7rpn/Gi7evPbRvffkXIl6o5 Y3JS2nq9z9yuHpa8VTm/N7K2CpSJFfiLgA0ovBRsNcjtmuhgC2W6ebssa A2HcULrRUaT/c8qmZKtlYku/sbcqg9JOfD02PSHxKqwgim3JbO/2Uc/JN 5FCv/1zVb2kVyw7J46ChaDy7GTTzR78+27NBxIb2LSj/Ig50fVB3YdPOM mY5o0N5f+GDNfBQeaWxiTu6iLruqk;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100728133648.GC4272@xxxxxxxxxxxxxxxxxxx>
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> <4C50305A.8070209@xxxxxxxxxxxxxx> <20100728133648.GC4272@xxxxxxxxxxxxxxxxxxx>
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 03:36 PM, Konrad Rzeszutek Wilk wrote:
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).

Well, that is what it does right now. It zeros it out so that the DMAR
entry is gone from the ACPI tables.

No. It changes the ORIGINAL ACPI table, not a copy of it.

I am not really sure that having a DMAR accessible to Dom0 is good. You
would have two entities trying to write to the DMAR's to control the
IOMMU and the PCI devices. Does Xen enable the IOMMU? Do you see that in
the serial log?

I don't want to let dom0 access DMAR. I want the crash kernel be able to
access it.

And I think Xen does enable the IOMMU:

(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Intel machine check reporting enabled
(XEN) Intel VT-d Snoop Control supported.
(XEN) Intel VT-d DMA Passthrough not supported.
(XEN) Intel VT-d Queued Invalidation supported.
(XEN) Intel VT-d Interrupt Remapping supported.
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests disabled
(XEN) x2APIC mode enabled.

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.

What is the crash? And do you see any indiciation that x2APIC is turned
on? Do provide a serial log please.

Log is attached.

I did some more testing. The problem occurred on a Nehalem-EX system. I tried
the same on a Nehalem-EP system and all was okay. I suspect some further
problems in the ACPI tables of the EX system now. I'm not too familiar with
ACPI tables. Anything I can do for further analysis?


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

Attachment: crash.log
Description: Text Data

Xen-devel mailing list