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 ])

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: 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

Reply via email to