[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH V2 5/5] Xen: switch to linear virtual mapped sparse p2m list



On 11/07/2014 03:40 PM, David Vrabel wrote:
On 07/11/14 14:11, Juergen Gross wrote:
On 11/07/2014 02:54 PM, David Vrabel wrote:
On 06/11/14 05:47, Juergen Gross wrote:
[...]
@@ -526,23 +411,83 @@ unsigned long get_phys_to_machine(unsigned long
pfn)
           return IDENTITY_FRAME(pfn);
       }

-    topidx = p2m_top_index(pfn);
-    mididx = p2m_mid_index(pfn);
-    idx = p2m_index(pfn);
+    ptep = lookup_address((unsigned long)(xen_p2m_addr + pfn), &level);
+    BUG_ON(!ptep || level != PG_LEVEL_4K);

       /*
        * The INVALID_P2M_ENTRY is filled in both p2m_*identity
        * and in p2m_*missing, so returning the INVALID_P2M_ENTRY
        * would be wrong.
        */
-    if (p2m_top[topidx][mididx] == p2m_identity)
+    if (pte_pfn(*ptep) == PFN_DOWN(__pa(p2m_identity)))
           return IDENTITY_FRAME(pfn);

-    return p2m_top[topidx][mididx][idx];
+    return xen_p2m_addr[pfn];

You should test xen_p2m_addr[pfn] == INVALID_P2M_ENTRY before checking
if it's an identity entry.  This should skip the more expensive
lookup_address() in the common case.

I do. The check is in __pfn_to_mfn(). get_phys_to_machine() is called in
this case only.

So you do.  I missed that.

   bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)

I think you should map p2m_missing and p2m_identity as read-only and do
the new page allocation on a write fault.

set_phys_to_machine() is used every grant map and unmap and in the
common case (already allocated array page) it must be a fast and simple:

      xen_p2m_addr[pfn] = mfn;

Nice idea. I'll try it.

You probably want to try this with a custom exception fixup (or abuse
put_user()).

Yeah, that was my idea, too.

Juergen


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