Xen project Mailing List

RE: [Xen-devel]Two dead-lock situation occurs on 32bit HVM SMP Windows

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Xin, Xiaohui" <xiaohui.xin@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>

From: "Li, Xin B" <xin.b.li@xxxxxxxxx>

Date: Wed, 15 Nov 2006 01:33:39 +0800

Cc: "Mallick, Asit K" <asit.k.mallick@xxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Li, Susie" <susie.li@xxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, "He, Qing" <qing.he@xxxxxxxxx>

Delivery-date: Tue, 14 Nov 2006 09:34:02 -0800

List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Thread-index: AccAF9dKTIq91n6sSkWEGX/0OhiYJwAK0KTSAfN1PNA=

Thread-topic: [Xen-devel]Two dead-lock situation occurs on 32bit HVM SMP Windows

>The PV drivers should not have been hitting the MMIO region with >any regularity however. Is it the LAPIC and IOAPIC that are getting > hit? It certainly makes sense to cover hot regions of the P2M table > with valid mappings - we should not expect the fault-and-fixup > path to be fast. A single extra pagetable with INVALID_MFN just >below 4GB would I'm sure speed things up quite a bit! Keir On x86_64 xen, we saw get_mfn_from_gpfn gets into the fault-and-fixup path frequently when running 64bit windows guests with 1G RAM, and quite a few of them are caused by gpfn > 0x100000, i.e. above 4G, so how about aslo adding a gpfn range check into get_mfn_from_gpfn? And we can use hvm_set_param to set the max gpfn # in xc_hvm_build.c. -Xin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.