Re: [XenPPC] domain physical to machine address translation

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

nice, some comments.
On Feb 14, 2007, at 11:54 AM, Hollis Blanchard wrote:

> I was talking with Ryan yesterday, and we settled on a scheme to  
> resolve
> some of our current memory management ugliness.
>
> If we have a notification hook in the XEN_DOMCTL_max_mem handler, we
> could size an array for each domain containing a pointer into the
> frame_table per page. There are already hooks in
> increase/decrease_reservation, except we aren't using them! In
> particular:
>       * When a domain's max_page is set, we allocate an appropriately
>         sized array of pointers, initialized to NULL.
Is domain->p2m that array?
Why pointers, you can decrease the array size if you keep it full of  
MFNs (which are u32s) which is good to 16TiB
>       * increase_reservation() calls guest_physmap_add_page() with
>         domain, pfn, and mfn. domain->p2m[pfn] = mfn_to_page(mfn)
domain->p2m[pfn] = mfn
>       * decrease_reservation() calls guest_physmap_remove_page() with
>         the same parameters. domain->p2m[pfn] = NULL
domain->p2m[pfn] = INVALID_MFN

What is the locking model?

IIRC it is possible to increase (but not decrease?) maxmem, so that  
would be an alloc, copy, free?
Will you allow increases that are not multiple of 16MiB of our  
current extents?
Should we (trivially) teach linux not to use large pages to allow  
maximum freedom (after RMA)?
It would actually reduce our linux patch.

> Benefits:
>       * slightly simplify pfn2mfn(); in particular we could remove the
>         RMA check, the extent list walk, and the grant table check. I
>         think the IO and foreign checks wouldn't be as trivial, but
>         maybe we could figure that out later
Thoughts,
on the 970 if you have more than 2GiB of memory then your frame_table  
will actually contain the IO area.  In order to
>       * drastically improves performance for accessing high  
> addresses in
>         large domains (avoids the extent list walk)
Agreed!

>       * enables memory ballooning, although some Linux work needed to
>         avoid the RMA.
>
> By my calculations (which always need to be double-checked ;) the  
> memory
> consumption of a pointer per page would be 1/500th,
1/512th.. please respect the powers of 2 :)
> e.g. a 1GB domain
> would require a 2MB array.
Moving to MFNs drops that down to 1MB

> This memory would probably need to be
> allocated from the domain heap to avoid exhausting the Xen heap.
I'd like to avoid messing up the domain heap, nothing is worse than  
having a lot of free memory no space that can be used for RMA.  Since  
the needs of these arrays are quite predicable, 1 p2m[] entry for  
every mfn, we could accommodate for that in the Xen heap like we do  
for HTABs.
> We don't need to use an array long-term, though I think it's the  
> easiest
> initial implementation.
agreed.

> The simplest version of this patch would just replace the RMA and  
> extent
> list walking in pfn2mfn(), so it's nothing radical.
nice.

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