RE: [RFC] fix xen_in_range()

["Jan Beulich" <jbeulich@novell.com>]

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

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