[TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

[TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

[Jimi Xenidis]

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

Re: [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

[Keir Fraser]

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

Re: [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

[Jimi Xenidis]

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

Re: [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

[Keir Fraser]

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

Re: [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

[Jimi Xenidis]

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

Re: [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

[Keir Fraser]

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

Re: [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

[Gerd Hoffmann]

  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

Re: [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

[Keir Fraser]

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

Re: [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

[Gerd Hoffmann]

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

Re: [Xen-devel] [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

[Jimi Xenidis]

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

Re: [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

[Gerd Hoffmann]

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

Re: [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

[Keir Fraser]

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

Re: [Xen-devel] [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

[Jimi Xenidis]

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