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

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

>> Just to be certain as to where we stand:
>>
>> 1. The "page table RW bit flipping" solution is not viable because pausing
>> the domain synchronously takes too long for many vcpus domains. Plus
>there is
>> the added issue of vcpu vs domain heuristics. This is the case even after
>> solving the page boundary and multiple page copy issues.
>>
>> 2. The "CR0.WP with interrupts disabled" solution is not viable because of
>> NMIs. Or did I misunderstand?
>
>For this second option, NMIs are a concern. Whether that makes it
>not viable I'm not certain. We really need to weigh benefits and risks
>here, and from a project wide perspective I'm currently viewing the

From what I can tell, Andrew does think that this route is a viable option and 
I will defer to you and him about this. If there is agreement that this 
approach is acceptable, I will send out another version of the patches 
implementing it.

>PV mem-access feature as a niche thing, the more that I'm unaware
>of really wide spread use if HVM mem-access capabilities. I.e. the
>most I can currently see happening is for it to go in clearly marked
>experimental, provided that no code path used outside of that
>feature suffers in any way (functionality and performance). But of
>course I'm open to be convinced otherwise, or overruled by a
>majority of other maintainers.

I agree that PV/HVM mem_access feature is indeed niche, however it is a value 
add feature for Xen when compared to other hypervisors. It is attracting users 
who are interested in developing security and guest inspection/introspection 
products. And yes, I agree that the code added for mem_access should not 
adversely affect other areas of the project. I would hope this feature area is 
given encouragement to grow by the community. Just my two bits...

Thanks,
Aravindh


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