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.
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems.
[Company #5334508: XenSource UK Ltd, reg'd c/o EC2Y 5EB, UK.]
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home