[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC v2 1/4] x86/mm: Shadow and p2m changes for PV mem_access
>>> On 30.07.14 at 06:05, <aravindp@xxxxxxxxx> wrote: > I took another stab at solving this issue. This is what the solution looks > like: > > 1. mem_access listener attaches to a PV domain and listens for write > violation. > 2. Xen tries to write to a guest page that is marked not writable. > 3. PF occurs. > - Do not pass on the violation to the mem_access listener. > - Temporarily change the access permission for the page in question to > R/W. > - Allow the fault to be handled which will end up with a PTE with the > RW bit set. > - Stash the mfn in question in the pv_vcpu structure. > - Check if this field is set on exiting from guest access functions. If > it > is, reset the page permission to the default value and drop its shadows. > 4. I had to take care that the checks in the guest access functions for > resetting the page permissions do not kick in when the shadow code is trying > to construct the PTE for the page in question or when removing all the > mappings. > > Here is a POC patch that does the above. I have it on top of the patch that > was using CR0.WP to highlight the difference. I realize some of the other > comments like using shadow_flags have not been addressed here. I just want to > get feedback if this is a viable solution before addressing those issues. Still rather ugly, and still leaving the window in time as big as the CR0.CD variant (the window in space got shrunk to just a page). Furthermore, how would you guarantee no other vCPU of the same guest modifies the now writable page in the meantime? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |