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

[Xen-devel] RE: [Question] Why code differs in construct_dom0?

To: "Shan, Haitao" <haitao.shan@xxxxxxxxx>, 'Keir Fraser' <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] RE: [Question] Why code differs in construct_dom0?
From: "Shan, Haitao" <haitao.shan@xxxxxxxxx>
Date: Thu, 20 Nov 2008 17:44:34 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "'xen-devel@xxxxxxxxxxxxxxxxxxx'" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 20 Nov 2008 01:45:18 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <61563CE63B4F854986A895DA7AD3C17701F100E8@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <61563CE63B4F854986A895DA7AD3C17701F7E601@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C54ADBC5.1F6E7%keir.fraser@xxxxxxxxxxxxx> <61563CE63B4F854986A895DA7AD3C17701F100E8@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclK7215rpYCsocDQfKwAUF7KsGCIAAAXKusAABBHNAAAJm4oA==
Thread-topic: [Question] Why code differs in construct_dom0?
I forgot to mention in our configuration we did not specify the dom0_mem. Dom0 
was allocated a large portion of the total system memory.

Best Regards
Haitao Shan

Shan, Haitao wrote:
> So you mean in the release build we make the mapping discontiguous to
> detect possible bugs, while in debug build it is not discontiguous? 
> 
> And another question from problems we encountered recently, system
> with more than 4G memory installed will crash when X server shutdown.
> The reason is: 1> dom0 allocates memory for agp by calling
> agp_allocate_memory with GFP_DMA32 set. This implies the pfn comes
> from memory lower than 4G, while mfn are likely to be from memory
> above 4G. 2> dom0 then call map_pages_to_apg, since the kernel of
> handles 32bit gart table, dom0 uses hypercall to change its memory
> mappings (xen_create_contiguous_region). Xen will pick proper memory
> below 4G and free those from the guest (likely to be from memory
> above 4G). 3> As the process goes on. More and more memory below 4G
> is return to dom0 while leaving memory above 4G in xen. Finally,
> xen's reservation of memory below 4G for DMA are exhausted. This
> creates severe problems for us.         
> 
> What is your comments on this? Both increase the reservation in Xen
> and using contiguous mappings are helpful in this cases. Which one do
> you prefer?  
> 
> Best Regards
> Haitao Shan
> 
> Keir Fraser wrote:
>> By deliberately making dom0's p2m mapping discontiguous we can detect
>> bugs where dom0 is incorrectly assuming pseudophys contiguous memory
>> is machine contiguous. We had nasty bugs of this sort in dom0's
>> block layer many years ago. 
>> 
>>  -- Keir
>> 
>> On 20/11/08 09:07, "Shan, Haitao" <haitao.shan@xxxxxxxxx> wrote:
>> 
>>> Hi, Keir,
>>> 
>>> Please see the code shown below. I don't understand why pfn's
>>> definitions are different depending on whether NDEBUG is defined or
>>> not. Can you tell me why? 
>>> 
>>>     while ( pfn < nr_pages )
>>>     {
>>>         if ( (page = alloc_chunk(d, nr_pages - d->tot_pages)) ==
>>>             NULL ) panic("Not enough RAM for DOM0 reservation.\n");
>>>         while ( pfn < d->tot_pages )
>>>         {
>>>             mfn = page_to_mfn(page);
>>> #ifndef NDEBUG
>>> #define pfn (nr_pages - 1 - (pfn - (alloc_epfn - alloc_spfn)))
>>>             #endif if ( !is_pv_32on64_domain(d) )
>>>                 ((unsigned long *)vphysmap_start)[pfn] = mfn;
>>>                 else ((unsigned int *)vphysmap_start)[pfn] = mfn;
>>>             set_gpfn_from_mfn(mfn, pfn);
>>> #undef pfn
>>>             page++; pfn++;
>>>         }
>>>     }
>>> 
>>> Best Regards
>>> Haitao Shan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel