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

RE: [Xen-devel] PCI MSI questions



>> 2) While pci_restore_msi_state() properly checks the success of
>> msi_map_pirq_to_vector(), pci_restore_msix_state() doesn't. Is this
>> for a reason, or just because the code would get more complex if the
>> error needs to be handled?
>Yes. I do not know what is the proper action. If one of the MSI-X pirq
>failed, should we return? Or unmap those already mapped and return? Or
>continue processing other MSI-X entries?
>Any comments on this? Jan.

I would think this should follow the logic in msix_capabilities_init(), i.e.
unmap what was mapped (and hence leave the device in a semi-
consistent [interrupts non-functional] state).

>> 3) The type parameter of xc_physdev_map_pirq{,_msi}() seems
>> superfluous, or is there any reason why these could be called with the
> respectively reversed types?
>Yes. The type is not useful in current code.
>I am not quite sure about the reason. I think at the beginning of
>submitting the patches, we do not have two seperate wrap functions for
>this hypercall (only xc_physdev_map_pirq). That's where the "type"
>parameter comes. Later, with MSI capabilities owned by Xen, we need pass
>down more information to Xen via this hypercall. Thus the second one was
>born.
>Agree that this may need to be cleaned up.

That is what I suspected. I'll prepare a patch, unless you want to.

Jan


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


 


Rackspace

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