Re: Re: IRQs, move_in_progress, -EBUSY &c

[Keir Fraser <keir.fraser@eu.citrix.com>]

On 11/08/2010 18:49, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:

> Seems to work about 50/50.
> 
> Attached is a log of a successful boot (exile.008.log), and a failed
> boot (exile.009.log).  Suspicious things about the failed case:  the
> usb code starts to initialize before the SATA code finishes
> initializing, and complains that "Controller is probably using the
> wrong IRQ".

Cc'ing Xiantao Zhang, who submitted the per-CPU IDT patches. Perhaps he has
some ideas how to fix this. The only other simple thing I can think to try
is to modify my patch so that it loops in the hypervisor. Something like:
 do{ ret = mp_register_gsi(...}; } while (ret == -EBUSY);
Since the condition being EBUSYed on is cleared in hardirq context, that
should be safe.

Apart from that, it is possible that greater surgery is neede don the
per-CPU IDT and IRQ migration logic, and I think we need Xiantao's help for
that.

 -- Keir

> Keir: the machine in question (as you may have guessed) is exile; let
> me know if you want to grab it and use it directly.
> 
>  -George
> 
> On Wed, Aug 11, 2010 at 4:59 PM, Keir Fraser <keir.fraser@eu.citrix.com>
> wrote:
>> On 11/08/2010 15:56, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:
>> 
>>> However, it seems that moving IRQs is not handled properly.  Either
>>> the pvops kernel should retry if it gets an -EBUSY, or the hypercall
>>> should not fail, but wait until it can return success.
>> 
>> Can you try the attached patch?
>> 
>>  Thanks,
>>  Keir
>> 
>>> I discovered all this by adding debug statements to the IRQ path; the
>>> patch is attached, if anyone else wants to use it.
>>> 
>>>  -George
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>> 
>>