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

[Tim Deegan <tim@xxxxxxx>]

At 22:20 +0000 on 28 Aug (1409260838), Aravindh Puthiyaparambil (aravindp) 
wrote:
> >>> 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.

(Also, I suspect this plan might get tangled by pages that have
multiple PTEs mapping them, but I haven't thought that all the way
through yet.)

Tim.

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