[Skiboot] [PATCH v2 14/17] xive/p9: introduce NVT_SHIFT

[Cédric Le Goater]

On 24/09/2019 08:31, Oliver O'Halloran wrote:
> On Thu, 2019-09-12 at 19:22 +0200, Cédric Le Goater wrote:
>> This defines the size of our VP space.
>>
>> Signed-off-by: Cédric Le Goater <clg at kaod.org>
>> ---
>>  hw/xive.c | 7 +++++--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/xive.c b/hw/xive.c
>> index 6572a45f57be..8c92a612a5fa 100644
>> --- a/hw/xive.c
>> +++ b/hw/xive.c
>> @@ -189,7 +189,10 @@
>>   *
>>   * XXX Adjust that based on BAR value ?
>>   */
>> -#define MAX_VP_ORDER		19	/* 512k */
>> +
> 
>> +#define NVT_SHIFT		19	/* in sync with EQ_W6_NVT_INDEX */
> 
> What is the being kept in sync with? The width of the "Base NVT Block
> Offset (Index)" field in the XIVE spec? 

yes.  

It's in direct relation with the XIVE END field : 

	uint32_t	w6;
#define EQ_W6_FORMAT_BIT	PPC_BIT32(8)
#define EQ_W6_NVT_BLOCK		PPC_BITMASK32(9,12)
#define EQ_W6_NVT_INDEX		PPC_BITMASK32(13,31)

and the W2 of the TIMA (cam values), which is the reason behind the change
in opal_xive_get_vp_info()

> Is that a HW specific value or
> is there some software configuration that I'm not understanding here?

It's a HW limit.

> 
>> +#define MAX_VP_ORDER		NVT_SHIFT /* 512k */
>>  #define MAX_VP_COUNT		(1ul << MAX_VP_ORDER)
>>  #define VP_PER_PAGE		(0x10000 / 64) // Use sizeof ?
>>  #define IND_VP_TABLE_SIZE	((MAX_VP_COUNT / VP_PER_PAGE) * 8)
>> @@ -4042,7 +4045,7 @@ static int64_t opal_xive_get_vp_info(uint64_t vp_id,
>>  	}
>>  
>>  	if (out_cam_value)
>> -		*out_cam_value = (blk << 19) | idx;
>> +		*out_cam_value = (blk << NVT_SHIFT) | idx;
>>  
>>  	if (out_report_cl_pair) {
>>  		*out_report_cl_pair = ((uint64_t)(vp->w6 & 0x0fffffff)) << 32;
>