>> When we analyze and test xenpaging,we found there are some problems between
>> mapping and xenpaging.
>> 1) When mapping firstly, then do xenpaging,and the code paths have resolved
>> the problems.It's OK.
>> 2) The problems exists if we do address mapping firstly then go to
>> xenpaging,and our confusions are as followings:
>> a) If the domU's memory is directly mapped to dom0,such as the hypercall
>> from pv driver,then it will build a related page-table in dom0,which will not
>> change p2m-type.
>> and then do the xenpaging to page out the domU's memory pages whose gfn
>> address have been already mapped to dom0;So it will cause some problems when
>> dom0
>> accesses these pages.Because these pages are paged-out,and dom0 cannot
>> tell the p2mt before access the pages.
>
> I'm not entirely sure what you do. xenpaging runs in dom0 and is able to
> map paged-out pages. It uses that to trigger a page-in, see
> tools/xenpaging/pagein.c in xen-unstable.hg
Here's my take...
Xenpaging doesn't allow selection of pages that have been mapped by
other domains (as in p2m.c):
669 int p2m_mem_paging_nominate(struct domain *d, unsigned long gfn)
....
693 /* Check page count and type */
694 page = mfn_to_page(mfn);
695 if ( (page->count_info & (PGC_count_mask | PGC_allocated)) !=
696 (1 | PGC_allocated) )
697 goto out;
*However*, I think that the problem Zhen is describing still exists:
1) xenpaging nominates a page, it is successful.
2) dom0 maps the same page (a process other than xenpaging, which will
also map it).
3) xenpaging evicts the page, successfully.
I've experienced a few nasty crashes, and I think this could account
for a couple (but certainly not all)... I think that the solution may
be to repeat the refcount check in paging_evict, and roll back the
nomination gracefully if the race is detected. Thoughts?
>> b)The another situation is that if xen has mapped the domU's page, and get
>> the mfn according to pfn_to_mfn.But then the page's p2mt is changed by
>> others,
>> so when xen
>> accesses the page ,it will cause problems such as BSOD or reboot.Because
>> the operations of getting mfn and accessing the page are not
>> atomic.and the situation exists
>> in many code paths .
I believe I have recreated this problem a few times, resulting in
various crashes... unfortunately, there is somewhat of an implicit
assumption throughout the code that when you grab an mfn via
gfn_to_mfn, that mfn won't disappear underneath you (for example, see
vmx_load_pdptrs). Really, you want something like gfn_to_mfn_getpage,
where the underlying page has its refcount bumped so that it won't be
nominated/evicted while you map and use the page, then you must put it
back when you're done. I hope to look into helping fix some of these
paging bugs soon.
Cheers,
-Adin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home