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] RE: [RFC] fix xen_in_range()

To: Jan Beulich <jbeulich@xxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] RE: [RFC] fix xen_in_range()
From: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Date: Fri, 24 Apr 2009 16:29:40 -0700
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>, "Wang, Shane" <shane.wang@xxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, "Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>, "Ke, Liping" <liping.ke@xxxxxxxxx>, "Li, Xin" <xin.li@xxxxxxxxx>
Delivery-date: Fri, 24 Apr 2009 16:30:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49F180A8.76EA.0078.0@xxxxxxxxxx>
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: <4F65016F6CB04E49BFFA15D4F7B798D9988CF1A3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C615D676.947F%keir.fraser@xxxxxxxxxxxxx> <4F65016F6CB04E49BFFA15D4F7B798D9988CFA8C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <49F180A8.76EA.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcnEqtB/7HmfrRQcS/uFWnvJiit1sgAiQ4aQ
Thread-topic: [Xen-devel] RE: [RFC] fix xen_in_range()
> From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx]
> Sent: Friday, April 24, 2009 12:05 AM
>
> >>> "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> 24.04.09 03:26 >>>
> >> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> >> Sent: Thursday, April 23, 2009 12:25 AM
> >>
> >> On 23/04/2009 00:53, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> 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).

It's actually 8 (I cut off my trace early before).

I don't think that it is worth the effort of walking the page tables just to 
exclude the frametable from the VT-d tables, since there are other memory 
regions (xenheap, etc.) that we're not excluding.  But if there is a binlist of 
things to do when someone gets time, I'd suggest adding this to it.

Joe

> 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


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