Re: PATCH: Hugepage support for Domains booting with 4KB pages

[Keshav Darak <keshav_darak@yahoo.com>]

Konrad,

Thanks for reviewing the patch.

>> We have implemented hugepage support for guests in following manner
>> 
>> In
>>  our implementation we added a parameter hugepage_num which is specified
>>  in the config file of the DomU. It is the number of hugepages that the 
>> guest is guaranteed to receive whenever the kernel asks for hugepage by 
>> using its boot time parameter or reserving after booting (eg. Using echo
>>  XX > /proc/sys/vm/nr_hugepages). During creation of the domain we 
>> reserve MFN's for these hugepages and store them in the list. The 

>There is bootup option for normal Linux kernels to set that up. Was
>that something you could use?

ya, it can be used too, to allocate the hugepages.

>> 
>> static inline int arch_prepare_hugepage(struct page *page)
>> {
>>index f46c340..00c489a 100644
>>--- a/arch/x86/mm/hugetlbpage.c
>>+++ b/arch/x86/mm/hugetlbpage.c
>>@@ -147,8 +147,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
>>             pte = (pte_t *) pmd_alloc(mm, pud, addr);
>>         }
>>     }
>>-    BUG_ON(pte && !pte_none(*pte) && !pte_huge(*pte));
>>-
>>+    BUG_ON(pte && !pte_none(*pte) && !((*pte).pte & (_AT(pteval_t, 1)<<7)));

>Ugh. That is horrible.

>why can't you use 'pte_huge' ? Is it b/c of this
> * (We should never see kernel mappings with _PAGE_PSE set,
> * but we could see hugetlbfs mappings, I think.).
> */

Here actually we don't known the exact reason, but when pte_huge was used the BUG_ON was called even though the PSE bit was set, so we had to rewrite the BUG_ON testing the 7th bit.there could be better ways to do it, But we couldn't find the exact reasons why was it(pte_huge) returning 0 even when the pte was a huge_pte.    


we will try to resolve other issues with the patch as soon as possible. 

--
Keshav Darak
Kaustubh Kabra
Ashwin Vasani
Aditya Gadre