Xen devel - Oct 2006 - [XenPPC] [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

It looks like IA64 has introduced a start_pfn for xc_get_pfn_list().  
The PPC port requires this as well since it allows us to fill in the  
page_array a little bit at a time.

I can either replicate the IA64 ifdef logic (yuk!) or we can formally  
add a start_pfn to this interface, since it _is_ a formal member of  
the data structure.

I''ll take a stab at it, if it is acceptable.
-JX

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

On 18/10/06 10:57 pm, "Jimi Xenidis" <jimix@watson.ibm.com>
wrote:
> It looks like IA64 has introduced a start_pfn for xc_get_pfn_list().
> The PPC port requires this as well since it allows us to fill in the
> page_array a little bit at a time.
> 
> I can either replicate the IA64 ifdef logic (yuk!) or we can formally
> add a start_pfn to this interface, since it _is_ a formal member of
> the data structure.
> 
> I''ll take a stab at it, if it is acceptable.
Where is the ifdef logic?

 -- Keir



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

On Oct 19, 2006, at 3:29 AM, Keir Fraser wrote:
> On 18/10/06 10:57 pm, "Jimi Xenidis" <jimix@watson.ibm.com>
wrote:
>
>> It looks like IA64 has introduced a start_pfn for xc_get_pfn_list().
>> The PPC port requires this as well since it allows us to fill in the
>> page_array a little bit at a time.
>>
>> I can either replicate the IA64 ifdef logic (yuk!) or we can formally
>> add a start_pfn to this interface, since it _is_ a formal member of
>> the data structure.
>>
>> I''ll take a stab at it, if it is acceptable.
>
> Where is the ifdef logic?
tools/libxc/xc_private.c:265
   #ifndef __ia64__
   int xc_get_pfn_list(int xc_handle,
                     uint32_t domid,
                     xen_pfn_t *pfn_buf,
                     unsigned long max_pfns)

the patch would change this "libxc private" interface to

   int xc_get_pfn_list(int xc_handle,
                     uint32_t domid,
                     xen_pfn_t *pfn_buf,
+                   xen_pfn_t start_pfn,
                     unsigned long max_pfns)

use the start_pfn member of struct xen_domctl_getmemlist
Fix all callers and change xen to pay attention to it, I think I have  
the x86-xen patch.

-JX

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

On 19/10/06 14:12, "Jimi Xenidis" <jimix@watson.ibm.com> wrote:
> use the start_pfn member of struct xen_domctl_getmemlist
> Fix all callers and change xen to pay attention to it, I think I have
> the x86-xen patch.
Sure. Actually this interface is going away for x86, but not in the
immediate future.

 -- Keir



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

On Oct 19, 2006, at 9:15 AM, Keir Fraser wrote:
>
>
>
> On 19/10/06 14:12, "Jimi Xenidis" <jimix@watson.ibm.com>
wrote:
>
>> use the start_pfn member of struct xen_domctl_getmemlist
>> Fix all callers and change xen to pay attention to it, I think I have
>> the x86-xen patch.
>
> Sure. Actually this interface is going away for x86, but not in the
> immediate future.
Any hints, I''d like to go away for PPC as well :)
-JX

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

On 19/10/06 14:54, "Jimi Xenidis" <jimix@watson.ibm.com> wrote:
>>> use the start_pfn member of struct xen_domctl_getmemlist
>>> Fix all callers and change xen to pay attention to it, I think I
have
>>> the x86-xen patch.
>> 
>> Sure. Actually this interface is going away for x86, but not in the
>> immediate future.
> 
> Any hints, I''d like to go away for PPC as well :)
It''s only really used to get pages in PFN order. This can be done by
other
means -- for paravirt save/restore we access the guest''s own P2M table;
for
HVM guests I intend to change the mapping interface so that all callers
specify pages by PFN rather than MFN. That pretty much leaves only the
domain builder. I could leave the interface just for that I suppose, but
equally we could fill in the initial P2M table when we allocate the
domain''s
initial memory reservation (since that hypercall returns the PFNs).

Maybe we won''t kill the domctl after all, but we''ll certainly
be using it a
whole lot less. 

 -- Keir



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

Hi,
> domain builder. I could leave the interface just for that I suppose, but
> equally we could fill in the initial P2M table when we allocate the
domain''s
> initial memory reservation (since that hypercall returns the PFNs).
Who does that hypercall btw?  Seems not to be somewhere in the
xc_linux_build() code path ...

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

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

On 20/10/06 09:01, "Gerd Hoffmann" <kraxel@suse.de> wrote:
>> domain builder. I could leave the interface just for that I suppose,
but
>> equally we could fill in the initial P2M table when we allocate the
domain''s
>> initial memory reservation (since that hypercall returns the PFNs).
> 
> Who does that hypercall btw?  Seems not to be somewhere in the
> xc_linux_build() code path ...
Everyone goes through xc_get_pfn_list() (except ia64, who are
''special'' ;-).

 -- Keir



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

Keir Fraser wrote:
> 
> 
> On 20/10/06 09:01, "Gerd Hoffmann" <kraxel@suse.de> wrote:
> 
>>> domain builder. I could leave the interface just for that I
suppose, but
>>> equally we could fill in the initial P2M table when we allocate the
domain''s
>>> initial memory reservation (since that hypercall returns the PFNs).
>> Who does that hypercall btw?  Seems not to be somewhere in the
>> xc_linux_build() code path ...
> 
> Everyone goes through xc_get_pfn_list() (except ia64, who are
''special'' ;-).
I want to know nevertheless.

