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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.09.14 at 21:40, <aravindp@xxxxxxxxx> wrote:
>> > It might be possible to make the walk restartable if we arrange that:
>>> - all additions to the page list are at the tail;
>>> - walks in progress are recorded (though I'm not sure where: it might
>>>   be possible just to use a single bit in the page_info to say "this
>>>   page is the cursor of an interrupted walk" and have a separate
>>>   per-domain list of interrupted walks); and
>>> - anything that removes a page from a domain's page_list must check
>>>   that bit; if it finds it set it must update the per-walk state to
>>>   point to the next page.
>>>
>>> Jan, do you think that's viable?  I think it'll need a bit of thought
>>> around the edge cases, and the semantics will need to be written down
>>> carefully.
>>
>>Yes, nice idea - I think that could work (with particularly converting
>>arch_iommu_populate_page_table() to use that mechanism, while inspecting
>>[and perhaps adjusting] the related code in
>>p2m_pod_offline_or_broken_hit()) and would not end up being too ugly (i.e.
>>not exactly nice, but maintainable).
> 
> As I was looking into implementing this, I notice that the functions won't 
> be called for PV domains. So I assume this implementation is a generic 
> mechanism to make page_list walks pre-emptible and not specific to the PV 
> mem_access use case. If that is the case I would prefer committing this as a 
> separate patch in the 4.6 time frame and follow it up with the PV mem_access 
> patch. Is that agreeable?

The generic part being a separate patch certainly makes sense. And
yours then going on top does (of course) too. The implication being
that the PV mem-access functionality then all will only go in for 4.6.

Jan


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