From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@novell.com>
Subject: RE: page fault in xmem_pool_alloc w/ TXT
Date: Fri, 25 Mar 2011 11:49:28 +0000
Message-ID: <4D8C8F580200007800038565@vpn.id2.novell.com>
References: <4F65016F6CB04E49BFFA15D4F7B798D90160478222@orsmsx506.amr.corp.intel.com>
	<4D8B85CB02000078000381F6@vpn.id2.novell.com>
	<4F65016F6CB04E49BFFA15D4F7B798D901607954F3@orsmsx506.amr.corp.intel.com>
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: <4F65016F6CB04E49BFFA15D4F7B798D901607954F3@orsmsx506.amr.corp.intel.com>
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: Joseph Cihula <joseph.cihula@intel.com>
Cc: Shane Wang <shane.wang@intel.com>, Xen-devel <xen-devel@lists.xensource.com>, Gang Wei <gang.wei@intel.com>
List-Id: xen-devel@lists.xenproject.org

This appears to be caused by that changset's change to
xen/drivers/passthrough/vtd/dmar.c - I didn't notice that
tboot_parse_dmar_table() would call acpi_parse_dmar() on a copy of
the table rather than the original, and I also can't see why it needs to
do so. Just not freeing the table copy should at least get the crash
resolved, but the zapping then still wouldn't work. Me agreeing to
reverting that part of the change needs explanation why things need
to be done this way (i.e. why, if Dom0 can find the real table anyway,
Xen can't use it directly), and would perhaps force quite a bit of code
back out of .init.*, which I'd really like to avoid. Plus, this code in
tboot_parse_dmar_table() looks more like a hack currently.

Hmm, wait - an apparently simple alternative might be to have
acpi_parse_dmar() or acpi_dmar_init() do what get_dmar() did
before (rather than simply using acpi_parse_dmar()'s input to
store into dmar_table). Could you give the patch below a try
(I kept the disabling of IRQs, but I don't think that is necessary
anymore)?

Jan

--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -673,7 +673,6 @@ static int __init acpi_parse_dmar(struct
     u8 dmar_host_address_width;
     int ret =3D 0;
=20
-    dmar_table =3D table;
     dmar =3D (struct acpi_table_dmar *)table;
=20
     if ( !iommu_enabled )
@@ -762,6 +761,13 @@ out:
=20
 int __init acpi_dmar_init(void)
 {
+    unsigned long flags;
+
+    /* Disabling IRQs avoids cross-CPU TLB flush in map_pages_to_xen(). =
*/
+    local_irq_save(flags);
+    acpi_get_table(ACPI_SIG_DMAR, 0, &dmar_table);
+    local_irq_restore(flags);
+
     return parse_dmar_table(acpi_parse_dmar);
 }
=20