[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

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


Xen-devel mailing list



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