WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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 14:13:39 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 28 Jul 2010 05:14:47 -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=1280319311; x=1311855311; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4C501EF3.8070402@xxxxxxxxxxxxxx>|Date:=20 Wed,=2028=20Jul=202010=2014:13:39=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<C875D57C.1BD3D%keir.fraser@ eu.citrix.com>|In-Reply-To:=20<C875D57C.1BD3D%keir.fraser @eu.citrix.com>|Content-Transfer-Encoding:=207bit; bh=A5mfOKDdFQmn+TFXMWwS1/s26icljch6kL60mZune+k=; b=QO7cvhCYvEGdx4Ea3keLmCW5i6s5GCXjLNxpP3FNTkVdMnIJ3T/hyRlu 7aGUPlx0wloT6xRM7mmNTeNHx/GTqYljEAxEtI5lTqDOcVaTN8OSeQHiN VmmUt5FxPMHrApM1IqR72PXt7jDzWvDGm7Bb9iH9OudVs/m5zMNsTX7dh JVfaNWasOzRasVHl8UOtv34Nc3feTvT1VS2CnarWuYXloOk9N71JIFZsd tIFOISfd675kUPfpsdwVaaC+1QUUe;
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=vCA/wF3V0I1MgWjhtTPon2OY/fdDV37keTGjybn3HDOrYg78GPAzyCU5 M3LX0zUEXnWz298WCqbyGdAlXwSiqFPbbqUgxy0AwpZVmPOZvkN4CCw7V Z1Y5bBky4e9/SKxgbKSuXHFOyJZbOrGlyXiSYfLqKj4LD3MlgfzMGiCtc YzFOSOB5Le0WW+QHIPkjolMTwFWJAeV1qfJwFdB5kzGSn0c9WOLeaJz2x Lh5IaosFM5mCjH6kUh5TB6/yjVNR5;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C875D57C.1BD3D%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: <C875D57C.1BD3D%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Iceowl/1.0b1 Icedove/3.0.5
On 07/28/2010 01:39 PM, Keir Fraser wrote:



On 28/07/2010 12:26, "Juergen Gross"<juergen.gross@xxxxxxxxxxxxxx>  wrote:

On 07/28/2010 12:03 PM, Keir Fraser wrote:
On 28/07/2010 10:38, "Juergen Gross"<juergen.gross@xxxxxxxxxxxxxx>   wrote:

As you can see, the DMAR eye-catcher is replaced by blanks!
This leads to a programmed panic in the crash kernel later in case of a
panic in dom0...

Any ideas?
BTW: seen in unstable AND 4.0

Look at the tail of xen/drivers/passthrough/vtd/dmar.c: Xen *always*
*unconditionally* trashes the DMAR so that dom0 will not parse it.
Presumably bad stuff would happen if it did.

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


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):

void __init enable_IR_x2apic(void)
{
        unsigned long flags;
        struct IO_APIC_route_entry **ioapic_entries = NULL;
        int ret, x2apic_enabled = 0;
        int dmar_table_init_ret = 0;

#ifdef CONFIG_INTR_REMAP
        dmar_table_init_ret = dmar_table_init();
        if (dmar_table_init_ret)
                pr_debug("dmar_table_init() failed with %d:\n",
                                dmar_table_init_ret);
#endif

        ioapic_entries = alloc_ioapic_entries();
        if (!ioapic_entries) {
                pr_err("Allocate ioapic_entries failed\n");
                goto out;
        }

        ret = save_IO_APIC_setup(ioapic_entries);
        if (ret) {
                pr_info("Saving IO-APIC state failed: %d\n", ret);
                goto out;
        }

        local_irq_save(flags);
        mask_8259A();
        mask_IO_APIC_setup(ioapic_entries);

        if (dmar_table_init_ret)
                ret = 0;
        else
                ret = enable_IR();

        if (!ret) {
                /* IR is required if there is APIC ID > 255 even when running
                 * under KVM
                 */
                if (max_physical_apicid > 255 || !kvm_para_available())
                        goto nox2apic;
                /*
                 * without IR all CPUs can be addressed by IOAPIC/MSI
                 * only in physical mode
                 */
                x2apic_force_phys();
        }

        x2apic_enabled = 1;

        if (x2apic_supported() && !x2apic_mode) {
                x2apic_mode = 1;
                enable_x2apic();
                pr_info("Enabled x2apic\n");
        }

nox2apic:
        if (!ret) /* IR enabling failed */
                restore_IO_APIC_setup(ioapic_entries);
        unmask_8259A();
        local_irq_restore(flags);

out:
        if (ioapic_entries)
                free_ioapic_entries(ioapic_entries);

        if (x2apic_enabled)
                return;

        if (x2apic_preenabled)
                panic("x2apic: enabled by BIOS but kernel init failed.");
        else if (cpu_has_x2apic)
                pr_info("Not enabling x2apic, Intr-remapping init failed.\n");
}


dmar_table_init() will return -ENODEV if no DMAR record is found.


Juergen

--
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel