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] [PATCH] Dont call msi_unmap_pirq() if did not enabled ms

>>> Joe Jin <joe.jin@xxxxxxxxxx> 17.11.09 11:14 >>>
>On 2009-11-17 07:59, Jan Beulich wrote:
>> >>> Joe Jin <joe.jin@xxxxxxxxxx> 17.11.09 01:19 >>>
>> >--- a/drivers/pci/msi-xen.c Fri Oct 23 10:07:22 2009 +0100
>> >+++ b/drivers/pci/msi-xen.c Tue Nov 17 08:16:42 2009 +0800
>> >@@ -673,6 +673,12 @@
>> >    if (!pos)
>> >            return;
>> > 
>> >+   if (!(dev->msi_enabled)) {
>> >+           printk(KERN_INFO "PCI: %s: Device did not enabled MSI.\n",
>> >+                  pci_name(dev));
>> >+           return;
>> >+   }
>> >+ 
>> >    pirq = dev->irq;
>> >    /* Restore dev->irq to its default pin-assertion vector */
>> >    dev->irq = msi_dev_entry->default_irq;
>> 
>> But shouldn't this happen before the CONFIG_XEN_PCIDEV_FRONTEND
>> conditional block? This one also calls evtchn_map_pirq(..., 0), i.e. would
>> also result in the storing of no_irq_chip.
>
>However when irq_desc[irq]->chip set to no_irq_chip, if any device try to 
>request
>the @irq will failed and return -ENOSYS via request_irq()->setup_irq().
>
>According to codes, only when CONFIG_XEN_PCIDEV_FRONTEND and 
>!is_initial_xendomain(),
>it will called evtchn_map_pirq(), meant only guest OS may call it, Dom0 will 
>not.
>But during pci_enable_msi(), it never set the flag(dev->msi_enabled), I'm not 
>sure if
>Guest OS will set it if enabled msi, any suggestion?

Hmm, indeed - I'm not sure then. Clarification from the Intel guys having
originally written this code would be very desirable here; adding them to
Cc.

Jan


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