On Thu, May 8, 2014 at 11:12 PM, Alexey Kardashevskiy wrote:
>> There are
>> a couple ways to mitigate this type of situation by using alternative
>> data structures to inform the loop traversal. I don't know if it is
>> worth the effort, though.
>
> Here I lost you :)
If I read the code correctl
On 05/07/2014 11:09 PM, Mike Day wrote:
>
>>
>> for (i = 0; i < ics->nr_irqs; i++) {
>> /* FIXME: filter by server#? */
>> -if (ics->islsi[i]) {
>> +if (ics->irqs[i].flags & XICS_FLAGS_LSI) {
>> resend_lsi(ics, i);
>
> Not part of your patch, but I'm c
On 05/07/2014 08:01 AM, Alexey Kardashevskiy wrote:
The existing interrupt allocation scheme in SPAPR assumes that
interrupts are allocated at the start time, continously and the config
will not change. However, there are cases when this is not going to work
such as:
1. migration - we will have
>
> for (i = 0; i < ics->nr_irqs; i++) {
> /* FIXME: filter by server#? */
> -if (ics->islsi[i]) {
> +if (ics->irqs[i].flags & XICS_FLAGS_LSI) {
> resend_lsi(ics, i);
Not part of your patch, but I'm curious about this FIXME (there's an
identical FIXME
The existing interrupt allocation scheme in SPAPR assumes that
interrupts are allocated at the start time, continously and the config
will not change. However, there are cases when this is not going to work
such as:
1. migration - we will have to have an ability to choose interrupt
numbers for dev
