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

Re: [Xen-devel] [PATCH] Dont call msi_unmap_pirq() if did not enabled msi



>>> 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


 


Rackspace

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