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

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

>>>>Nope, I think you're in even deeper trouble than that -- shadow PTEs
>>>>can be dropped at any time (e.g. because of memory pressure) so you
>>>>can't rely on their being present or absent to mean anything.
>>>
>>>You are right. Shadow PTEs being present cannot be used as an
>>>indicator. So the problem of setting default access and converting all
>>>pages to it will
>> exist
>>>irrespective of what data structure I use. The only way I can think of
>>>doing
>> this
>>>is to walk the page_list but if the hypercall gets preempted, there is
>>>the possibility that the list could get modified which would break the
>> continuation.
>>>Is the page_list the only place that will tell me the range of pages
>>>that
>> belong
>>>to a PV guest? Is the max PFN stored somewhere?
>>
>> The one solution I was kicking around is to add a flag that denotes if
>> the page_list was modified. The flag will be set to 0 at the beginning
>> of
>> mem_access_set_default() if we are starting at the head of page_list
>> and when it is preempted. The flag will be set to 1 in
>> page_list_add/del() and friends if the page belongs to a PV domain
>> that has a mem_access listener. On hypercall preemption / continuation
>> i.e. start_page has a value,
>> mem_access_set_default() will check this flag. If it is set then it
>> will restart setting the permissions from the head of page_list. We
>> can give it N number of retries and if it does not go through we can
>> return an error. If it goes through successfully, we will set this
>> flag to 0. Do you think this is a viable solution?
>
>What would you think of a feature that has relatively little change of working
>at all on certain kinds of guests (e.g. with autoballooning turned on, i.e. 
>where
>the list of owned pages may be constantly in flux)?

Setting the default access is typically an operation done once during the life 
of mem_access listener. It is not something that the listener constantly calls. 
So this issue will occur only when mem_access_set_default() is called during 
ballooning. For pages added after the call has been made will get the default 
access permission using a hook in assign_pages().

>What we do in at least one other place is shuffle the list from one
>list head to another, and put the hole thing back when done. I'm
>not sure this is a good option here (in particular not going to break
>that other case, as well as then needing to consider that if there
>are two sites doing this, there may well appear a third one, and
>hence the question would become whether this scales).

Yes, you are right that if the number of places the page_list is modified 
outside of the page_list_*() functions, then this check will have to be done in 
every location. 

Is the page_list the only place that will tell me the range of pages that 
belong to a PV guest? 

Thanks,
Aravindh


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