From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [RFC] fix xen_in_range() Date: Thu, 23 Apr 2009 08:58:12 +0100 Message-ID: <49F03BB4.76EA.0078.0@novell.com> References: <4F65016F6CB04E49BFFA15D4F7B798D9988CF1A3@orsmsx506.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Yunhong Jiang , Dexuan Cui , Shane Wang , Joseph Cihula , Xiaowei Yang , Liping Ke , "xen-devel@lists.xensource.com" , Xin Li List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 23.04.09 09:25 >>> >On 23/04/2009 00:53, "Cihula, Joseph" wrote: > >> Unfortunately, the frametable is only contiguous in the virtual address = space, >> so one can't simply take __pa() of its start and end. And since it is = quite >> large, iterating through each page to gets its phys addr adds a = perceptible >> delay when that check has to be done for each page of physical memory = (as is >> the case in the only caller, the VT-d routine that maps memory for = dom0). But >> it also appears that we can't convert the phys addr arguments into = their virt >> addrs to compare with the contiguous frametable range because they will >> convert to the DIRECTMAP va's instead. > >The frametable is allocated in aligned 2MB chunks. So you can check at = that >granularity rather than 4kB. ... and perhaps allocation should be attempted in 1Gb chunks when the = table size is getting close to or exceeding 1Gb (and 1Gb-pages are supported). = Or, since the space mapped is larger than the space allocated anyway, the condition might be just that of 1Gb-pages being supported (provided a 1Gb- aligned chunk can be allocated). Jan