[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



Yes, we need keep the msi disable/enable information for frontend also, now it 
is only kept in backend side. It is a issue introduced by us from beginning.

I will cook a patch after I get an environment to test.

--jyh

Jan Beulich wrote:
>>>> 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®.