[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/2 v5] iommu/amd: Fix logic for clearing the IOMMU interrupt bits



>>> On 14.06.13 at 08:27, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>> On 13.06.13 at 18:34, Suravee Suthikulanit <suravee.suthikulpanit@xxxxxxx> 
> wrote:
>> Basically, the only different is this line that only appears in the "Bad" 
>> version.
>> 
>>      (XEN)  MSI     56 vec=28  fixed  edge deassert phys    cpu 
> dest=00000001 mask=0/0/1
>> 
>> "xl debug-key i" also show the following information
>> 
>>      (XEN)    IRQ:  56 affinity:1 vec:28 type=AMD-IOMMU-MSI   
>> status=00000000 
> mapped, unbound
> 
> There are several questionable things here:
> - the interrupt being of "deassert" kind
> - destination mode being physical (while all others are logical)
> - the interrupt being unbound (i.e. there's no action associated
>   with it, and hence no handler would ever get called)

And I think I see now at least part of what's missing: Neither
msi_compose_msg() nor write_msi_msg() get (indirectly) called
from set_iommu_interrupt_handler(). Which was that (wrong)
way already before said c/s, but got masked by
iommu_msi_set_affinity() doing a full setup rather than
incremental modification as set_msi_affinity() does. In order to
fix this reasonably cleanly I'd like to do a little bit of code
re-structuring, so it'll be more than a couple of minutes until I
could send you a patch.

Plus that - to me - doesn't explain the NULL action pointer yet.
But wait - was that log perhaps taken with the tree rewound to
said broken commit? I.e. missing commit d739470b? That would
explain it.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.