In testing out the p2m/m2p patches which simplify our memory translation code,
I ran into the issue of not being able to distinguish foreign machine frames
from valid dom0 pfns with dom0 >2G.
To address this particular issue we want to move the p2m table from Xen into the
guest kernel for privileged domains (or any domain needing to do IO) and require
priv domains to pass machine addrs to the hypervisor for insertion into the hash
table.
As a result of this change, we can further simplify our pfn2mfn()
translation (we can drop check for IO, and the foreign type check hack) and we
will be able to support balloon drivers, with priv domains maintaining their
p2m table.
The privileged guest needs the p2m table to be available during early boot in
order to build its memory mappings. As the guest is in real-mode during early
boot the p2m table has to reside in the RMA. By putting the p2m table in the
RMA, we are introducing some limitations. There are smaller RMA sizes that we
would like to use even if we are stuck at 64MB for now, however, putting in the
p2m table would keep our min RMA at 64MB. Assuming that we would install the
p2m table at 32MB, that imposes a practical limit of a guest no larger than 32G.
For dom0, the p2m table will be constructed and initialized in Xen, but
installed
into the domain's RMA. A new entry in the devtree will contain the paddr of
this table for use by Linux. We will override hpte_insert et al to use the p2m
table prior to hcall.
The following changes will be needed:
Xen:
guest_physmap_{add/remove}_page():
- don't manipulate the p2m table for non-shadow domains
as the guest kernel will maintain the translation
something like:
guest_physmap_add_page()
if (!d->is_shadow)
return;
/* update d->arch.p2m table for shadow domains*/
pfn2mfn():
- translation for priv domains is done in the kernel
if (!d->is_shadow)
return pfn;
construct_dom0:
- we won't initialize the Xen p2m table for dom0 (d->arch.p2m)
don't call guest_physmap_max_mem_pages()
- allocate the rma (which calls guest_physmap_add_page, but
that is a nop for non-shadow domains)
- calculate a location for the p2m table in the guest RMA
something like just past the OF area, or some distance back
from the end of the RMA, leaving enough room for a p2m table
that covers the max domain size as limited by the platform
- fix up p2m table in RMA with the mfns allocated. We can do this
as we have a struct page pointer (d->arch.rma_page) which we can turn
into a mfn. A simple for loop and we will build the p2m mapping for
the RMA.
- set d->arch.p2m to the maddr of the p2m table in the guest RMA
this will be used when we allocate extents for the domain.
- add paddr of p2m table to devtree or at least keep track of paddr
for devtree to use when we later construct it
- allocate_extents()
- as we allocate the extents, rather than call guest_physmap_add_page()
we use the struct page pointer and a small for loop to initialize
the p2m table directly (using d->arch.p2m).
Linux:
- override hpte_insert et al to translate pfn to mfn prior to hcall
- modify xen comm code (for priv domains) to use p2m table to translate
physical to machine before calling hypervisor
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
