Re: [XenPPC] Remapping xenheap pages into dom0.

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

Tony,
Yes you are getting Kernel pages.

On Nov 13, 2006, at 12:47 AM, Tony Breeds wrote:

> Howdy all,
>         I'm having problems getting what should be a reasonably
> fundamental operation working.
>
> I have a set of xenheap pages that I'm initialising and then  
> attempting
> to map in to dom0 (This is for hcall tracing [ xen/common/trace.c ])
[SNIP]
> Does anyone have any ideas on what I can look at to work out why  
> I'm not
> getting that page I think I should be getting?
>
> Does anyone have any ideas on what I can look at to work out why  
> I'm not
> getting that page I think I should be getting?
You are on the verge of discovering a dirty little secret.
Currently our PFN (aka Guest MFN or GMFN) to MFN translation is  
pretty messy.
This all comes down to the fact that our PTE entry hypercall  
(H_ENTER) has not mechanism to say that the PFN is actually an MFN.   
Much of the hacker is explained in pfn2mfn() in the Xen code.
The only reason Dom0 is currently able to map an MFN belonging to a  
new domain is that when you use that MFN as a PFN it is greater than  
Dom0's Largest PFN and we let you map the MFN dirrectly because you  
are Dom0.
The problem you are having is that Xen Heap pages all have MFNs that  
are below even Dom0's MFN, and therefore will not get trapped by the  
hack above. So yes, you are simply remapping your own dom0 memory.
What we have been doing to get around this is "decorating" the PFN  
with a high order bit in such a way that Xen can recognize the PFN as  
(<Magic Bit> | MFN) and map it.  Dan and Yi are using (1UL<<34 [I  
think]) to decorate Dom0 apps access to the HTAB of a suspending  
domain, also more Xen heap pages.
The grant tables (mappable by all doamins) are more xen heap pages  
that need decorating, where I'm currently using the page after max_page.
Complicating this even further is that we need a foreign page area  
(Magic bit == 1UL<<22) to allow for granted memory to be mapped by  
the grantee.
Its dirty, stinky and sucks, but its what we have at the moment until  
we spend the time to unify it all somehow.
Take a look at Dan and Yi's patch you should be able to reuse their  
decoration:
  http://lists.xensource.com/archives/html/xen-ppc-devel/2006-11/ 
msg00028.html
NOTE: this patch is still under review.


> Also, this may or may not be related.
>
> If I don't call down to share_xen_page_with_guest() I would have
> expected to get some form of oops or crash, but the machine  
> exhibits the
> same behavior.  Actually that probably indicates that I'm getting a
> kernel pages rather than xen page.
All share_xen_page_with_guest() seems to do is mark a XenHeap page as  
used by a domain for accounting purposes and debugging.  Am not  
surprised it makes no difference.

_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel