For some CoW purposes, I''m marking all of a the PTEs of ab HVM guest''s current shadow PTs read-only and catching shadow PT induced page faults to perform the CoW. I''ve modified the page fault handler in xen/arch/x86/mm/shadow/multi.c to catch our CoW induced faults as well as the sh_update_cr3 function to go through and mark all shadow PTEs read-only for the new set of PTs created on the address space change. It seems that for some types of page faults, the shadow PTEs are mucked with and brought back into line with the guest PTEs, which could revert a read-only shadow PTE back to writable. I can handle this case in the page fault handler to remark those pages read-only in the shadow PTE, but I''m afraid there are other places in which the shadow PTEs are mucked with (e.g. x86 guest PT write emulations) which could break my read-only requirement. In which places can shadow PTEs be changed and/or where is the best place for me to check to see if I must remark them read-only for my purposes? Maybe in a low level function like "shadow_set_l1e"? Thanks, Mike _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 00:15 -0400 on 02 May (1209687305), Mike Sun wrote:> In which places can shadow PTEs be changed and/or where is the best > place for me to check to see if I must remark them read-only for my > purposes? Maybe in a low level function like "shadow_set_l1e"?Shadow PTEs are calculated from guest PTEs in _sh_propagate(): anywhere that we write a shadow entry, it should have come from a call to one of the propagate_from_guest() functions, which all end up in _sh_propagate(). There''s already a clause in that function to remove the _PAGE_RW bit if the target page hasn''t been marked dirty and log-dirty mode is enabled. Extending that should be enough. The tricky part, I would have thought, is finding all the places where guest memory is written without going via the shadow pagetables. Cheers, Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Citrix Systems (R&D) Ltd. [Company #02300071, SL9 0DZ, UK.] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel