Re: [Xen-devel] [PATCH RFC v2 1/4] x86/mm: Shadow and p2m changes for PV mem_access

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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