[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xen-ppc-devel
Subject:    Re: [XenPPC] [PATCH 1/3] libxc: add start_info_t node to devtree
From:       Jimi Xenidis <jimix () watson ! ibm ! com>
Date:       2007-01-25 21:24:57
Message-ID: 224E86D7-906E-4560-9135-D4CB8357D3B9 () watson ! ibm ! com
[Download RAW message or body]


On Jan 25, 2007, at 3:51 PM, Ryan Harper wrote:

> * Jimi Xenidis <jimix@watson.ibm.com> [2007-01-25 14:40]:
>>>> Since you later look for the console_mfn and store_mfn later, it
>>>> would be better in the caller and pass then in.
>>>> FYI: It is xend that decides where store and console go.  
>>>> shared_info
>>>> is a hypervisor contract so you can continue to calculate it  
>>>> here if
>>>> you want.
>>>>
>>>> Also the devtree should not contain MFNs for frame numbers of any
>>>> kind, simply addresses.
>>>
>>> I don't follow.  the start_info_t structure explicitly wants an
>>> mfn, how
>>> else am I suppose to fill that value out in linux?
>>
>> they are MFNs on x86, in PPC they are domain physical addresses.
>
> Maybe I've just got it named funny, I don't know.  And I'm still
> confused as to what you want me to put in?

I'm suggesting that we do not use a frame number in the devtree but  
use the address that the frame number represents.
On PPC, MFN is a misnomer, this value is not an MFN but a domain PFN  
(that is the page belongs to the domain), its just a bad name for us  
because the structure is for x86.  Later (on PPC) we convert the  
domain PFN to and phys addr.

>
> The value that I put in start_info->console.domU.mfn is:
>
> ((rma_pages << 12) - (2*PAGE_SIZE)) >> PAGE_SHIFT
>
> where rma_pages = (1 << 26) >> PAGE_SHIFT
>
> the resulting value is 0x3ffe.  Is this value correct and I just  
> have an
> incorrect name for it (mfn)?
yes

> Am I getting lucky? I've tested the
> patches and dom0 and domU boot.

Not luck, we just preserved a crappy name for a crappy struct that in  
PPC land will dissapear.

>
>>
>>>
>>>>
>>>>> {
>>>>>    struct boot_param_header *bph = NULL;
>>>>>    uint64_t val[2];
>>>>>    uint32_t val32[2];
>>>>>    unsigned long remaining;
>>>>> -    unsigned long rma_reserve = 4 * PAGE_SIZE;
>>>>> +    unsigned long rma_reserve = 3 * PAGE_SIZE;
>>>>
>>>> base this on MIN(store, console)
>>>
>>> Why? Don't we always have a store and a console page?
>>
>> yes we do, but they could be in any order, all you are trying to do
>> is make sure the pages are in the reserve map.  Another possibility
>> is you could not assume contiguity and create a reservation entry for
>> each of the three pages.
>
> I don't understand what is wrong with the above.  We are reserving the
> last X pages of the RMA.  1 for shared_info, 1 for console, one for
> store.  I futher don't understand what the value MIN(store,console)
> gives me.  Sorry for being dense here.

I know it is confusing, thats why it is so important we get it right.
First, I suggested that you pass in these addresses.
Once they are passed in, this function has no idea which one has the  
lowest address.
There is nothing from stoping from changing the order of these 2  
pages, as long as both sides agree.
-JX



_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[prev in list] [next in list] [prev in thread] [next in thread]