| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ppc-devel
Re: [XenPPC] Remapping xenheap pages into dom0.
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
|
|
|
| |
|
Home