Re: [Xen-devel] Re: mapping problems in xenpaging

[Adin Scannell <adin@xxxxxxxxxxxxxx>]

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