[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 29.08.14 at 21:03, <aravindp@xxxxxxxxx> wrote:
>>>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)?

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

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.