Jan Beulich wrote:
>>>> "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx> 22.10.09 09:11 >>>
>> Jan Beulich wrote:
>>>>>> "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx> 20.10.09 09:51 >>>
>>>> Attached two patches should fix the issues. For the issue which
>>>> complains "(XEN) do_IRQ: 1.187 No irq handler for vector (irq
>>>> -1),", I root-caused it. Currenlty, when programs MSI address &
>>>> data, Xen doesn't perform the mask/unmask logic to avoid
>>>> inconsistent interrupt genernation. In this case, according to
>>>> spec, the interrupt generation behavior is undfined,
>>>> and device may generate MSI interrupts with the expected vector and
>>>> incorrect destination ID, so leads to the issue. The attached two
>>>> patches should address it.
>>>
>>> What about the case of MSI not having a mask bit? Shouldn't movement
>>> (i.e. vector or affinity changes) be disallowed for non-maskable
>>> ones?
>>
>> IRQ migration shouldn't depend on the interrupt status(mask/unmask),
>> and hyperviosr can handle non-masked irq during the migration.
>
> Hmm, then I don't understand which case your patch was a fix for: I
> understood that it addresses an issue when the affinity of an
> interrupt gets changed (requiring a re-write of the address/data
> pair). If the hypervisor can deal with it without masking, then why
> did you add it?
Hmm, sorry, seems I misunderstood your question. If the msi doesn't support
mask bit(clearing MSI enable bit doesn't help in this case), the issue may
still exist. Just checked Linux side, seems it doesn't perform mask operation
when program MSI, but don't know why Linux hasn't such issues. Actaully, we do
see inconsisten interrupt message from the device without this patch, and after
applying the patch, the issue is gone. May need further investigation why
Linux doesn't need the mask operation.
Xiantao
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home