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? 

Thanks,
Aravindh


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