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

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

>>> >>> In the PV case step 2 is problematic as the range of pages that belong
>>> >>> to the PV guest is unknown to the mem-access listener. I tried adding
>>> >>> another PV specific API for setting default access that will walk the
>>> >>> page_list and set the shadow_flag to default. But Jan rightly pointed
>>> >>> out issues surrounding hypercall preemption / continuation during
>>> >>> which, the page_list could be modified. So my current plan is to blow
>>> >>> all shadow pages every time the API for setting default access is
>>> >>> called. The on the subsequent page-faults where the PTE is marked
>not
>>> >>> present, set the shadow_flag to the default access as part of creating
>>> >>> the PTE.
>>> >>
>>> >>How do you know when this step finishes?  I.e. how can you tell the
>>> >>difference between an access field in the shadow_flags that was set
>>before
>>> >>you enabled mem_access and one that was set since?
>>> >
>>> >What I was thinking of doing is, in p2m_mem_access_get_entry(), check
>if
>>PTE
>>> >for the page is marked present and return the access value in the
>>> >shadow_flags if it is. If it is not present, then return the default access
>>value.
>>>
>>> I realized this does not cover for the case when
>>p2m_mem_access_set_entry() gets called for a non-present page.
>>Subsequent p2m_mem_access_get_entry() will return the default access
>>value. Even worse subsequent page fault will overwrite the access value in
>>shadow flags with the default. Should I disallow
>>p2m_mem_access_set_entry() for non-present pages to work around this?
>>>
>>
>>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?

Thanks,
Aravindh


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