This patch add MSI support to domain0/domain U. Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com> Signed-off-by: Shan Haitao <haitao.shan@intel.co <<msi_kernel.patch>> m> Best Regards Haitao Shan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> "Shan, Haitao" <haitao.shan@intel.com> 30.04.08 09:25 >>> >This patch add MSI support to domain0/domain U. > >Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com> >Signed-off-by: Shan Haitao <haitao.shan@intel.co ><<msi_kernel.patch>> m>The change to drivers/pci/msi.c looks bogus, not only because the patch adds a drivers/pci/msi-xen.c. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, Jan, I do not want to touch drivers/pci/msi.c. Sorry, this part of code is left in the patch duo to my mistake. The attached is the updated patch. The reason that I add a new file is that I did not find a clean way to use the original msi.c. There is code there managing vectors, which is definitly not needed in dom0. Also I do not want to insert too many "ifdef"s in that file. Do I understand your comments correctly? Best Regards Haitao Shan Jan Beulich wrote:>>>> "Shan, Haitao" <haitao.shan@intel.com> 30.04.08 09:25 >>> >> This patch add MSI support to domain0/domain U. >> >> Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com> >> Signed-off-by: Shan Haitao <haitao.shan@intel.co >> <<msi_kernel.patch>> m> > > The change to drivers/pci/msi.c looks bogus, not only because the > patch adds a drivers/pci/msi-xen.c. > > Jan_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> "Shan, Haitao" <haitao.shan@intel.com> 30.04.08 10:15 >>> >Hi, Jan, >I do not want to touch drivers/pci/msi.c. Sorry, this part of code is >left in the patch duo to my mistake. The attached is the updated patch. >The reason that I add a new file is that I did not find a clean way to >use the original msi.c. There is code there managing vectors, which is >definitly not needed in dom0. Also I do not want to insert too many >"ifdef"s in that file. >Do I understand your comments correctly?Yes, I understand why you created a Xen clone of the original file, and I indeed suspected the change to the original file just being a leftover. Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I tried the latest unstable tree on a NIC which supports both MSI and MSI-X. When the driver was configured to use MSI mode, everything worked fine but when it was configured to use MSI-X, the call to pci_enable_msix succeeded but the interrupt didn''t work. Have these patches been seen to work on an MSI-X device? In msix_capability_init (drivers/pci/msi-xen.c), there''s a loop which unmaps the old pirqs. Shouldn''t there be some similar code in msi_capability_init? I can''t see any reason for the inconsistency between the two functions. Would it be possible to extend this code so that a PV backend driver could map different MSI-X entries on a PCI device into different guests? We already have frontend/backend drivers which allow multiple guests to securely access the PCI memory of a single NIC and would like to extend those drivers to map MSI-X interrupts directly to guests. I still don''t understand enough about the new hypercalls to see how that would work. Cheers, Neil. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, Neil, Please see my comments embedded. 2008/5/13 Neil Turton <nturton@solarflare.com>:> I tried the latest unstable tree on a NIC which supports both MSI and > MSI-X. When the driver was configured to use MSI mode, everything > worked fine but when it was configured to use MSI-X, the call to > pci_enable_msix succeeded but the interrupt didn''t work. Have these > patches been seen to work on an MSI-X device?I have tested the patch using a NIC with both MSI-X and MSX capabilities. I can successfully enable MSI-X for the NIC both in dom0 and in domU. The drivers I used for test is igb from e1000.sourceforge.net. Can you tell me how to reproduce your problem? Maybe there are some pathes that I do not take care of. So that I can fix the problem.> > In msix_capability_init (drivers/pci/msi-xen.c), there''s a loop which > unmaps the old pirqs. Shouldn''t there be some similar code in > msi_capability_init? I can''t see any reason for the inconsistency > between the two functions.Agree. I will add that.> > Would it be possible to extend this code so that a PV backend driver > could map different MSI-X entries on a PCI device into different guests? > We already have frontend/backend drivers which allow multiple guests to > securely access the PCI memory of a single NIC and would like to extend > those drivers to map MSI-X interrupts directly to guests. I > still don''t understand enough about the new hypercalls to see how that > would work.Do you mean your MSI-X capable NIC is owned simultaneously by multi guests? Actually, I have not thought of this usage model. Currently, we rely on pcibackend to provide the owner of the device. Yes, all MSI-X interrupts are mapped to the same domain to which the device belongs. But I think by properly set the dom_id for hypercall PHYSDEVOP_map_pirq, it can cope wth such situations.> > Cheers, Neil. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Haitao Shan wrote:> Can you tell me how to reproduce your problem? Maybe there are some > pathes that I do not take care of. So that I can fix the problem.I''ve fixed it now, thanks.> Do you mean your MSI-X capable NIC is owned simultaneously by multi > guests?Exactly. Do I just call request_irq in the frontend? Cheers, Neil. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
2008/5/14 Neil Turton <nturton@solarflare.com>:> Haitao Shan wrote: >> Can you tell me how to reproduce your problem? Maybe there are some >> pathes that I do not take care of. So that I can fix the problem. > > I''ve fixed it now, thanks.OK. I see your patch. It is my fault to make such a mistake.> >> Do you mean your MSI-X capable NIC is owned simultaneously by multi >> guests? > > Exactly. Do I just call request_irq in the frontend?I do not quite understand. What I mean is call PHYSDEVOP_map_pirq with proper domain_id ( the domain you want Xen to deliver this specific MSI to) in pci backend and tell frontend the pirq number . Then request_irq in the frontend. I think this should work if you want to deliver that MSI to some specific domain.> > Cheers, Neil. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Shan, Haitao
2008-May-15 08:50 UTC
[Xen-devel] [PATCH] Not unmap all MSI-X pirqs when enabling MSI-X
Hi, Keir, This patch made some changes to msix_capability_init for kernel. Originally, all existing MSI-X pirqs of that device are unmapped before mapping the required MSI-X entries. This is actually not right. This function may be called several times, with each time requiring enabling different parts of the device MSI-X entry. Former pirqs should not be unmapped. I made this patch to correct this. Thanks for Turton''s comments on this problem. Signed-off-by: Shan Haitao <Haitao.shan@intel.com> Best Regards Shan Haitao _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Haitao Shan wrote:> I do not quite understand. > What I mean is call PHYSDEVOP_map_pirq with proper domain_id ( the > domain you want Xen to deliver this specific MSI to) in pci backend > and tell frontend the pirq number . Then request_irq in the frontend.That answers my question. Thanks for your help. Cheers, Neil. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel