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

xen-devel

[Top] [All Lists]

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: 2011年3月25日 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: 2011年3月25日 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
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date: Re: [Xen-devel] Xen 4.2 unstable + Jeremy's stable/2.6.32.x , Goncalo Gomes
Next by Date: Re: [Xen-devel] Re: [RFC PATCH V4 2/5] cpuidle: list based cpuidle driver registration and selection , Konrad Rzeszutek Wilk
Previous by Thread: RE: [Xen-devel] page fault in xmem_pool_alloc w/ TXT , Jan Beulich
Next by Thread: RE: [Xen-devel] page fault in xmem_pool_alloc w/ TXT , Cihula, Joseph
Indexes: [Date] [Thread] [Top] [All Lists]

Copyright ©, Citrix Systems Inc. All rights reserved. Legal and Privacy
Citrix This site is hosted by Citrix

AltStyle によって変換されたページ (->オリジナル) /