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

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

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: Re: [Xen-ia64-devel] RE: [Xen-devel] RE: Linux PG_arch_1 conflict
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Tue, 14 Mar 2006 13:42:44 +0900
Cc: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx, Hollis Blanchard <hollisb@xxxxxxxxxx>, xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 14 Mar 2006 04:43:43 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <571ACEFD467F7749BC50E0A98C17CDD8094E792E@pdsmsx403>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <571ACEFD467F7749BC50E0A98C17CDD8094E792E@pdsmsx403>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Tue, Mar 14, 2006 at 10:54:05AM +0800, Tian, Kevin wrote:
> >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.

A special destructor is kept in page->private by set_page_private() and
get by page_private(). page->private is unsigned long so that it can
hold pointer value.

They are just defined as
#define page_private(page)              ((page)->private)
#define set_page_private(page, v)       ((page)->private = (v))



-- 
yamahata

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

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