| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ppc-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
|
|
|
| |
|
Home