[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC] DOMCTL_memattrs_op : a new DOMCTL to play with stage-2 page attributes
>>> On 07.07.17 at 10:56, <george.dunlap@xxxxxxxxxx> wrote: > On 07/07/2017 08:27 AM, Jan Beulich wrote: >>>>> 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. > > I had a hard time interpreting that paragraph. Did you mean: > > "Have you considered trying to populate the p2m table with the correct > permissions when first populating it, rather than populating it with > plain rw ram and then changing it afterwards?" Yes. I'm sorry for having badly expressed myself. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |