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-ia64-devel

[Xen-ia64-devel] RE: [Xen-devel] RE: Linux PG_arch_1 conflict

To: "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>, "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>
Subject: [Xen-ia64-devel] RE: [Xen-devel] RE: Linux PG_arch_1 conflict
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Tue, 14 Mar 2006 10:54:05 +0800
Cc: xen-ppc-devel@xxxxxxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Hollis Blanchard <hollisb@xxxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 14 Mar 2006 02:54:59 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZHDPZZgWaszaiRTQyQB+ABpFXUyQABQSHw
Thread-topic: [Xen-devel] RE: Linux PG_arch_1 conflict
>From: Isaku Yamahata
>Sent: 2006年3月14日 10:12
>> > > Comments, Keir (or others)?
>> >
>> > Sounds like the proper fix. I'll leave it to Christian and others
>> > involved in the Linux upstreaming effort to have the final word.
>>
>> Comments, Christian (or others)?  Any chance this will get into
>> 3.0.2?  Certainly it should be changed before attempting to push
>> the drivers upstream to Linux.
>
>What do you think of the followings? Too hacky?
>
>
>extern struct address_space xen_ia64_foreign_dummy_mapping;
>#define PageForeign(page)      \
>       (page->mapping == &xen_ia64_foreign_dummy_mapping)
>
>#define SetPageForeign(page, dtor) do {                                \
>       set_page_private((page), (unsigned long)dtor);          \
>       (page)->mapping = &xen_ia64_foreign_dummy_mapping;      \
>} while (0)
>
>#define ClearPageForeign(page) do {    \
>       (page)->mapping = NULL;         \
>       set_page_private((page), 0);    \
>} while (0)
>
>#define PageForeignDestructor(page)    \
>       ( (void (*) (struct page *)) page_private((page)) )
>

Hi, Isaku,
        (page)->mapping is used to keep special destructor since that foreign 
page needs to be freed differently as normal linux pages, as you see in 
foreign_page.h. Your hack only ensures the check. Agree right way to go to 
propose PG_foreign upstream.

Thanks,
Kevin

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

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