[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



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

Thanks,
Aravindh


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