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

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

>>>Since the page table one has the overall smaller window of reduced
>>>protection, I think I'd prefer that one. However, judging the overhead
>>>acceptability by just the specific use case you have is perhaps
>>>insufficient for including your changes in the public tree, especially
>>>with no clear perspective of how to reduce it if someone indeed cared.
>>
>> I am a little lost by your statement about specific use case. People using
>> mem_access typically use it for security and guest inspection purposes. They
>> are aware of the performance hits that come along with that. Given that use
>> case, would you please reconsider including these changes? Or were you
>> talking about other use cases?
>
>No, at least not about unspecified hypothetical ones. But again - a
>vague statement like you gave, without any kind of quantification of
>the imposed overhead, isn't going to be good enough a judgment.
>After all pausing a domain can be quite problematic for its performance
>if that happens reasonably frequently. Otoh I admit that the user of
>your new mechanism has a certain level of control over the impact via
>the number of pages (s)he wants to write-protect. So yes, perhaps it
>isn't going to be too bad as long as the hackery you need to do isn't.

I just wanted to give an update as to where I stand so as to not leave this 
thread hanging. As I was working through pausing and unpausing the domain 
during Xen writes to guest memory, I found a spot where the write happens 
outside of __copy_to_user_ll() and __put_user_size(). It occurs in 
create_bounce_frame() where Xen writes to the guest stack to setup an exception 
frame. At that moment, if the guest stack is marked read-only, we end up in the 
same situation as with the copy to guest functions but with no obvious place to 
revert the page table entry back to read-only. I am at the moment looking for a 
spot where I can do this. 

Thanks,
Aravindh


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