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

["Aravindh Puthiyaparambil (aravindp)" <aravindp@xxxxxxxxx>]

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

Good point. The only other thing I can think of to get around this issue is to 
pause the domain during these writes and unpause it on the way out of the guest 
access functions.

Thanks,
Aravindh


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel