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]Two dead-lock situation occurs on 32bit HVM SMP Windows

To: "Li, Xin B" <xin.b.li@xxxxxxxxx>, "Xin, Xiaohui" <xiaohui.xin@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel]Two dead-lock situation occurs on 32bit HVM SMP Windows
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Tue, 14 Nov 2006 17:37:11 +0000
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:37:27 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <B30DA1341B0CFA4893EF8A36B40B5C5D679212@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AccAF9dKTIq91n6sSkWEGX/0OhiYJwAK0KTSAfN1PNAAAKU53Q==
Thread-topic: [Xen-devel]Two dead-lock situation occurs on 32bit HVM SMP Windows
User-agent: Microsoft-Entourage/11.2.5.060620
On 14/11/06 17:33, "Li, Xin B" <xin.b.li@xxxxxxxxx> wrote:

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

Any idea what it's trying to access? Presumably nothing is mapped up there
so it just gets all-ones back from reads? I'm surprised it would be doing
lots of accesses to totally unused memory space. That tends to be fairly
slow even on native hardware.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel