From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Walking an HVM's shadow page tables and other memory management questions. Date: Sat, 07 Jul 2007 09:42:34 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1839846410==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Roger Cruz , xen-devel@lists.xensource.com Cc: Tim Deegan List-Id: xen-devel@lists.xenproject.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1839846410== Content-type: multipart/alternative; boundary="B_3266646154_5314651" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3266646154_5314651 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit The phys-to-machine mechanism needs to be taught about foreign mappings. Currently it will always assume that the pages mapped into the p2m belong to the local domain. For encoding I would suggest the p2m entries have PAGE_PRESENT clear and then use some special encoding of the N-1 other bits to indicate a foreign page. I expect then shadow code may need modifying to pass around a foreign domain pointer in some contexts. -- Keir On 6/7/07 20:09, "Roger Cruz" wrote: > It looks like get_page_and_type is returning 0. > > (XEN) mm.c:633:d3 l1e_get_flags(l1e) =0x63, shadow_mode_external(d)= 0x4000, > current->domain=0x3,get_page_and_type=0x0, get_page(page, d)=0x0 > (XEN) mm.c:639:d3 Error getting mfn 14f0d4 (pfn 1697) from L1 entry > 000000014f0d4063 for dom3 > > Domain 2 is the grantor and Domain 3 is the grantee in this example. It > appears to me that it is failing because dom3 is not the owner of the shared > page > > if ( unlikely((x & PGC_count_mask) == 0) || /* Not allocated? */ > unlikely((nx & PGC_count_mask) == 0) || /* Count overflow? */ > unlikely(d != _domain) ) /* Wrong owner? */ > > Any suggestions? --B_3266646154_5314651 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Xen-devel] Walking an HVM's shadow page tables and other memory= management questions. The p= hys-to-machine mechanism needs to be taught about foreign mappings. Currentl= y it will always assume that the pages mapped into the p2m belong to the loc= al domain.

For encoding I would suggest the p2m entries have PAGE_PRESENT clear and th= en use some special encoding of the N-1 other bits to indicate a foreign pag= e. I expect then shadow code may need modifying to pass around a foreign dom= ain pointer in some contexts.

 -- Keir

On 6/7/07 20:09, "Roger Cruz" <rcruz@marathontechnologies.com&= gt; wrote:

It looks like get_page_and_type is ret= urning 0.
 
(XEN) mm.c:633:d3 l1e_get_flags(l1e) =3D0x63, shadow_mode_external(d)=3D 0x4000= , current->domain=3D0x3,get_page_and_type=3D0x0, get_page(page, d)=3D0x0
(XEN) mm.c:639:d3 Error getting mfn 14f0d4 (pfn 1697) from L1 entry 0000000= 14f0d4063 for dom3
 
Domain 2 is the grantor and Domain 3 is the grantee in this example.  = It appears to me that it is failing because dom3 is not the owner of the sha= red page
 
       if ( unlikely((x & PGC_count_= mask) =3D=3D 0) ||  /* Not allocated? */
            unl= ikely((nx & PGC_count_mask) =3D=3D 0) || /* Count overflow? */
            unl= ikely(d !=3D _domain) )          =      /* Wrong owner? */
 
Any suggestions?

 --B_3266646154_5314651-- --===============1839846410== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1839846410==--