[Skiboot] [PATCH v2 15/17] xive/p9: remove XIVE_INT_SAFETY_GAP

[Cédric Le Goater]

On 24/09/2019 08:40, Oliver O'Halloran wrote:
> On Thu, 2019-09-12 at 19:22 +0200, Cédric Le Goater wrote:
>> It was used by bringup code only.
>>
>> Signed-off-by: Cédric Le Goater <clg at kaod.org>
>> ---
>>  hw/xive.c | 9 ++++-----
>>  1 file changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/hw/xive.c b/hw/xive.c
>> index 8c92a612a5fa..b43357296896 100644
>> --- a/hw/xive.c
>> +++ b/hw/xive.c
>> @@ -35,7 +35,6 @@
>>  #define XIVE_EXTRA_CHECK_INIT_CACHE
>>  #undef XIVE_CHECK_MISROUTED_IPI
>>  #define XIVE_CHECK_LOCKS
>> -#define XIVE_INT_SAFETY_GAP 0x1000
>>  #else
>>  #undef  XIVE_DEBUG_DUPLICATES
>>  #undef  XIVE_PERCPU_LOG
>> @@ -43,7 +42,6 @@
>>  #undef  XIVE_EXTRA_CHECK_INIT_CACHE
>>  #undef  XIVE_CHECK_MISROUTED_IPI
>>  #undef  XIVE_CHECK_LOCKS
>> -#define XIVE_INT_SAFETY_GAP 0x10
>>  #endif
>>  
>>  /*
>> @@ -149,6 +147,7 @@
>>   * overlap the HW interrupts.
>>   */
>>  #define MAX_INT_ENTRIES		(1 * 1024 * 1024)
>> +#define XIVE_INT_FIRST		0x10
> 
>>  /* Corresponding direct table sizes */
>>  #define SBE_SIZE	(MAX_INT_ENTRIES / 4)
>> @@ -2584,8 +2583,8 @@ static struct xive *init_one_xive(struct dt_node *np)
>>  	/* Make sure we never hand out "2" as it's reserved for XICS emulation
>>  	 * IPI returns. Generally start handing out at 0x10
> 
> Why do we start from 0x10? 

the number of preallocated irqs by Linux is :

 #define NR_IRQS_LEGACY		NUM_ISA_INTERRUPTS

The first logical number we can get is 0x10 and it is assigned to the 
CPU IPIs. 

> The commit message for 726753e781e8 ("xive:
> Increase the interrupt "gap" on debug builds") says that INT_SAFETY_GAP
> is 0x10000 for debug builds so the int numbers don't overlap with linux
> interrupt numbers, which seems reasonable enough, but there's nothing
> on where 0x10 came from. Is it just to stop us handing out a HWIRQ
> number of zero?

The XIVE interrupt controller enqueues logical numbers in the event queue 
assigned to the source and the OS, or the XICS emulation in OPAL or the 
KVM XICS-on-XIVE device, dequeues. 

I think that using HW interrupt numbers in a high range was one way to 
check that we were not mixing HW and logical interrupt numbers in the 
event queues.

C.


> 
>>  	 */
>> -	if (x->int_ipi_top < XIVE_INT_SAFETY_GAP)
>> -		x->int_ipi_top = XIVE_INT_SAFETY_GAP;
>> +	if (x->int_ipi_top < XIVE_INT_FIRST)
>> +		x->int_ipi_top = XIVE_INT_FIRST;
>>  
>>  	/* Allocate a few bitmaps */
>>  	x->eq_map = zalloc(BITMAP_BYTES(MAX_EQ_COUNT >> 3));
>> @@ -3484,7 +3483,7 @@ static int64_t opal_xive_get_xirr(uint32_t *out_xirr, bool just_poll)
>>  		/* XXX Use "p" to select queue */
>>  		val = xive_read_eq(xs, just_poll);
>>  
>> -		if (val && val < XIVE_INT_SAFETY_GAP)
>> +		if (val && val < XIVE_INT_FIRST)
>>  			xive_cpu_err(c, "Bogus interrupt 0x%x received !\n", val);
>>  
>>  		/* Convert to magic IPI if needed */
>