WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

<Prev in Thread] Current Thread [Next in Thread>