Re: [Xen-devel] Re: IRQs, move_in_progress, -EBUSY &c

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

Looks like there are other callers of __assign_irq_vector() which also
don't handle the -EBUSY return value, namely
xen/arch/x86/io_apic.c:set_desc_affinity().

Unfortunately, set_desc_affinity() cannot simply loop until it stops
getting -EBUSY, as it is almost always called with irqs disabled -- so
the very IPI which will call the function to make it not busy anymore
is blocked.  And it only returns one value (a cpu mask), and the
function which calls it returns no value at all; so we can's pass the
"loop and retry" up one more level; we'd have to do a ton more code
rewriting to be able to handle retries.

Can we just call the cleanup function directly if we get -EBUSY?

 -George

On Wed, Aug 11, 2010 at 7:18 PM, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
> On 11/08/2010 18:49, "George Dunlap" <George.Dunlap@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
>> wrote:
>>> On 11/08/2010 15:56, "George Dunlap" <George.Dunlap@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/xen-devel
>>>
>>>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel