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: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] ACPI-Tables corrupted?
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Wed, 28 Jul 2010 09:36:48 -0400
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Wed, 28 Jul 2010 06:40:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C50305A.8070209@xxxxxxxxxxxxxx>
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>
References: <C875E4E8.1BE14%keir.fraser@xxxxxxxxxxxxx> <4C50305A.8070209@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-12-10)
> 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.

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?
> >
> >>>>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.

Xen-devel mailing list