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] Xenheap issue on 32b

To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] Xenheap issue on 32b
From: "Wang, Shane" <shane.wang@xxxxxxxxx>
Date: Thu, 28 Jan 2010 23:13:40 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Wang, Shane" <shane.wang@xxxxxxxxx>, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, "Hao, Xudong" <xudong.hao@xxxxxxxxx>
Delivery-date: Thu, 28 Jan 2010 07:14:07 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcqgLHlBPjFa2NrMQzO7aYaNfricRQ==
Thread-topic: Xenheap issue on 32b
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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>