xen-devel
RE: [Xen-devel] page fault in xmem_pool_alloc w/ TXT
To: |
Jan Beulich <JBeulich@xxxxxxxxxx>, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> |
Subject: |
RE: [Xen-devel] page fault in xmem_pool_alloc w/ TXT |
From: |
"Wei, Gang" <gang.wei@xxxxxxxxx> |
Date: |
Fri, 25 Mar 2011 23:34:12 +0800 |
Accept-language: |
zh-CN, en-US |
Acceptlanguage: |
zh-CN, en-US |
Cc: |
"Wang, Shane" <shane.wang@xxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx> |
Delivery-date: |
Fri, 25 Mar 2011 08:36:20 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<4D8C8F580200007800038565@xxxxxxxxxxxxxxxxxx> |
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: |
<4F65016F6CB04E49BFFA15D4F7B798D90160478222@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4D8B85CB02000078000381F6@xxxxxxxxxxxxxxxxxx> <4F65016F6CB04E49BFFA15D4F7B798D901607954F3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4D8C8F580200007800038565@xxxxxxxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
Thread-index: |
Acvq4paaHmNf8/fwTCW+KrTAyRyWmAAHSFRA |
Thread-topic: |
[Xen-devel] page fault in xmem_pool_alloc w/ TXT |
Jan Beulich wrote on 2011-03-25:
> 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)?
I applied this patch on c/s 23013 and tested, it makes things working again.
BTW, just looked into the code before 23013, the original acpi_dmar_reinstate()
should never work because acpi_get_table(ACPI_SIG_DMAR, 0, &dmar_table) could
not find the dmar table after it was zapped during the booting. That may be
reason why tboot S3 don't work recently. I haven't verified whether tboot S3 is
working after apply this patch yet, and may give it a try next week.
Jimmy
>
> 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 = 0;
> - dmar_table = table;
> dmar = (struct acpi_table_dmar *)table;
>
> if ( !iommu_enabled )
> @@ -762,6 +761,13 @@ out:
>
> 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);
> }
>
Jimmy
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|