Re: [Xen-devel] Xen4.2 S3 regression?

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.08.12 at 20:37, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 23/08/12 19:03, Ben Guthro wrote:
>> I did some more bisecting here, and I came up with another changeset
>> that seems to be problematic, Re: IRQs
>>
>> After bisecting the problem discussed earlier in this thread to the
>> changeset below,
>> http://xenbits.xen.org/hg/xen-unstable.hg/rev/0695a5cdcb42 
>>
>>
>> I worked past that issue by the following hack:
>>
>> --- a/xen/common/event_channel.c
>> +++ b/xen/common/event_channel.c
>> @@ -1103,7 +1103,7 @@ void evtchn_destroy_final(struct domain *d)
>>  void evtchn_move_pirqs(struct vcpu *v)
>>  {
>>      struct domain *d = v->domain;
>> -    const cpumask_t *mask = cpumask_of(v->processor);
>> +    //const cpumask_t *mask = cpumask_of(v->processor);
>>      unsigned int port;
>>      struct evtchn *chn;
>>
>> @@ -1111,7 +1111,9 @@ void evtchn_move_pirqs(struct vcpu *v)
>>      for ( port = v->pirq_evtchn_head; port; port = chn->u.pirq.next_port )
>>      {
>>          chn = evtchn_from_port(d, port);
>> +#if 0
>>          pirq_set_affinity(d, chn->u.pirq.irq, mask);
>> +#endif
>>      }
>>      spin_unlock(&d->event_lock);
>>  }
>>
>>
>> This seemed to work for this rather old changeset, but it was not
>> sufficient to fix it against the 4.1, or unstable trees.
>>
>> I further bisected, in combination with this hack, and found the
>> following changeset to also be problematic:
>>
>> http://xenbits.xen.org/hg/xen-unstable.hg/rev/c2cb776a5365 
>>
>>
>> That is, before this change I could resume reliably (with the hack
>> above) - and after I could not.
>> This was surprising to me, as this change also looks rather innocuous.
> 
> And by the looks of that changeset, the logic in fixup_irqs() in irq.c
> was changed.
> 
> Jan: The commit message says "simplify operations [in] a few cases". 
> Was the change in fixup_irqs() deliberate?

Yes, it was: There's no need to break/adjust the affinity if it
continues to be a subset of cpu_online_map (i.e. there's no
need for the to match exactly). A similar change was also done
to Linux'es fixup_irqs() later one, without any problems that I'm
aware of.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel