RE: RE: [RFC] fix xen_in_range()

["Cihula, Joseph" <joseph.cihula@intel.com>]

> From: Jan Beulich [mailto:jbeulich@novell.com]
> Sent: Friday, April 24, 2009 12:05 AM
>
> >>> "Cihula, Joseph" <joseph.cihula@intel.com> 24.04.09 03:26 >>>
> >> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com]
> >> Sent: Thursday, April 23, 2009 12:25 AM
> >>
> >> On 23/04/2009 00:53, "Cihula, Joseph" <joseph.cihula@intel.com> 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