From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: RE: [RFC] fix xen_in_range() Date: Fri, 24 Apr 2009 08:04:40 +0100 Message-ID: <49F180A8.76EA.0078.0@novell.com> References: <4F65016F6CB04E49BFFA15D4F7B798D9988CF1A3@orsmsx506.amr.corp.intel.com> <4F65016F6CB04E49BFFA15D4F7B798D9988CFA8C@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: <4F65016F6CB04E49BFFA15D4F7B798D9988CFA8C@orsmsx506.amr.corp.intel.com> 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 , Joseph Cihula , "xen-devel@lists.xensource.com" Cc: Dexuan Cui , Shane Wang , Yunhong Jiang , Xiaowei Yang , Liping Ke , Xin Li List-Id: xen-devel@lists.xenproject.org >>> "Cihula, Joseph" 24.04.09 03:26 >>> >> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com]=20 >> Sent: Thursday, April 23, 2009 12:25 AM >> >> 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. > >That made it just a single iteration on a 2GB system, but what fn should = be used >to convert the va to pa? __pa() isn't converting this correctly. I'm afraid you'll have to either create one, or you'll have to consult the = page tables. Also, how can this be a single iteration on a 2Gb system? struct page_info is 32 bytes, so I'd expect the frame table to be 16Mb in size = (i.e. eight iterations). Also, after suggesting to use gb-pages when possible here I realized that it's probably a latent bug to map more space than was allocated - if the non-allocated-but-mapped pages happen to later get allocated to a domain, that domain may change the cacheability attributes of any of these pages, resulting in aliasing issues. I'll put together a patch for this, but = it'll be a couple of days until I'll be able to do so. Jan