Re: [Xen-devel] [RFC] DOMCTL_memattrs_op : a new DOMCTL to play with stage-2 page attributes

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.07.17 at 20:07, <julien.grall@xxxxxxx> wrote:
> On 07/06/2017 06:42 PM, Stefano Stabellini wrote:
>> On Thu, 6 Jul 2017, Jan Beulich wrote:
>>> Considering the intended purpose here (as far as I recall it), was it
>>> already taken into consideration to request suitable attributes right
>>> at the time the page gets installed into the physmap? Iirc there's no
>>> need to actually "play" with the attributes at random times.
>> 
>> This operation would be done before the guest starts.
>> 
>> 
>> Let's give a look at the list the changes that would be required to make
>> these hypercalls suitable for this task:
>> 
>> 1) remove the dependency on CONFIG_HAS_MEM_ACCESS
>> 2) remove the p2m_mem_access_sanity_check check for these two hypercalls
>> 3) remove the (!d->vm_event->monitor.ring_page) check for these two 
>> hypercalls
>> 4) prevent p2m->mem_access_enabled from being set for these two hypercalls
>> 
>> Am I missing anything? After we do this, would they still be useful for
>> their original mem_access related purpose?
> 
> But how would you handle mem_access on those regions in that case? This 
> looks completely incompatible.
> 
> The memaccess code has to store the previous permission in order to look 
> for the fault. Here you want to modify for good.
> 
> Furthermore, memaccess is only here to modify permission. It does not 
> handle cacheability... So it looks to me you are trying to re-purposing 
> an hypercall that will not fit all our needs in the future.
> 
> I think the way forward is to introduce an hypercall which populate/map 
> memory with a given set of attributes and permissions.
> 
> This would simplify quite a lot the logic (one hypercall instead of 
> multiple one) and avoid to worry about attributes changed multiple time 
> even before the guest is booting.

Right - that's what I was suggesting with the last paragraph of my
previous reply; I have to admit that I have trouble seeing how
Stefano's response relates to that.

Jan


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