Unshadowing the whole page is probably not a very good idea. If bit 0 is set
then of course you can do a lot more. But if bit 0 is clear then there is
not necessarily a gpfn to pull out and test.
Perhaps if you knew that the page contained no or very few _PAGE_PRESENT
ptes then you could unshadow? But it's probably not worth the book-keeping.
Beyond that you're into OS-specific heuristics.
-- Keir
On 10/12/07 08:42, "Xin, Xiaohui" <xiaohui.xin@xxxxxxxxx> wrote:
> So now we CANNOT do any optimization to the guest write (like what we have
> seen that the guest just write pure data in an unused page table), right?
>
> Thanks
> Xiaohui
>
> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
> Sent: 2007年12月10日 16:25
> To: Xin, Xiaohui; Tim Deegan
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Kay, Allen M
> Subject: Re: [Xen-devel][PATCH] unshadow the page table page which areused as
> data page
>
> 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
>
> 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
|
Home