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

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

>>> > 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.

I am going to make a best effort to get in to 4.5 but it is looking like a long 
shot at this point.

Thanks,
Aravindh


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