Xenheap issue on 32b

Xenheap issue on 32b

[Wang, Shane]

Hi Keir,

I noticed that you added the code

#if defined(CONFIG_X86_32)
    /* Initialise the Xen heap. */
    for ( nr_pages = i = 0; i < boot_e820.nr_map; i++ )
    {
        uint64_t s = boot_e820.map[i].addr;
        uint64_t e = s + boot_e820.map[i].size;
        s = max_t(uint64_t, s, xenheap_initial_phys_start);
        e = min_t(uint64_t, e, xenheap_phys_end);
        if ( (boot_e820.map[i].type != E820_RAM) || (s >= e) )
            continue;
        init_xenheap_pages(s, e);
        nr_pages += (e - s) >> PAGE_SHIFT;
    }
    printk("Xen heap: %luMB (%lukB)\n", 
           nr_pages >> (20 - PAGE_SHIFT),
           nr_pages << (PAGE_SHIFT - 10));
#endif

in start_xen() in xen/arch/x86/setup.c,
And for init_xenheap_pages(), you implemented as

void init_xenheap_pages(paddr_t ps, paddr_t pe)
{
    ps = round_pgup(ps);
    pe = round_pgdown(pe);
    if ( pe <= ps )
        return;

    memguard_guard_range(maddr_to_virt(ps), pe - ps);

    /*
     * Yuk! Ensure there is a one-page buffer between Xen and Dom zones, to
     * prevent merging of power-of-two blocks across the zone boundary.
     */
    if ( ps && !is_xen_heap_mfn(paddr_to_pfn(ps)-1) )
        ps += PAGE_SIZE;
    if ( !is_xen_heap_mfn(paddr_to_pfn(pe)) )
        pe -= PAGE_SIZE;

    init_heap_pages(maddr_to_page(ps), (pe - ps) >> PAGE_SHIFT);
}


Here, I noticed that you destroyed the mapping of xenheap in that function and you commented:
    /*
     * Yuk! Ensure there is a one-page buffer between Xen and Dom zones, to
     * prevent merging of power-of-two blocks across the zone boundary.
     */

I am not aware of the purpose. But for S3, Intel Trusted Execution Technology (TXT) will MAC the used xenheap.

On my system, Xenheap is up to C00000, but for the page 0xbff000, it is not mapped. Also, it is marked as "used" tested by is_page_in_use().

OK, now the page 0xbff000 is xenheap according to is_xen_heap_page(), and it is used according to is_page_in_use(), but it is not mapped.
The issue happens.

Comment?

Thanks.
Shane


Here is my print.

(XEN) memguard: 2e6000 - 800000
(XEN) init_heap_pages: 2e6000 - 800000
(XEN) memguard: 87f000 - c00000
(XEN) init_heap_pages: 87f000 - bff000

RE: Xenheap issue on 32b

[Wang, Shane]

Hi Keir,

The issue causes page fault when the MACing code tries to access the page and hang.
I suggest to initialize that page (I think it is in use because of dirty content) as unused, or xenheap_phys_end minus one page.

Which one do you prefer?

Thanks.
Shane

Wang, Shane wrote:
> 
> OK, now the page 0xbff000 is xenheap according to is_xen_heap_page(),
> and it is used according to is_page_in_use(), but it is not mapped.
> The issue happens. 
> 
> Comment?
> 
> Thanks.
> Shane

Re: Xenheap issue on 32b

[Keir Fraser]

In init_Xenheap_pages(), try placing the call to memguard_guard_range()
*after* the adjustments to ps and pe (i.e., immediately before the call to
init_heap_pages()). I reckon that simple change should work for you.

 -- Keir

On 28/01/2010 15:29, "Wang, Shane" <shane.wang@intel.com> wrote:

> Hi Keir,
> 
> The issue causes page fault when the MACing code tries to access the page and
> hang.
> I suggest to initialize that page (I think it is in use because of dirty
> content) as unused, or xenheap_phys_end minus one page.
> 
> Which one do you prefer?
> 
> Thanks.
> Shane
> 
> Wang, Shane wrote:
>> 
>> OK, now the page 0xbff000 is xenheap according to is_xen_heap_page(),
>> and it is used according to is_page_in_use(), but it is not mapped.
>> The issue happens.
>> 
>> Comment?
>> 
>> Thanks.
>> Shane
> 
>