While I''m hacking the domain builder code anyway, maybe it''s a
good time
to change that too ;)

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

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

On Oct 20, 2006, at 4:30 AM, Gerd Hoffmann wrote:
> Keir Fraser wrote:
>>
>>
>> On 20/10/06 09:01, "Gerd Hoffmann" <kraxel@suse.de>
wrote:
>>
>>>> domain builder. I could leave the interface just for that I  
>>>> suppose, but
>>>> equally we could fill in the initial P2M table when we allocate
>>>> the domain''s
>>>> initial memory reservation (since that hypercall returns the
PFNs).
>>> Who does that hypercall btw?  Seems not to be somewhere in the
>>> xc_linux_build() code path ...
>>
>> Everyone goes through xc_get_pfn_list() (except ia64, who are  
>> ''special'' ;-).
>
> I want to know nevertheless.
>
> While I''m hacking the domain builder code anyway, maybe
it''s a good
> time
> to change that too ;)
It is called to get the MFNs of another domain fromt he build tools


cd ./xen-unstable.hg/tools/libxc/
find . \( -name CVS -o -name SCCS \) -prune -o \! \( -name \*~ -o - 
name .#\* -o -name cscope.\* \) -type f -print0 | xargs -0 -e grep -n  
xc_get_pfn_list
./xc_core.c:89:    if ( xc_get_pfn_list(xc_handle, domid, page_array,  
0, nr_pages)
./xc_hvm_build.c:259:    if ( xc_get_pfn_list(xc_handle, dom,  
page_array, nr_pages) != nr_pages )
./xc_linux_build.c:856:    if ( xc_get_pfn_list(xc_handle, dom,  
page_array, nr_pages) != nr_pages )
./xc_linux_restore.c:283:    if (xc_get_pfn_list(xc_handle, dom, p2m,  
max_pfn) != max_pfn) {
./xc_private.c:309:static int __xc_get_pfn_list(int xc_handle,
./xc_private.c:330:        PERROR("xc_get_pfn_list: pfn_buf mlock  
failed");
./xc_private.c:340:    DPRINTF(("Ret for xc_get_pfn_list is %d\n",  
ret));
./xc_private.c:355:int xc_get_pfn_list(int xc_handle,
./xc_ptrace.c:370:        if ( xc_get_pfn_list(xc_handle, current_domid,
./xenctrl.h:525:int xc_get_pfn_list(int xc_handle, uint32_t domid,  
xen_pfn_t *pfn_buf,
./powerpc64/xc_linux_build.c:372:    DPRINTF("xc_get_pfn_list\n");
./powerpc64/xc_linux_build.c:373:    rc = xc_get_pfn_list(xc_handle,  
domid, *page_array, *nr_pages);

-JX


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

Jimi Xenidis wrote:
>>>>> domain builder. I could leave the interface just for that I
>>>>> suppose, but
>>>>> equally we could fill in the initial P2M table when we
allocate the
>>>>> domain''s
>>>>> initial memory reservation (since that hypercall returns
the PFNs).
                                        ^^^^^^^^^^^^^^
>>> Everyone goes through xc_get_pfn_list() (except ia64, who are
>>> ''special'' ;-).
> .#\* -o -name cscope.\* \) -type f -print0 | xargs -0 -e grep -n
> xc_get_pfn_list
I''m not after the xc_get_pfn_list hypercall, but the (appearently?)
other hypercall Keir mentioned ...

Could be xc_domain_memory_increase_reservation() or
xc_domain_memory_populate_physmap() ...

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

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

On 20/10/06 13:29, "Gerd Hoffmann" <kraxel@suse.de> wrote:
> I''m not after the xc_get_pfn_list hypercall, but the
(appearently?)
> other hypercall Keir mentioned ...
> 
> Could be xc_domain_memory_increase_reservation() or
> xc_domain_memory_populate_physmap() ...
Oh, it''s called from xend python land somewhere... :-)

 -- Keir



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

On Oct 20, 2006, at 9:15 AM, Keir Fraser wrote:
>
>
>
> On 20/10/06 13:29, "Gerd Hoffmann" <kraxel@suse.de> wrote:
>
>> I''m not after the xc_get_pfn_list hypercall, but the
(appearently?)
>> other hypercall Keir mentioned ...
>>
>> Could be xc_domain_memory_increase_reservation() or
>> xc_domain_memory_populate_physmap() ...
>
> Oh, it''s called from xend python land somewhere... :-)
If you were not using python, or if the python was updated to  
actually obtain the list (passes a NULL pointer):
   ./python/xen/lowlevel/xc/xc.c:708:static PyObject  
*pyxc_domain_memory_increase_reservation()

one could easily build a pfn_to_mfn data structure on the tools side  
rather than get this huge array later.

This would be tremendously useful on PPC because the we typically do  
not use an order of 0 but large values (for large/super pages) that  
the data structure could be much more compact.
Baby steps will get us there.

BTW: not sure what xc_domain_memory_populate_physmap() does, looks  
like it can specify where in PFN space that allocated MFN are placed.

-JX


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