Xen devel - Mar 2006 - [Xen-ia64-devel] RE: 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@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

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@lists.xensource.com
http://lists.xensource.com/xen-devel