RE: [Question] Why code differs in construct_dom0?

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

>>> "Shan, Haitao" <haitao.shan@intel.com> 20.11.08 13:52 >>>
>I think I may not have described the problem clearly. The system has 4G
>memory. From E820 table, there was near 3.5G usable ram below 4G
>and about 0.5G above 4G. Of all the ram, most of the memory was
>allocated to dom0, leaving only those for xen >itself such as xenheap
>and xen's reservations.
>We were using an onboard graphic card. When starting X, agpgart
allocated memory from kernel, then asked xen to exchange these
>pages to contiguous pages below 4G. Each time agpgart module did
>this job, some pages in kernel (which are actually >above 4G in
>physical memory) were replaced with contiguous pages below 4G.
>These kind of demands were rather high, about 256M in our platform.
>Finally, xen's reservation (128M) was not enough to fulfill this
>requirement.
>Why was the reservation exhausted? Because kernel kept asking for
>memory below 4G but only returning to xen memory above 4G. Then
>why is agpgart's allocation always in effect from above 4G? According
>to the code I pasted in my first mail, when pfn in >dom0 was small in
>number, mfn was large. The smaller the pfn was, the larger the
>corresponding mfn was. Apggart allocated memory with GFP_DMA32
>set, so the pfns allocated was likely to be small. Then the mfns were
>likely to be actually quite large (above 4G).
>
>Either increasing the reservation (like 384M) or changing the initial p2m
>mapping in dom0 can solve the problem, and our tests verified this
>judgment. We do not know which solution is better. That's why we are
>seeking your kindly help. I am not sure if I have explained clearly
>enough so far. So any questions on the problem itself, Keir?

Neither of the suggested solutions seems correct to me - both would only
defer the point where the problem occurs. The question really is why
agpgart needs so much memory below 4G. And if that really isn't a bug
somewhere else, then requiring a sufficiently large negative value to
be passed with dom0_mem= would seem to be the only option on this
system (but not as a global default).

Jan