Re: [Qemu-ppc] [PATCH 15/25] spapr: notify the CPU when the XIVE interrupt priority is more privileged

[Cédric Le Goater]

>> +/* Convert a priority number to an Interrupt Pending Buffer (IPB)
>> + * register, which indicates a pending interrupt at the priority
>> + * corresponding to the bit number
>> + */
>> +static uint8_t priority_to_ipb(uint8_t priority)
>> +{
>> +    return priority > XIVE_PRIORITY_MAX ?
>> +        0 : 1 << (XIVE_PRIORITY_MAX - priority);
> 
> Does handling out of bounds values here make sense, or should you just
> assert() they're not passed in?

The priority can be above in the TM_SPC_SET_OS_PENDING command. 

>> +}
>> +
>> +/* Convert an Interrupt Pending Buffer (IPB) register to a Pending
>> + * Interrupt Priority Register (PIPR), which contains the priority of
>> + * the most favored pending notification.
>> + *
>> + * TODO:
>> + *
>> + *   PIPR is clamped to CPPR. So the value in the PIPR is:
>> + *
>> + *     v = leftmost_bit_of(ipb) (or 0xff);
>> + *     pipr = v < cppr ? v : cppr;
>> + *
>> + * Ben says: "which means it's never actually 0xff ... surprise !".
>> + * But, the CPPR can be set to 0xFF ... I am confused ...
> 
> A resolution to this would be nice..

The 'accept' sequence does :

  - store the PIPR in the CPPR
  - reset the pending buffer bit in the IPB
  - recompute the PIPR value from the new IPB
  - drop the exception bit for OS

Typical values are : 

  before  IBP=02 PIPR=06 CPPR=ff NSR=80
   after  IBP=00 PIPR=ff CPPR=06 NSR=00

So today, if the IPB becomes zero, the PIPR is adjusted to 0xFF.

But, if the PIPR is clamped to the CPPR (6), there is a disconnect
between the IBP and the PIPR values. Is that OK ? 

Then, the second effect is that as soon as the OS sets back the CPPR 
to 0xFF, we notify the CPU again and enter a loop. 

I think this is because a test on the EO bit of the NSR is missing 
in the routine setting the CPPR. this bit notifies the presence of 
an exception for the O/S. I will add that. I misunderstood the specs 
on the topic.

C.