RE: [Xen-devel][PATCH] unshadow the page table page which areused as data page

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Keir Fraser
>Sent: 2007年12月10日 16:25
>
>It's a very common thing to do with unused ptes. You can't really infer
>anything from writes where _PAGE_PRESENT is clear.
>
> -- Keir

Will OS use those unused ptes in performance critical path? If not, this
change may be tolerable for the penalty on that type of usage, due to
unshadow, but benefit normal data page access a lot like encountered
in Xiaohui's case? For _PAGE_PRESENT clear case, guest page fault
is anyway injected and shadow them just means we can accelerate the
injection by fast path...

Thanks,
Kevin

>
>On 10/12/07 02:48, "Xin, Xiaohui" <xiaohui.xin@xxxxxxxxx> wrote:
>
>> Hi, Tim
>> Heard from Kevin that the Linux kernel writes swap cache 
>entries in swap cache
>> pages. And the swap cache entries contains only type and 
>offset which seems
>> not contains valid mfn at all. Does the patch will hurt 
>this? Is there any
>> other situations that guest write NON-PTE entries in the page tables?
>> 
>> Thanks
>> Xiaohui
>> 
>> -----Original Message-----
>> From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx]
>> Sent: 2007年12月7日 22:40
>> To: Xin, Xiaohui
>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Kay, Allen M
>> Subject: Re: [Xen-devel][PATCH] unshadow the page table page 
>which are used as
>> data page
>> 
>> Hi, 
>> 
>> At 21:12 +0800 on 07 Dec (1197061925), Xin, Xiaohui wrote:
>>> Tim,
>>>  Attached is the updated patch which based on some part of your
>>> suggestion and some part of our new thoughts about it. We have
>>> re-checked the code path of the guest write emulate, found that in
>>> some extent(not all) the code checks the valid mfn for the guest
>>> written data. But maybe for the optimization, the code just check
>>> valide mfn when PRESENT bit exists. Maybe it can cover most of the
>>> cases, but not all, that's what we have found in the vt-d 
>iperf test.
>> 
>> Hmmm.  The new behaviour is slightly nonintuitive, as it 
>lets the guest
>> write non-present entries without unshadowing only if the bits that
>> would have been the GFN are in fact a valid GFN (which happens to
>> include zero).  I think it's OK, but needs a comment.
>> 
>> Please don't change validate_gl1e or include level-1 shadow types in
>> check_for_data_page_unshadow().  Windows, in particular, 
>keeps all sorts
>> of non-PTE-like values in PTE slots, and we can't treat those as a
>> reason to unshadow.
>> 
>>>  To minimize the hurt to other performance of shadow, the 
>patch tries
>>> to use the valid mfn check in the original code, please have a
>>> review. I'm not sure about the cost of the gfn_to_mfn(), 
>and not sure
>>> whether we may get some trade-off. If you have good ideas, 
>please let
>>> us know.
>> 
>> gfn_to_mfn() is very cheap when shadow mode is being used.
>> 
>> Cheers,
>> 
>> Tim.
>
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel
>

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