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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.08.14 at 02:14, <aravindp@xxxxxxxxx> wrote:
>>>>> 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.
>>>>
>>>>If that's tolerable guest-performance-wise...
>>>
>>> It would be for the use cases we. The performance hit would only be for
>>> users who want to watch for writes to memory that is shared between Xen
>>and
>>> the guest. Given that which variant would you prefer between the CR0.WP
>>and
>>> pagetable methods?
>>
>>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.

Jan


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